Pavel Ivanov <pivanof@google.com> writes:
Sorry, I didn't quite understand.
Sorry for being unclear, let me elaborate:
You didn't mention <log-bin>.state here. Is it intentional? Does it try to look into <log-bin>.state after rpl_slave_state and binlogs? Or e.g. in the situation when binlogs are not found?
There is just a single binlog state. The binlog state consists of the last GTID logged into the binlog for every (domain_id, server_id) pair. It also remembers the most recent GTID per domain. During normal server operation, the binlog state is kept only in-memory. The binlog state can be recovered from the binlog simply by scanning and recording every GTID encountered on the way. We do this after a crash. However, as an optimisation, to avoid having to scan binlog files at normal startup, we write out the binlog state to <log-bin>.state at server shutdown and read it back in at server startup. This is the only use of the file <log-bin>.state.
<log-bin>.state contains the current binlog state at the time of shutdown. This is used to be able to output the correct Gtid_list event at the start of the new binlog created at server startup, and also to initialise the sequence number counter for new events.
Again it "used to be" which means it's not used to do that anymore?
Just bad wording on my part, I meant "it is used", not that "it used to be". So to clarify: The server maintains an in-memory struct rpl_binlog_state with last GTIDs binlogged per-domain and per-(domain_id,server_id). At server shutdown, this in-memory state is saved to <log-bin>.state. At server startup, if we detect that binlog was properly closed and we do not need to do crash recovery, the in-memory struct rpl_binlog_state is initialised from the file <log-bin>.state. If we detect that we crashed prior and need to do crash recovery, <log-bin>.state is not consulted. Instead the in-memory struct rpl_binlog_state is initialised during the scan of the binlog, as part of crash recovery. I hope this makes things clear, - Kristian.