双slave的server_uuid同样问题

早上做数据迁移,部署完slave2,发现3台机子的日志狂刷:

旧slave:

2014-05-29 14:35:35 996 [Note] Slave: received end packet from server, apparent master shutdown: 
2014-05-29 14:35:35 996 [Note] Slave I/O thread: Failed reading log event, reconnecting to retry, log 'mysql-bin.000005' at position 407
2014-05-29 14:35:35 996 [Warning] Storing MySQL user name or password information in the master info repository is not secure and is therefore not recommende

新slave:

2014-05-29 14:35:35 16770 [Note] Slave: received end packet from server, apparent master shutdown: 
2014-05-29 14:35:35 16770 [Note] Slave I/O thread: Failed reading log event, reconnecting to retry, log 'mysql-bin.000005' at position 407
2014-05-29 14:35:35 16770 [Warning] Storing MySQL user name or password information in the master info repository is not secure and is therefore not recommended. 

master:

2014-05-29 14:35:35 8242 [Note] Start binlog_dump to master_thread_id(86182) slave_server(55), pos(mysql-bin.000005, 407)
2014-05-29 14:35:35 8242 [Note] Start binlog_dump to master_thread_id(86183) slave_server(111), pos(mysql-bin.000005, 407)
2014-05-29 14:35:35 8242 [Note] Start binlog_dump to master_thread_id(86184) slave_server(55), pos(mysql-bin.000005, 407)

这样的现象应该是server-id同样导致master不知道哪个是slave,在多次确认server-id确实不一样后陷入无比郁闷其中。

slave 1:




slave 2:




这时有个新的发现:server_uuid 是同样。

没错,我的迁移是直接把旧的slave停掉,然后复制到新的机子上,结果 auto.cnf  里面保存的uuid 仍然是slave1 的uuid,导致在向master 申请binlog时master神经错乱。


更加具体的解释例如以下(btw:这是网上的一段解释,偶瞧着不错直接搬过来,原作者如有侵权请联系我 :-)):

MySQL 5.6 用 128 位的 server_uuid 取代了原本的 32 位 server_id 的大部分功能。原因非常easy,server_id 依赖于 my.cnf 的手工配置,有可能产生冲突 —— 而自己主动产生 128 位 uuid 的算法能够保证全部的 MySQL uuid 都不会冲突。

在首次启动时 MySQL 会调用 generate_server_uuid() 自己主动生成一个 server_uuid,而且保存到 auto.cnf 文件 —— 这个文件眼下存在的唯一目的就是保存 server_uuid。

在 MySQL 再次启动时会读取 auto.cnf 文件,继续使用上次生成的 server_uuid。

使用 SHOW 命令能够查看 MySQL 实例当前使用的 server_uuid​:

SHOW GLOBAL VARIABLES LIKE 'server_uuid';

它是一个 MySQL 5.6 global variables

全局唯一的 server_uuid 的一个优点是:能够解决由 server_id 配置冲突带来的 MySQL 主备复制的异常终止

在 MySQL 5.6,Slave 向 Master 申请 binlog 时,会首先发送自己的 server_uuid,Master 用 Slave 发送的 server_uuid 取代 server_id (MySQL 5.6 之前的方式)作为 kill_zombie_dump_threads 的參数,终止冲突或者僵死的 BINLOG_DUMP 线程。


By linwaterbin

2014-05-29

Good Luck!


  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
当出现"A slave with the same server_uuid/server_id as this slave has connected to t"的错误时,意味着有两个或多个从服务器使用相同的server_uuidserver_id连接到了主服务器。 在MySQL复制中,每个从服务器都有唯一的server_uuidserver_id用于标识它们自己。这些标识符用于复制中的身份验证和同步过程。当出现一个从服务器与其他从服务器共享相同的server_uuidserver_id时,这会造成冲突并导致错误发生。 要解决此问题,我们需要确保每个从服务器都有其唯一的server_uuidserver_id,并且确保它们与主服务器上的相应设置保持一致。可通过以下步骤解决该问题: 1. 首先,确定从服务器上的server_uuidserver_id。可以在从服务器的my.cnf配置文件或通过执行以下命令获取: SELECT @@server_uuid; SELECT @@server_id; 2. 检查其他从服务器是否使用了相同的server_uuidserver_id。可以在每个从服务器上执行相同的命令并进行比较。 3. 如果发现重复的server_uuidserver_id,需要更新其中一个或所有从服务器的配置,以确保它们使用唯一的标识符。可以通过编辑每个从服务器的my.cnf配置文件来更改它们,修改server_uuidserver_id的值,并确保与其他从服务器不同。 4. 重新启动每个从服务器,使更改生效。 5. 在主服务器上执行RESET SLAVE语句,以清除与从服务器的复制关系。然后重新配置每个从服务器并重新建立复制连接。 通过以上步骤,可以确保每个从服务器都具有唯一的server_uuidserver_id,并且不会发生"A slave with the same server_uuid/server_id as this slave has connected to t"错误。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值