mysql Slave I/O: Fatal error
程序员文章站
2022-07-13 08:12:57
...
Slave I/O: 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. Error_code: 1593
解决方法:先看这一段:
To give some background first, starting in MySQL 5.6, the server generates a true UUID in addition to the –server-id supplied by the user. This is ultimately to help with new replication features.
From a under-the-hood view, when starting, the MySQL server automatically obtains a UUID as follows (per the manual):
Attempt to read and use the UUID written in the file data_dir/auto.cnf (where data_dir is the server’s data directory); exit on success.
Otherwise, generate a new UUID and save it to this file, creating the file if necessary.
First, this means there is a new file (in 5.6+) located in the datadir named auto.cnf. In this file is a unique uuid for the server.
This is great, but if you are unaware of it, and simply copy the datadir to set up a slave, and do not remove this file, then you’re in for some errors. So just be cautious/aware of this. Some of these errors are easier to track down, such as in this case, a master and slave with the same uuid throws an error right away in the SHOW SLAVE STATUS and the error log. However, if your master is different from the slave, but you have 2 slaves with the same uuid, you’re in for trouble, and the errors are not very descriptive. [More on this soon, once I can test it a bit more, but I saw some strange behaviors in my first tests.]
So, to fix it, simply delete the auto.cnf file, and restart that instance. A new auto.cnf file / and uuid will be generated. For reference, you’d see something like the following in your error log:
so,to fix it:
删掉默认目录/data下 auto.cnf
然后重启 mysql 使其自动重新生成 uuid
按照其他正常步骤设置 slave 启动,问题fixed 掉,注意uuid 并不是 server-id ,二者有本质区别;
Relay_Master_Log_File: mysql-bin.000014
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
1.Last_Error: Column 3 of table 'juxinli_credit.sys_user' cannot be converted from type 'varchar(90)' to type 'varchar(10)'
2. Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: 'Could not find first log file name in binary log index file'
my.cnf 配置log-bin/log-bin-index
3.Got fatal error 1236 from master when reading data from binary log: 'Could not find first log file name in binary log index file'
stop slave-->reset slave -->start slave -->问题解决;
3.数据不同步实时更新;show slave status\G 确定你的master 是正确的。并且两个IO running 都是yes
解决方法:先看这一段:
To give some background first, starting in MySQL 5.6, the server generates a true UUID in addition to the –server-id supplied by the user. This is ultimately to help with new replication features.
From a under-the-hood view, when starting, the MySQL server automatically obtains a UUID as follows (per the manual):
Attempt to read and use the UUID written in the file data_dir/auto.cnf (where data_dir is the server’s data directory); exit on success.
Otherwise, generate a new UUID and save it to this file, creating the file if necessary.
First, this means there is a new file (in 5.6+) located in the datadir named auto.cnf. In this file is a unique uuid for the server.
This is great, but if you are unaware of it, and simply copy the datadir to set up a slave, and do not remove this file, then you’re in for some errors. So just be cautious/aware of this. Some of these errors are easier to track down, such as in this case, a master and slave with the same uuid throws an error right away in the SHOW SLAVE STATUS and the error log. However, if your master is different from the slave, but you have 2 slaves with the same uuid, you’re in for trouble, and the errors are not very descriptive. [More on this soon, once I can test it a bit more, but I saw some strange behaviors in my first tests.]
So, to fix it, simply delete the auto.cnf file, and restart that instance. A new auto.cnf file / and uuid will be generated. For reference, you’d see something like the following in your error log:
so,to fix it:
删掉默认目录/data下 auto.cnf
然后重启 mysql 使其自动重新生成 uuid
按照其他正常步骤设置 slave 启动,问题fixed 掉,注意uuid 并不是 server-id ,二者有本质区别;
Relay_Master_Log_File: mysql-bin.000014
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
1.Last_Error: Column 3 of table 'juxinli_credit.sys_user' cannot be converted from type 'varchar(90)' to type 'varchar(10)'
2. Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: 'Could not find first log file name in binary log index file'
my.cnf 配置log-bin/log-bin-index
3.Got fatal error 1236 from master when reading data from binary log: 'Could not find first log file name in binary log index file'
stop slave-->reset slave -->start slave -->问题解决;
3.数据不同步实时更新;show slave status\G 确定你的master 是正确的。并且两个IO running 都是yes
推荐阅读
-
MySQL删除表时I/O错误的原因分析与解决
-
开机屏幕出现Disk I/O error的故障分析和解决
-
解决PHP mysql_query执行超时(Fatal error: Maximum execution time …)
-
mysql Slave I/O: Fatal error
-
MySQL案例09:Last_IO_Error: Got fatal error 1236 from master when reading data from binary log
-
电脑开机时提示Disk I/O error的快速解决办法
-
mysql 开发进阶篇系列 22 磁盘I/O问题(从linux操作系统上优化)
-
MySQL TroubleShoting:无任何操作、磁盘I/O负载跑满_MySQL
-
php连接mysql出错:Fatal error: Call to undefined function mysql_connect(),该如何处理
-
MySQL主从失败 错误Got fatal error 1236解决方法