| Bug #84192 | Slave behind and continuous Xid_log_event entries in general log | ||
|---|---|---|---|
| Submitted: | 13 Dec 2016 19:50 | Modified: | 20 Dec 2016 23:10 |
| Reporter: | monty solomon | Email Updates: | |
| Status: | Can't repeat | Impact on me: | |
| Category: | MySQL Server | Severity: | S1 (Critical) |
| Version: | 5.7.13 | OS: | CentOS (6.7) |
| Assigned to: | MySQL Verification Team | CPU Architecture: | Any |
[13 Dec 2016 19:54]
monty solomon
mysql> select @@sync_binlog, @@innodb_flush_log_at_trx_commit\G
*************************** 1. row ***************************
@@sync_binlog: 0
@@innodb_flush_log_at_trx_commit: 2
1 row in set (0.00 sec)
[13 Dec 2016 19:56]
monty solomon
After a restart of the slave it appears to be catching up.
Seconds_Behind_Master: 9072
[13 Dec 2016 19:57]
monty solomon
Uptime: 23 min 59 sec Threads: 8 Questions: 10257202 Slow queries: 5 Opens: 206 Flush tables: 1 Open tables: 200 Queries per second avg: 7128.006
[13 Dec 2016 20:02]
monty solomon
I tried a stop/start of the slave before the restart and that did not help STOP SLAVE; START SLAVE;
[16 Dec 2016 12:54]
MySQL Verification Team
Hi, Thanks for your report but I don't see what are you considering a bug here? The commits you see in your log are normal and are not related to your slave lagging. What can influence your slave lagging is how you configure it, how powerful the machine is etc, but is not a bug. Can you elaborate please what you consider a bug here? With regards to configuration of the replication I can suggest some great support service for MySQL :) kind regards Bogdan Kecman
[20 Dec 2016 5:19]
monty solomon
The slave was behind and continued to get further behind even though it did not appear to be doing any work. After restarting the slave mysql server it did not have any problem catching up. It appears that the slave got in some strange state that was remedied by a restart. There did not appear to be any other viable option.
[20 Dec 2016 23:10]
MySQL Verification Team
Hi Monty, > It appears that the slave got in some strange state > that was remedied by a restart. There did not appear to be > any other viable option. That is very possible, and very possible it's caused by a bug but there's nothing in the log that helps us determine what/why happened and I can't reproduce the problem locally. All best Bogdan Kecman
Description: The slave was running behind and continued to get further behind. Seconds_Behind_Master: 15020 Looking at the general log on the slave I see many entries of the form 2016-12-13T19:44:17.299363Z 13 Query BEGIN 2016-12-13T19:44:17.299486Z 13 Query COMMIT /* implicit, from Xid_log_event * grep -c 'COMMIT /* implicit, from Xid_log_event *' general.log 3102911 zfgrep -c 'COMMIT /* implicit, from Xid_log_event *' general.log-201612131481644861.gz 1630292 How to repeat: I am not sure how to replicate this on demand. log_slave_updates = 1