maria-developers team mailing list archive

[Kristian Nielsen <knielsen@xxxxxxxxxxxxxxx>]

Hi Daniel, Ian,

I have implemented a new system variable for global transaction ID and pushed
it into 10.0-base (so it should appear in 10.0.5 I suppose).

I have written some text for documenting the new variable, appended below.

Can one of you help me get this text into the Knowledgebase with proper
formatting and cross-referencing across relevant pages?

 - Kristian.

-----------------------------------------------------------------------

Variable: gtid_binlog_state
Scope: global
Dynamic: Yes
Type: String

The variable gtid_binlog_state holds the internal state of the binlog. The
state consists of the last GTID ever logged to the binary log for every
combination of domain_id and server_id. This information is used by the master
to determine whether a given GTID has been logged to the binlog in the past,
even if it has later been deleted due to binlog purge. For each domain_id, the
last entry in @@gtid_binlog_state is the last GTID logged into binlog,
ie. this is the value that appears in @@gtid_binlog_pos.

Normally this internal state is not needed by users, as @@gtid_binlog_pos is
more useful in most cases. The main usage of @@gtid_binlog_state is to restore
the state of the binlog after RESET MASTER (or equivalently if the binlog
files are lost). If the value of @@gtid_binlog_state is saved before RESET
MASTER and restored afterwards, the master will retain information about past
history, same as if PURGE BINARY LOGS had been used (of course the actual
events in the binary logs are still deleted).

Note that to set the value of @@gtid_binlog_state, the binary log must be
empty, that is it must not contain any GTID events and the previous value of
@@gtid_binlog_state must be the empty string. If not, then RESET MASTER must
be used first to erase the binary log first.

For completeness, note that setting @@gtid_binlog_state internally executes a
RESET MASTER. This is normally not noticable as it can only be changed when
the binlog is empty of GTID events. However, if executed eg. immediately after
upgrading to MariaDB 10, it is possible that the binlog is non-empty but
without any GTID events, in which case all such events will be deleted, just
as if RESET MASTER had been run.