Mariadb – Percona pt-table-checksum output is in infinite loop “Waiting for the –replicate table to replicate”

I do not understand why an application requires the MIXED replication format, as MIXED is equal to STATEMENT-based, but changing to ROW format when executing "unsafe" queries. So, a MIXED-compatible application should be compatible with both STATEMENT and ROW.

As you can see here, if the the format detected (server-side) is ROW or MIXED, it tries to change it dynamically for the session only. In your case, it complains about one of the slaves here (it requires SUPER privileges).

Assuming you do not have a 3-node chain replication, or you use the slave's binlog for anything, you can ignore the warning with --no-check-binlog-format. No need to change the my.cnf. The question is, will the session-only change to statement affect your "application that requires MIXED"? pt-table-checksum requires its own calculations to be done as statements, as a hash has to be calculated independently on the master and the slave independently and synchronously (not in time, but in relation with other queries).

In the latest Percona XtraDB cluster version it is possible to make WAN segments so that there is more efficient communication between nodes. If you didn't do that, all nodes would try to replicate to all nodes, which is highly inefficient for Galera. With Galera 3/PXC 5.6, you can establish those so that only one node at a time will replicate to the other segments. This was specifically thought for geographical redundancy.

Before 5.6:

  ---------------
 /     /   \     \
A --- B --- D --- E   (A, B, C Local nodes; D,E Remote nodes; all talk to all)
 \   /     /     /
   C ------------

After 5.6 (Galera 3):

[ A --- B ] --- [ D --- E ]   (no redundant communication between segments)
[  \   /  ]
[    C    ]

In any case, think that the round-trip time will limit the minimum latency for each transaction, which means that using geographical replication will make the cluster much slower.

An alternative option that you can setup is combining Galera and standard replication, like this:

 A --- B ~~~ D --- E (--- : Galera replication; ~~~: MySQL replication )
  \   /
    C

Standard MySQL replication is way more efficient, as it does not wait for the "slaves" to confirm the changes (it does not use group communication). The disadvantage is clear: being asynchronous it does not guarantee that absolutely all changes applied to the primary cluster has been transmitted to the slave node or nodes. If the replications is well managed that should only mean less than 1 second of transactions, but this is certainly a no-go for banking applications or other applications where loss of information is impossible even if the whole datacenter fails. Whoever, that is something that most web applications and services can handle. On the negative aspect, standard replication has some disadvantages, specially if it is not well managed, like potential data drifts or extra latency due to it being single-threaded.