On Wed, May 15, 2013 at 1:11 AM, Kristian Nielsen <knielsen@knielsen-hq.org> wrote:
Pavel Ivanov <pivanof@google.com> 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...
This sounds good to me. So always reading the state file (unless crash is detected) and deleting the file after the state is read. It seems that in such situation it will be even impossible to find the state file and detect a crash at the same time. If you don't see any other issues with this it looks worth implementing. Pavel