maria-developers team mailing list archive

[Kristian Nielsen <knielsen@xxxxxxxxxxxxxxx>]

Pavel Ivanov <pivanof@xxxxxxxxxx> writes:

>> My intention for this was to use the existing facilities for such backup/restore,
>> like mysqldump and XtraDB.
>
> I didn't check with the 10.0.2, but in 10.0.0 XtraDB didn't compile.
> Does it compile now?

I do not know, I do not think anyone tried. It may need some updates, as 10.0
is based on InnoDB from 5.6. But surely it will be made to work at some point.

>> If you take a mysqldump or XtraDB backup of the master, there are facilities
>> to get the current binlog position (filename/offset) in a non-blocking way.
>> You can then convert that into a GTID position with BINLOG_GTID_POS(filename,
>> offset). Finally, on the new slave, you SET GLOBAL gtid_pos to the correct
>> value. This is how I planned slave provisioning to work.
>>
>> You should not think of somehow copying around <log-bin>.state on its own
>> without the binlog files, this will not work. Of course, a full consistent
>> filesystem copy of everything (datadir and binlogs), like tar file of a
>> stopped server or LVM snapshot or whatever, is ok.
>

> We are taking backup by the full consistent filesystem copy of
> datadir.

> Copying binlogs seem to be overkill because they can be huge
> and the only info that matters in there is information to restore
> gtid_pos. Somehow I thought that additional copying or <log-bin>.state

Agree it seems overkill. In fact, you only need the last binlog file (or last
two just around binlog rotate). But that may be too fiddly to be worth it.

> will be enough for MariaDB to restore that state. If it's not then I
> guess we'll just need to extract the gtid_pos while taking backup and
> then force-set it during the restore. This should work, right?

Yes, that should work fine.

Though I wonder - if you are not copying binlog files, how do you deal with
transactions inside InnoDB that are in the prepared state when the consistent
filesystem copy is taken? Normally, the binlog is used to recover correctly,
by rolling back those that did not commit to the binlog, and committing those
that do. But without the binlog on the restored server, I wonder how you
handle this.

Are you sure that you get prepared transactions rolled back/committed
correctly inside InnoDB? And that the resulting InnoDB state matches the
binlog position you associate with the restored backup?

 - Kristian.