共計 3101 個字符，預計需要花費 8 分鐘才能閱讀完成。

這篇文章主要為大家分析了 online DDL 的原理以及 Vitess 如何幫助處理模式遷移的相關知識點，內容詳細易懂，操作細節合理，具有一定參考價值。如果感興趣的話，不妨跟著跟隨丸趣 TV 小編一起來看看，下面跟著丸趣 TV 小編一起深入學習“online DDL 的原理以及 Vitess 如何幫助處理模式遷移”的知識吧。

Vitess 引入了一種運行模式遷移的新方法：非阻塞的、異步的、預定的 online DDL。通過 online DDL，Vitess 簡化了模式遷移過程，它獲得了操作開銷的所有權，并為用戶提供了一個簡單、熟悉的界面：標準的 ALTER TABLE 語句。

讓我們首先介紹一些背景知識并解釋為什么模式遷移在數據庫世界中是一個如此重要的問題，然后深入研究實現細節。 

關系模型和操作開銷

關系模型是軟件世界中存在時間最長的模型之一，它是幾十年前引入的，直到今天仍被廣泛使用。SQL 同樣古老而可靠，甚至在非關系數據庫中也可以找到 SQL 或類似 SQL 的語言。

關系模型對許多常見的用例都有意義，具有屬性的實體（分別為表和列）可以很好地映射到流行的結構，如用戶、產品、成員關系、消息等，而且 SQL 的表達能力足夠強，能夠構造簡單和復雜的問題。

但從歷史上看，關系模型是有代價的。雖然許多數據庫系統對讀和寫進行了優化，但它們對元數據更改（特別是模式更改）的優化程度并不高。此類更改的最大挑戰之一是，它們需要一個操作程序，而且大多不在開發人員的領域之內。

在早期，數據庫管理員（DBA）充當數據庫的保鏢是很常見的。他們會拖延來自開發者的“瘋狂請求”。變更的要求需要經過漫長的程序和文書工作。

幸運的是，這些日子已經過去了，我們在持續部署和快速開發方面更加協作。然而，新的變化加劇了這個問題。在過去，你需要每月更改一次模式；也許幾個月就有一次。你應該為此做好準備，推出一個新的版本。如今，世界上最繁忙的數據庫部署每天都要運行多個模式遷移，這并不少見。

這重新引入并強化了模式遷移問題：該過程大部分不在開發人員的領域之內。它要求他們是數據庫專家。在每天進行多次遷移的情況下，他們需要以與自己的開發流程不兼容的方式與其他開發人員協作和同步（例如，這與比較和合并 git 分支完全不同）。在小公司中，你會看到開發人員只是在他們認為合適的時候擁有和運行他們的遷移，但這并不能擴展，而且產品和組織越大，就越需要一個更正式的流程。

在 MySQL 世界中，直接的模式遷移是阻塞的，如果不是在主服務器上，那就是在副本上。他們對資源咄咄逼人，無法被打斷或壓制。在線模式更改工具已經存在了十多年，但是它們引入了自己的復雜性：你需要將它們與數據庫一起安裝、允許訪問、安排執行、登錄、執行、通知這些工具如何進行限制、處理錯誤、為它們的操作提供可見性等等。在規模較大的公司中，有專門的 DBA 或 Ops 團隊手動執行模式更改是很常見的。這些團隊可以每周甚至每天花費數小時來處理模式遷移的操作開銷。

對于開發人員來說，這是一種所有權的喪失。雖然他們有向某個表添加列的想法，但他們需要從外部團隊請求幫助，并且常常等待，而對進展狀態沒有太多的可見性。這就打破了他們的流程。也許 NoSQL 數據庫最大的吸引力之一是它們不會對開發人員的流程施加這種級別的約束。

對于 DBA 來說，模式遷移是一種負擔。一些開發人員對他們自己的工作流程的意外中斷。

  操作的一些復雜性

操作開銷始于模式遷移跨越多個域這一事實。讓我們來看看模式遷移流的不完整分解：

正規化：某些人（開發人員？）需要正規化遷移。通常會有人提出一個 CREATE，DROP，或者 ALTER TABLE 語句。這種說法正確嗎？它在語法上有效嗎？它是否與現有的慣例相沖突？發現：這條語句需要在生產環境的什么地方運行？開發人員可能不知道模式是如何跨不同集群部署的。發現機制是什么？并且，如果我們找到了正確的集群，那么哪個服務器作為該集群的主服務器呢？數據是否分片？如果是，我們如何檢測所有的碎片？調度：是否已經在需要的集群上運行了遷移？數據庫對并發遷移的反應很差；最好是按順序運行它們。我們需要等嗎？多長時間？如果我們要睡覺，誰來搶我們的空位？我們還會再失去一天的工作嗎？執行：我們需要登錄到某個服務器上嗎？我們應該在哪里運行我們的在線模式遷移工具？我們應該傳遞什么命令行標志？監控：我們能說說進展情況嗎？我們能讓所有人都看到嗎？當遷移完成時，我們如何通知相關方？清理：MySQL 的模式遷移工具會留下一些工件：需要刪除的大型表。刪除表本身就是一個問題。我們如何自動清理這些工件？恢復：如果遷移失敗，我們如何繼續？還有其他的清理工作要做嗎？

對于生產環境中的多個集群（其中一些是分片的），用于識別正確的集群的發現機制是什么？用于應用模式更改的集群的主機是？

 Vitess 幫助處理模式遷移流程

Vitess 的架構使其處于一個獨特的位置，可以處理大多數模式遷移流程。例如：

發現是微不足道的。Vitess 在內部將所有模式映射到碎片和集群，并在任何給定時間知道應該在何處應用遷移（或查詢）。Vitess 模擬了一個單一的數據庫。用戶通過 vtgate 訪問 Vitess，這是一個智能代理，可以從語義上理解查詢。當 Vitess 攔截一個查詢時，它不必嚴格地將該查詢發送到后端數據庫服務器。對于 online DDL，Vitess 會注意模式更改請求，并在之后安排它。適當的后端 tablet 將接收該請求，并各自安排它，以避免運行并發遷移。tablet 自己執行在線模式遷移工具。今天，Vitess 支持 pt-online-schema-change 和 gh-ost。tablet 決定如何執行這些工具，提供命令行標志，任何必要的掛鉤 / 插件。而且，在 Linux/amd64 上，gh-ost 是預編譯的，并與 Vitess 綁定，所以不需要安裝。Vitess 指示工具使用它自己的內部節流機制，因此工具不需要擔心要監視哪些副本。節流機制可以動態適應拓撲變化。Vitess 提供了一個跨所有碎片查詢遷移進度的接口。此外，它還提供了一個接口，用于中止遷移，或重新嘗試中止的遷移或失敗的遷移。Vitess 了解哪些工件是由模式遷移工具生成的。事實上，它指示他們生成什么工件。無論成功還是失敗，Vitess 都可以在遷移后進行清理。它將把工件表發送到垃圾收集機制。它將為 pt-osc 遷移清理遺留的觸發器。Vitess 為每個遷移創建一個臨時帳戶，并在遷移完成后銷毀它。Vitess 知道遷移何時失敗，并運行適當的清理，即使 Vitess 本身在遷移過程中失敗。此時，Vitess 為故障轉移導致的遷移失敗提供了一次性的自動重試。

Vitess 知道模式部署在何處、存在哪些碎片、在任何給定時間誰是主節點，并且可以在正確的數據庫服務器上應用 DDL，而無需用戶干預。

  對用戶來說是什么樣子的？

開發 Vitess online DDL 的目標是盡可能地向用戶隱藏所有的復雜性。因此，所有用戶需要運行的是：

SET @@ddl_strategy=’gh-ost’;
ALTER TABLE my_table ADD COLUMN some_column INT NOT NULL;

ALTER TABLE 語句本身是完全正常的，但是響應不同。它立即返回，并帶有一個作業 ID，用戶可以使用該 ID 跟蹤遷移的進度。用戶可以選擇 gh-ost 策略、pt-osc 策略或普通 direct 策略（不是 online DDL）。

關于“online DDL 的原理以及 Vitess 如何幫助處理模式遷移”就介紹到這了, 更多相關內容可以搜索丸趣 TV 以前的文章，希望能夠幫助大家答疑解惑，請多多支持丸趣 TV 網站！