主從複製故障處理
阿新 • • 發佈：2020-07-17
目錄
主從複製執行緒管理命令
啟動所有執行緒 start slave; 關閉所有執行緒 stop slave; 單獨啟停SQL執行緒 start slave sql_thread; stop slave sql_thread; 單獨啟停IO執行緒 satrt slave io_thread; stop slave io_thread;
IO 執行緒故障
連線主庫: connecting
- 網路：
-連線資訊錯誤或變更了,防火牆,連線數上線
排查思路
使用複製使用者手工登入
[root@db01 data]# mysql -urepl -p12321321 -h 10.0.0.51 -P 3307 mysql: [Warning] Using a password on the command line interface can be insecure. ERROR 1045 (28000): Access denied for user 'repl'@'db01' (using password: YES) [root@db01 data]# mysql -urep -p123 -h 10.0.0.51 -P 3307 mysql: [Warning] Using a password on the command line interface can be insecure. ERROR 1045 (28000): Access denied for user 'rep'@'db01' (using password: YES) [root@db01 data]# mysql -urepl -p123 -h 10.0.0.52 -P 3307 mysql: [Warning] Using a password on the command line interface can be insecure. ERROR 2003 (HY000): Can't connect to MySQL server on '10.0.0.52' (113) [root@db01 data]# mysql -urepl -p123 -h 10.0.0.51 -P 3309 mysql: [Warning] Using a password on the command line interface can be insecure. ERROR 2003 (HY000): Can't connect to MySQL server on '10.0.0.51' (111)
解決此類問題
1. stop slave
2. reset slave all;
3. change master to
4. start slave1.
請求日誌，接收日誌（Binlog）
- binlog 沒開
- binlog 損壞,不存在
- binlog日誌不完整，不連續
- 從庫請求起點問題
- 主從server_id(server_uuid）相同
- relaylog問題
Last_IO_Errno: 1236 Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: 'could not find next log; the first event 'mysql-bin.000007' at 967, the last event read from '/binlog/3306/mysql-bin.000007' at 1329, the last byte read from '/binlog/3306/mysql-bin.000007' at 1329.'
解決此類問題
- 找個業務不繁忙期間，停止業務5分鐘
如果業務繁忙期間做，有可能會導致資料庫hang死
- 等待從庫重新放完所有的主庫日誌
- 主庫reset master,並檢視位置點資訊show binary logs;
- 從庫重新同步主庫日誌
stop slave ;
reset slave all;
CHANGE MASTER TO
MASTER_HOST='10.0.0.12',
MASTER_USER='repl',
MASTER_PASSWORD='123456',
MASTER_PORT=3306,
MASTER_LOG_FILE='mysql-bin.000001',
MASTER_LOG_POS=154,
MASTER_CONNECT_RETRY=10;
start slave;
show slave status\G;
查詢binlog的相關命令
檢視二進位制日誌位置
mysql> show variables like '%log_bin%';
檢視所有已存在的二進位制日誌
mysql> show binary logs;
mysql> flush logs;
mysql> show binary logs;
檢視正在使用的二進位制日誌
mysql> show master status ;
或者使用第三方pt工具
SQL執行緒故障
SQL主要做什麼工作？
回放relay-log中的日誌。可以理解為執行relay-log SQL
relay-log故障本質
一條SQL語句為什麼執行失敗?
- insert delete update ---> t1 表 操作的物件不存在
- create table wx ---> wx 操作的物件已存在
- 約束衝突(主鍵,唯一鍵,非空..)
- 引數，版本問題
以上問題大機率出現從庫寫入或者雙主結構中，或者引數，版本不一致的問題
解決此類問題
合理處理方法:
- 把握一個原則,一切以主庫為準進行解決
- 如果出現問題,儘量進行從庫反操作
- 最直接穩妥辦法,重新構建主從
解決思路1：
進行從庫反操作。重啟執行緒
drop database wx;
start slave;
解決思路2：
stop slave;
set global sql_slave_skip_counter = 1;
#將同步指標向下移動一個，如果多次不同步，可以重複操作。
start slave;
解決思路3（暴力）：
/etc/my.cnf
slave-skip-errors = 1032,1062,1007
常見錯誤程式碼:
1007:物件已存在
1032:無法執行DML
1062:主鍵衝突,或約束衝突
但是，以上操作有時是有風險的，最安全的做法就是重新構建主從。把握一個原則,一切以主庫為主.
避免一定程度的SQL執行緒故障
- 從庫只讀
read_only
super_read_only
- 使用讀寫分離中介軟體
- atlas
- mycat
- ProxySQL
- MaxScale
主從延時監控及原因
什麼是主從延時？
主庫發生了操作，從庫‘很久’才跟上。
主庫方面原因的監控
主庫:
3306 [(none)]>show master status;
+------------------+----------+--------------+------------------+----------------------------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+------------------+----------+--------------+------------------+----------------------------------------+
| mysql-bin.000001 | 319 | | | 7d1fda1c-c705-11ea-9af4-000c2925c00d:1 |
+------------------+----------+--------------+------------------+----------------------------------------+
從庫:
db02 [(none)]>show slave status\G;
Master_Log_File: mysql-bin.000001
Read_Master_Log_Pos: 319
Retrieved_Gtid_Set: 7d1fda1c-c705-11ea-9af4-000c2925c00d:1
Retrieved_Gtid_Set: 7d1fda1c-c705-11ea-9af4-000c2925c00d:1
Executed_Gtid_Set: 13ce935d-c710-11ea-861d-000c29753b09:1,
7d1fda1c-c705-11ea-9af4-000c2925c00d:1:5-6
主從延時的監控
粗略：
show slave status\G;
Seconds_Behind_Master: 0
準確：
日誌量：主庫binlog位置點：從庫relay執行的位置點
如何計算延時的日誌量：
show master status;
cat /data/3306/relay-log.info
從庫方面原因監控:
拿了多少:
db02 [(none)]>show slave status\G;
Master_Log_File: mysql-bin.000001
Read_Master_Log_Pos: 319
主從複製延時原因
主庫方面原因
- 外部原因：網路，硬體配置，主庫業務繁忙，從庫太多
主庫業務繁忙：
1.拆分業務（分散式）：元件分離，垂直拆分，水平拆分
2.大事務的拆分：比如，1000w業務，拆分為20次執行
2.內部原因
1.二進位制更新問題：
binlog寫入不及時
sync_binlog=1
2.本版5.7之前版本，沒有開GTID之前，主從可以併發事務，但是dump傳輸時序列傳輸binlog：
會導致，事務量，由於dump_t 是串型工作的，大事務時會出現比較嚴重延時，導致傳送日誌較慢
如何解決問題?
5.6+ 版本，手工開啟GTID，事務在主從的全域性範圍內就有了唯一標誌。
5.7+ 版本，無需手工開啟gdit，系統會自動生成匿名的GTID資訊
有了GTID之後，就可以實現併發（使用Group commit方式）傳輸binlog
3.主庫極其繁忙
慢語句
鎖等待
從庫個數
網路延時