[Pacemaker] Question about Pacemaker & mysql master/slave replication and DRBD replication

[Andrew Beekhof]

On Thu, Mar 15, 2012 at 11:09 PM, coma <coma.inf at gmail.com> wrote:
> Hello,
>
> I'm a new Pacemaker user and i trying to understand exactly what it can do /
> can't do in case of MySQL Replication or DRBD replication.
>
> I have two MySQl servers, for the moment with a simple Master/Slave
> replication, my need is to implement a high availability system with
> automated IP and DB fail-over / fail-back (including replication).
>
> I would like to be able to have 1 node designated as Master and in case of
> failure, automatically promote the slave node to master, and when the
> initial master will available again do the reverse operation automatically.
>
> I have compared several solutions and according to my needs (i have two
> servers only and i don't want / don't need use solutions like MySQL Cluster
> which requires 4 servers), Pacemaker seems the best solution in my case.
>
> I have to choose between Pacemaker with MySQL replication or Pacemaker with
> DRBD replication but it's difficult to find clear explanations and
> documentation about the 2 solutions, so i have some questions about it.
> If anyone can enlighten me i thank in advance!
>
>
> In the Pacemaker + MySQL replication case:
>
> I know pacemaker is able to do IP failover and it seems DB failover too(?),
> but what type of failure pacemaker can detect?
> I know it is able to monitor the network failure (node unreachable), but can
> it detect MySQL service failure and promote the slave to master?

Yes.  We call the mysql resource agent and react to any failures it detects.

> Example: Master node reachable, but database not (mysql service stopped,
> access failed->too many connexions, disk full, database read access but
> write error...)?
>
> Can pacemaker do (natively) the reverse operation automatically (When
> initial master node or MySQL DB will be available again)?

Yes. This is what the http://www.mysqlperformanceblog.com blog is talking about.
Pacemaker doesn't actually understand what it is managing, the details
are hidden by the RA scripts.

> In this case, can it manage the replication? and if not, can i use a
> personal shell scipt to do it?
>
> Else, i have browsing the maillinglist archives and i've seen the Percona
> Replication Manager solution
> (http://www.mysqlperformanceblog.com/2011/11/29/percona-replication-manager-a-solution-for-mysql-high-availability-with-replication-using-pacemaker/),
> somebody he already implemented it in production environment? Is it
> reliable?

I've not used it myself but I hear good things.

>
>
> In the Pacemaker +   DRBD replication case:
>
> I understand that pacemaker and drbd work very well together and drbd is a
> good solution for mysql replication.
> In case of master (active node) failure, pacemaker+DRBD promote
> automatically the slave (passive node) as master and i have read that drbd
> can handle itself the back replication when master node is available again?
> can you enlighten me a little more about it?
>
> I also read that it is recommended to have a dedicated network for drbd
> replication, but can i do without? I don't write a lot on my databases,
> reading much more, so replication will not be a big charge.
>
> The big problem i have with DRBD is that i work on RHEL5 and i have read
> that i will have to recompile DRBD after each kernel update (there is not a
> lot of updates but still some),
> is it possible to avoid it? (CentOS DRBD packages maybe?)
>
> Somebody has already been problems with RHEL updates and DRBD/Pacemaker?

RHEL5 is getting on a bit, its version of glib is too old to even
build pacemaker there anymore.
What about using RHEL6 which even ships with pacemaker?

>
> Thank you in advance for any response, and sorry if my english is not very
> good.
>
>
>
> _______________________________________________
> Pacemaker mailing list: Pacemaker at oss.clusterlabs.org
> http://oss.clusterlabs.org/mailman/listinfo/pacemaker
>
> Project Home: http://www.clusterlabs.org
> Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
> Bugs: http://bugs.clusterlabs.org
>