maria-developers team mailing list archive

[Pavel Ivanov <pivanof@xxxxxxxxxx>]

Thank you.

Quick note:
Sys_var_gtid_binlog_state::global_update() has label "err" in the
wrong place -- it tries to free "data" before it's allocated.

And as I picked up rev 3682 from 10.0-base it also has problems:
New variables "rev" and "glev" in the
write_ignored_events_info_to_relay_log should be initialized to NULL.
For the new code in Gtid_list_log_event::Gtid_list_log_event() instead
of "#ifdef MYSQL_SERVER" you probably wanted to write "#if
defined(MYSQL_SERVER) && defined(HAVE_REPLICATION)" or "#if
defined(MYSQL_SERVER) && !defined(EMBEDDED_LIBRARY)".


Pavel

On Thu, Aug 22, 2013 at 7:27 AM, Kristian Nielsen
<knielsen@xxxxxxxxxxxxxxx> wrote:
> Kristian Nielsen <knielsen@xxxxxxxxxxxxxxx> writes:
>
>> If you have time to test this then that would be a nice help. I'll see if I
>> can come up with a quick patch (ie. later today or tomorrow).
>
> Please try this patch and let me know if you find any issues. I still need to
> implement test cases, but it seems to work from quick manual testing.
>
> If you use this to save and restore the internal binlog state across deleting
> the binlogs, you should be able to have things work the same as if FLUSH LOGS
> + PURGE BINARY LOGS had been used, and avoid all the small issues that were
> caused by the deletion of the binlogs.
>
> I've attached the patch and also appended some text that I indend to add to
> the documentation.
>
>  - 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.
>
> 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 lost).
>
> 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.
> -----------------------------------------------------------------------
>