Rafal,
I have added all that you requested with the exceptions below.
>> +#
>> +# Use Case 1 - Backup performed on a master.
>> +# When a backup is performed on a master, the master shall not log
>> +# the backup event nor shall the master replicate any data
...
> More things can and should be checked:
>
> - check that nothing was added to master's binary log with SHOW BINLOG
> EVENTS.
> - check that slave is active after BACKUP on master
> - check that slave's master position was not changed
>
> I see some of these checked below in Case 3, which is confusing - do it
> here as this is the place to test what happens when you perform BACKUP
> on a master host.
>
I've added the above that aren't already there. See below for a
description of how I deal with the SHOW BINLOG EVENTS issues.
...
>> +#
>> +# Use Case 3 - Backup performed on a slave (part 1 of 2)
>> +# Test backup on slave but slave has not slaves.
>> +#
> (cut)
>> +--echo Backup_id = 600.
>> +BACKUP DATABASE rpl_backup TO 'rpl_bup_s1.bak';
>> +
>> +SET SESSION debug="d";
>> +
>> +--echo Check saving of master's binlog information.
>> +--echo Should have count(*) = 1.
>> +SELECT count(*) FROM mysql.backup_progress +WHERE backup_id = 600 AND
>> notes LIKE 'Recording master binlog information%';
>
> This does not check that a correct position has been reported.
Correct. See WL#4612. It is part of that work. I think this will take a
lot of work to do properly. However, the basic checking is in this test
for the other use cases you cited.
...
> Case 3 talks about "BACKUP on slave" but you perform it on master. This
> looks like still testing Case 1.
>
> Don't forget to test BACKUP on slave as well.
It's in there.
...
>> +#
>> +# Use Case 2 - Restore performed on a master.
>> +#
>> +
>> +# To ensure the master does not log anything in the binary log
>> +# during a restore, we first drop the database on the slave
>> +# then run the restore and after slave is restarted check to
>> +# see if database is still missing (it should be).
>> +
>
> Please do more:
>
> - check what is inserted into binlog on master
I've done basic checks. The problem is SHOW BINLOG EVENTS produces
different output depending on the logging format. Instead of showing the
binlog contents, I capture the binlog position before the backup or
restore then do a SHOW BINLOG EVENTS FROM... to show that nothing was
added (except for restore which includes the incident event).
> - check that slave is stopped after restore on master (due to the
> incident event).
It's in there. See wait_for_slave_to_stop calls.
> - check that restored data is not in the slave in case slave replicates
> a database which is being restored on master.
It's in there already.
> - check that new slaves can not connect when RESTORE runs on the master
This last one is part of WL#4612. I cannot create a test to do this. I
think we will need some more detailed design and planning (perhaps a
standalone test or changes to MTR) to get this to work.
>> +#
>> +# Use Case 5 - Backup run with no binary log.
>> +#
>> +
>
> Do we need to include this test case in a test checking how
> BACKUP/RESTORE interracts with binary logging and replication. Equally
> well, you could include a scenario where neither BACKUP nor RESTORE is
> executed ;)
Yes, it was specifically requested. See use case 5 in the worklog.
>> +#
>> +# Use Case 6 - Restore run with binary log turned on but no slaves
>> attached.
>> +#
>> +
>> +--echo backup_id = 505.
>> +RESTORE FROM 'rpl_bup_m4.bak';
>
> Check contents of the binary log, e.g., with SHOW BINLOG EVENTS.
Done.
Chuck
