萬盛學電腦網

 萬盛學電腦網 >> 數據庫 >> mysql教程 >> MySQL 5.7增強版Semisync Replication性能優化

MySQL 5.7增強版Semisync Replication性能優化

   這篇文章主要介紹了MySQL 5.7增強版Semisync Replication性能優化,本文著重講解支持發送binlog和接受ack的異步化、支持在事務commit前等待ACK兩項內容,需要的朋友可以參考下

  一 前言

  前文 介紹了5.5/5.6 版本的MySQL semi sync 基礎原理和配置,隨著MySQL 5.7 的發布,新版本的MySQL修復了semi sync 的一些bug 並且增強了功能。

  支持發送binlog和接受ack的異步化;

  支持在事務commit前等待ACK;

  在server層判斷備庫是否要求半同步以減少Plugin鎖沖突;

  解除binlog dump線程和lock_log的沖突等等。

  本文重點分析 第1,2個改進項,因為原來的模式的確會影響系統的tps,新的異步模式可以提高半同步模式下的系統事務處理能力。

  二 優化

  1、支持發送binlog和接受ack的異步化

  通過前面的介紹,我們知道Semisynchronous Replication模式下,app在主庫上提交一個事務/event,MySQL將每個事務寫入binary並且同步到到slave ,master會等待至少一個slave通知:slave 已經接收到傳過來的events並寫入relay log,才返回給回話層 寫入成功,或者直到傳送日志發生超時,系統自動將為異步復制模式。

  整體流程的邏輯圖

  5.5 版本semi sync 設計的缺點:

  從原理以及上圖來看,舊版本的semi sync 受限於dump thread ,原因是dump thread 承擔了兩份不同且又十分頻繁的任務:傳送binlog 給slave ,還需要等待slave反饋信息,而且這兩個任務是串行的,dump thread 必須等待 slave 返回之後才會傳送下一個 events 事務。dump thread 已然成為整個半同步提高性能的瓶頸在高並發業務場景下,這樣的機制會影響數據庫整體的TPS .

  為了解決上述問題,在5.7.4版本的semi sync 框架中,獨立出一個 ack collector thread ,專門用於接收slave 的反饋信息。這樣master 上有兩個進程獨立工作,可以同時發送binlog 到slave ,和接收slave的反饋。整體流程的邏輯圖

  大體的實現思路是:

  備庫IO線程使用TCP協議和主庫交互,讀寫socket可以同時進行,在開啟主庫semisync時,啟動一個後台線程,使用select監聽備庫連接socket;

  dump線程不再等待備庫ACK;在ack reciver線程等待ACK時,dump線程還能繼續發送下一組group commit的binlog,進而提升TPS.

  2 支持在事務commit前等待ACK;

  新版本的semi sync 增加了rpl_semi_sync_master_wait_point參數 來控制半同步模式下 主庫在返回給會話事務成功之前提交事務的方式。

  該參數有兩個值:

  AFTER_SYNC (默認值):master 將每個事務寫入binlog ,傳遞到slave,並且刷新到磁盤。master等待slave 反饋接收到事務並刷新到磁盤。一旦接到slave反饋,master在主庫提交事務並且返回結果給會話。 在AFTER_SYNC模式下,所有的客戶端在同一時刻查看已經提交的數據。假如發生主庫crash,所有在主庫上已經提交的事務已經同步到slave並記錄到relay log。此時切換到從庫,可以保障最小的數據損失。

  AFTER_COMMIT: master 將每個事務寫入binlog ,傳遞到slave 刷新到磁盤(relay log),然後在主庫提交事務。master在提交事務後等待slave 反饋接收到事務並刷新到磁盤。一旦接到slave反饋,master將結果反饋給客戶端。

  在AFTER_COMMIT模式下,如果slave 沒有應用日志,此時master crash,系統failover到slave,app將發現數據出現不一致,在master提交而slave 沒有應用。

copyright © 萬盛學電腦網 all rights reserved