EmergencyEMERGENCY? Get 24/7 Help Now!

Q&A: Geographical disaster recovery with Percona Replication Manager

 | December 10, 2013 |  Posted In: High-availability, MySQL


Q&A: Geographical disaster recovery with Percona Replication ManagerMy December 4 webinar, “Geographical disaster recovery with  Percona Replication Manager (PRM),”  gave rise to a few questions. The recording of the webinar and the slides are available here, and I’ve answered the questions I didn’t have time to address below.

Q1: Hi, I was wondering if corosync will work in cloud environment. As far as I know it is hard to implement because of no support of unicast or multicast.

A1: Corosync supports the udpu transport since somewhere in the 1.3.0 branch. udpu stands for udp unicast and it works in AWS for instance. Most recent distribution are using 1.4.x so it is easy to find.

Q2: For token wouldn’t it make sense to have a value higher than 3000 to account for any packetloss and the default retry of 3 seconds for tcp communication?

A2: Corosync uses udp, not tcp so the argument is somewhat irrelevant.

Q3: Is PRM supported with a Percona support contract?

A3: Yes, PRM is now supported with a Percona Gold or Platinum Support contract. It is not availabe with Silver support.

Q4: Is PRM working with GTID’s in 5.6?

A4: There’s a version in testing phases adapted by Frederic Descamps that works with 5.6/GTID. As soon as it is tested properly, I’ll release it. So far, it is very clean in term of logic.

Q5: Does Percona Replication Manager do anything different with replication over the built in mySQL replication to combat the single threaded nature?

A5: No

Q6: We agree that fencing always has to be configured (even with no shared resources , in cases of mysql stop failure for example) : What about MySQL and Percona’s PRM Ressource agent behavior when fencing? and recommendations concerning fencing? There was no fencing in the demo and there is no fencing configured on the pacemaker crm snippets examples provided in on Percona’s github repo.

A6: Fencing is independent of PRM and is well covered elsewhere on the web. I’ll see to add an example configuration with stonith devices. On real hardware, the most common stonith device are IPMI or ILO. These technologies comes with nearly all the server brands.

Q7: Is there any other Mysql HA setup supported by Percona’s mysql_prm pacemaker resource agent than the Mysql master slave replication ? Like Multi master setups ? In case yes , will you release some crm configurations snippets examples for other Mysql HA setups ?

A7: No, only a single master is supported. The main argument here is that multiple master doesn’t scale writes and are a big source of conflicts.

Q8: Why use Percona Replication Manager over XtraDB cluster (omitting ease of Geo-DR) on a write performance perspective , also considering HA and cost ?

A8: Percona XtraDB Cluster (PXC) is more advanced and capable but, some workloads, like large transactions, are not working well with PXC. Regular replication is well known and many customers are not willing to try a newer technology like (PXC) and prefer to rely on regular replication. Also, PRM can be mixed with PXC without problem. Example of such configuration will be published soon. In term of cost both are free, support is available from Percona (Gold and Platinium) but (PXC) has a premium.

Yves Trudeau

Yves is a Principal Consultant at Percona, specializing in distributed technologies such as MySQL Cluster, Pacemaker and XtraDB cluster. He was previously a senior consultant for MySQL and Sun Microsystems. He holds a Ph.D. in Experimental Physics.

One Comment

  • regarding multi mastering mysql, I would disagree about it not scaling writes. It certainly can be a source of problems if your writes are not completely isolated form each other, but I have found great success in scaling writes of different types such as segregating ETL’s and OLAPS one server and OLTP on the other.

Leave a Reply