Details
Major
Description
Test rpl.rpl_rotate_purge_deadlock has in the beginning:
source include/master-slave.inc; source include/have_debug_sync.inc; source include/have_binlog_format_row.inc; source include/have_innodb.inc;
It means that when debug_sync is not enabled, or binlog format is not 'row', or there's no innodb master-slave configuration will be already set up and won't be torn down. So any subsequent test involving master-slave configuration will break because it won't be able to set it up.
I guess just making master-slave.inc the last in this list is enough to fix the problem.
Gliffy Diagrams
Attachments
Activity
- All
- Comments
- Work Log
- History
- Activity
- Transitions
It looks like you are right about intended behavior – I can't reproduce the error coupling rpl.rpl_rotate_purge_deadlock with randomly chosen other test (I didn't try all of them). But the following set of commands reproduces the problem reliably:
cmake . -DCMAKE_BUILD_TYPE=Release
make
cd mysql-test/
./mtr rpl.rpl_rotate_purge_deadlock rpl.rpl_not_null_innodb
You are right. Server restart doesn't save the day because MTR is too efficient, it only restarts the master (since the test has a master config file), but not the slave.
Pushed into maria/5.5 as revno 3668
Hi Pavel,
Have you ever seen an actual failure due to the described problem with rpl.rpl_rotate_purge_deadlock?
I'm wondering because while generally you are right about the wrong order, in practice I think nothing wrong should ever happen since the test in question has its own config file, so the servers should be restarted after it anyway. So if you did see a failure, maybe we should look deeper into MTR logic.