mysql主從同步異常原因及恢復
前言
mysql數據庫做主從復制，不僅可以為數據庫的數據做實時備份，保證數據的完整性，還能做為讀寫分離，提升數據庫的整體性能。但是，mysql主從復制經常會因為某些原因使主從數據同步出現異常。因此，下面介紹的是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數據庫了相同的UUID，所以，只需要修改auto.cnf配置文件即可。
【3】解決方法
<1>查找auto.cnf文件的位置(位置一般為:/var/lib/mysql/auto.cnf)
find / -iname auto.cnf
<2>將文件中的uuid修改為不同數值。
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數據庫的my.cnf中的server-id 必須是唯一，但是有的時候可能因為粗心而配成了相同的數值，也有可能mysql沒有加載到my.cnf 文件中的server-id。
【3】解決方法
<1>找到mysql的配置文件my.cnf(默認位置為:/etc/my.cnf)
find / -name my.cnf
<2>修改從服務器的my.cnf配置文件中的server-id(注意要改為與主服務器不同的）
<3>在從服務器的數據庫中直接添加server_id(此server_id數值與my.cnf中的一致)
mysql> set global server_id=2;
mysql> start slave;
主庫重啟(數據庫服務器宕機)
重點問題
這個問題常見於運維mysql數據庫主從的過程中，一般都是由於數據庫的誤操作引起的，也有可能是數據庫服務器因某些原因宕機或重啟引起的。
數據庫備份一定要定期進行，確保數據萬無一失 .
【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’…..’ 進入數據庫
show master status; 查看主庫
重點關注：
File 與 Position
<2>查看從庫的狀態
show slave status\G ；
重點關注下列兩個的狀態[yes/no]：
Slave_IO_Running
Slave_SQL_Running
<3>解決方法一：
忽略錯誤后，繼續同步
(適用於主庫與從庫數據相差不大；要求數據可以不完全統一，數據要求不嚴格的情況）
{1}進入從庫操作：
mysql -uroot -p‘…’
{2}停止從庫同步
stop slave;
{3}跳過1步錯誤（后面的數字可更改）
set global sql_slave_skip_counter =1;
{4}開啟從庫
start slave;
{5}查看從庫狀態
show slave status\G;
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
即為正常
<4>解決方法二
重新做主從，完全同步
(適用於主庫從庫的數據相差較大；要求數據完全統一的情況 )
{1}先進入主庫，進行鎖表，此處鎖定為只讀狀態，防止數據寫入 (可選，因如有數據庫備份，可直接利用備份)
flush tables with read lock;
{2}進行數據備份,把數據備份為.sql的文件(可選，因如有數據庫備份，可直接利用備份)
mysqldump -uroot -p‘密碼’ –all-databases > mysql.back.sql
{3}進入主庫，進行解鎖(可選，因如有數據庫備份，可直接利用備份)
unlock tables;
{4}把mysql的備份文件傳輸到從庫服務器上(位置任意，但要能找到)
scp -r /root/mysql.bask.sql root@node2:/tmp/
{5}進入從庫，停止從庫的狀態
stop slave;
清除slave上的同步位置，刪除所有舊的同步日志，使用新的日志重新開始.(使用前先停止slave服務）
reset slave;(可選)
{6}在從庫中導入數據備份
source /tmp/mysql.back.sql ;
或
mysql -uroot -p‘….’ database -f < /tmp/mysql.bask.sql
(-f 為跳過錯誤的Sql，繼續往下執行，可不加)
{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}查看同步狀態
mysql> show slave status\G 查看：
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
