maria-developers team mailing list archive

[andrei.elkin@xxxxxxxxxx]

> Andrei Elkin <andrei.elkin@xxxxxxxxxx> writes:
>
>> And really why not
>>
>>   3. SET @@GLOBAL.gtid_binlog_state=list-without-d;
>
> The main issue I see with this if the master is actively adding new
> transactions (in other domains than d). It will be hard for the user
> to know
> the right value to set without doing something like FLUSH TABLES WITH
> READ
> LOCK during the operation to stop transactions between selecting
> @@global.gtid_binlog_state and SETting the new value.
>
> Whereas FLUSH BINARY LOGS DELETE DOMAIN d only needs a shorter-lived
> lock on
> the binlog while doing the rotation and check.

Right.

>
> Other than that, I agree SET gtid_binlog_state could be a good fit.

Then a function to discard a domain term would do:

 SET @@gtid_binlog_state=gtid_discard_domain(@@gtid_binlog_state,'d')

While this time it would be new object introduced still it's of var
setting semantics and might be generally useful too.

How about it?

Andrei


>
>>   the new state value must cover (include as a math set) all gtids
>> in
>>   the current list of binlog files. (Naturally I consider [presume]
>> Gtid_list
>>   header of a binlog file assumes there are no gaps or out-of-order
>>   in the preceding files. That is it provides the right-hand-side of
>>   gtid seqno range for each domain-server pair).
>
> Yes. (There is no strict requirement of no gaps in MariaDB GTID, but
> it
> should not matter here).
>
>> So we conduct the 1-3 procedure. Pseudo-sql would go like
>>
>>   mysql> /* 1. */ SELECT @@global.gtid_binlog_state into
>>   mysql> @pre_purge_state;
>>   mysql> /* 2. */ PURGE LOGS to 'b.2'
>>   mysql> /* 3. */ SET
>>   mysql> @@global.gtid_binlog_state="REPLACE"(@pre_purge_state,
>>   mysql> '0-1-1', '');
>
> So this requires that there are no new transactions written to binlog
> between (1) and (3).
>
>> The check technically is a comparison between Gtid_list.d term in
>> the oldest file and @pre_purge_state.d one.
>> If they are equal the current binlog files are proven not to contain
>> events from 'd'.
>
> Agree.
>
>  - Kristian.
>