MySQL究極防禦工事(全自動化MHA機制) - PINK
===

###### tags: `COSCUP2021` `Skilled` `zh-tw` `COSCUP2021` `可能重要的 MySQL 三兩事 Aspects of MySQL` `TR213`

{%hackmd kra72OaxRTiBzdV8Y4GMKA %}

:::info
Slido: https://app.sli.do/event/8uueng5t
:::

> RecoverMaster 機制你們會怎麼進行測試確保 dead master 後回復成你們所想要的狀態?如果 DB 版本更新後每次都會再次 check recover 機制是沒問題的嗎?

A1: 我在簡單回答一下這個問題，這問題很好就是日常ＤＢＡ需要面對的狀況，我這邊建議是ProxySQL一但從mysql_servers移除該old Master host後，就等於對線上移除群集，可以讓它保持原樣等候DBA上班的時候方便查明原因，如果要做成自動恢復成new slave並切回原群集，orchestrator雖然有對應的判斷以及提供hook協作，但是不建議使用，因為一來dead master的情況太多種，script不好寫適應每種狀況的判斷條件，二來如果順利切換回去，等於上班時間還必須要停下該台slave查明原因。

A2: DB 版本更新基本上底層的binlog機制同步核心功能應該差異不大，所以不擔心這點，因為 orchestrator 只是利用 binlog 同步機制上做了點中間的手腳來協助整個MHA機制，只要binlog機制同步核心沒變應該都不需要擔心，如果擔心的話也可以在測試環境搭建一個完整的體系測試一遍。

> 想請問有遇到有些需求要自主做MS切換，但有時候因為環境眾多，有些環境有上orchestrator有些沒有，在停掉同步的那一刻就觸發了 orchestrator，導致切換更複雜，不知道Pink老師一開始有沒有遇到這樣的問題，怎麼解決的?感謝。

A: 後來想到可以利用這個參數 PromotionIgnoreHostnameFilters= [host ip ] 把你不想要觸發切換的機器填上去，orchestrator就不會去把這些機器切換成 Master,或是影片內提到的 RecoverMasterClusterFilters=" * " 不要填上＊ 改成你想要偵測的master，缺點是如果你只填寫一台原本的 Master Host，那經過第一次MHA觸發後，第二次必須改成後來 Promote 上的 New Master，印象中可以利用以上兩個參數控制。

> 前陣子才初學DB，有搭配python後端做出簡單的專案，今天第一次聽到ProxySQL，想請教講者如果初學這個工具，或是想要了解MHA這個概念，有什麼建議？想知道講者在一開始操作ProxySQL有遇到什麼困難？

A1: 請完全理解 MySQL 主從架構的原生replication機制後，非常熟悉整體叢集的操作後，在來延伸第三方Proxy工具會比較好。
A2: 所有第三方工具都跟MySQL一樣客製化的參數非常多，雖然大多時候都是預設值就可以了，但是要非常清楚整個自動化流程，還是都必須要熟讀所有的官方文件才是合格的DBA (淚)

> 不曉得這樣的理解是否有錯。ProxySQL 主要的目的是讓 backend application 可以有個同一個路口，下 query 的時候藉由 ProxySQL 做 routing 。而 Ochestrator 比較偏向是管理主從架構的這個 cluster ?

A: 沒有錯，你得到它了！！！ 雖然這中間的設定非常繁瑣，但是為了全自動化的終極目標，DBA就是必須熟悉很多第三方工具，不一定要用我介紹的兩種工具，也有其他類似功能的開源工具。

這邊提供原始的投影片，歡迎取用，並且說明一下內文 PostGracefulfailover.sh & prefailover.sh ，我有拿掉大部分我客製化在職場上實作的內容，只保留網路上參考的切換寫法，我這邊在寫稿的時候，實在是查不到原本參考的寫法是從哪邊文章了，所以沒有附上來源出處，請不要介意這點，我翻遍過往的瀏覽紀錄，真的是挖不出去年參考的文章來源 QQ

https://drive.google.com/file/d/1zOv6JTVZwFHYkT69_-22Q_BUxZh1TgE6/view?usp=sharing

## 由於錄製影片時間發現自己廢話太多，所以後面就沒特別錄製實際操作觸發MHA的demo，如果大家有興趣我明年有機會再次分享更細部的設定跟demo操作。

謝謝講者Pink的用心分享！