maria-developers team mailing list archive
-
maria-developers team
-
Mailing list archive
-
Message #08965
Re: On the issue of Seconds_behind_master and Parallel Replication
----- On 16 Oct, 2015, at 3:57 PM, Jean-François Gagné jeanfrancois.gagne@xxxxxxxxxxx wrote:
> On 2015-10-15 08:16, Kristian Nielsen wrote:
>> Monty suggested changing the behaviour also for non-parallel mode - letting
>> Seconds_Behind_Master reflect only events actually committed, not just read
>> from the relay log. This would introduce an incompatible behaviour for
>> Seconds_Behind_Master, but could perhaps be done for 10.1, if desired. Doing
>> it in stable 10.0 would be more drastic.
>
> I agree with Monty: we should only update on commit and in both // and
> non-// cases.
+1 here. works for me too.
> Having yo-yo in seconds-behind-master (because of a long running
> transaction) should probably be considered a bug and should be fixed
> (non-// case).
>
> The commit event (if we can call it as such) is the only reliable (-ish)
> timing synchronization point in the binlog stream, all the rest depends
> on execution time and session-latency. The timestamp of those
> non-commit events should not be trusted for delay computation.
>
> Fixing that in 10.0 has too many implications, I think fixing in 10.1 is
> a good target.
>
> If something needs to be done in 10.0, and if it is not too hard, adding
> a "improved_seconds_behind_master" global variables for this behavior
> could be done. In 10.0, the default value of this variable would be 0,
> in 10.1 it would be 1. If that path is chosen, I think this variable
> should be deprecated in 10.1 and go away in 10.2 to reduce code complexity.
seconds_behind_master=commit?
I tend to think people using 10.0 haven't seen or cared enough about it to be worth fixing in 10.0.
--
--
Daniel Black, Engineer @ Open Query (http://openquery.com.au)
Remote expertise & maintenance for MySQL/MariaDB server environments.
References