Feature Request: Supporting multi-master configuration

[yoshinorim]

Some users want MHA to work with multi-master configuration, which current MHA (v 0.50) does not support.

Here are some design considerations.

• Only one master should be writable
• How should MHA verify that?
  • 1. Checking "read_only" global variable When MHA detects two or more masters and two or masters are read_only ==0, MHA aborts
  • 2. Adding additional configuration parameter on MHA i.e. read_only_master=1 (I like no.1)
• How MHA detects current (writable) master?
  • Get all unique "Master_Hosts" from all servers
  • Skip if read_only==1 on that Master_Host
  • If the number of the rest servers is 1, that is the current writable master. Otherwise MHA aborts.

[seattlegaucho]

Consider the following scenario:

• Server A <---> Server B
• Server A ---> Server C
• Server B ---> Server D

(I apologize, but GitHub is not friendly to ASCII code)

Active master would be A, and B would be the stand-by. The manager would be monitoring A, B & C. If A fails, B would have to be promoted to active master and C would now replicate of it.

It would be nice to be able to include D in the configuration file and MHA Manager not fail at start up if the 3rd tier slaves replicate off the stand-by master. This way, when the MHA Manager gets restarted after the fail over, D would be included as a fail-over candidate.

I would also consider making sure that only the masters have 'candidate_master=1' set.

My $.02 Gerry

[yoshinorim]

It would be nice to be able to include D in the configuration file and MHA Manager not fail at start up if the 3rd tier slaves replicate off the stand-by master. This way, when the MHA Manager gets restarted after the fail over, D would be included as a fail-over candidate.

This makes sense. How about adding a new application-scope parameter like "multi_tier_slave"? By default, MHA Manager aborts if it detects any slave NOT replicating from the current primary master. But if multi_tier_slave=1 is set, MHA Manager handles these slaves as "not managed", and starts running.

Regards, Yoshinori

[yoshinorim]

Multi-master is implemented and published at a separated "multimaster" branch. http://yoshinorimatsunobu.blogspot.com/2011/08/mysql-mha-support-for-multi-master.html

I verified it works by many test cases, but I'd like to take some time for people to evaluate, and will decide whether I'll merge it to the main branch.

[seattlegaucho]

Hi there,

I followed your instructions to get the source for the multimaster version after removing all the old software and I keep getting the following error:

on Aug 29 16:58:40 2011 - [error][/usr/lib/perl5/site_perl/5.8.8/MHA/MasterMonitor.pm, ln316] Error happend on checking configurations. Parameter name multi-tier-slave is invalid! at /usr/lib/perl5/site_perl/5.8.8/MHA/MasterMonitor.pm line 190

I checked that the MasterMonitor.pm file is the same I got from the git repository. Here's my new configuration file:

[server default] manager_workdir=/var/log/masterha/test manager_log=/var/log/masterha/test.log multi-tier-slave=1

[server1] hostname=CentOS-OM candidate_master=1

[server2] hostname=CentOS-OM-02 candidate_master=1

[server3] hostname=CentOS-OM-03

[server4] hostname=CentOS-OM-04

"server4" is replicating from "server3".

I grepped for 'multi_tier_slave' (and shorter combinations just in case) and didn't find it on any of the .pm files.

Can you help? Thx.

Gerry

[yoshinorim]

Please try multi_tier_slave, not multi-tier-slave. Keyword multi_tier_slave should be in Config.pm and ServerManager.pm if you have switched to multimaster branch correctly.

[yoshinorim]

Gerry,

Sorry, the original blog entry was not correct. Would you please try to switch branch as below? git checkout -b multimaster origin/multimaster

[seattlegaucho]

Thank you very much, although I had the typo in the configuration file, the git checkout needed correction. I got the checks to run properly. Thank you very much.

[yoshinorim]

Pushed to the main branch.