Bug #47161 | rpl_backup_shutdown fails sporadically on PB2 | ||
---|---|---|---|
Submitted: | 7 Sep 2009 0:09 | Modified: | 11 Jan 2010 16:14 |
Reporter: | Luis Soares | Email Updates: | |
Status: | Duplicate | Impact on me: | |
Category: | Tests: Replication | Severity: | S3 (Non-critical) |
Version: | 5.4 | OS: | Any |
Assigned to: | Assigned Account | CPU Architecture: | Any |
Tags: | experimental, mysql-next-bugfixing, pb2, test failure |
[7 Sep 2009 0:09]
Luis Soares
[10 Sep 2009 6:10]
Libing Song
Hi Omer, the issue is with the slave I/O thread shutdown that hangs and does not execute
[10 Sep 2009 7:05]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/82881 2814 Li-Bing.Song@sun.com 2009-09-10 Bug #47161 rpl_backup_shutdown fails sporadically on PB2 The master is shutdowned and restarted before "RESTORE FROM 'db12m.bak' is executed" ; Thus will result the slave I/O thread to reconnect to master automatically. It sometimes happens after 'RESTORE' command has started on master. Master will send an error to slave and then close the connection if 'RESTORE' command is running, and slave I/O thread will stop after receiving the error. So the incident RESTORE_ON_MASTER which leads to stop of the slave SQL thread can not be sent from master to slave and the slave SQL thread will keep on runing. As a result, wait_for_slave_sql_to_stop.inc will timeout. This patch write code to stop the slave I/O thread before 'RESTORE' command starting on master and restart it after 'RESTORE' command has done.
[16 Sep 2009 7:13]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/83421 2818 Li-Bing.Song@sun.com 2009-09-16 Bug #47161 rpl_backup_shutdown fails sporadically on PB2 The master is shutdowned and restarted before "RESTORE FROM 'db12m.bak' is executed". At that point, slave I/O thread notices that connection has been broken, and attempt to automatically reconnect. Sometimes, connection succeeds before the 'RESTORE' operation is issued on the master. This is no problem, because slave I/O thread will read the INCIDENT EVENT from master binlog and SQL thread will eventually stop. However, if slave I/O thread attempts connection when the 'RESTORE' command already ongoing on the master, then master will refuse it and connection will not be retried. As a consequence, Slave I/O thread will not be able to read the INCIDENT EVENT, ultimately causing slave SQL thread not be aware of the incident event. This will make in slave SQL thread not to stop and ultimately test will time out ("source include/wait_for_slave_sql_to_stop.inc"). This patch write code to stop the slave I/O thread before 'RESTORE' command starting on master and restart it after 'RESTORE' command has done.
[19 Sep 2009 11:18]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/83795 2817 Li-Bing.Song@sun.com 2009-09-19 Bug #47161 rpl_backup_shutdown fails sporadically on PB2 The master is shutdowned and restarted before "RESTORE FROM 'db12m.bak' is executed". At that point, slave I/O thread notices that connection has been broken, and attempt to automatically reconnect. Sometimes, connection succeeds before the 'RESTORE' operation is issued on the master. This is no problem, because slave I/O thread will read the INCIDENT EVENT from master binlog and SQL thread will eventually stop. However, if slave I/O thread attempts connection when the 'RESTORE' command already ongoing on the master, then master will refuse it and connection will not be retried. As a consequence, Slave I/O thread will not be able to read the INCIDENT EVENT, ultimately causing slave SQL thread not be aware of the incident event. This will make in slave SQL thread not to stop and ultimately test will time out ("source include/wait_for_slave_sql_to_stop.inc"). This patch write code to stop the slave I/O thread before 'RESTORE' command starting on master and restart it after 'RESTORE' command has done.
[21 Sep 2009 13:37]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/83940 2861 Li-Bing.Song@sun.com 2009-09-21 Bug #47161 rpl_backup_shutdown fails sporadically on PB2 The master is shutdowned and restarted before "RESTORE FROM 'db12m.bak' is executed". At that point, slave I/O thread notices that connection has been broken, and attempt to automatically reconnect. Sometimes, connection succeeds before the 'RESTORE' operation is issued on the master. This is no problem, because slave I/O thread will read the INCIDENT EVENT from master binlog and SQL thread will eventually stop. However, if slave I/O thread attempts connection when the 'RESTORE' command already ongoing on the master, then master will refuse it and connection will not be retried. As a consequence, Slave I/O thread will not be able to read the INCIDENT EVENT, ultimately causing slave SQL thread not be aware of the incident event. This will make in slave SQL thread not to stop and ultimately test will time out ("source include/wait_for_slave_sql_to_stop.inc"). This patch write code to stop the slave I/O thread before 'RESTORE' command starting on master and restart it after 'RESTORE' command has done.
[25 Sep 2009 2:55]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/84579 2839 Li-Bing.Song@sun.com 2009-09-25 Bug #47161 rpl_backup_shutdown fails sporadically on PB2 The master is shutdowned and restarted before "RESTORE FROM 'db12m.bak' is executed". At that point, slave I/O thread notices that connection has been broken, and attempt to automatically reconnect. Sometimes, connection succeeds before the 'RESTORE' operation is issued on the master. This is no problem, because slave I/O thread will read the INCIDENT EVENT from master binlog and SQL thread will eventually stop. However, if slave I/O thread attempts connection when the 'RESTORE' command already ongoing on the master, then master will refuse it and connection will not be retried. As a consequence, Slave I/O thread will not be able to read the INCIDENT EVENT, ultimately causing slave SQL thread not be aware of the incident event. This will make in slave SQL thread not to stop and ultimately test will time out ("source include/wait_for_slave_sql_to_stop.inc"). This patch write code to stop the slave I/O thread before 'RESTORE' command starting on master and restart it after 'RESTORE' command has done.
[25 Sep 2009 3:10]
Libing Song
Pushed to mysql-6.0-codebase-bugfixing
[30 Sep 2009 8:16]
Bugs System
Pushed into 6.0.14-alpha (revid:alik@sun.com-20090929093622-1mooerbh12e97zux) (version source revid:alik@sun.com-20090927203924-087s36mrs0uxepwb) (merge vers: 6.0.14-alpha) (pib:11)
[1 Oct 2009 8:26]
Jon Stephens
Testing only, no end-user changes to document. Closed.
[22 Oct 2009 6:30]
Alexander Nozdrin
It fails again with the following symptom: @@ -177,6 +177,7 @@ mtr mysql test +test # Connecting to master Marking the test experimental.
[22 Oct 2009 6:32]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/87726 3644 Alexander Nozdrin 2009-10-22 Mark rpl_backup_shutdown experimental due to Bug#47161.
[22 Oct 2009 6:35]
Bugs System
Pushed into 6.0.14-alpha (revid:alik@sun.com-20091022063126-l0qzirh9xyhp0bpc) (version source revid:alik@sun.com-20091022063126-l0qzirh9xyhp0bpc) (merge vers: 6.0.14-alpha) (pib:13)
[11 Jan 2010 16:14]
Andrei Elkin
LiBing, I setting your bug optimistically as a dup of Bug #50176. I suggest you to try on http://lists.mysql.com/commits/96475 and if it suits indeed then do nothing as the fixes are about to be pushed to mysql-backup-backport. Thanks, Andrei