前言
本文主要介紹 MySQL 主備延遲，延遲產生的原因和主備切換策略，
主備延遲
主備同步程序中時間點主要有三個：
-
主庫A執行完成一個事務，寫入binlog，我們把這個時刻記為T1;
-
之后傳給備庫B，我們把備庫B接收完這個binlog的時刻記為T2;
-
備庫B執行完成這個事務，我們把這個時刻記為T3，
所謂主備延遲，指的就是同一個事務下，T3-T1 的時間差值，
主備延遲的計算，可以在備庫下，通過 show slave status 命令查看，回傳的結果中 seconds_behind_master 代表的就是主備延遲，單位是秒，它會等于（備機執行 binlog 時間戳 - binlog 記錄的主機執行時間戳），
一般在網路正常的情況下，備機接收主機發送的 binlog 很快，即 T2-T1 很小，可以忽略不計，主備延遲的主要來自于 T3-T2，這個時間差值代表備機執行中繼日志（relay log）的速度比主機產生 binlog 日志的速度慢多少，
此外，你心里可能還會想主備機器系統時間不一致是否會影響主備延遲？
答案是不會的，因為在主備機器連接上之后，備機會獲取主機的系統時間，然后和本機系統時間比較，計算出差值，在后面計算的時候都會帶上這個差值
產生原因
1. 備機的性能比主機差
目前，這種部署少了，因為考慮到會進行主備切換，所以一般采用對稱部署，即主備機采用一樣的規格，
2. 備機壓力大
主機用來完成寫操作，而備機可能用于完成一些讀操作，或者后臺運營做一些資料分析的作業，備機的壓力不比主機小，從而導致備機的同步延遲，
解決方案：
1、一主多從，多個從機分擔查詢壓力
2、對于資料分析場景，可以將 binlog 同步到外部系統，像 hadoop，
3. 大事務
即便保證主備機壓力基本一致，但大事務情況下，主備機都要耗費相近的執行時間，從而導致備機的同步延遲，所以，DBA 往往會叮囑開發不要執行大事務，就算一定要執行，也要將大事務分割成多個小事務來執行，
4. 大表DDL
大表DDL會占用很多的 CPU 和 IO 資源，很容易造成主備延遲，所以，要比較安全的操作，建議采用 gh-ost 進行，
開發在線上執行 SQL 時一定要注意，不能執行大事務或者大表DDL這種耗時操作，尤其是比較重要的服務，否則會造成主備延遲，影響業務，
主備切換策略
1. 可靠性優先策略
切換步驟：
-
判斷備庫B現在的seconds_behind_master，如果小于某個值（比如5秒）繼續下一步，否則持續重試這一步；
-
把主庫A改成只讀狀態，即把readonly設定為true；
-
判斷備庫B的seconds_behind_master的值，直到這個值變成0為止；
-
把備庫B改成可讀寫狀態，也就是把readonly 設定為false；
-
把業務請求切到備庫B，
可靠性優先的缺點在于主備機存在一段時間的不可用狀態，不可用的時間長短取決于步驟 3，直到步驟 5 執行完成后才恢復，
2. 可用性優先策略
為了保證可用性優先，會先執行步驟 4、5，使得不可用時間為 0 ，但是這可能會造成主備機的資料不一致，
參考
- [1] MySQL是怎么保證高可用的
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/308613.html
標籤：其他
上一篇：MongoDB進階之查詢（二）
下一篇：初識爬蟲