maria-developers team mailing list archive

[Kristian Nielsen <knielsen@xxxxxxxxxxxxxxx>]

Pavel Ivanov <pivanof@xxxxxxxxxx> writes:

> We reaching consistency in the backup by shutting down the server. I

So thinking about this again ...

So if we shut down the server gracefully, copy over everything to a new
server, delete all binlogs (or omit binlogs from the copy), restart the server
- then it could actually work to read the <log-bin>.state file.

The result on the new server would be exactly the same as if we copied
everything (including all binlogs), and then immediately purged all binlog
files except the newly created one.

Your use case seems valid - do you think it is worth it to have that (reading
<log-bin>.state at server startup if there are no binlogs)? The implementation
should be trivial.

The main potential issue I can think of is if users do it wrong, eg. take an
LVM snapshot of a _running_ server, remove the binlogs, forget to remove the
<log-bin>.state. Then the binlog state will be wrong (it will be a stale file
from when the original server was last restarted). But I could solve that by
simply unlinking <log-bin>.state during server startup. That seems like a good
thing to do anyway.

With this, it should be possible to shut down master, copy all files except
<log-bin>.NNNNNN/<log-bin>.index, start server on new copy, join original
master as a slave using GTID.

What do you think? I did not understand your use case correctly the first time
I read it, as I was thinking about snapshots of a running server...

 - Kristian.