Hi Oystein,
> >> 2. I do not understand why the binlog handling is necessary in
> >> LOGGER::backup_history_log_write/backup_progress_log_write.
> >> Please, explain. See [1] below.
> >
> > We must ensure the entries written to the backup logs are not
> > replicated to the slave. They should never be replicated. See R06.
> >
>
> But can't you turn it off for the entire backup/restore? Do
> you have to turn it off for every write?
If we don't include it in the logging code, it is possible for the changes
to be written to the binary log because restore (or backup) complete befores
the final log entries are written. This way, we are ensured the backup log
entries are never written to the log. See the other forms of logs -- they do
exactly the same thing.
> >> 3. Please, verify that restore may not enable slave
> connections after
> >> restore when it was disabled before restore. [3]
> >
> > This is ok. We set disable_slaves = FALSE regardless of whether we
> > turned it on (set to TRUE) or not. So this is safe to call
> without a
> > guard or checking to see if it was set to TRUE previously.
>
> And there can not be a scenario where a user has disabled
> slaves prior to restore and do not want to have them enabled
> as a side effect of executing restore?
I don't know. I suppose it is possible but it was never considered in the
lengthy architecture discussions. If you can think of such a scenario where
a user would indeed like this, we can add it via a feature request (bug
report). Feel free to do so if you'd like.
> >> 4. Please, use SET SESSION debug="-d" to turn off set_backup_id.
> >> Otherwise, test will generate 20MB of master.err which
> takes a very
> >> long time to parse at the end of the test. [4]
> >
> > Done. This must be a new and recent change to MTR or
> something because
> > it never caused this problem before. Can you please check
> other backup
> > tests and if you find them in those tests issue a bug report to fix
> > them? Thanks.
>
> I will.
Thanks.
Chuck
