mysql複製在業界裡有叫：mysql同步，ab複製等。專業名稱就是叫：複製

複製是單向的，只能從master複製到slave上，延時基本上是毫秒級別的。

一組複製結構中可以有多個slave，對於master一般場景推薦只有一個。

master使用者寫入資料，生成event記到binary log中

slave接收master上傳來的binlog，然後按順序應用，重現master上的使用者操作。

記錄最小的單位是一個event，日誌前4個位元組是一個magic number,接下來19個位元組記錄formatt desc event:FDE

MySQL5.6增加了GTID複製

classic

核心配置

[mysqld]

log-bin

server-id

gtid_mode=off #禁掉gtid

grantreplication slave on *.* to 'repl'@'%' identified by 'repl4slave';

flushprivileges;

新增一個新的從庫

獲取主庫上一個帶binlog及pos偏移量的備份

在從庫上恢復後

>changemaster to

master_host='192.168.199.117',

master_user='slave',

master_port=7000,

master_password='slavepass',

master_log_file='mysql-bin.000008',

master_log_pos=896;

>startslave;

>showslave status\G;

錯誤跳過：

stopslave;

set globalsql_slave_skip_counter=1;

startslave;

show slavestatus\G;

GTID複製配置

一個事務對應一個唯一ID

一個GTID在一個伺服器上只會執行一次

GTID是用來替代以前classic的複製方法

mysql5.62支援，mysql5.6.10後完善

優點：

相對於行復制來講資料安全性更高

故障切換更簡單

GTID

[mysqld]

#GTID:

gtid_mode=on

enforce-gtid-consistency=on

#binlog

log-bin=mysql-bin

log-slave-updates=1

GTID新增從庫有兩種方法：

1.如果master所有的binlog還在，安裝slave後，直接changemaster 到master

原理是直接獲取master所有的gtid並執行

優點是簡單

缺點是如果binlog太多，資料完全同步需要的時間較長，並且需要master一開始就啟用了GTID

總結：適用於master也是新建不久的情況

2.通過master或者其它slave的備份搭建新的slave.

原理：獲取master的資料和這些資料對應的GTID範圍，然後通過在slave設定@@GLOBAL.GTID_PURGED從而跳過備份包含的GTID

優點是可以避免第一種方法中的不足

缺點操作相對複雜

總結：適用於擁有較大資料集的情況

GTID新增從庫：

mysqldump

在備份的時候需要指定--master-data

匯出的語句中包括：set @@GLOBAL.GTID_PURGED='c8d960f1-83ca-11e5-a8eb-000c29ea831c:1-745497';恢復時，需要先在slave上執行一個

reset master;再執行

changemaster to

perconaxtrabackup

xtrabackup_binlog_info包含了GTID在資訊

做從庫恢復後，需要手工設定：

[email protected]@GLOBAL.GTID_PURGED='c8d960f1-83ca-11e5-a8eb-000c29ea831c:1-745497';

恢復後，執行change master to

>changemaster to

master_host='192.168.199.117',

master_user='slave',

master_port=7000,

master_password='slavepass',

master_auto_position=1;

錯誤跳過

stopslave;

setgtid_next='xxxxxxxx:N';

begin;

commit;

setgtid_next='automatic';

startslave;

GTID的限制：

不支援非事務引擎（從庫報錯，stopslave; start slave; 忽略）

不支援create table … select 語句複製（主庫直接報錯）

不允許在一個SQL同時更新一個事務引擎和非事務引擎的表

在一個複製組中，必須要求統一開啟CTID或是關閉GTID

開啟DTID需要重啟（5.7中可能不需要）

開啟DTID後，就不在使用原來的傳統的複製方式

對於createtemporary table 和drop temporary table語句不支援

不支援sql_slave_skip_counter

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

官方半同步複製的概念：

1.當Slave主機連線到Master時，能夠檢視其是否處於半同步複製的機制。

2.當Master上開啟半同步複製的功能時，至少應該有一個Slave開啟其功能。此時，一個執行緒在Master上提交事務將受到阻塞，直到得知一個已開啟半同步複製功能的Slave已收到此事務的所有事件，或等待超時。

3.當一個事務的事件都已寫入其relay-log中且已重新整理到磁碟上，Slave才會告知已收到。

4.如果等待超時，也就是Master沒被告知已收到，此時Master會自動轉換為非同步複製的機制。當至少一個半同步的Slave趕上了，Master與其Slave自動轉換為半同步複製的機制。

5.半同步複製的功能要在Master，Slave都開啟，半同步複製才會起作用；否則，只開啟一邊，它依然為非同步複製。

同步（社群增強半同步），非同步，半同步複製的比較：

同步複製：Master提交事務，直到事務在所有的Slave都已提交，此時才會返回客戶端，事務執行完畢。缺點：完成一個事務可能會有很大的延遲。

非同步複製：當Slave準備好才會向Master請求binlog。缺點：不能保證一些事件都能夠被所有的Slave所接收。

半同步複製：半同步複製工作的機制處於同步和非同步之間，Master的事務提交阻塞，只要一個Slave已收到該事務的事件且已記錄。它不會等待所有的Slave都告知已收到，且它只是接收，並不用等其完全執行且提交。

半同步,開啟後嚴重影響效能

解決主庫不關心日誌是否被從庫讀到

半同步配置，在master和slave上都配置

master

[mysqld]

rpl_semi_sync_master_enabled=1

rp;_semi_sync_master_timeout=1000#1s

slave

[mysqld]

rpl_semi_sync_slave_enabled=1

複製引數