bzr commit into mysql-6.0-bugfixing branch (Li-Bing.Song:2839) Bug#47161

[Li-Bing.Song]

#At file:///home/anders/work/bzrwork/mysql-6.0-codebase-bugfixing/ based on revid:tor.didriksen@stripped

 2839 Li-Bing.Song@stripped	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.

    modified:
      mysql-test/suite/rpl/r/rpl_backup_shutdown.result
      mysql-test/suite/rpl/t/rpl_backup_shutdown.test
=== modified file 'mysql-test/suite/rpl/r/rpl_backup_shutdown.result'
--- a/mysql-test/suite/rpl/r/rpl_backup_shutdown.result	2009-04-29 18:20:21 +0000
+++ b/mysql-test/suite/rpl/r/rpl_backup_shutdown.result	2009-09-25 02:55:21 +0000
@@ -110,12 +110,14 @@ DROP DATABASE db2;
 --> Start master server ...
 SHOW DATABASES LIKE 'db%';
 Database (db%)
+STOP SLAVE IO_THREAD;
 # Perform Restore
 RESTORE FROM 'db12m.bak';
 backup_id
 #
 # Slave will be stopped as result of restore incident event
 # Connecting to slave...
+START SLAVE IO_THREAD;
 # Check the slave status
 SHOW SLAVE STATUS;
 Slave_IO_State	#

=== modified file 'mysql-test/suite/rpl/t/rpl_backup_shutdown.test'
--- a/mysql-test/suite/rpl/t/rpl_backup_shutdown.test	2009-04-29 18:20:21 +0000
+++ b/mysql-test/suite/rpl/t/rpl_backup_shutdown.test	2009-09-25 02:55:21 +0000
@@ -69,6 +69,25 @@ EOF
 
 SHOW DATABASES LIKE 'db%';
 
+# 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").
+connection slave;
+STOP SLAVE IO_THREAD;
+source include/wait_for_slave_io_to_stop.inc;
+
+connection master;
 --echo # Perform Restore
 --replace_column 1 #
 RESTORE FROM 'db12m.bak';
@@ -76,6 +95,10 @@ RESTORE FROM 'db12m.bak';
 --echo # Slave will be stopped as result of restore incident event
 --echo # Connecting to slave...
 connection slave;
+
+START SLAVE IO_THREAD;
+source include/wait_for_slave_io_to_start.inc;
+
 source include/wait_for_slave_sql_to_stop.inc;
 
 --echo # Check the slave status


Attachment: [text/bzr-bundle] bzr/[e-mail]