master and slave have equal MySQL server ids_Mysql

蚊子今天下午搭了一主三从的mysql复制,结果所有服务器都配置好后,发现从上报如下的错误

复制代码 代码如下:

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).

意思就是从上的server_id和主的一样的,经查看发现从上的/etc/my.cnf中的server_id=1这行我没有注释掉(在下面复制部分我设置了server_id),于是马上把这行注释掉了,然后重启mysql,发现还是报同样的错误。

使用如下命令查看了一下server_id

复制代码 代码如下:

mysql> show variables like 'server_id';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| server_id | 1 |
+---------------+-------+
1 row in set (0.00 sec)

发现,mysql并没有从my.cnf文件中更新server_id,既然这样就只能手动修改了

复制代码 代码如下:

mysql> set global server_id=2; #此处的数值和my.cnf里设置的一样就行
mysql> slave start;

如此执行后,slave恢复了正常。

不过稍后蚊子使用/etc/init.d/mysqld restart重启了mysql服务,然后查看slave状态,发现又出现了上面的错误,然后查看server_id发现这个数值又恢复到了1。

之后蚊子又重新查看了一下/etc/my.cnf的内容,确认应该不是这个文件的问题,于是去google查了一下,看到mysql在启动的时候会查找/etc/my.cnf、DATADIR/my.cnf,USER_HOME/my.cnf。

于是我执行了

复制代码 代码如下:

find / -name "my.cnf"

居然在/usr/local/mysql这个目录下发现了my.cnf文件,于是蚊子将这个文件删除了,然后再重启mysql服务,发现一切恢复了正常。如果有人也出现类似的问题,不妨试试这个办法吧。

时间: 2024-10-21 17:49:56

master and slave have equal MySQL server ids_Mysql的相关文章

master and slave have equal MySQL server ids

Fatal error: The slave I/O thread stops because master and slave have equal MySQL server ids   蚊子今天下午搭了一主三从的mysql复制,结果所有服务器都配置好后,发现从上报如下的错误 复制代码 代码如下: Last_IO_Error: Fatal error: The slave I/O thread stops because master and slave have equal MySQL se

master and slave have equal MySQL server UUIDs 解决方法

使用rsync配置了大量mysql,省去了大量编译和配置的时间,随逐个修改master和slave服务器的my.cnf,后,发现数据不能同步   使用rsync配置了大量mysql,省去了大量编译和配置的时间,随逐个修改master和slave服务器的my.cnf,后,发现数据不能同步, 在slave服务器show slave status: Fatal error: The slave I/O thread stops because master and slave have equal M

MySQL主从复制报错slave have equal MySQL server UUIDs

最近在部署MySQL主从复制架构的时候,碰到了"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." 这个错误提示.即主从架构中使用了相同的UUID.检查server_id系统变量,已经是不同的设置,那原因是

slave have equal MySQL server UUIDs

    最近在部署MySQL主从复制架构的时候,碰到了"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." 这个错误提示.即主从架构中使用了相同的UUID.检查server_id系统变量,已经是不同的设置,

主备不一致:Table definition on master and slave does not match

昨天一同事在线上做变更,为了保证主库的稳定性,先在备库把binlog关闭,然后在进行DDL变更,在通过切换HA,把备库切换为主库,在老的主库上做DDL变更 看上去这样做法没有太大的问题,但是当备库变更一做完,HA切换到备库,开始老主库变更的时候,备库就出现复制出现错误: Last_Error: Table definition on master and slave does not match: Column 10 type mismatch – received type 3, dbname

MySQL server has gone away

MySQL server has gone away  运行sql文件导入数据库时,会报异常MySQL server has gone away  mysql出现ERROR : (2006, 'MySQL server has gone away') 的问题意思就是指client和MySQL server之间的链接断开了. 造成这样的原因一般是sql操作的时间过长,或者是传送的数据太大(例如使用insert ... values的语句过长, 这种情况可以通过修改max_allowed_packe

Step by step guide to set up master and slave machines(转)

Note: There is no need to install Jenkins on the slave machine. On your master machine go to Manage Jenkins > Manage Nodes. New Node --> Enter Node Name. Select Dumb Slave --> Press OK. Fill out the following: Set a number of executors (one or mo

Possible MySQL server UUID duplication for server

     在mysql enterprise monitor监控过程中出现这样的event事件,Topic: Possible MySQL server UUID duplication for server 事件,从该提示的描述来看貌似是存在重复的uuid,而实际上主从关系并不存在重复的uuid.主从关系是通过xtrabackup来构建的.那到底是哪里的问题呢?下文是描述基于xtrabackup复制时导致监控出现重复uuid的问题. 1.故障现象Topic: Possible MySQL

MySQL server has gone away 问题的解决方法_Mysql

mysql出现ERROR : (2006, 'MySQL server has gone away') 的问题意思就是指client和MySQL server之间的链接断开了. 造成这样的原因一般是sql操作的时间过长,或者是传送的数据太大(例如使用insert ... values的语句过长, 这种情况可以通过修改max_allowed_packed的配置参数来避免,也可以在程序中将数据分批插入). 产生这个问题的原因有很多,总结下网上的分析: 原因一. MySQL 服务宕了 判断是否属于这个