Because --delete-master-logs immediately purges logs after flushing,
it is possible the binlog dump thread would still be using the old
log when the purge executes, disallowing the file from being
deleted.
This patch institutes a work-around in the test as follows:
1) temporarily stop the slave so there is no chance the old binlog
is still being referenced.
2) set master_use_gtid=Slave_pos so the slave can still appear
up-to-date on the master after the master flushes/purges its logs
(while the slave is offline). Otherwise (i.e. if using binlog
file/pos), the slave would point to a purged log file, and receive
an error immediately upon connecting to the master.
Reviewed By
============
Andrei Elkin <andrei.elkin@mariadb.com>
Extending the rpl_mysqldump_slave.test to incorporate the
delete-master-logs option, and this options is alias of
get binlogs: show master status -> flush logs -> purge binary logs to <new_binlog>
sequence and this test is derived using the same pattern.
also we measure the pre and post log state
on the master following the mysqldump process. Introducing
assertions to validate the correct state.
