Rafal,
A new patch has been committed.
http://lists.mysql.com/commits/61286
Per our conversation today, I have made the following changes.
Chuck
Rafal Somla wrote:
> STATUS
> ------
> Patch not approved - changes requested.
>
> REQUESTS
> --------
> 1. Implement this functionality inside Backup_restore_ctx - see [1] below.
done
> 2. Remove the possibility of race condition described in [4].
done -- in a different, simple way though
> SUGGESTIONS
> -----------
> 1. Initialize allow_slave_start in init_slave_start() [2].
done
> 2. Move the code used to implement this functionality from rpl_failsafe
> to sql_rpl. The latter contains code related to starting replication on
> the server, the former code related to failover handling - your code
> does not belong here.
done
> 3. Instead of introducing new restore_running(), use is_slave() function
> for the purpose after changing its semantics as follows:
declined suggestion -- want to keep it simple. However, I did rename the
method and make it more generic.
...
> 4. If you don't follow suggestion 3, consider renaming restore_running()
> for the reasons indicated in [3] below.R: implement inside
> Backup_restore_ctx
done
...
>> +connection slave1;
>> +--echo Restore is now complete.
>> +--replace_column 1 #
>> +reap;
>> +SET DEBUG_SYNC = 'now SIGNAL done';
>> +
>> +connection slave;
>> +
>> +SET DEBUG_SYNC = 'now WAIT_FOR done';
>
> Are you sure this synchronization is needed? Aren't the statements after
> "connection slave" executed only when "reap" completes the RESTORE
> statement?
Yes, actually I am sure. This one baffled me for a while. It turns out
it is possible for MTR (at least on Windows) to stall at this point if I
leave this synchronization out. Strange, but true.
Chuck
