真实的国产乱ⅩXXX66竹夫人,五月香六月婷婷激情综合,亚洲日本VA一区二区三区,亚洲精品一区二区三区麻豆

【Mysql】mysql公開課之-mysql5.7復(fù)制特性

GTID的基礎(chǔ)知識(shí)

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

在事務(wù)中使用臨時(shí)表

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

小技巧

啟用GTID前，檢測(cè)系統(tǒng)中是否有GTID不支持的語句/事務(wù)，提前處理。
全局系統(tǒng)變量enforce-gtid-consistency
OFF 不檢測(cè)是否有GTID不支持的語句/事務(wù)
WARN 當(dāng)發(fā)現(xiàn)不支持的語句/事務(wù)時(shí)，返回警告，并在日志中記錄警告信息。
ON 當(dāng)發(fā)現(xiàn)語句/事務(wù)不支持GTID時(shí)，返回錯(cuò)誤。 ----所以上面報(bào)錯(cuò)了
在線上的數(shù)據(jù)庫服務(wù)器或測(cè)試環(huán)境中，開啟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。

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

MySQL5.7多線程并發(fā)復(fù)制

基本搭建過程可參如下文檔：
http://www.innomysql.com/article/16317.html
http://www.innomysql.com/inNOSQLmysql并行復(fù)制的實(shí)現(xiàn)與配置/
mysql5.6多線程復(fù)制：基于datababase/schema的
mysql5.7多線程復(fù)制：繼承5.6的同時(shí)，基于事務(wù)執(zhí)行的邏輯時(shí)鐘(Logical Clock)的并發(fā)(5.7以來)
具體區(qū)別如下：
兩種類型的并發(fā)
基于庫(Database/Schema)的并發(fā)(5.6以來)
Binlog中記錄語句使用的所有的庫的名字。
不同庫上的事務(wù)可以并發(fā)執(zhí)行，同庫的事務(wù)順序執(zhí)行。
基于事務(wù)執(zhí)行的邏輯時(shí)鐘(Logical Clock)的并發(fā)(5.7以來)。
Binlog中記錄事務(wù)執(zhí)行時(shí)的相對(duì)順序信息。
基本原理是鎖的沖突檢測(cè)，因此也叫基于鎖的并發(fā)機(jī)制。

基于鎖的并發(fā)復(fù)制的原理
待續(xù)。。。。
在線快速切換為并發(fā)復(fù)制：
1. mysql> STOP SLAVE SQL_THREAD；
2. mysql> SET GLOBAL slave_parallel_workers = 8; #并發(fā)線程數(shù)量
3. mysql> SET GLOBAL slave_parallel_type = “ LOGICAL_CLOCK” ; #or DATABASE
4. mysql> START SLAVE SQL_THREAD
注意：如果主5.6 從5.7使用LOGICAL_CLOCK的模式可能會(huì)出現(xiàn)如下類型錯(cuò)誤

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

參考文檔：http://imysql.com/2016/06/02/mysql-faq-5-6-to-5-7-replicaton-failure.shtml

MySQL-5.7的半同步復(fù)制

先了解一下什么是半同步，什么是同步，什么是異步

同步復(fù)制：直到所有的slave都commit了事務(wù)之后，此時(shí)才返回信息給客戶端；缺點(diǎn)：完成一個(gè)事務(wù)的延遲可能很大

半同步復(fù)制：

5.7無損半同步：master在收到slave的應(yīng)答之后才commit事務(wù) 更多詳細(xì)信息可參考文檔：http://mp.weixin.qq.com/s?__biz=MzIwNzEzNDkxNQ==&mid=400915320&idx=1&sn=58dcc499cbcedcd827002acd77c30d60&scene=4#wechat_redirect

5.6半同步：master在commit之后才等待salve的應(yīng)答

異步復(fù)制： Master將事件寫入binlog，但并不知道Slave是否或何時(shí)已經(jīng)接收且已處理。在異步復(fù)制的機(jī)制的情況下，如果Master宕機(jī)，事務(wù)在Master上已提交，但很可能這些事務(wù)沒有傳到任何的Slave上。假設(shè)有Master->Salve故障轉(zhuǎn)移的機(jī)制，此時(shí)Slave也可能會(huì)丟失事務(wù)