April 18, 2014

Percona replication manager (PRM) documentation available (beta)

Since the new MySQL Pacemaker resource agent supporting PRM is now included in version 3.9.3 of the official Pacemaker resource agents package and things have stabilized a bit, I have been able to write some documentation. I wrote a first draft of the PRM documentation that is likely far from perfect, but I hope it will be useful and improve rapidly. The PRM documentation is available here. Comments and suggestions are welcome, please use the PRM discuss or the PRM devel mailing lists instead of replying to the blog post directly.

2013-06-24: Code is now here: https://github.com/percona/percona-pacemaker-agents

About Yves Trudeau

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

Comments

  1. Yves,

    Good stuff! We are looking to implement an HA mysql solution built upon EC2 for one of our customers and I noticed your documentation had a section under testing called VIPless cluster (cloud). Do you have any information here? Are you planning on using EIPs or DNS failover? Do you have any preliminary information or something you can point me to which hooks pacemaker up with EC2 or Route53?

    thx.

    Jeremy

  2. Jacky Leung says:

    +1 to the suggestion to Jeremy

    Currently I am also looking into a proper setup for HA solution for EC2. (“proper” mean that the design have take into consideration of EC2 limitation and environment)

  3. Brian says:

    Excellent work Yves! I don’t think Pacemaker is the best place for most database failover scenarios, but this is actually a pretty sweet system you built. I am going to enjoy going through your agent source code.

  4. @Jeremy and @Jacky,
    basically, the VIPless solution use a fake mysql agent on the application servers. When the promote notification is received on the application servers, announcing a new master, the fake agent, instead of adjusting mysql replication just issue an iptables DNAT rule to redirect outgoing mysql traffic to the new master. Directing reads to slaves can also be handled but in a less efficient way.

  5. Sov1et says:

    What about switch over and looooong update queries? And syncing binary logs?

Speak Your Mind

*