I'm developing a scalable cloud application and I wish to use a multi-primary cluster to be better able to scale horizontally when needed. I have experience with a single primary cluster configuration.

When in multi primary mode, the group replication is slightly delayed from node to node. So, for example, two sequential requests, say PUT /users/1 and GET /users/1, can successfully insert but then fail to select until some time later.

Not necessarily specific to that issue above, are there established ways of designing an application to be built on top of a multi-primary cluster?

I considered making each user session stick to one of the databases for the lifetime of the session. That way anything that's created will be available on subsequent requests because it'll request the same cluster node.

This could be implemented by connecting to the node with id sessionId % n where n is the node count. However, actually doing that seems rather brittle and non-standard. So I was wondering if there are better, established methods of achieving this kind of consistency.

Thank you!

1 Answer 1


The short answer is no, unfortunately. Have you considered using Galera instead? It has mature synchronous replication and can virtually guarantee consistency across nodes. I would highly recommend it. This article compares what you are using now with the Galera option: https://www.percona.com/blog/2017/02/24/battle-for-synchronous-replication-in-mysql-galera-vs-group-replication/

Otherwise you would have to develop an ugly solution like you describe, and it still won't be 100% adequate in the event of a node failure.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.