• 双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!


  • 相关阅读:
    偶然看到3年前为企业内刊写的文章——像经营自己的事业一样经营工作
    Migration 时需要留意到几个问题
    Law of Seed
    时刻准备着
    一种trace APP Engine的方法
    强烈建议博客园增加Oracle ERP或者叫PeopleSoft模块
    回味四年前的自己——细节的魅力
    一封寫給兒子的信
    职场回顾:面试精华试题大全[转]
    快速放松的11种简单方法
  • 原文地址:https://www.cnblogs.com/mfrbuaa/p/3806258.html
Copyright © 2020-2023  润新知