資料同步延遲原因及主備切換政策

同步延遲

• t1為主庫a完成事務,寫完binlog的時間
• t2為備庫b完成從a傳輸過來binlog的時間
• t3為備庫執行完binlog的時間
• t3-t1就是備庫和主庫之間的延遲時間,在備庫執行指令show slave status,會顯示seconds_behind_master,就是延遲幾秒

主備延遲的原因

• 備庫所在的伺服器比主庫的伺服器性能來的差,但是他們寫入的檔案是一樣多的,是以盡量保證主備性能一緻
• 備庫壓力大,有些讀操作在備庫上執行,沒有優化,直接大批量讀取資料,導緻io飙升,進而主備延遲,解決方法有多備幾個從庫
• 大事務的操作,比如大批量的删除修改資料,盡量放在晚上執行這種耗性能的操作

主備切換的政策–可靠性優先政策

• 判斷備庫b的second_behind_master是否小于5,小于執行下一步,否則循環
• 把主庫a設定為隻讀,readonly設定為true
• 判斷備庫b的second_behind_master到0為止
• 把備庫b的readonly設定為false,也就是可讀寫
• 把業務切到備庫b

  

主備切換的政策-- 可用性優先政策

• 直接把上面45操作放在前面,能夠有效的保證可用性,但是有可能資料部分不一緻
• 在版本5.6之前,mysql隻支援單線程複制,如果主庫tps,并發高的時候,主備延遲就會很嚴重, 是以基本在備庫執行rely log的時候用多線程的話,就需要滿足一下兩個條件
  • 不能造成更新覆寫,是以更新同一行的兩個事務,要分發給同一個worker中
  • 同一個事務不能拆開,必須放在同一個worker中