作者 |RIGAS
譯者 |王強
策劃 |萬佳
在這篇博文中，我們會介紹如何在零停機時間的前提下，使用 將 數(shù)據庫遷移到一個新實例上。我們將介紹如何避免常見的陷阱，比如數(shù)據丟失、性能下降和數(shù)據完整性故障等。我們已成功使用這一流程將我們的 數(shù)據庫從 9.5 版遷移到 RDS 上的 12.5 版，但該流程不只適用于 RDS，也不依賴 AWS 獨有的任何內容。這種遷移策略應該能適用于任何自托管或托管的 。
分 析
在本文中，我們將討論將多個 Web 應用程序（如微服務）從一個數(shù)據庫遷移到另一個的過程。現(xiàn)代軟件架構由多個應用程序（或微服務）組成，而每個應用程序都有多個運行實例以增強擴展性。為了將你的應用程序移動到新的數(shù)據庫，你必須首先確保兩個數(shù)據庫中的數(shù)據是同步的，并在任何給定時間點保持同步，否則你的客戶端遲早會丟失數(shù)據，甚至陷入無效狀態(tài)。
一個簡單的解決方案是停止舊數(shù)據庫的寫入操作，獲取快照，將其恢復到新的數(shù)據庫，然后在新數(shù)據庫中恢復操作。這種方案需要的停機時間太久，不適合生產環(huán)境。我們提到這一點只是為了做參考，因為這是確保你不會丟失任何數(shù)據的最簡單方法，但用它的話，你可能會失去一些客戶。
更現(xiàn)實的方法是在兩個數(shù)據庫之間設置一個近乎實時的雙向復制，這樣在理想情況下，應用程序可以同時向兩者讀取和寫入，而不會注意到任何差異。你可以用這種方法一次一個實例地逐步移動你的應用程序，過程中不會停機，且不會影響用戶。
由于我們希望應用程序能寫入兩個數(shù)據庫，我們需要進行多主復制（multi- ）。在谷歌上搜索“ 中的多主復制”可以找到大量解決方案，每種方案都有自己需要注意的優(yōu)缺點。
我們決定繼續(xù)使用 ，因為它開源、速度快，并且提供了簡單的監(jiān)控和沖突解決機制。
的工作機制
充當兩個 實例之間的中間人。你可以讓 在你喜歡的任何機器上運行，只要它可以訪問源數(shù)據庫和目標數(shù)據庫即可。安裝并設置多主復制后， 將為你選擇復制的所有表添加一些額外的觸發(fā)器。
你運行 的實例在本地使用一個單獨的 數(shù)據庫以保存同步狀態(tài)，這樣你就可以隨意暫停和重啟同步過程。當發(fā)生更改時，觸發(fā)器會將所有受影響的主鍵添加到 實例的 中的“delta”表，另一個觸發(fā)器將“啟動（kick）”同步。每次同步被啟動時， 將對比所有主表中每個表的受影響行并選擇一個獲勝者，然后將更改同步到其余數(shù)據庫。選擇獲勝者并不簡單，此時可能會發(fā)生沖突。
小心漂移
一些在線指南建議，使用 的正確方法是獲取源數(shù)據庫的快照，將其恢復到新的數(shù)據庫，然后啟動一個多主 同步。不要那樣做！
如果這樣做，你將丟失與當前數(shù)據庫大小和寫入流量成正比的數(shù)據。這是因為獲取快照并恢復它需要大量時間。在這段時間里，源數(shù)據庫將因為數(shù)據寫入而開始漂移，并且這種漂移也必須同步以確保兩個主數(shù)據庫包含相同的數(shù)據。這里的問題是人們相信 會做某種回填，但事實證明它在這項任務上不可靠，并且可能無法同步大的漂移。你自然可以使用跨數(shù)據庫對比數(shù)據的工具，確保消除偏差；但如果數(shù)據集很大，這樣做會浪費大量時間，而恰恰我們追求的就是零停機時間。
此外，如果復制延遲足夠大，正在進行的同步可能會被誤報為漂移。
如何同步漂移
你可以啟動 同步，并使用=0標志告訴它在本地數(shù)據庫中緩存所有漂移。不幸的是，雖然這個選項很關鍵，但它沒有文檔支持！這一步很關鍵，據我們所知唯一明確的參考資料出現(xiàn)在 David E. 的這篇優(yōu)秀博文中。
注意 =0。這個標志確保了在記錄增量時，它們不會被復制到任何地方，直到我們讓 這樣做為止。
使用這個標志，你就可以在本地緩存 實例中的增量，為你騰出了足夠的時間來準備新數(shù)據庫。這是非常關鍵的，尤其是對于大漂移更是如此。
如何引導新數(shù)據庫
這里有兩個選項。你可以從第一個數(shù)據庫中獲取全包快照并將其恢復到新實例，或者你可以從一個新的空數(shù)據庫開始，然后分別傳輸用戶、模式和數(shù)據（按這個順序）。我們推薦后一種方法。原因是在對兩個解決方案進行基準測試對比后，第二個的結果更干凈。我們可以從頭開始關閉舊用戶帳戶和臨時表并細化用戶權限。
如果你使用的是 AWS RDS，推薦的這個方案也會更快。獲取快照可能需要幾分鐘時間，具體取決于你的數(shù)據庫大小。
此外，如果你像我們一樣從未加密的服務器遷移到使用靜態(tài)加密的服務器，你需要獲取快照、加密快照，然后將其還原到新的 RDS 實例。這樣做用的時間更久，而最小化遷移時間是我們的一個關鍵目標。
選擇性同步
在開始 同步前，你需要正確配置它。你需要指定兩個數(shù)據庫、它們的類型（主 / 副本），還有指定數(shù)據庫的哪些部分應包含在同步中。你可以從一個模式（）中批量添加所有表，數(shù)據庫有很多表的時候這個辦法非常有用。
無法在沒有主鍵（PK）的情況下同步表，這很正常，因為那種情況下它無法區(qū)分唯一條目。我們不得不在流程中排除一些表，這些表充當各種表遷移的緩存并且不包含 PK。一些未使用的表也被排除在外，因此我們沒有將未使用的數(shù)據傳輸?shù)叫聰?shù)據庫。在 中很容易完成上述操作：添加所有表后，你可以移除要排除的表。
遷移用戶
不會遷移 用戶，你需要手動轉移你的用戶帳戶。我們?yōu)榇司帉懥艘粋€腳本。這個腳本會到新數(shù)據庫，使用從配置服務器檢索到的密碼創(chuàng)建新用戶，然后設置他們的權限。盡管你可能不會將數(shù)據存儲為代碼，但將用戶保存為代碼是一種很好的做法，這樣在發(fā)生災難時就能夠恢復它們了。
遷移模式和數(shù)據
你可以使用 及其/工具來傳輸你的模式和數(shù)據。這個步驟很簡單，但有一個要點。請記住，此時我們已經啟動并運行了 來記錄漂移，因此在目標服務器上恢復數(shù)據將被解釋為同步回源數(shù)據庫的更改。這就是為什么我們需要啟用 role=標志，使用一個副本會話將數(shù)據恢復到目標 數(shù)據庫。在我們啟動你的持續(xù)同步之前，我們需要禁用它。
沖 突
高可用性是零停機遷移的先決條件，它通常要求每個應用程序有多個正在運行的實例。一般來說，每個實例都應該在重新啟動之前排空，因此無法在完全相同的時間點將所有實例切換到新數(shù)據庫。所以總會有一個關鍵的——或短或長的——時間窗口，在這個窗口中同一個應用程序將同時寫入兩個數(shù)據庫，并且在這段時間內可能會發(fā)生沖突。
沖突很少見，因為它們需要在兩個數(shù)據庫中進行兩次寫入，然后 才能復制這兩個記錄。復制時間接近于零終結者2文件格式錯誤，你可能根本不會遇到任何沖突，但這種遷移發(fā)生在關鍵的生產環(huán)境中，因此不能忽略它們。
想象一下，兩個客戶試圖在同一天預訂同一所房子。如果他們同時嘗試這樣做并且每個用戶都指向不同的數(shù)據庫，則可能會發(fā)生沖突。 有一個 沖突解決機制，提供了兩個基本選項：要么讓 自動處理沖突（默認選項），要么中止同步并手動解決它們。這是遷移過程中最關鍵的部分，我們進一步分析一下。
如果你的表有一個自動遞增的 ID 作為主鍵， 會自動從相應的序列中選擇下一個 ID。 也會同步序列。假設在上面的示例中，你有一個帶有自動遞增 ID 作為 PK 的 表，并且最新的記錄 ID 是 42。這里會發(fā)生并發(fā)插入，并且在兩個數(shù)據庫中創(chuàng)建兩條不同的記錄，它們都以 43 作為 PK，但數(shù)據不同。如果你讓 處理沖突，它會只保留最新的一個并刪除另一個。最后你會丟失一個對你的客戶來說似乎是成功的預訂。你的數(shù)據庫仍處于有效狀態(tài)，但你會丟失數(shù)據，還沒法恢復。這是一個死胡同！
在討論解決方案之前，讓我們考慮另一種情況。假設你的表使用 UUID 作為 PK。回放上面的場景，并發(fā)預訂將在兩個數(shù)據庫中創(chuàng)建兩個不同的記錄，并具有兩個不同的 PK。這次沒有發(fā)生沖突。 將成功同步兩個數(shù)據庫中的兩條記錄，但從業(yè)務角度來看你的數(shù)據仍然無效，因為你不能兩次預訂同一所房子。因此這里很明顯，從業(yè)務角度來看數(shù)據庫有效性并不能保證你的數(shù)據有效。你需要小心對待沖突的處理方式，以免你的客戶遇到問題。
支持自定義解析策略。你可以根據業(yè)務需求制定自己的策略，但這很快就會變得過于復雜和耗時。另一種方法是創(chuàng)建你自己的工具來檢測和解決遷移期間的數(shù)據違規(guī)問題。這并非易事：它必須根據數(shù)據的復雜程度來做設計，并且可能需要大量開發(fā)工作。
我們的解決方案是在開始遷移之前滿足兩個條件，來徹底避免沖突。
首先，我們努力最小化數(shù)據庫之間的轉換時間，以最小化沖突概率。為了做到這一點，我們會修改應用的重配置腳本以指向新的數(shù)據庫，一次一個實例，但所有的不同應用會并行操作。
第二步最關鍵，就在我們開始將應用切換到新數(shù)據庫之前，我們撤銷了舊數(shù)據庫中應用用戶的寫入權限。通過這種方式，我們可以徹底避免沖突，但代價是一定比例的數(shù)據庫寫入失敗時間。這當然需要你的應用程序能夠優(yōu)雅地處理失敗的數(shù)據庫寫入。你的應用程序執(zhí)行此操作時應該能獨立于任何數(shù)據庫遷移活動，因為這對于生產環(huán)境來說至關重要。
下面就是最終的遷移計劃：
實 現(xiàn)
本節(jié)將展示我們遵循的步驟，以及每個步驟對應的腳本。我們已將代碼上傳到這個 存儲庫，下文會對代碼做具體拆解分析。
準備
啟動一個新實例（在我們的例子中是 EC2）。該指令假設你運行的是 操作系統(tǒng)。
運行.sh來安裝
編輯vars.sh以設置你的數(shù)據庫和 角色密碼
在 shell 中導出上述變量：$.sh
（可選）如果你之前在源數(shù)據庫中使用過 ，你可能需要運行 .sh 來清除舊觸發(fā)器。在運行之前，請查看我們根據我們的數(shù)據庫生成的 .。你需要在那里列出你所有的表。
你需要手動運行$ 才能完成本地 安裝。
遷移
仔細看看 .sh 腳本。在這里，你需要編輯腳本以匹配你的遷移方案。你需要為 對象定義描述性名稱并指定排除的表或略過此選項。在你了解腳本的作用后可以繼續(xù)運行它。該腳本執(zhí)行以下操作：
設置.文件和一條 別名命令，以避免在此過程中要求你輸入密碼的交互式提示中斷流程
配置 數(shù)據庫、herds、數(shù)據庫組和同步。如果你需要進一步了解 對象類型，他們的文檔頁面中有一個 列表。
在新的 主機中初始化一個空數(shù)據庫并運行此腳本創(chuàng)建用戶。你需要編輯這個腳本來指定你的角色。密碼由我們之前獲取的vars.sh文件檢索。
這一步只傳輸數(shù)據庫模式，使用并將其傳輸?shù)叫轮鳈C
使用本地緩存啟動 同步
以壓縮格式傳輸數(shù)據庫數(shù)據。當數(shù)據傳輸和漂移開始堆積時， 會將其保存在本地并在 標志更改值后重播
重置 標志的值以停止本地緩存，然后重新加載配置以讓同步遵守新值
啟動多主同步
現(xiàn)在持續(xù)同步已就位，是時候開始在新數(shù)據庫中移動應用了。對我們來說，我們是更改配置服務器中的應用程序參數(shù)然后一一重新部署來完成這一步的。在這一步中，我們需要將舊數(shù)據庫中的用戶權限設置為只讀。一旦我們應用的第一個實例連接到新數(shù)據庫，我們就運行 .sql 腳本更改舊數(shù)據庫中的權限。這一步的時機非常重要。
遷移后檢查總 結
將你的 數(shù)據庫遷移到一個新實例會面臨巨大挑戰(zhàn)。無論你選擇哪種工具來實施，你要面對的挑戰(zhàn)都是一樣的：
在本文中，我們介紹了自己是如何解決這些問題的。我們遇到的一大困難是沒有這方面的在線教程，因此我們不得不隨機應變，并多次迭代我們的解決方案，直到我們正確地完成任務。我們也想聽聽你的反饋意見，這樣可以幫助我們改進流程，并幫助可能面臨相同問題的其他讀者。
PS：背景故事
2020 年初，我們發(fā)現(xiàn)我們使用了兩個 .5 實例，我們從 的早期就一直在使用它們。2020 年 1 月，我們不得不關閉舊實例并使用新實例，因為亞馬遜即將遷移到新的 SSL/TLS 證書。這次遷移中，我們丟失了不少數(shù)據，花費了幾天的時間來恢復它們。問題出在我們信任 的自動同步機制，讓它處理我們的漂移；正如前面提到的那樣，它有問題并且失敗了。今年我們不得不再做一次，因為 9.5 即將 EOL 了，否則它們會被 AWS 強行升級。這次我們下定決心要注意每一個小細節(jié)。我們相信我們可以快速、可靠且無故障地達成目標，我們做到了。
為什么要升級到新實例
首先，我們需要解釋為什么我們不讓亞馬遜在沒有我們干預的情況下在線升級我們的數(shù)據庫。亞馬遜提供了升級流程終結者2文件格式錯誤，但與遷移到新數(shù)據庫實例的方案相比，它有一些嚴重的缺點：
我們選擇 是因為我們想要一個在我們的 VPC 中沙盒化的解決方案，這樣生產數(shù)據永遠不會泄露到互聯(lián)網上。最后遷移很成功，也沒有丟失數(shù)據。遷移過程的總耗時不到 2 小時，算是比較成功的！
原文鏈接：
本周好文推薦
InfoQ 寫作平臺歡迎所有熱愛技術、熱愛創(chuàng)作、熱愛分享的內容創(chuàng)作者入駐！
還有更多超值活動等你來！
掃描下方二維碼
填寫申請，成為作者
開啟你的創(chuàng)作之路吧~
點個在看少個 bug