Mysql 5.6 與5.7 server_uuid 相同導致slave故障問題解決

問題
今天添加了一個mysql5.7的 slave資料庫,部署完成之後,啟動新部署的slave一切正常,但是收到了老slave資料庫的主從同步報警。
登陸故障資料庫查詢到,Mysql主從同步報錯如下
1. Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: ‘A slave with the same server_uuid/server_id as this slave has connected to the master; the first event ‘mysql-bin.003459’ at 4, the last event read from ‘/data/dblogs/binlog_3306/mysql-bin.003466’ at 445747689, the last byte read from ‘/data/dblogs/binlog_3306/mysql-bin.003466′ at 445747689.’
問題原因
如報錯信息可以見到,這種現象是server-UUid相同導致,並且經過多次確認集群中server-id是不一樣,而server_uuid是一樣,如下所示。
兩台機的server-id是一樣的
slave1@192.168.179.52: (none) 09:58:45>show variables like ‘server_id’;
+—————+———+
| Variable_name | Value |
+—————+———+
| server_id | 2 |
+—————+———+
1 row in set (0.00 sec)
slave2@192.168.179.53: (none) 09:58:58>show variables like ‘server_id’;
+—————+——-+
| Variable_name | Value |
+—————+——-+
| server_id | 3|
+—————+——-+
1 row in set (0.00 sec)
兩台機的server_uuid 是相同的

slave1@192.168.179.52: (none) 09:59:45>show variables like ‘server_uuid’;
+—————+————————————–+
| Variable_name | Value |
+—————+————————————–+
| server_uuid | 851bc22f-c0ce-11e6-a3bf-1866dae7e3f0 |
+—————+————————————–+
1 row in set (0.00 sec)
slave2@192.168.179.53: (none) 10:00:42>show variables like ‘server_uuid’;
+—————+————————————–+
| Variable_name | Value |
+—————+————————————–+
| server_uuid | 851bc22f-c0ce-11e6-a3bf-1866dae7e3f0 |
+—————+————————————–+
1 row in set (0.00 sec)
錯誤原因:
俺要配置mysql 一主多從的主備架構環境,就將原來的配好的一主一從的主從環境的從機,直接複製備份一套出不,然後修改主機名和IP地址,就直接嘗試新增的從機跟主機作主從配置,也就是執行命令change master。。。就報錯,因為俺的新增從機是直接備份出來的,結果auth.cnf裡面保存的uuid仍然是slave1的uuid,導致再向master申請binlog時master神經錯亂,無法識別兩個slave。
如下內容為網路查詢總結:
1. MySQL 5.6 用 128 位的 server_uuid 代替了原本的 32 位 server_id 的大部分功能。原因很簡單,server_id 依賴於 my.cnf 的手工配置,有可能產生衝突 —— 而自動產生 128 位 uuid 的演算法可以保證所有的 MySQL uuid 都不會衝突。
2. 在首次啟動時 MySQL 會調用 generate_server_uuid() 自動生成一個 server_uuid,並且保存到 auto.cnf 文件 —— 這個文件目前存在的唯一目的就是保存 server_uuid。
3. 在 MySQL 再次啟動時會讀取 auto.cnf 文件,繼續使用上次生成的 server_uuid。
4. 使用 SHOW 命令可以查看 MySQL 實例當前使用的 server_uuid:
5. SHOW GLOBAL VARIABLES LIKE ‘server_uuid’;
6. 它是一個 MySQL 5.6 global variables
7. 全局唯一的 server_uuid 的一個好處是:可以解決由 server_id 配置衝突帶來的 MySQL 主備複製的異常終止
8. 在 MySQL 5.6,Slave 向 Master 申請 binlog 時,會首先發送自己的 server_uuid,Master 用 Slave 發送的 server_uuid 代替 server_id (MySQL 5.6 之前的方式)作為 kill_zombie_dump_threads 的參數,終止衝突或者僵死的 BINLOG_DUMP 線程。
解決方法
既然我們知道故障原因是server_uuid 相同導致,而且server_uuid是在mysql啟動的時候生成的,那麼我們就可以,進入mysql的數據目錄,找到auto.cnf文件,將此文件移動走,然後重啟mysql生成新的server_uuid 即可。

以下文章點擊率最高

Loading…

發表評論