Bug #51129 Backup and repl tests fail in mtr when using replicate_*_table option
Submitted: 12 Feb 2010 1:49 Modified: 19 Feb 2010 14:53
Reporter: Hema Sridharan Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL Server: Backup Severity:S3 (Non-critical)
Version:mysql-5.5 OS:Any
Assigned to: Thava Alagu CPU Architecture:Any

[12 Feb 2010 1:49] Hema Sridharan
Description:
* Set up master and slave servers and enable the server option --replicate-do-table=db1.t11
( Replication is possible only for db1.t11. All other tables and databases are ignored)
* Create database db1
* Create table db1.t11 and db1.t12
[Create another table(t12) in db1 which is not involved in replication.]
* Perform backup of db1 in master
* Execute restore of db1 in master . This will stop replication and we need to restart manually
* Perform some data manipulations for t11 in master. Ensure that replication continues and updates are visible in slave.

Now run the test in mtr, it will fail by generating warnings / errors

worker[1] Using MTR_BUILD_THREAD 300, with reserved ports 13000..13009
rpl.rpl_backup_best 'row'                [ fail ]  Found warnings/errors in server log file!

The mysqld.2.err log file shows the following error messages,

100212  3:44:26 [Warning] Slave: Slave SQL thread ignored the query because of replicate-*-table rules Error_code: 1237

100212  3:44:26 [ERROR] Slave SQL: The incident RESTORE_ON_MASTER occured on the master. Message: A restore operation was initiated on the master. Error_code: 1590
100212  3:44:26 [ERROR] Slave: Slave SQL thread ignored the query because of replicate-*-table rules Error_code: 1237
100212  3:44:26 [ERROR] Error running query, slave SQL thread aborted. Fix the problem, and restart the slave SQL thread with "SLAVE START". We stopped at log 'master-bin.000001' position 859
100212  3:44:26 [ERROR] Error reading packet from server: Lost connection to MySQL server during query ( server_errno=2013)

NOTE: The tests will pass when db1.t12 table is not created(or disabled)

How to repeat:
Please find the attached test case to repeat the failure.
Note that you need to create opt file including server option  --replicate-do-table=db1.t11
[12 Feb 2010 1:49] Hema Sridharan
Test file

Attachment: rpl_backup_bug.test (application/test, text), 2.49 KiB.

[12 Feb 2010 1:50] Hema Sridharan
Result file

Attachment: rpl_backup_bug.result (application/octet-stream, text), 3.10 KiB.

[12 Feb 2010 6:51] Sveta Smirnova
Thank you for the report.

Verified as described.
[12 Feb 2010 8:18] Rafal Somla
Hema,

It is not clear from the description if the rpl_backup_best test is run against a server with --replicate-do-table option enabled. If this is the case then it could be that the errors shown in the server log are expected - they are normal reaction to seeing a query which is filtered out by --replicate-* option or seeing an incident event. If I am right then the correct action would be to suppress these errors in test script.
[19 Feb 2010 14:53] Thava Alagu
The failure is caused by the warning message that the additional tables have been filtered out at slave. There is no server issue. This failure can be fixed by
suppressing following warning message in tests:

 [Warning] Slave: Slave SQL thread ignored the query because of replicate-*-table rules Error_code: 1237
[19 Feb 2010 15:39] Thava Alagu
Also note that the call to add the suppression of warning message should be done from each connection which generates these warning messages (See Bug#46996).
Adding following lines for this test should work:

connection slave;
# Add suppression for expected warning(s) in slaves error log 
call mtr.add_suppression("Slave: Slave SQL thread ignored the query because of replicate-.*-table rules Error_code: 1237");