maria-developers team mailing list archive

[Pavel Ivanov <pivanof@xxxxxxxxxx>]

Kristian,

Unfortunately this doesn't work as expected.
I took 10.0-base r3685. Started new just bootstrapped server with
server_id = 1. It has @@global.gtid_binlog_pos,
@@global.gtid_slave_pos and @@global.gtid_current_pos empty. Then I
execute

set global gtid_binlog_state = '0-10-10'

After that @@global.gtid_binlog_pos = '0-10-10' as expected, but both
@@global.gtid_slave_pos and @@global.gtid_current_pos are still empty.
Because of that server won't be able to replicate from master.
If I set gtid_binlog_state to '0-1-10' though
@@global.gtid_current_pos changes to '0-1-10' and everything is fine.

It looks like the problem is in the server_id check in the first loop
in rpl_slave_state::iterate(). Can it be removed from there?


Pavel

On Thu, Aug 22, 2013 at 1:26 PM, Pavel Ivanov <pivanof@xxxxxxxxxx> wrote:
> 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.
>> -----------------------------------------------------------------------
>>