MySQL MHA Typical usage scenarios

1Management node Deployment Location 1.1. Dedicated Manager server and multiple MySQL (master,slaves) servers

Managing multiple sets of MySQL master and slave servers using a dedicated Management Server

Since MHA Manager uses very little cpu/memory resources, you can manage lots of (master, slaves) pairs from single MHA man Ager. It is even possible to manage 100+ pairs from the single manager server.

1.2. Running MHA Manager on one of the MySQL slaves

Deploying the Management node from a library

If you had only one (master, slaves) pair and you could not be like allocating dedicated hardware for MHA Manager because it Adds relatively high costs. In such cases, running MHA Manager on one of the slaves makes sense. Note that current version of MHA Manager connects to MySQL slave server via SSH even though the MySQL server is located on the same host as MHA Manager, so you need to enable SSH public key authentication from the same host.

2Master-Slave switching scenarios under different master and slave configurations 2.1 single master, multiple slaves (one master multiple slave)

M (rw) m (rw), promoted from S1

| |

+------+------+--(master crash)-+-----+-----+

S1 (R) S2 (r) S3 (r) S2 (r) S3 (R)

The most common replication settings. MHA works very well here.

2.2 Single master, multiple slaves (one on remote datacenter) One-master-multi-slave, from a Remote data center

M (rw) m (rw), promoted from S1

| |

+------+---------+--(master crash)-+-----+------+

S1 (R) S2 (R) SR (r,no_master=1) S2 (R) SR (R,no_master=1)

In many cases-want to deploy at least one slave server on a remote datacenter. When the master is crashes, you may not be want to promote the remote slave to the new master, but let one of the other slaves Runni Ng on the local datacenter become the new master. MHA supports such requirements. Setting no_master=1 in the configuration file makes the slave never becomes new master .

2.3 Single master, multiple slaves, one candidate master (master multiple slave, a candidate master)

M (rw)-----S0 (R,candidate_master=1) m (rw), promoted from S0

| |

+----+----+--(master crash)-+----+----+

S1 (R) S2 (r) S1 (r) S2 (R)

In some cases-want to promote a specific server to the new master if the current master crashes. In such cases, setting candidate_master=1 in the configuration file would help .

2.4 Multiple masters, multiple slaves (multi-master multi-Slave)

M (rw) <--->m2 (r,candidate_master=1) m (rw), promoted from M2

| |

+----+----+--(master crash)-+----+----+

S (R) S2 (r) S1 (r) S2 (R)

In some cases-want to use multi-master configurations, and your may want-make the Read-only master the new Maste R If the current master crashes. MHA Manager supports multi-master configurations as long as all non-primary Masters (M2 in this figure) is read-only.

2.5 Three tier replication (three-tier replication architecture)

M (rw) m (rw), promoted from S1

| |

+------+---------+--(master crash)-+-----+------+

S1 (R) S2 (R) SR (R) S2 (R) SR (R)

| |

+                                              +

SR2 SR2

in Some cases you could want to use three-tier replication like this. M HA can still is used for master failover. In the configuration file , manage the master and all Second-tier slaves (in this figure, add m,s1,s2 and Sr in the MHA config file, but does not add SR2). If the current master (M) fails, MHA automatically promotes one of the second-tier slaves (S1,S2,SR, and can also set P Riorities) to the new master, and recover the rest second-tier slaves. the third tier Slave (SR2) is not managed by MHA, but as long as Sr (SR2 ' s master) is alive, SR2 C An continue replication without changing anything.

If SR crashes, SR2 can ' t continue replication because SR2 ' s master is Sr. MHA can not be used to recover Sr2. This is where the support for global transaction ID is desired. Hopefully this was less serious than master crash.

2.6 Three tier replication, multi-master (three-tier replication architecture, multi-Master)

M1 (HOST1,RW) <-----------------> M2 (host2,read-only)

| |

+-----+--------+                       +

S1 (host3,r) S2 (host4,r) S3 (host5,r)

= after failover

M2 (HOST2,RW)

|

+--------------+--------------------------+

S1 (host3,r) S2 (host4,r) S3 (host5,r)

This structure is also supported. In this case, Host5 are a third-tier slave, so MHA does not manage HOST5 (MHA does no execute change MASTER on HOST5 when T He primary master host1 fails). When current master host1 are down, Host2 would be new master, so HOST5 can keep replication from host2 without doing Anythi Ng. here is the configuration file example.

[Server default] multi_tier_slave=1[server1]hostname=host1candidate_master=1[server2]hostname=host2candidate_master=1[ Server3]hostname=host3[server4]hostname=host4[server5]hostname=host5

MySQL MHA Typical usage scenarios