请稍等 ...
×

采纳答案成功!

向帮助你的同学说点啥吧!感谢那些助人为乐的人

mha主从切换失败的问题

老师,您好。
我搭建了一个 一主二从的MHA集群,master,slave1,slave2,主从切换的时候失败了。此时slave2的master_host以切换为slave1的ip。但是查看slave1的 show slave status 时发现它的master_host还是原来的master的ip.
以下是slave2的 错误信息

		Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 13114
                Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: 'Cannot replicate because the master purged required binary logs. Replicate the missing transactions from elsewhere, or provision a new slave from backup. Consider increasing the master's binary log expiration period. To find the missing transactions, see the master's error log or the manual for GTID_SUBTRACT.'
               Last_SQL_Errno: 0
               Last_SQL_Error: 
  Replicate_Ignore_Server_Ids: 
             Master_Server_Id: 1008
                  Master_UUID: 500a5f39-237a-11ee-bedf-000c29dd657a
             Master_Info_File: mysql.slave_master_info
                    SQL_Delay: 0
          SQL_Remaining_Delay: NULL
      Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates
           Master_Retry_Count: 86400
                  Master_Bind: 
      Last_IO_Error_Timestamp: 230719 00:25:12
     Last_SQL_Error_Timestamp: 
               Master_SSL_Crl: 
           Master_SSL_Crlpath: 
           Retrieved_Gtid_Set: 
            Executed_Gtid_Set: 36081d77-219f-11ee-8604-08002706c077:1,
aa758a8a-2335-11ee-a0b9-080027f097ad:1-25
                Auto_Position: 1
         Replicate_Rewrite_DB: 
                 Channel_Name: 
           Master_TLS_Version: 
       Master_public_key_path: 
        Get_master_public_key: 0

以下是mha的报错日志

Mon Jul 24 20:04:29 2023 - [info] -- Slave recovery on host 192.168.2.109(192.168.2.109:3306) started, pid: 30238. Check tmp log /home/mha/192.168.2.109_3306_20230724200423.log if it takes time..
Mon Jul 24 20:14:34 2023 - [error][/usr/share/perl5/vendor_perl/MHA/Server.pm, ln789] Slave could not be started on 192.168.2.109(192.168.2.109:3306)! Check slave status.
Mon Jul 24 20:14:35 2023 - [info]
Mon Jul 24 20:14:35 2023 - [info] Log messages from 192.168.2.109 ...
Mon Jul 24 20:14:35 2023 - [info]
Mon Jul 24 20:04:29 2023 - [info]  Resetting slave 192.168.2.109(192.168.2.109:3306) and starting replication from the new master 192.168.2.108(192.168.2.108:3306)..
Mon Jul 24 20:04:29 2023 - [info]  Executed CHANGE MASTER. 
Mon Jul 24 20:14:34 2023 - [error][/usr/share/perl5/vendor_perl/MHA/Server.pm, ln867] Starting slave IO/SQL thread on 192.168.2.109(192.168.2.109:3306) failed!
Mon Jul 24 20:14:35 2023 - [info] End of log messages from 192.168.2.109.
Mon Jul 24 20:14:35 2023 - [error][/usr/share/perl5/vendor_perl/MHA/MasterFailover.pm, ln2022] Master failover to 192.168.2.108(192.168.2.108:3306) done, but recovery on slave partially failed.
Mon Jul 24 20:14:35 2023 - [info]

----- Failover Report -----

mysql-mha: MySQL Master failover 192.168.2.103(192.168.2.103:3306) to 192.168.2.108(192.168.2.108:3306)

Master 192.168.2.103(192.168.2.103:3306) is down!

Check MHA Manager logs at 192.168.2.81:/home/mha/manager.log for details.

Started automated(non-interactive) failover.
Invalidated master IP address on 192.168.2.103(192.168.2.103:3306)
Selected 192.168.2.108(192.168.2.108:3306) as a new master.
192.168.2.108(192.168.2.108:3306): OK: Applying all logs succeeded.
192.168.2.108(192.168.2.108:3306): OK: Activated master IP address.
192.168.2.109(192.168.2.109:3306): ERROR: Starting slave failed.
Master failover to 192.168.2.108(192.168.2.108:3306) done, but recovery on slave partially failed.Master failover to 192.168.2.108(192.168.2.108:3306) done, but recovery on slave partially failed.

正在回答 回答被采纳积分+3

插入代码

1回答

sqlercn 2023-07-29 15:05:38

检查一下两个Slave配置的server_uuid和server_id是否相同?

0 回复 有任何疑惑可以回复我~
  • 提问者 慕后端4419857 #1
    解决了,总是在这步出问题,卡很长时间。
     Phase 4.1: Starting Slaves in parallel.
    应该是网络原因,被卡住的那台服务器信号不好。
    还有个问题,主从复制的时候,是否每次都要mysqldump 同步从库?
    回复 有任何疑惑可以回复我~ 2023-07-31 20:42:13
  • sqlercn 回复 提问者 慕后端4419857 #2
    是不是需要mysqldump要看从库中的数据是否可以通过主库的binlog进行恢复,如果主库中保留了从库所需要的所有binlog那就不用dump数据到从库了。
    回复 有任何疑惑可以回复我~ 2023-09-01 09:25:56
问题已解决,确定采纳
还有疑问,暂不采纳
微信客服

购课补贴
联系客服咨询优惠详情

帮助反馈 APP下载

慕课网APP
您的移动学习伙伴

公众号

扫描二维码
关注慕课网微信公众号