GTID的基礎知識

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

GTID的受限語句檢測

GTID不支援的語句/事務
CREATE TABLE … SELECT

事務中同時使用了支援事務和不支援事務的引擎。

BEGIN；
INSERT INTO innodb_tbl(…);
INSERT INTO myisam_tbl(…);
COMMIT;

在事務中使用臨時表

BEGIN；
INSERT INTO innodb_tbl(…);
CREATE TEMPORARY TABLE temp1;
．．．
COMMIT;

小技巧

啟用GTID前，檢測系統中是否有GTID不支援的語句/事務，提前處理。
全域性系統變數enforce-gtid-consistency
OFF 不檢測是否有GTID不支援的語句/事務
WARN 當發現不支援的語句/事務時，返回警告，並在日誌中記錄警告資訊。
ON 當發現語句/事務不支援GTID時，返回錯誤。 ----所以上面報錯了
線上上的資料庫伺服器或測試環境中，開啟WARN模式。

+---------+------+---------------------------------------------------------------+
| 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可以參考這篇文章

連線：
http://blog.itpub.net/29096438/viewspace-2060975/

Mysql5.7多執行緒併發複製

基本搭建過程可參如下文件：

並行複製的實現與配置/

mysql5.6多執行緒複製：基於datababase/schema的

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

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

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

線上快速切換為併發複製：

mysql> STOP SLAVE SQL_THREAD；

mysql> SET GLOBAL slave_parallel_workers = 8; #併發執行緒數量

mysql> SET GLOBAL slave_parallel_type = “ LOGICAL_CLOCK” ; #or DATABASE

mysql> START SLAVE SQL_THREAD

注意：如果主5.6 從5.7使用LOGICAL_CLOCK的模式可能會出現如下型別錯誤

Last_Errno: 1756

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).

參考文件：

MySQL-5.7的半同步複製

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

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

半同步複製：

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

5.6半同步：master在commit之後才等待salve的應答

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

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

GTID的基礎知識

MySQL-5.7的半同步複製

相關文章