[Maria-discuss] "Rewind" type of mechanisms?
Hi! I would like to know about following topic regarding MariaDB.We would like to run DB cluster with HA (high availability). -- E.g. with MaxScale. My Q:Does MariaDB support such mechanism which would be similar to pg_rewind? Reference: PostgreSQL supports such a rewind operation.Or, are there plans to support such regarding MariaDB? ( If such would be needed / useful. ) Rewind: "A typical scenario is to bring an old primary server back online after failover as a standby that follows the new primary." Target: robustness/stability of a DB cluster. Avoiding needs to manually fix DB cluster. Best Regards Sam
You can automatically resync either with gtid based async replication or with Galera without full reseeding. On Fri, Aug 19, 2022 at 11:57 AM Sam R. <samruohola@yahoo.com> wrote:
Hi!
I would like to know about following topic regarding MariaDB. We would like to run DB cluster with HA (high availability). -- E.g. with MaxScale.
My Q: Does MariaDB support such mechanism which would be similar to pg_rewind? Reference: PostgreSQL supports such a rewind operation. Or, are there plans to support such regarding MariaDB? ( If such would be needed / useful. )
Rewind: "A typical scenario is to bring an old primary server back online after failover as a standby that follows the new primary."
Target: robustness/stability of a DB cluster. Avoiding needs to manually fix DB cluster.
Best Regards Sam _______________________________________________ Mailing list: https://launchpad.net/~maria-discuss Post to : maria-discuss@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-discuss More help : https://help.launchpad.net/ListHelp
Thank you!
"You can automatically resync either with gtid based async replication"
Few questions: resync automatically --> Does it remove a possible (obsolete) rogue row? How long task is such resyncing operation? --> Does it "recreate" the whole DB node? Best Regards Samuli On Friday, August 19, 2022 at 12:23:03 PM GMT+3, Gordan Bobic <gordan.bobic@gmail.com> wrote: You can automatically resync either with gtid based async replication or with Galera without full reseeding. On Fri, Aug 19, 2022 at 11:57 AM Sam R. <samruohola@yahoo.com> wrote:
Hi!
I would like to know about following topic regarding MariaDB. We would like to run DB cluster with HA (high availability). -- E.g. with MaxScale.
My Q: Does MariaDB support such mechanism which would be similar to pg_rewind? Reference: PostgreSQL supports such a rewind operation. Or, are there plans to support such regarding MariaDB? ( If such would be needed / useful. )
Rewind: "A typical scenario is to bring an old primary server back online after failover as a standby that follows the new primary."
Target: robustness/stability of a DB cluster. Avoiding needs to manually fix DB cluster.
Best Regards Sam _______________________________________________ Mailing list: https://launchpad.net/~maria-discuss Post to : maria-discuss@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-discuss More help : https://help.launchpad.net/ListHelp
On Fri, Aug 19, 2022 at 12:37 PM Sam R. <samruohola@yahoo.com> wrote:
Thank you!
"You can automatically resync either with gtid based async replication"
Few questions: resync automatically --> Does it remove a possible (obsolete) rogue row?
In asynchronous replication, yes it does. In Galera, it doesn't because the node doesn't come online until it is fully in sync, and replication in Galera is synchronous.
How long task is such resyncing operation? --> Does it "recreate" the whole DB node?
Provided the replication logs on the other node haven't expired, it will be an incremental update. In async replication, that will be done by applying missing transactions from the donor node. In Galera it will be done by doing an incremental state transfer, logically they amount to the same thing. If the replication logs or the galera cache have expired while the node was down, Galera will do a full state transfer (all data from scratch) automatically. With async replication in that case you will have to reseed the node yourself using mariabackup or one of several other approaches, but this is reasonably well automatable.
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. Best Regards Sam
On Fri, Aug 19, 2022 at 3:05 PM Sam R. <samruohola@yahoo.com> 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.
Hi, Sam, It's not automatic, but you can replay binlog backwards and undo already committed changes: https://mariadb.com/kb/en/flashback/ On Aug 19, Sam R. wrote:
Gordan Bobic wrote:
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.
Yes. This may be the question after which I am with my emails.
Regards, Sergei VP of MariaDB Server Engineering and security@mariadb.org
participants (3)
-
Gordan Bobic -
Sam R. -
Sergei Golubchik