對于運維來(lái)說(shuō)，對數據庫模式進(jìn)行更新，是許多非常困難的任務(wù)之一。將數據庫模式與其他更新一起進(jìn)行同步，有幾種常見(jiàn)的情景:部署、快速開(kāi)發(fā)、通過(guò)修改索引和其他結構優(yōu)化性能。假如模式更新是一種阻塞操作(MYSQL中通常就是這樣的)，這就真的成問(wèn)題了。



將表做得小一點(diǎn)是有很大好處的。存檔或刪除數據是保持小表的好方法，但還有其他方法，例如，假如應用是分片架構，則將每個(gè)分片做得足夠小，從而使得每個(gè)表都不會(huì )變得很大。也可以將數據分到不同的表中，如對于基于日期的數據，每天都創(chuàng )建一個(gè)新表。這里的大多數建議都是比較極端的，并不推薦到處應用，但假如加上一點(diǎn)創(chuàng )造性的話(huà)，則可以走得更遠一點(diǎn)。

INNODBI的新版本(稱(chēng)為 INNODB插件)，以及Xtradb，提供在線(xiàn)增加或刪除索引的能力，而且速度很快。這一點(diǎn)確實(shí)很好。我仍然記得，第一次計算索引更新需要停機多長(cháng)時(shí)間的情景:客戶(hù)給了我一個(gè)小時(shí)，然后運行更新索引的命令，僅僅花了30秒鐘，而我記得他們用的是INNODB插件。假如你還沒(méi)有用過(guò)的話(huà)，我想INNODB插件版本(或 XTRADB)是一次相當引人注目的升級。

如果表不是足夠小，則這些類(lèi)型的操作都是不可能的。這個(gè)時(shí)候，就需要另想辦法。通過(guò)創(chuàng )建一個(gè)有著(zhù)所需結構的“影子表”，借助于外部工具，在最后時(shí)刻對表進(jìn)行交換與重命名，雖然理論上可行，我仍然不認為這樣做對每種情形都是可行的解決方案。所以，仍然有大量的情況，其中，交換服務(wù)器都是首選的方案。

一般的想法是設置主一主復制對，當然其中只有一臺服務(wù)器可寫(xiě)。在只讀服務(wù)器上執行更新，但不要復制到可寫(xiě)服務(wù)器上?？梢酝ㄟ^(guò)禁止將更新寫(xiě)入日志，或在可寫(xiě)服務(wù)器上停止復制過(guò)程來(lái)實(shí)現。更新一旦完成，則用正常方式使應用程序實(shí)現失效轉移，這樣，讀者和寫(xiě)者就實(shí)現了角色變換。然后在另一臺網(wǎng)站建設服務(wù)器上重復執行更新一一或許只需要重啟復制過(guò)程。使用這種方式，就實(shí)現了對應用程序隱含宕機時(shí)間的目的。