加入收藏 | 设为首页 | 会员中心 | 我要投稿 52站长网 (https://www.52zhanzhang.com/)- 科技、建站、经验、云计算、5G、大数据,站长网!
当前位置: 首页 > 站长学院 > MySql教程 > 正文

init_command导致mysql 5.6主从连接失败怎么做

发布时间:2022-01-10 16:03:09 所属栏目:MySql教程 来源:互联网
导读:小编给大家分享一下init_command导致mysql 5.6主从连接失败怎么办,相信大部分人都还不怎么了解,因此分享这篇文章给大家参考一下,希望大家阅读完这篇文章后大有收获,下面让我们一起去了解一下吧! mysql 5.6 从库主机安排了计划性重启, 重启主机后, 问
      小编给大家分享一下init_command导致mysql 5.6主从连接失败怎么办,相信大部分人都还不怎么了解,因此分享这篇文章给大家参考一下,希望大家阅读完这篇文章后大有收获,下面让我们一起去了解一下吧!
 
       mysql  5.6 从库主机安排了计划性重启,  重启主机后, 问题来了。
       实例 无法连接master 了。
 
报错如下:
 
[code]
2018-09-17 12:21:50 28554 [Note] 'CHANGE MASTER TO executed'. Previous state master_host='192.168.8.42', master_port= 3307, master_log_file='', master_log_pos= 4, master_bind=''. New state master_host='192.168.8.42', master_port= 3307, master_log_file='', master_log_pos= 4, master_bind=''.2018-09-17 12:21:58 28554
 
 [Warning] Storing MySQL user name or password information in the master info repository is not secure and is therefore not recommended.
 
 Please consider using the USER and PASSWORD connection options for START SLAVE;
 
see the 'START SLAVE Syntax' in the MySQL Manual for more information.2018-09-17 12:21:58 28554
 
[Note] Slave SQL thread initialized, starting replication in log 'FIRST' at position 0, relay log './relay-bin.000001' position: 42018-09-17 12:21:58 28554
 
 [Note] Slave I/O thread: connected to master 'repl@192.168.8.42:3307',replication started in log 'FIRST' at position 42018-09-17 12:21:58 28554
 
 [Warning] "SELECT UNIX_TIMESTAMP()" failed on master, do not trust column Seconds_Behind_Master of SHOW SLAVE STATUS. Error: Aborted connection 12505106 to db: 'unconnected' user: 'repl' host: '192.168.8.43' (init_connect command failed) (1184)2018-09-17 12:21:58 28554 [ERROR] Slave I/O: The slave I/O thread stops because a fatal error is encountered  when it tries to SET @master_heartbeat_period on master. Error: , Error_code: 15932018-09-17 12:21:58 28554
 
[Note] Slave I/O thread exiting, read up to log 'FIRST', position 4
[/code]
 
咋回事呢, 同事重置了slave 还是报错。
 
因为启用了gtid  , 两边对照了gtid 的各个参数都是一致的。 也排除了gtid 的故障。
 
因为重启之前都是OK 的, 也不存数据问题。 纳闷了。
 
看日志就上上面这样了。
 
一时没明白过来。 去主库上看看 。
 
问题找到了。
 
#init_connect='set names gbk;insert into db_monitor.accesslog(thread_id,log_time,localname,matchname) values(connection_id(),now(),user(),current_user());commit;'
 
主库上的init_command  参数 加了一条sql 语句。
 
对应到了日志里的 init_command 的报错。
 
看看权限
 
[code]
 
mysql.sock@(none)> use mysql
 
Database changed
 
mysql.sock@mysql> select * from  tables_priv   ;
 
+------+------------+--------------+------------+----------------+---------------------+------------+-------------+
 
| Host | Db         | User         | Table_name | Grantor        | Timestamp           | Table_priv | Column_priv |
 
+------+------------+--------------+------------+----------------+---------------------+------------+-------------+
 
| %    | db_monitor | user_app | accesslog  | root@localhost | 0000-00-00 00:00:00 | Insert     |             |
 
+------+------------+--------------+------------+----------------+---------------------+------------+-------------+
 
1 row in set (0.02 sec)
 
mysql.sock@mysql>
 
[/code]
 
把init_command   注释掉后,  一切都ok 了。
 
原来之前因为某个事件 , 增加了一点审计功能, 就用init_command  实现了。
 
原来是忘记给repl 授权了。  
 
导致  repl 再次登录的时候, 无权操作这个insert 语句报错。退出了。无法连接master .
 
以上是“init_command导致mysql 5.6主从连接失败怎么办”这篇文章的所有内容,感谢各位的阅读!

(编辑:52站长网)

【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!

    热点阅读