mysql5.6主从复制日志应用错误
2018-02-04 00:42
621 查看
今天做主从测试,在从库进行日志应用的时候报了一个错,导致从库的slave IO sql应用进程停止工作,报了一个下面的错:
1,在主库上执行了revoke all privileges on *.* from wufan@'%' ;
2,从库同时也会执行这样语句,但是由于从库并没有wufan这个用户,所以必然报错
可以看到,从主库复制binlog的salve_io线程还在忙活,但是执行从库更新的slave_sql已经罢工了,从Last_error:可以看到是因为执行主库执行跟wufan用户相关的权限操作时报的错。
此时可以通过使从库跳过这一错误事件继续运行下面的日志应用:
上面的语句是告诉slave跳过当前卡住的event,然后重新起来干活。
查看一下slave的状态:
注意这两个信息:
发现日志获取io进程和sql应用进程都正常了。
上面的方法在slave比较少的时候还可以,但是当从库有几十台时,逐台去处理既费时又容易出错,怎样在主库这一侧一劳永逸地避免呢?
对,就是在主库这侧不要将这样的grant语句写入到binlog中,MySQL不愧世界级的软件产品,它提供了一个session粒度的选项,通过关闭这个选项可以不让主库将打开这个选项或关闭连接前的SQL语句写入binlog。
在主库侧执行下面的命令临时关闭binlog日志,然后需要的时候在启动binlog日志
mysql> show slave status \G; *************************** 1. row *************************** Slave_IO_State: Waiting for master to send event Master_Host: 127.0.0.1 Master_User: repl Master_Port: 3306 Connect_Retry: 60 Master_Log_File: binlog.000018 Read_Master_Log_Pos: 2807 Relay_Log_File: relaylog.000002 Relay_Log_Pos: 1279 Relay_Master_Log_File: binlog.000018 Slave_IO_Running: Yes Slave_SQL_Running: No Replicate_Do_DB: Replicate_Ignore_DB: Replicate_Do_Table: Replicate_Ignore_Table: Replicate_Wild_Do_Table: Replicate_Wild_Ignore_Table: Last_Errno: 1141 Last_Error: Error 'There is no such grant defined for user 'wufan' on host '%'' on query. Default database: 'test'. Query: 'revoke SELECT ON `jfedu`.* from wufan@'%'' Skip_Counter: 0 Exec_Master_Log_Pos: 1717 Relay_Log_Space: 3656 Until_Condition: None Until_Log_File: Until_Log_Pos: 0 Master_SSL_Allowed: No Master_SSL_CA_File: Master_SSL_CA_Path: Master_SSL_Cert: Master_SSL_Cipher: Master_SSL_Key: Seconds_Behind_Master: NULL Master_SSL_Verify_Server_Cert: No Last_IO_Errno: 0 Last_IO_Error: Last_SQL_Errno: 1141 Last_SQL_Error: Error 'There is no such grant defined for user 'wufan' on host '%'' on query. Default database: 'test'. Query: 'revoke SELECT ON `jfedu`.* from wufan@'%'' Replicate_Ignore_Server_Ids: Master_Server_Id: 101 Master_UUID: 36020f29-004a-11e8-9f6a-080027293866 Master_Info_File: /u01/my3307/data/master.info SQL_Delay: 0 SQL_Remaining_Delay: NULL Slave_SQL_Running_State: Master_Retry_Count: 86400 Master_Bind: Last_IO_Error_Timestamp: Last_SQL_Error_Timestamp: 180203 18:05:22 Master_SSL_Crl: Master_SSL_Crlpath: Retrieved_Gtid_Set: Executed_Gtid_Set: Auto_Position: 0 1 row in set (0.00 sec) ERROR: No query specified
1,在主库上执行了revoke all privileges on *.* from wufan@'%' ;
2,从库同时也会执行这样语句,但是由于从库并没有wufan这个用户,所以必然报错
可以看到,从主库复制binlog的salve_io线程还在忙活,但是执行从库更新的slave_sql已经罢工了,从Last_error:可以看到是因为执行主库执行跟wufan用户相关的权限操作时报的错。
There is no such grant defined for user 'wufan' on host '%'' on query. Default database: 'test'. Query: 'revoke SELECT ON `jfedu`.* from wufan@'%''
此时可以通过使从库跳过这一错误事件继续运行下面的日志应用:
mysql> set global sql_slave_skip_counter=1; Query OK, 0 rows affected (0.00 sec) mysql> start slave; Query OK, 0 rows affected (0.00 sec)
上面的语句是告诉slave跳过当前卡住的event,然后重新起来干活。
查看一下slave的状态:
mysql> show slave status \G; *************************** 1. row *************************** Slave_IO_State: Waiting for master to send event Master_Host: 127.0.0.1 Master_User: repl Master_Port: 3306 Connect_Retry: 60 Master_Log_File: binlog.000018 Read_Master_Log_Pos: 2807 Relay_Log_File: relaylog.000006 Relay_Log_Pos: 280 Relay_Master_Log_File: binlog.000018 Slave_IO_Running: Yes Slave_SQL_Running: Yes Replicate_Do_DB: Replicate_Ignore_DB: Replicate_Do_Table: Replicate_Ignore_Table: Replicate_Wild_Do_Table: Replicate_Wild_Ignore_Table: Last_Errno: 0 Last_Error: Skip_Counter: 0 Exec_Master_Log_Pos: 2807 Relay_Log_Space: 606 Until_Condition: None Until_Log_File: Until_Log_Pos: 0 Master_SSL_Allowed: No Master_SSL_CA_File: Master_SSL_CA_Path: Master_SSL_Cert: Master_SSL_Cipher: Master_SSL_Key: Seconds_Behind_Master: 0 Master_SSL_Verify_Server_Cert: No Last_IO_Errno: 0 Last_IO_Error: Last_SQL_Errno: 0 Last_SQL_Error: Replicate_Ignore_Server_Ids: Master_Server_Id: 101 Master_UUID: 36020f29-004a-11e8-9f6a-080027293866 Master_Info_File: /u01/my3307/data/master.info SQL_Delay: 0 SQL_Remaining_Delay: NULL Slave_SQL_Running_State: Slave has read all relay log; waiting for the slave I/O thread to update it Master_Retry_Count: 86400 Master_Bind: Last_IO_Error_Timestamp: Last_SQL_Error_Timestamp: Master_SSL_Crl: Master_SSL_Crlpath: Retrieved_Gtid_Set: Executed_Gtid_Set: Auto_Position: 0 1 row in set (0.00 sec) ERROR: No query specified
注意这两个信息:
Slave_IO_Running: Yes Slave_SQL_Running: Yes
发现日志获取io进程和sql应用进程都正常了。
上面的方法在slave比较少的时候还可以,但是当从库有几十台时,逐台去处理既费时又容易出错,怎样在主库这一侧一劳永逸地避免呢?
对,就是在主库这侧不要将这样的grant语句写入到binlog中,MySQL不愧世界级的软件产品,它提供了一个session粒度的选项,通过关闭这个选项可以不让主库将打开这个选项或关闭连接前的SQL语句写入binlog。
在主库侧执行下面的命令临时关闭binlog日志,然后需要的时候在启动binlog日志
相关文章推荐
- MySQL复制应用中继日志解析
- MySQL-五种日志(查询日志、慢查询日志、更新日志、二进制日志、错误日志)、备份及主从复制配置
- mysql-5.6主从复制及遇到的错误
- MySQL复制应用中继日志解析
- mysql 主从复制 忽略错误
- 查看MySQL的错误日志的方法
- MYSQL开启错误日志的方法
- mysql主从复制Slave_IO_Running: No错误
- mysql开启GTID复制模式后手动跳过复制错误
- Mysql之基于日志主从复制
- 【MySQL】【复制】利用slave_exec_mode处理复制过程中出现的1062与1032错误
- MySQL错误日志、binlog日志、查询日志、慢查询日志简介
- mysql复制环境清理二进制日志
- MySQL主从复制技术与读写分离技术amoeba应用
- mysql主从复制基于日志复制
- php的慢速日志引起的Mysql错误问题分析
- mysql主从复制读写分离之——proxysql应用
- Mysql5.6主从复制-基于binlog
- 菜鸟学Linux 第095篇笔记 MySQL 5.6主从复制
- MySQL5.6主从复制