數據庫切換了，業務之前一直連接的都是主庫，怎么讓業務連接備庫呢？
- 業務切換到新的地址，也就是業務應用配置文件修改一下新的主庫
- 使用內部dns，通過域名連接，一般公司都用CoreDNS框架搭建內部的映射，有對應的域名配置對應的IP解析，所以改的話只改域名映射配置就可以了。這樣的好處是項目的配置文件永遠不需要改配置文件，只需要改DNS服務器的配置
- 使用keeppalived進行自動VIP漂移，也就是相當於心跳檢測mysql服務器是否掛掉，它會自動切換保證隨時有新的頂上去，也就自動實現了主從切換；也可以自動執行切換腳本，比如檢測出主庫掛了，不僅僅可以漂移VIP，也可以自動執行一個腳本，這個腳本是可以自定義，實現想要的功能，比如實現主只讀，把備庫可以寫等等。
- 使用代理，如HaProxy
- MHA，高可用首選！結合DBLE可以實現負載！
MHA
MHA支持GTID，可以在binlog來不及傳送時會嘗試登錄主庫傳送binlog到從庫。當主庫還沒來得及把binlog傳送給從庫的時候，MHA會登錄主庫把沒傳送的binlog傳送出去，但MHA不支持想keepalived一樣漂移VIP，但是配合DBLE就可以了。
原理
MHA支持GTID，可以在binlog來不及傳送時會嘗試登錄主庫傳送binlog到從庫。當主庫還沒來得及把binlog傳送給從庫的時候，MHA會登錄主庫把沒傳送的binlog傳送出去，但MHA不支持想keepalived一樣漂移VIP，但是配合DBLE就可以了。
從下圖來看，一主兩從，一般從生產來看，都會架設兩個從庫一個主庫，其次MHA作為中間件的服務器，並且每個Mysql服務器都安裝一個MHA組件（MHA node腳本）
假如mysql的主庫掛了，這個時候從庫連接不上主庫，MHA會登錄Mysql主庫搶救為傳送出來的binlog，也就完成了第一步。有人好奇了，假如開了binlog的半同步復制的話，是不是就沒有未傳送的binlog，理論上至少是這樣，但是binlog傳送過長可能會中斷變成異步binlog傳送，如果用主庫宕機了，手動切換，很可能搶救不了主庫遺留的binlog，但是binlog還沒有復制到從庫。
等待從庫執行中繼日志追趕master，也就是MHA使用的是可靠性策略，追上之后然后 MHA會在從庫執行從主庫搶救出來的binlog，那么保證了主從的一致，完成了第二步。
然后提升一個從庫為主庫，這時候另一個從庫會從一個新提升的主庫復制數據，到這一步MHA的工作就完成了，可以退休了。
這個時候MHA就完成了一波周期工作，接下來還需要人工修復，把之前宕機的主庫改為從庫，等待下一波的容災。
