Comparing different cluster implementations for MySQL?

Question

MySQL

Hello!
I hope that my question does not go beyond the scope of this resource and will find an answer.
At the moment, in one of the projects, I am considering the option of implementing a fault-tolerant solution for running MySQL on multiple servers. Data replication between servers must be synchronous. There are no plans to move away from MySQL.
The use of some MySQL cluster implementation immediately catches my eye, and I consider several solutions:

• MySQL Cluster
• Percona XtraDB Cluster
• MariaDB Galera Cluster

Unfortunately, I didn’t work with them before and my practical / theoretical knowledge on them is not much (raised Percona XtraDB Cluster on virtual machines - it seems to work). Russian information is also googled a little. I hope, dear community, will help me with the choice of technology.
From the original data:

• The project works with one MySQL 5.5 server. innodb tables
• Read operations take precedence over write operations
• I would like to avoid serious revisions of the project code
• To implement the solution, it is possible (and planned) to use 3+ servers. They can be distributed to different DCs.

Mostly interested in the following:

1. Are there any intelligible materials comparing all three solutions?
2. How stable are cluster solutions? (departure of nodes from work, situations when communication is lost)
3. What are the strengths/weaknesses of certain solutions?
4. Maintenance of each solution at the administrator level (difficult, easy, failover)?
5. Are there any alternatives?

I'll be glad for your answers :)
PS Since I'm still "swimming" in this topic, I could miss any important details or questions that may arise in the course of studying / implementing the technology. If you tell them - it will be very cool!

Answer 1

Thank you all for your help!
Ultimately, clustering using Percona Cluster was chosen as the most stable solution with the lowest implementation costs.
Several clusters on Percona have already been put into operation (so far from 3 servers). The fall of one node is going through normally. There are no problems with any data loss.
Yes, with geographical distribution, when recording data, there are delays. But between Selectel and Hetzner - quite tolerant.
Between St. Petersburg and Moscow are also not very big (it all depends on how the site works with the database).
As a result - you can use Percona Cluster and not be afraid :) It all depends on the allowable "degradation" of your system. In this case, this is some delay when writing data (but there are usually fewer write requests than read requests ;))

Answer 2

Perkona uses a galley cluster solution
. In a standard muscle, everything is on NDB tables
. Cluster and spacing across data centers is an unlikely solution, either synchronous operation or wild delays if the servers are far away.

Answer 3

Percona XtraDB Cluster and MariaDB Galera Cluster worked the same on my test within the margin of error, the standard muscle is much worse. 1. The most intelligible materials - the official dock
of projects, everything that I found (about 2 years ago) did not correspond to reality
due to poor performance) with an unpredictable result from normal to complete desynchronization with the need for manual intervention, on which it depends, I didn’t understand, it looks like the phase of the moon.
3. Strong - still convenient, weak - it was unstable, I don’t know now, well, at different geographical sites, strong brakes are very demanding on the data transmission medium.
4. From a couple of minutes to restore from the last backup.
5. Cluster at the level of FS, not muscles, Orakl.

Answer 4

1. MariaDB Gallera Cluster and Percona Cluster are essentially the same solution, as they are based on the same technology - Gallera library ( https://github.com/codership/galera)
https://mariadb.com/kb/en /mariadb/what-is-mariadb-...
www.percona.com/doc/percona-xtradb-cluster/5.6/int...
2. Oracle MySQL Cluster is a sharded In memory DB. This solution is more for low latency and not for high availability.
The main drawback is a commercial license that will cost depending on the size of the database and can cost tens and hundreds of thousands of green money.
And part of the SQL code will most likely have to be rewritten.