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

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

當(dāng)前名稱：嘗試在線模式修改網(wǎng)站數(shù)據(jù)庫
新聞來源：http://www.aaarwkj.com/news8/143658.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供微信公眾號、建站公司、網(wǎng)頁設(shè)計公司、用戶體驗、品牌網(wǎng)站建設(shè)、云服務(wù)器

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)