Does BinlogClient support cluster?

[rusuly]

Does BinlogClient support cluster?

[rusuly]

also, be informed that BinlogClient doesn't support reconnecting right now. I need some time to think about how to implement keep-alive feature properly

[rusuly]

Hi,
Currently, it doesn't.
You could use FromGtid() method for GTID-based replication but currently, it doesn't implement GtidSet

Are you talking about a simple master-slave replication cluster configured manually or a complex tool like Galera Cluster for master-master replication and automatic failover?

[ElderJames]

The second. I want to be highly available.

[rusuly]

In theory, GTID is designed for replication with failovers and allows to support multi-master setup.
I am going to implement GtidSet for MySQL 5.6+ later this week or by the end of the month.
But I have no idea how to integrate it with custom coordination software like Galera Cluster.

[rusuly]

Hi,
I'm working on the task(GtidSet for MySQL 5.6-8.0).
I think it will be ready in two days.
If you need MariaDB let me know(as the fork has different Gtid list implementation)

[ElderJames]

For now,I only use MySQL.
It would be very helpful if it supports GtidSet.

[rusuly]

Sorry,
still working on the task

[rusuly]

Hi again,
I just finished GtidSet.

To properly support cluster replication failover please make sure you understand:

• GtidSet concept as well as @@gtid_purged and @@gtid_executed.
• Gtid replication
• Semy-sync replication mode that guarantees reliability.

So, BinlogClient keeps the current replication state in the State property and updates it on every transaction commit or rollback(see Q&A in the readme). It updates binlog filename, position and the GtidSet in Gtid mode. Think of BinlogClient as a slave whose @@gtid_executed is stored in State and updated when each transaction is replicated.

Note: In order to guarantee consistency, the State is updated only after your event callback was called and didn't throw an exception. Otherwise, your derived database(Elasticsearch, Redis) could end up in an inconsistent state.

In case of failover, you get the current position from State.GtidState and connect to the new master
using the position as the starting point in FromGtid.

And as I mentioned above, I have no idea how to integrate the library with orchestration software that performs failover & switchover automatically(like Galera, or other tools that elect the new master and tell other replicas to switch to it)

[ElderJames]

Excellent!
I have a question about whether the replication state of BinlogClient can be persisted directly so that BinlogClient can be restored to its previous state after being restarted.

[rusuly]

yes, State.GtidState.ToString() constructs string representation that you can parse GtidSet.Parse()

[ElderJames]

Hi, you just said

the State is updated only after your event callback was called and didn't throw an exception.

Can I just assume that when I throw an exception in the callback, the replication will retry?

[rusuly]

Hi,
Basically, this behavior is designed to retry replication from the last failed position.
But as I mentioned before, retry(keep-alive) is not implemented right now, you should manually call again ReplicateAsync. This way replication will restart from the last committed State (which was updated after last successful client callback).