1. 程式人生 > >mysql主從同步異常原因及恢復

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 [email protected]:/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

這裡寫圖片描述