maria-developers team mailing list archive

[Pavel Ivanov <pivanof@xxxxxxxxxx>]

Sorry, I didn't quite understand.

On Sun, May 12, 2013 at 10:24 PM, Kristian Nielsen
<knielsen@xxxxxxxxxxxxxxx> wrote:
> Pavel Ivanov <pivanof@xxxxxxxxxx> writes:
>
>> I was thinking about your words above and they make me wonder: if we
>> have a master and it doesn't write its current state into
>> rpl_slave_state, then we shut down the master, and while it's out we
>> failover to another server. Then the first server comes back and
>> should start to replicate from the new master. But how will it know
>> which GTID to start from if it doesn't have any state in
>> rpl_slave_state?
>
> It uses what it has in the binlog (I call this the "binlog state").
>
> The value of @@GLOBAL.gtid_pos is obtained as follows:
>
>  - First take the row with the highest sub_id from mysql.rpl_slave_state, per
>    domain_id.
>
>  - Then look in the binlog state. If we have something there with higher
>    seq_no, then it overrides what was in rpl_slave_state.
>
> So basically if the last transaction originated on this server it uses the
> binlog state, if the last transaction was replicated it uses
> mysql.rpl_slave_state.

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?

>> I can guess that with a graceful shutdown there's also file
>> <log-bin>.state which seem to contain the last state of the binlog.
>> BTW, can you tell more about this file, how it participates in the
>> replication? Will it be used to restore gtid_pos after shutdown?
>
> <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?


Thank you,
Pavel