【Mysql】mysql公開課之-mysql5.7複製特性

小亮520cl發表於2016-07-15
MySql

GTID的基礎知識

  1.  AUTO_POSITION的原理
  2.  MySQL Server 記錄了所有已經執行了的事務的GTID，包括複製過來的。可用過系統變數Gtid_executed檢視。
  3.  Slave記錄了所有從master接收過來的事務的GTID。可透過Retrieve_gtid_set檢視（包括已執行的和未執行的）
  4.  Slave連線到Master時，會把gtid_executed中的gtid發給master. Master會自動跳過這些事務，只將沒有複製的事物傳送到Slave去。
  5. Retrieved_Gtid_Set: c05a182a-48c9-11e6-8b56-001188be19c0:2
     Executed_Gtid_Set: c05a182a-48c9-11e6-8b56-001188be19c0:1-2   有一個等價的表在mysql下為gtid_executed
     
GTID的受限語句檢測
  1. GTID不支援的語句/事務
     CREATE TABLE … SELECT

  2. 事務中同時使用了支援事務和不支援事務的引擎。
    1. BEGIN；
      INSERT INTO innodb_tbl(…);
      INSERT INTO myisam_tbl(…);
      COMMIT;

  5. 在事務中使用臨時表
  6. BEGIN；
    INSERT INTO innodb_tbl(…);
    CREATE TEMPORARY TABLE temp1;
    ．．．
    COMMIT;



小技巧
  1. 啟用GTID前，檢測系統中是否有GTID不支援的語句/事務，提前處理。
     全域性系統變數enforce-gtid-consistency
     OFF 不檢測是否有GTID不支援的語句/事務
     WARN 當發現不支援的語句/事務時，返回警告，並在日誌中記錄警告資訊。
     ON 當發現語句/事務不支援GTID時，返回錯誤。                     ----所以上面報錯了
     線上上的資料庫伺服器或測試環境中，開啟WARN模式。
  2. +---------+------+---------------------------------------------------------------+
    | Level | Code | Message |
    +---------+------+---------------------------------------------------------------+
    | Warning | 1786 | Statement violates GTID consistency: CREATE TABLE ... SELECT. |
    +---------+------+---------------------------------------------------------------+
    2016-07-11T10:48:34.627976Z 2 [Warning] Statement violates GTID consistency: CREATE TABLE ... SELECT.

    處理完GTID不支援的語句後，再啟用GTID。
線上升級h為gtid可以參考這篇文章
  1. 連線：
  2. http://blog.itpub.net/29096438/viewspace-2060975/



Mysql5.7多執行緒併發複製
  1. 基本搭建過程可參如下文件：
  3. 並行複製的實現與配置/

  5. mysql5.6多執行緒複製：基於datababase/schema的
  6. mysql5.7多執行緒複製：繼承5.6的同時，基於事務執行的邏輯時鐘(Logical Clock)的併發(5.7以來)

  7. 具體區別如下：
     兩種型別的併發
       基於庫(Database/Schema)的併發(5.6以來)
         Binlog中記錄語句使用的所有的庫的名字。
         不同庫上的事務可以併發執行，同庫的事務順序執行。
       基於事務執行的邏輯時鐘(Logical Clock)的併發(5.7以來)。
         Binlog中記錄事務執行時的相對順序資訊。
         基本原理是鎖的衝突檢測，因此也叫基於鎖的併發機制。


    基於鎖的併發複製的原理
    待續。。。。

  8. 線上快速切換為併發複製：
    1. mysql> STOP SLAVE SQL_THREAD；
    2. mysql> SET GLOBAL slave_parallel_workers = 8; #併發執行緒數量
    3. mysql> SET GLOBAL slave_parallel_type = “ LOGICAL_CLOCK” ; #or DATABASE      
    4. mysql> START SLAVE SQL_THREAD
     注意：如果主5.6 從5.7使用LOGICAL_CLOCK的模式可能會出現如下型別錯誤
    1. Last_Errno: 1756

    3. Last_Error: … The slave coordinator and worker threads are stopped, possibly leaving data in inconsistent state. A restart should restore consistency automatically, although using non-transactional storage for data or info tables or DDL queries could lead to problems. In such cases you have to examine your data (see documentation for details).
    4. 參考文件：




MySQL-5.7的半同步複製

  1. 先了解一下什麼是半同步，什麼是同步，什麼是非同步

  3. 同步複製：  直到所有的slave都commit了事務之後，此時才返回資訊給客戶端；缺點：完成一個事務的延遲可能很大

  5. 半同步複製：
  6.            5.7無損半同步：master在收到slave的應答之後才commit事務    更多詳細資訊可參考文件：http://mp.weixin.qq.com/s?__biz=MzIwNzEzNDkxNQ==&mid=400915320&idx=1&sn=58dcc499cbcedcd827002acd77c30d60&scene=4#wechat_redirect
  7.            5.6半同步：master在commit之後才等待salve的應答

  9. 非同步複製：  Master將事件寫入binlog，但並不知道Slave是否或何時已經接收且已處理。在非同步複製的機制的情況下，如果Master當機，事務在Master上已提交，但很可能這些事務沒有傳到任何的Slave上。假設有Master->Salve故障轉移的機制，此時Slave也可能會丟失事務



來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/29096438/viewspace-2122065/，如需轉載，請註明出處，否則將追究法律責任。

相關文章