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

MySQL Semisynchronous Replication引見

編輯:MySQL綜合教程

MySQL Semisynchronous Replication引見。本站提示廣大學習愛好者:(MySQL Semisynchronous Replication引見)文章只能為提供參考,不一定能成為您想要的結果。以下是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 則取了一個比擬折衷的方法,確保已提交的事務必需存在於至多兩個機械(主庫和任一備庫),立刻前往給客戶端 事務勝利。

1、Semisynchronous Replication 界說
 Semisynchronous Replication形式下,在主庫上提交一個事務/event,它會期待至多一個slave告訴主庫,slave 曾經吸收到傳遞過去的events並寫入relay log,才前往給回話層 寫入勝利,或許直到傳送日記產生超時。

 2、優缺陷

   長處:當事務前往勝利給客戶端時,則事務至多在兩台機械上存在,加強數據平安性。比擬異步形式和全同步形式,是一種折衷。
    缺陷:半同步切實其實會對數據庫機能有必定影響,由於事務的提交必需期待slave 反應。機能消耗取決於tcp/IP 收集傳輸時光,也即傳輸已提交事務和期待slave 反應曾經吸收事務的時光。

3、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 加強》。

4、異常處置

   當備庫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到備庫上,客戶端會發明後面的“牆頭事務”都沒有勝利,則須要從新做這些事務,然後持續停止後續的營業處置,其實此時主備是紛歧致的,須要經由過程主備數據校驗來檢討哪個庫是准確的,然落後行修復。
5、小結

   總之比擬於MySQL 5.5 版本之前的異步復制形式 semi sync 曾經有了很年夜的提高,加強了數據的平安性,以平安換必定的機能消耗照樣可以接收的。後續會引見若何裝置和應用semi sync。

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