程序師世界是廣大編程愛好者互助、分享、學習的平台,程序師世界有你更精彩!
首頁
編程語言
C語言|JAVA編程
Python編程
網頁編程
ASP編程|PHP編程
JSP編程
數據庫知識
MYSQL數據庫|SqlServer數據庫
Oracle數據庫|DB2數據庫
 程式師世界 >> 數據庫知識 >> MYSQL數據庫 >> MySQL綜合教程 >> MySQL Semisynchronous Replication介紹,

MySQL Semisynchronous Replication介紹,

編輯:MySQL綜合教程

MySQL Semisynchronous Replication介紹,


前言

    MySQL 5.5版本之前默認的復制是異步(Asynchronous )模式的, MySQL 5.5 以plugins的方式提供了Semisynchronous Replication 模式。在介紹 semi sync 之前,我們先了解:半同步 Asynchronous 和 同步 Synchronous 。

異步復制模式

    主庫將已經提交的事務event 寫入binlog後,即返回成功給app,該模式下並不保證任何已經提交的事務會傳遞到任何slave並被成功應用。

全同步復制模式。

    當主庫提交一個事務 event,主庫會等待該事務被傳遞到所有的slave上,且所有slave applay 該事務/event 通知主庫之後,才會返回回話,事務已經成功。

   從定義中可以看出 異步模式不能保證數據的安全性,因為它不等待主庫提交的事務在slave 上落盤,而全同步模式 由於要等待所有的slave 確認已提交事務成功被應用,如此則會帶來事務處理上的延時。semi sync 則取了一個比較折中的方式,確保已提交的事務必須存在於至少兩個機器(主庫和任一備庫),立即返回給客戶端 事務成功。

一、Semisynchronous Replication 定義
 Semisynchronous Replication模式下,在主庫上提交一個事務/event,它會等待至少一個slave通知主庫,slave 已經接收到傳遞過來的events並寫入relay log,才返回給回話層 寫入成功,或者直到傳送日志發生超時。

 二、優缺點

   優點:當事務返回成功給客戶端時,則事務至少在兩台機器上存在,增強數據安全性。相比異步模式和全同步模式,是一種折中。
    缺點:半同步的確會對數據庫性能有一定影響,因為事務的提交必須等待slave 反饋。性能損耗取決於tcp/IP 網絡傳輸時間,也即傳輸已提交事務和等待slave 反饋已經接收事務的時間。

三、MySQL 半同步的特性

    1 當slave 連接主庫時,它會告知主庫它是不是semi sync 模式。
    2 如果主庫啟用了semi sync模式,且至少一個slave 也啟用了semi sync模式,一個在主庫操作事務的進程在事務提交之後,且至少一個slave 通知主庫成功接收所有事務之前,該進程會處於blocks 等待狀態或者直到超時發生。
    3 當且僅當傳遞過來的events 傳遞到slave,被寫入relay log,刷新到磁盤才會通知主庫完成。
    4 Semisynchronous replication 必須在主備兩端都同時啟用,否則任何一個未設置,主備之間的復制模式將轉變為異步復制模式。
    5 當所有slave 在(rpl_semi_sync_master_timeout的默認值)時間內未返回給主庫成功接收event,主備之間就會變回原來的異步狀態。
 其中關於第二點 MySQL 5.7 已經做了優化,由ack Collector (Col) thread 等待備庫的成功接收事務的通知,這點後續會做詳細介紹--《5.7 Semisync replication 增強》。

四、異常處理

   當備庫Crash時,主庫會在某次等待超時後,關閉Semi-sync的特性,降級為普通的異步復制,這種情況比較簡單。
MySQL的 error.log 會提示:
復制代碼 代碼如下:   
140523 22:26:00 [Warning] Timeout waiting for reply of binlog (file: mysql-bin.000002, pos: 465893519), semi-sync up to file , position 0.
140523 22:26:00 [Note] Semi-sync replication switched OFF.

    比較難以處理的情況是:當主機/主庫Crash時,可能存在一些事務已經在主庫提交,但是還沒有來的及傳給任何備庫,也即這些事務都是沒有返回給客戶端的,所以發起事務的客戶端並不知道這個事務是否已經完成--"牆頭事務"。這時,如果客戶端不做切換,只是等Crash的主庫恢復後,繼續在主庫進行操作,客戶端會發現前面的"牆頭事務"都已經完成,可以繼續進行後續的業務處理;另一種情況,如果客戶端Failover到備庫上,客戶端會發現前面的“牆頭事務”都沒有成功,則需要重新做這些事務,然後繼續進行後續的業務處理,其實此時主備是不一致的,需要通過主備數據校驗來檢查哪一個庫是正確的,然後進行修復。
五、小結

   總之相比於MySQL 5.5 版本之前的異步復制模式 semi sync 已經有了很大的進步,增強了數據的安全性,以安全換一定的性能損耗還是可以接受的。後續會介紹如何安裝和使用semi sync。

  1. 上一頁:
  2. 下一頁:
Copyright © 程式師世界 All Rights Reserved