前言

mysql數(shù)據(jù)庫做主從復制，不僅可以為數(shù)據(jù)庫的數(shù)據(jù)做實時備份，保證數(shù)據(jù)的完整性，還能做為讀寫分離，提升數(shù)據(jù)庫的整體性能。但是，mysql主從復制經(jīng)常會因為某些原因使主從數(shù)據(jù)同步出現(xiàn)異常。因此，下面介紹的是mysql主從同步異常的原因及恢復的方法。

auto.cnf 配置問題

這個問題是在部署主從復制的時候，可能會遇到的

【1】報錯

Last_IO_Error: Fatal error: The slave I/O thread stops because master and slave have equal MySQL server UUIDs; these UUIDs must be different for replication to work

【2】分析：

當mysql做了主從時，每個mysql都會有個uuid 作為唯一標識的。上面是由于主從復制的mysql數(shù)據(jù)庫了相同的UUID，所以，只需要修改auto.cnf配置文件即可。

【3】解決方法

<1>查找auto.cnf文件的位置(位置一般為:/var/lib/mysql/auto.cnf)

find / -iname auto.cnf

<2>將文件中的uuid修改為不同數(shù)值。

my.cnf配置問題

這個問題也是在部署主從復制的時候，可能會遇到的

【1】報錯

Last_IO_Error: Fatal error: The slave I/O thread stops because master and slave have equal MySQL server ids; these ids must be different for replication to work (or the –replicate-same-server-id option must be used on slave but this does not always make sense; please check the manual before using it).

【2】分析

在mysql的主從配置中，每臺mysql數(shù)據(jù)庫的my.cnf中的server-id 必須是唯一，但是有的時候可能因為粗心而配成了相同的數(shù)值，也有可能mysql沒有加載到my.cnf 文件中的server-id。

【3】解決方法

<1>找到mysql的配置文件my.cnf(默認位置為:/etc/my.cnf)

find / -name my.cnf

<2>修改從服務器的my.cnf配置文件中的server-id(注意要改為與主服務器不同的）

<3>在從服務器的數(shù)據(jù)庫中直接添加server_id(此server_id數(shù)值與my.cnf中的一致)

mysql>  set global server_id=2;
mysql>  start slave;

主庫重啟(數(shù)據(jù)庫服務器宕機)

重點問題

這個問題常見于運維mysql數(shù)據(jù)庫主從的過程中，一般都是由于數(shù)據(jù)庫的誤操作引起的，也有可能是數(shù)據(jù)庫服務器因某些原因宕機或重啟引起的。

數(shù)據(jù)庫備份一定要定期進行，確保數(shù)據(jù)萬無一失 .

【1】報錯

Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: ‘binlog truncated in the middle of event; consider out of disk space on master; the first event ‘mysql-bin.001989’ at 9179, the last event read from ‘./mysql-bin.001989’ at 9179, the last byte read from ‘./mysql-bin.001989’ at 9179.’

【2】分析

由報錯可看出是由于從庫的二進制文件位置與主庫的不一致導致的

【3】解決方法

<1>查看主庫的二進制文件的位置

mysql -uroot -p'.....'    進入數(shù)據(jù)庫

show master status;   查看主庫

重點關注：
File 與 Position

<2>查看從庫的狀態(tài)

show slave status\G ；

重點關注下列兩個的狀態(tài)[yes/no]：
Slave_IO_Running
Slave_SQL_Running

<3>解決方法一：

忽略錯誤后，繼續(xù)同步
(適用于主庫與從庫數(shù)據(jù)相差不大；要求數(shù)據(jù)可以不完全統(tǒng)一，數(shù)據(jù)要求不嚴格的情況）

{1}進入從庫操作：

mysql -uroot -p‘...'

{2}停止從庫同步

stop slave;     

{3}跳過1步錯誤（后面的數(shù)字可更改）

set global sql_slave_skip_counter =1;        

{4}開啟從庫

start slave;    

{5}查看從庫狀態(tài)

show slave status\G;

Slave_IO_Running: Yes
Slave_SQL_Running: Yes
即為正常

<4>解決方法二

重新做主從，完全同步
(適用于主庫從庫的數(shù)據(jù)相差較大；要求數(shù)據(jù)完全統(tǒng)一的情況 )

{1}先進入主庫，進行鎖表，此處鎖定為只讀狀態(tài)，防止數(shù)據(jù)寫入 (可選，因如有數(shù)據(jù)庫備份，可直接利用備份)

flush tables with read lock; 

{2}進行數(shù)據(jù)備份,把數(shù)據(jù)備份為.sql的文件(可選，因如有數(shù)據(jù)庫備份，可直接利用備份)

mysqldump -uroot -p‘密碼'  --all-databases > mysql.back.sql 

{3}進入主庫，進行解鎖(可選，因如有數(shù)據(jù)庫備份，可直接利用備份)

unlock tables;

{4}把mysql的備份文件傳輸?shù)綇膸旆掌魃?位置任意，但要能找到)

scp -r /root/mysql.bask.sql root@node2:/tmp/ 

{5}進入從庫，停止從庫的狀態(tài)

stop slave; 

清除slave上的同步位置，刪除所有舊的同步日志，使用新的日志重新開始.(使用前先停止slave服務）

reset slave;(可選)

{6}在從庫中導入數(shù)據(jù)備份

source /tmp/mysql.back.sql ;

或

mysql -uroot -p‘....'  database -f < /tmp/mysql.bask.sql   
(-f 為跳過錯誤的Sql，繼續(xù)往下執(zhí)行，可不加)

{7}設置從庫同步

change master to master_host = '主庫的IP', master_user = '設置主從時設定的主庫的用戶', master_port=主庫的端口, master_password='主庫設定的密碼', master_log_file = 'mysqld-bin.001989', master_log_pos=24110520; 

注意：
master_log_file與master_log_pos 是主庫show master status信息里的| File與Position

{8}重新開啟從庫同步

start slave;  

{9}查看同步狀態(tài)
mysql> show slave status\G 查看：
Slave_IO_Running: Yes
Slave_SQL_Running: Yes

到此這篇關于mysql主從同步異常原因及恢復的文章就介紹到這了,更多相關mysql主從同步異常內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家！ 

最新評論