复制代码 代码如下:
Last_IO_Error: Fatal error: The slave I/O thread stops because master and slave have equal MySQL server idsthese 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 senseplease 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服务,发现一切恢复了正常。如果有人也出现类似的问题,不妨试试这个办法吧。
按order by id desc limit 0,1进行一次数据查询,查询到的id即为你刚插入的数据id(此方法适用与单用户,多用户适用于楼上的LAST_INSERT_ID()方法)假设A表有3个字段,ID, DATA1,DATA2简单的话可以不使用存储过程,比如:select * form A where ID in (select ID from A where DATA1 between 0 and 100)如果你的应用比较复杂,在嵌套中还有复杂的运算,存储过程可以如下例子:CREATE PROCEDURE test(in_start int,in_end int)BEGIN DECLARE ids TEXT select GROUP_CONCAT(ID) into ids from A where DATA1 between in_start and in_end select * from A where FIND_IN_SET(ID,ids) >0END注: in_start, in_end是DATA1的筛选范围。 后面一个select直接返回一个表直接用SQL和使用存储过程各有利弊,存储过程在你使用大量查询及SQL运算的时候效率很高,而且存储过程一旦写入数据库会被自动编译运行速度比较快,而SQL是每次执行都需要被编译一次的。但是存储过程的调试比较麻烦,不像你使用编程语言和SQL的时候可以单步调试。而且如果没有熟练掌握存储过程的效率优化情况下,使用存储过程可能比使用SQL更慢。欢迎分享,转载请注明来源:内存溢出
评论列表(0条)