maria-developers team mailing list archive

[Pavel Ivanov <pivanof@xxxxxxxxxx>]

Krisitan,

Did you figure out what would be the best solution here?

Thank you,
Pavel

On Tue, Sep 3, 2013 at 2:05 AM, Kristian Nielsen
<knielsen@xxxxxxxxxxxxxxx> wrote:
> Kristian Nielsen <knielsen@xxxxxxxxxxxxxxx> writes:
>
>> The main problem I see is what should be the default? I suppose we cannot
>> safely change the default for --replicate-same-server-id. On the other hand,
>> if users explicitly set --replicate-same-server-id=0, then it really does not
>> seem correct that some events with same server id are nevertheless replicated
>> depending on some complicated GTID semantics. So the curse of backwards
>> compatibility seems to hit here...
>
> Hm, on second thoughts...
>
> CHANGE MASTER TO ... master_use_gtid is a new feature, so backwards
> compatibility does not really apply. And in GTID mode, we have a better way to
> prevent loops - the seq_no. Even in non-strict mode this can be relied on for
> our own server_id, at least.
>
> So perhaps it is better to just say that --replicate-same-server-id does not
> apply to GTID mode at all. Instead, in GTID mode, if we receive an event with
> our own server_id and smaller seq_no than what we already have, we skip
> it. Otherwise we apply it. That should be correct in the important use-case
> that you mentioned (restoring old backup), as well as in ring topologies.
>
> I need to think on this a bit more to be sure, but it seems like a possible
> solution.
>
>  - Kristian.