maria-discuss team mailing list archive

[Gordan Bobic <gordan.bobic@xxxxxxxxx>]

On Fri, Aug 19, 2022 at 3:05 PM Sam R. <samruohola@xxxxxxxxx> wrote:
>
> Thank you again!
>
> Sam wrote:
>
> Q: > > resync automatically --> Does it remove a possible (obsolete) rogue row?
>
> Gordan Bobic wrote:
>
> A: >  In asynchronous replication, yes it does.
>
> Only to double check the same. To make sure we are discussing the same context.
>
> So, we are talking in the following context: in the "rewind" type of situation? (Rogue row.)
> Rogue row is on old Master. Old Master has been switched to Standby mode. --> Rogue row gets rewinded automatically?
>
> In other words,
> With rogue row and rewind, I mean following situation:
>
> Master -- Slave
>
> 1. Row is inserted to Master:
> Master (new row) -- Slave
>
> 2. The row does not end up on Slave DB node. E.g. because of a sudden failover.
>
> 3. So:
> Master (has rogue row)  --  Slave (rogue row does not end up on the Slave node)
>
> 4. The sudden failover happens in the middle.
>
> ==>
> 5. The previous Master becomes New Slave:
>
> New Slave (old Master, with the rogue row)  -- New Master (old Slave)
>
> 6. Now: "New Slave" has the rogue row. Such rogue row would need to be rewinded.
>
> So, only to double check (repeating the same question).
> Q: MariaDB is able to rewind such automatically?
>
> Is my understanding correct?
>
> Async replication would be in use, with MaxScale in use.

When the old master comes back up, the new master will get the missing
transaction provided it doesn't violate any constraints.
If you want to avoid that race condition, then you will have to use
Galera, because in Galera the slave cannot be behind.
There is no built in rewind option to roll back a committed
transaction that I am aware of - though it probably could be
implemented by reverse playback of row based binlog.