1.主從復(fù)制故障分析及處理

1.1線程不工作

1.1.1 IO線程的常見故障

1.IO的工作：連接主庫，請求日志，存儲(chǔ)日志。

2.連接主庫存儲(chǔ)著網(wǎng)絡(luò)，ip，port，firewalld，user，password，網(wǎng)絡(luò)不通
如果是這些信息不對的話，在從庫上show slave時(shí)會(huì)報(bào)Slave_io_Running:Connecting;
解決的方法：
首先在從庫上將stop slave;
然后在從庫上重新執(zhí)行change master to 里面的信息，
修改成正確的ip，port，user，password
最后再啟動(dòng) start slave；
2.1.如果是查看ip，port，user，password和firewalld都是正確的，
那就是網(wǎng)絡(luò)的問題，如果網(wǎng)絡(luò)是能ping通（因?yàn)閜ing是小的數(shù)據(jù)包，不需要拆分很多次），
但是有丟包的現(xiàn)象（兩臺(tái)服務(wù)器中，各有兩個(gè)網(wǎng)卡，其中這兩臺(tái)服務(wù)器中的兩張網(wǎng)卡綁定成一張網(wǎng)卡，
兩臺(tái)服務(wù)器通過兩臺(tái)交換機(jī)鏈接，但是交換機(jī)沒有做綁定（堆疊），
導(dǎo)致導(dǎo)大的數(shù)據(jù)包，會(huì)將大的數(shù)據(jù)包拆分成小的數(shù)據(jù)包進(jìn)行傳輸，
但是主從走的是不同的線路，在合包的時(shí)候訪問不到，導(dǎo)致網(wǎng)絡(luò)阻塞）
2.1.1  解決辦法：
A 第一種解決辦法
在默認(rèn)的情況下，網(wǎng)卡和交換機(jī)走的是負(fù)載均衡的模式，可以將交換機(jī)和網(wǎng)卡做成主備的模式。
B 第二種解決辦法
將交換機(jī)做堆疊
3.請求日志的常見錯(cuò)誤
3.1 日志位置點(diǎn)錯(cuò)誤（搭建過程的問題）
解決的方法：
重新change master to 即可
3.2 主庫的二進(jìn)制文件（binlog）損壞，誤刪等操作（slave_io_Running:NO）
第一種解決辦法 ：
最好是重新搭建主從(最靠譜的方法）;
第二種解決的方法：
stop slave;
reset slave all;
show binary logs;
+------------------+-----------+
| Log_name         | File_size |
+------------------+-----------+
| mysql-bin.000001 |       177 |
| mysql-bin.000002 |       444 |
+------------------+-----------+
CHANGE MASTER TO
  MASTER_HOST='10.0.0.51',
  MASTER_USER='repl',
  MASTER_PASSWORD='123',
  MASTER_PORT=3307,
  MASTER_LOG_FILE='mysql-bin.000001',
  MASTER_LOG_POS=177, # 指定的file_size的號(hào)
  MASTER_CONNECT_RETRY=10;
start slave；
show slave status \G
4.存儲(chǔ)日志的常見錯(cuò)誤
4.1 relaylog損壞，丟失，不連續(xù)
解決辦法：
relaylog有自動(dòng)清理

1.1.2 SQL線程的常見錯(cuò)誤

1.SQL的主要功能是回放relaylog，即回放二進(jìn)制日志，日志里存放的SQL語句，
但是二進(jìn)制文件不存儲(chǔ)查詢類的語句
2.常見的問題
2.1 創(chuàng)建對象失敗：權(quán)限不足，庫或表已經(jīng)存在（主庫創(chuàng)建成功，但是從庫創(chuàng)建失?。?一些特殊的關(guān)鍵字
從庫被誤寫入（誤將從庫當(dāng)成主庫，先在從庫上創(chuàng)建一個(gè)A表，
然后再到主庫上創(chuàng)建A表，show databases的時(shí)候都有A這兩張表，在主庫上use A，然后craete table ，
再插入一條數(shù)據(jù) instert into t1 ，在show * from t1;的時(shí)候報(bào)錯(cuò)，看起來主從不同步，
其實(shí)首先我們要查看一下主從的狀態(tài)，
即在從庫上show slave status \G 查看的時(shí)候Slave_SQL_Running的狀態(tài)是NO，
*** 當(dāng)出現(xiàn)Slave_SQL_Running的狀態(tài)是NO的情況一般是因?yàn)?要?jiǎng)h除的對象不存在或者是創(chuàng)建的對象已經(jīng)存在再或者是因?yàn)閺膸戾礄C(jī)，導(dǎo)致數(shù)據(jù)不連續(xù) ;版本，SQL_mode和配置的不一致也會(huì)導(dǎo)致；***
這種情況的解決辦法：
第一種辦法：跳過該錯(cuò)誤（生產(chǎn)中不建議這樣）
第二種辦法：首先在主庫上刪除這張表即drop 
databases，然后再次start slave；查看主從的狀態(tài)，即show slave status \G,如果成功可以查看一下即可，use 表；
然后show tables；select * from t1 查看即可
預(yù)防的方案：
1.將從庫設(shè)定的權(quán)限為只讀
db03 [(none)]>show variables like '%read_only%';
+-----------------------+-------+
| Variable_name         | Value |
+-----------------------+-------+
| innodb_read_only      | OFF   |
| read_only             | OFF   |        
| super_read_only       | OFF   |
| transaction_read_only | OFF   |
| tx_read_only          | OFF   |
+-----------------------+-------+
注釋：其中read_only是對普通用戶的限制，super_read_only是對超級用戶的限制；
將這兩個(gè)的設(shè)置成1或者是on即可
db03 [(none)]>set global read_only=on;
db03 [(none)]>set global super_read_only=on;
db03 [(none)]>show variables like '%read_only%' ;
+-----------------------+-------+
| Variable_name         | Value |
+-----------------------+-------+
| innodb_read_only      | OFF   |
| read_only             | ON    |
| super_read_only       | ON   |
| transaction_read_only | OFF   |
| tx_read_only          | OFF   |
+-----------------------+-------+
2.配合中間件（讀寫分離）
2.2 DML語句執(zhí)行失敗主庫（有A表，但從庫沒有A表。因?yàn)橹鲝膹?fù)制是一個(gè)異步的過程）
解決辦法：
認(rèn)為校驗(yàn)主從不一致的原因，將有問題的操作補(bǔ)上，修復(fù)數(shù)據(jù)
首先在主庫中show create table A ;查看A表的結(jié)構(gòu)，并將里面的信息復(fù)制出來，并在從庫上執(zhí)行一次，然后select * from A；
可是沒有數(shù)據(jù)，可以start slave；查看一下show * from t2查看數(shù)據(jù)是否存在，
最后show slave status \G 查看Slove_SQL_Running的狀態(tài)即可
2.3 約束沖突：主鍵自增列沖突（8.0版本以前的故障）
描述故障：一般情況下在主機(jī)出現(xiàn)過宕機(jī)后，比如在主庫上的id有為十的表，然后從庫上早已有id為十的表
解決辦法：
首先在主庫和從庫上查找到這張表 select * from t3 where id=10;。若都為10就可以跳過，操作為：stop slave; set global sql_slave_skip_counter=1;
start slave；
；如果這兩個(gè)值不相同的話，手動(dòng)的變成一致的，以主庫為主