Synchronous replication: MySQL NDB Cluster, Percona XtraDB, MariaDB Galera, mysql group replication (innodb cluster). What are the differences?

Question

MySQL

There are 3 identical VPS on SSD in different DCs in Moscow, ping between them is up to 5ms.
Synchronous replication is needed so that there are at least 2 copies of data.
You need to survive the fall of 1 server out of 3, if 2 servers have fallen - read-only mode.
We will write and read only from one server.
In order to speed up the write speed, it would be desirable to configure it so that when writing, if a write confirmation is received from at least one more server, then we do not wait for the 3rd one and give the write confirmation to the client (as is done in cockroachdb). But I don’t understand yet whether this is possible and how it will affect consistency.
What are the main differences between the solutions mentioned in the title?
How do they behave when the 1st server crashes?
If the cluster learned about the fall of the 3rd server only during the recording (did not receive confirmation from it), will the recording pass? Or the record will be rejected and then the 3rd server leaves the cluster list by timeout, and only then will the records begin to pass?
Percona, as I understand it, has an advantage in their engine tuning + copy utility.
Mysql group replication (innodb cluster) is relatively new, but attracts the paxos consensus protocol in it. Any positive experience with it?

Answer 1

I can’t compare all of the above, because I haven’t tried everything, I’ll share a scheme that has been in production for a year.
The Galera cluster based on Percona Xtradb is used. It has two physical nodes (the base lives on an SSD in mdadm RAID1), spaced apart by cities (~ 200 km) + an arbitrator on a virtual machine (needed for a quorum because the cluster should not contain an even number of nodes). Any INSERT\UPDATE\DELETE is approved by all nodes and only then is it considered committed. Requests are resolved using the Maxscale proxy living on the virtual machine. One of the nodes is a master, it receives write requests, the second is a slave, it receives read requests. If one of the nodes crashes, the second one automatically takes over its functions (more precisely, the nodes themselves do not know about their roles, they drive the Maxscale process). When the node rises, it absorbs the IST (Incremental State Transfer) changes that have occurred since the fall if the amount of changes that have occurred does not exceed the size of galera cache (just a file, the size is specified in the mysql config) or, in the worst case, the entire database is loaded. At the same time, the donor node continues to process customer requests as if nothing had happened. The joined node becomes a slave, because changing the master leads to termination of connections and it is better to do it manually, at night.
To increase reliability, both nodes have one slave, where all changes are replicated in real time. It is convenient to make a backup from them at any time, without fear of loading the database (we use the native Percon Innobackupex, which backups the database on the fly very quickly and without blocking) or perform heavy selects.
If you have any questions - ask, I will try to answer.

Answer 2

Judging by the following presentation, Percona wins
https://www.slideshare.net/Grypyrg/percona-xtradb-...
The presentation states that decisions on Galera are waiting for record confirmation from all users, and group replication from the majority, and accordingly the record should be faster.
But at the same time, it is indicated that group replication is not recommended for WAN.
Another article in favor of Percona again
https://www.percona.com/blog/2017/02/24/battle-for...