主從復(fù)制架構(gòu)演變介紹
職責(zé):
1搭建主從復(fù)制
2主從原理的熟悉
3主從故障處理
4主從延時(shí)
5主從的特殊架構(gòu)
6主從特殊架構(gòu)的配置使用
7主從架構(gòu)的演變
搭建主從
1準(zhǔn)備多實(shí)例
重新初始化3307
mysqld--initialize-insecure--user=mysql--basedir=/app/mysql--datadir=/data/3307/data
修改my.cnf ,開啟二進(jìn)制日志功能
[root@db013307]# vim/data/3307/my.cnf log_bin=/data/3307/data/mysql-bin
?主庫(kù)創(chuàng)建復(fù)制用戶3307
mysql -uroot -p123 -S? /data/3307/mysql.sock -e "grant replication slave on *.* to ligang@'%' identified by '123'"
mysqldump -root -p123 -S /data/3307/mysql.sock -A --master-data=2 --single-transaction -R --triggers >/backup/full.sql
mysqldump -S /data/3307/mysql.sock-A--master-data=2--single-transaction-R--triggers>/backup/full.sql--CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000002',MASTER_LOG_POS=154;
從庫(kù)3308
set sql_log_bin=0
source /backup/full.sql
告訴主庫(kù)誰(shuí)是從庫(kù)
mysql? -S /data/3308/mysql.sock
help?change master to
CHANGE MASTER TO
? MASTER_HOST='192.168.80.134',
? MASTER_USER='repl',
? MASTER_PASSWORD='123',
? MASTER_PORT=3307,
? MASTER_LOG_FILE='mysql-bin.000001',
? MASTER_LOG_POS=437,
? MASTER_CONNECT_RETRY=10;
開啟復(fù)制線程
show slave status \G
告訴從庫(kù)開始你的表演
show slave status \G
grant all on *.* to ligang@'%' identified by '123';
主從復(fù)制工作原理
主庫(kù):
binlog?
從庫(kù):
relaylog??
master.info
relaylog.info
主從涉及的線程:
主庫(kù):
binlog_dump thread :dump_t
從庫(kù):
slave_io_thread
slave_sql_thread
主從復(fù)制原理
監(jiān)控
show full processlists;
show slave status \G
************************* 1. row ***************************
? ? ? ? ? ? ? Slave_IO_State: Waiting for master to send event
? ? ? ? ? ? ? ? ? Master_Host: 192.168.80.134
? ? ? ? ? ? ? ? ? Master_User: repl
? ? ? ? ? ? ? ? ? Master_Port: 3307
? ? ? ? ? ? ? ? Connect_Retry: 10
? ? ? ? ? ? ? Master_Log_File: mysql-bin.000001
? ? ? ? ? Read_Master_Log_Pos: 733
? ? ? ? ? ? ? Relay_Log_File: localhost-relay-bin.000002
? ? ? ? ? ? ? ? Relay_Log_Pos: 616
? ? ? ? Relay_Master_Log_File: mysql-bin.000001
? ? ? ? ? ? Slave_IO_Running: Yes
? ? ? ? ? ? Slave_SQL_Running: Yes
show master status;
File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+------------------+----------+--------------+------------------+-------------------+
| mysql-bin.000001 |? ? ? 733 |? ? ? ? ? ? ? |? ? ? ? ? ? ? ? ? |? ? ? ? ? ? ? ? ? |
主從延時(shí)相關(guān)狀態(tài)(非人為)
Seconds_Behind_Master: 0
延時(shí)從庫(kù)有關(guān)的狀態(tài)(人為)
SQL_Delay:0SQL_Remaining_Delay:NULL
GTID 復(fù)制有關(guān)的狀態(tài)
Retrieved_Gtid_Set:
Executed_Gtid_Set:
Auto_Position: 0
主從復(fù)制故障 ******
從庫(kù):
io?線程故障
連接主庫(kù)
網(wǎng)絡(luò),連接信息錯(cuò)誤或者變更了零抬,防火墻沒(méi)開端口,連接數(shù)上線
排查思路:
使用復(fù)制用戶手工登錄
1stop?slave
2reset?slave?all
3change master to
4 start slave
最容易出的問(wèn)題? 就是二進(jìn)制日志的損壞
sql線程故障:
relay_log損壞
回放relayl_og
研究SQL語(yǔ)句為什么失敗?
insert?delete?update? ?
有可能連到從庫(kù)
解決:一切以主庫(kù)為準(zhǔn)
主鍵沖突:
穩(wěn)妥的結(jié)局方案岩四,更新那個(gè)錯(cuò)誤的主鍵然后?跳過(guò)那個(gè)包斑。。
1 從庫(kù)只讀
2?讀寫分離中間件
mycat
主從延時(shí) *****
主庫(kù)做了修改操作,從庫(kù)比較長(zhǎng)時(shí)間才能追上.
網(wǎng)絡(luò)
主從硬件差異較大
版本差異
參數(shù)因素
?主庫(kù)
(1)二進(jìn)制日志寫入不及時(shí)
[rep]>select @@sync_binlog;
(2)CR的主從復(fù)制中,binlog_dump線程,事件為單元,串行傳送二進(jìn)制日志(5.6 5.5)
1. 主庫(kù)并發(fā)事務(wù)量大,主庫(kù)可以并行,傳送時(shí)是串行
2. 主庫(kù)發(fā)生了大事務(wù),由于是串行傳送,會(huì)產(chǎn)生阻塞后續(xù)的事務(wù).
解決方案:
1. 5.6 開始,開啟GTID,實(shí)現(xiàn)了GC(group commit)機(jī)制,
可以并行傳輸日志給從庫(kù)IO2. 5.7 開始,
不開啟GTID,會(huì)自動(dòng)維護(hù)匿名的GTID,也能實(shí)現(xiàn)GC,
我們建議還是認(rèn)為開啟GTID3. 大事務(wù)拆成多個(gè)小事務(wù),可以有效的減少主從延時(shí).
從庫(kù)
SQL線程導(dǎo)致的主從延時(shí)
在CR復(fù)制情況下:從庫(kù)默認(rèn)情況下只有一個(gè)SQL,只能串行回放事務(wù)SQL
1. 主庫(kù)如果并發(fā)事務(wù)量較大,從庫(kù)只能串行回放
2. 主庫(kù)發(fā)生了大事務(wù),會(huì)阻塞后續(xù)的所有的事務(wù)的運(yùn)行
解決方案:
1. 5.6 版本開啟GTID之后,加入了SQL多線程的特性,但是只能針對(duì)不同庫(kù)(database)下的事務(wù)進(jìn)行并發(fā)回放.
2. 5.7 版本開始GTID之后,在SQL方面,提供了基于邏輯時(shí)鐘(logical_clock),binlog加入了seq_no機(jī)制,
真正實(shí)現(xiàn)了基于事務(wù)級(jí)別的并發(fā)回放,這種技術(shù)我們把它稱之為MTS(enhanced multi-threaded slave).
3. 大事務(wù)拆成多個(gè)小事務(wù),可以有效的減少主從延時(shí).[https://dev.mysql.com/worklog/task/?id=6314]