將表做得小一點是有很大好處的。存檔或刪除數(shù)據(jù)是保持小表的好方法,但還有其他方法,例如,假如應用是分片架構,則將每個分片做得足夠小,從而使得每個表都不會變得很大。也可以將數(shù)據(jù)分到不同的表中,如對于基于日期的數(shù)據(jù),每天都創(chuàng)建一個新表。這里的大多數(shù)建議都是比較極端的,并不推薦到處應用,但假如加上一點創(chuàng)造性的話,則可以走得更遠一點。
INNODBI的新版本(稱為 INNODB插件),以及Xtradb,提供在線增加或刪除索引的能力,而且速度很快。這一點確實很好。我仍然記得,第一次計算索引更新需要停機多長時間的情景:客戶給了我一個小時,然后運行更新索引的命令,僅僅花了30秒鐘,而我記得他們用的是INNODB插件。假如你還沒有用過的話,我想INNODB插件版本(或 XTRADB)是一次相當引人注目的升級。
如果表不是足夠小,則這些類型的操作都是不可能的。這個時候,就需要另想辦法。通過創(chuàng)建一個有著所需結構的“影子表”,借助于外部工具,在最后時刻對表進行交換與重命名,雖然理論上可行,我仍然不認為這樣做對每種情形都是可行的解決方案。所以,仍然有大量的情況,其中,交換服務器都是首選的方案。
一般的想法是設置主一主復制對,當然其中只有一臺服務器可寫。在只讀服務器上執(zhí)行更新,但不要復制到可寫服務器上。可以通過禁止將更新寫入日志,或在可寫服務器上停止復制過程來實現(xiàn)。更新一旦完成,則用正常方式使應用程序?qū)崿F(xiàn)失效轉(zhuǎn)移,這樣,讀者和寫者就實現(xiàn)了角色變換。然后在另一臺網(wǎng)站建設服務器上重復執(zhí)行更新一一或許只需要重啟復制過程。使用這種方式,就實現(xiàn)了對應用程序隱含宕機時間的目的。
本文地址:http://knowyourextract.com//article/3322.html