任何大型專案都是從幾台伺服器開始的。 起初有一個資料庫伺服器，然後向其中添加從屬伺服器以擴展讀取。 然後——停下來！ 主人只有一位，奴隸卻很多； 如果其中一個從伺服器離開，那麼一切都會好起來，但如果主伺服器離開，那就很糟糕：停機，管理員正在嘗試提升伺服器。 怎麼辦？ 預留一個師傅。 我的同事帕維爾已經寫過這個 ，我就不重複了。 相反，我會告訴您為什麼一定需要 Orchestrator for MySQL！
讓我們從主要問題開始：“當主人離開時，我們如何將代碼切換到新機器上？”
- 我最喜歡有VIP（虛擬IP）的方案，我們下面會講到。 這是最簡單、最明顯的，儘管它有一個明顯的限制：我們要保留的主機必須位於新機器的 L2 段中，也就是說，我們可以忘記第二個 DC。 並且，以友好的方式，如果遵循大 L2 是邪惡的規則，因為 L2 僅適用於每個機架，而 L3 位於機架之間，並且這樣的方案具有更多限制。
- 您可以在程式碼中寫入DNS名稱並透過/etc/hosts進行解析。 事實上，不會有任何解決方案。 此方案的優點：沒有第一種方法的限制特性，即可以組織跨DC。 但隨後出現了一個明顯的問題：我們能多快透過 Puppet-Ansible 將變更傳遞到 /etc/hosts？
- 你可以稍微改變第二種方法：在所有Web伺服器上安裝快取DNS，透過它程式碼將進入主資料庫。 您可以在 DNS 中為此項目設定 TTL 60。 看起來，如果實施得當，這個方法是好的。
- 帶有服務發現的方案，意味著使用Consul和etcd。
- 一個有趣的選擇 。 你需要透過ProxySQL將所有流量路由到MySQL；ProxySQL本身可以決定誰是master。 順便說一句，您可以在我的文章中閱讀有關使用該產品的選項之一 .
Orchestrator的作者，在Github工作，首先用VIP實現了第一個方案，然後將其轉換為用consul的方案。
典型的基礎設施佈局：
我會立即描述需要考慮的明顯情況：
- VIP 位址不應在任何伺服器的設定中註冊。 讓我們想像一種情況：主伺服器重新啟動，在載入時，Orchestrator 進入故障轉移模式並使其中一個從伺服器成為主伺服器； 然後老爺子就起來了，現在貴賓就坐兩輛車了。 這不好。
- 對於orchestrator，您需要編寫一個腳本來呼叫舊master和新master。 在舊的 master 上，您需要執行 ifdown，在新的 master 上，您需要執行 ifup vip。 如果在此腳本中還包含以下內容，那就太好了：在發生故障轉移時，只需關閉舊主交換器上的連接埠以避免任何裂腦。
- Orchestrator 呼叫您的腳本首先刪除 VIP 和/或熄滅交換器上的端口，然後在新主設備上調用 VIP 提升腳本後，不要忘記使用 arping 命令告訴每個人新的 VIP 現已存在這裡。
- 所有從屬設備都應該有 read_only=1，並且一旦您將從屬設備提升為主設備，它就應該有 read_only=0。
- 不要忘記，我們為此選擇的任何從站都可以成為主站（編排器有一個完整的偏好機制，首先考慮哪個從站作為新主站的候選者，其次考慮哪個從站，以及哪個從站應該考慮）任何情況下都不能選擇master）。 如果從機成為主機，那麼從機的負載將保留在其上，並且主機的負載將被添加，這是必須考慮到的。
如果您沒有 Orchestrator，為什麼還需要 Orchestrator？
- Orchestrator 有一個非常用戶友好的圖形介面，可以顯示整個拓撲（請參見下面的螢幕截圖）。
- Orchestrator 可以追蹤哪些從屬裝置落後，以及複製通常在哪裡發生故障（我們在 Orchestrator 上附加了用於發送 SMS 的腳本）。
- Orchestrator 會告訴您哪些從站的 GTID 錯誤。
編排器介面：
什麼是 GTID 錯誤？
Orchestrator 的工作有兩個主要要求：
- 需要在MySQL叢集中的所有機器上啟用偽GTID；我們啟用了GTID。
- 任何地方都必須有一種類型的binlog，可以使用statement。 我們有一個配置，其中主設備和大多數從設備具有 Row，並且兩個歷史上保持混合模式。 因此，Orchestrator 根本不想將這些從站連接到新的主站。
請記住，生產從站中最重要的是它與主站的一致性！ 如果您在主伺服器和從伺服器上都啟用了全域事務 ID (GTID)，那麼您可以使用 gtid_subset 函數來找出這些機器上是否實際執行了相同的資料變更要求。 您可以閱讀更多相關內容 .
因此，Orchestrator 透過 GTID 錯誤向您顯示從屬裝置上存在主裝置上沒有的交易。 為什麼會發生這種情況？
- Read_only=1 在從站上未啟用，有人連接並完成了更改資料的請求。
- 從站上未啟用 Super_read_only=1，然後管理員混淆了伺服器，進入並在那裡執行請求。
- 如果你考慮到前面的兩點，那麼還有一個技巧：在MySQL中，刷新binlog的請求也會進入binlog，因此在第一次刷新時，Master和所有Slave上都會出現GTID錯誤。 如何避免這種情況？ Perona-5.7.25-28 引入了 binlog_skip_flush_commands=1 設置，該設置禁止將刷新寫入二進位日誌。 mysql.com 網站上有一個已建立的 .
讓我總結一下以上所有內容。 如果您還不想在故障轉移模式下使用 Orchestrator，請將其置於觀察模式。 然後，您眼前將始終看到 MySQL 機器的交互圖，以及有關每台機器上的複製類型、從機是否落後以及最重要的是它們與主機的一致性的可視化資訊！
顯而易見的問題是：“Orchestrator 應該如何運作？” 他必須從目前的slave中選擇一個新的master，然後將所有的slave重新連接到它（這就是需要GTID的原因；如果你使用帶有binlog_name和binlog_pos的舊機制，那麼將一個slave從當前的master切換到一個新的）根本不可能！）。 在我們擁有 Orchestrator 之前，我曾經必須手動完成所有這些工作。 舊的 master 由於有缺陷的 Adaptec 控制器而掛起；它有大約 10 個從屬設備。 我需要將 VIP 從主伺服器轉移到其中一個從伺服器，並將所有其他從伺服器重新連接到它。 我必須打開多少個控制台，我輸入了多少個同時命令...我必須等到凌晨3 點，刪除除兩個之外的所有從機的負載，使兩個主機中的第一台機器，立即連接第二台機器因此，將所有其他從站連接到新主站並返回負載。 總體而言，可怕...
Orchestrator 進入故障轉移模式時如何運作？ 這是最容易透過一個例子來說明的，我們希望讓主機成為比現在更強大、更現代的機器。
該圖顯示了該過程的中間部分。 到目前為止已經做了什麼？ 我們說我們想讓某個從站成為新的主站，Orchestrator 開始簡單地將所有其他從站重新連接到它，新的主站充當中轉機。 使用這種方案，不會發生錯誤，所有從站都工作，Orchestrator 從舊主站中刪除 VIP，將其轉移到新主站，使 read_only=0 並忘記舊主站。 全部！ 我們服務的停機時間是VIP轉接時間，2-3秒。
今天就到這裡，謝謝大家。 很快就會有第二篇關於 Orchestrator 的文章。 在著名的蘇聯電影《車庫》中，一個角色說：“我不會和他一起偵察！” 那麼，Orchestrator，我就跟你一起去偵察吧！
來源： www.habr.com