Transfer from: http: //hi.baidu.com/cloudhorizon/item/26bf393b2f142642033edc94 Centos Installation Reference: http: //ylw6006.blog.51cto.com/470441/890360 a. MHA MHA Automation introduces the primary server failover, rapid promotion from the server-based server (usually in the 10-30s), without affecting the consistency of replicated, do not need to spend money to buy more new servers, there is no performance loss, easy to install, without having to change the existing deployment environment for any storage engine. MHA online switching master server, the master server to change the running stage to another, this process only 0. 5-2s time, this time the data can not be written. MHA Manager mysql slave server connected via ssh. Although MHA attempt to save the binary log from the master block off, not always possible. For example, if the primary server hardware failure or inability to access via ssh, MHA can not save the binary log, perform failover only lost the latest data. Semi-synchronous replication, can greatly reduce the risk of data loss. MHA can be combined with the semi-synchronous replication. If only one slave has received the latest binary log, MHA latest binary log can be applied to all other slave servers, so keeping them consistent with each other. MHA has the following features: automated monitoring and transfer failure of the primary master server architecture MHA monitor replication, upon detection of the primary server fails, it will automatically fail. Even though some did not receive the latest relay log from a server, MHA from the latest automatic identification of differences from the server relay log and these logs to other applications, so all of consistency from the server from the server. MHA is usually completed within a few seconds failover, 9-12 seconds to detect the primary server fails, the failure to close the primary server to avoid the split brain, 7-10 seconds, relay log difference applied within a few seconds to a new primary server , the entire process can be completed in 10-30s. You can also set the priority of which is designated as a slave master's candidate. Since the MHA between slaves repair consistency, so it can be any slave becomes the new master, and the consistency of the problem does not occur, causing replication to fail. Interactive primary server failover can only use failover MHA, and not used to monitor the server if the primary server fails, manual call MHA for fault fault. The main non-interactive failover does not monitor the primary server, but automatic failover. This feature applies to other software has been used to monitor the status of the primary server, such as heartbeat to detect the primary server fails and the virtual IP address takeover, MHA can be used to implement failover and slave server is promoted to master server. Online switch the main server In many cases, you need to migrate to an existing master server on another server. For example, the primary server hardware failure, RAID controller card needs to be rebuilt, the primary server to the better performance of the server, and so on. Maintenance of the main server performance degradation, leading to downtime at least can not be written. In addition, block or kill session currently running can lead to inconsistent data between the main main problem. MHA provides fast switching and blocking elegant writing, the switching process takes only 0.5-2s time, this time the data is not written. In many cases, blocking write 0.5-2s is acceptable. Therefore, switch the main server does not need to allocate planned maintenance windows (Oh, you do not need to switch the main server through the night to complete the task at high dark and stormy night). NOTE: MHA replicated structure may be applied to any two .MHA conditions MHA SSH public key authentication server management node mysql required connection via ssh, MHA other slaves on the log to the server through the latest transmission relay scp. To make these process automation, using SSH public key authentication password. MHA operating system currently only supports a single Linux system can write to the master server and multiple server if the primary server or from a read-only when the primary server off, MHA repair data from consistency between servers. MHA trying to save the binary log file has not been sent from the crash of the primary server and applied to all from the server. If only one from the server, you do not need to care about consistency problem between servers. Even if only a binary log event has not been sent from the server, MHA also saved from the crash as long as the primary server through ssh access to the main server. Semi-synchronous replication can be solved when the primary server crashes, you can not ssh to save the master binary log events not yet been sent. From MHA Manager0. 52 version, supports multi-master replication structure. Wherein only one master server can be written, the main server must be set other read-only = 1. By default, the server should be a two-tier management structure copy. In the case of three or more layers copied by default, MHA does not support three or more than three replicate structure. As master1 --- master2 ---- slave3. MHA failover and recover directly from the selected one as the current primary server from the primary server. MHA can manage master1 and master2, when master1 crash, the master2 as the main, MHA does not monitor and restore slave3 because slave3 is copied from different primary servers (master2). In order to make this work MHA architecture, you need to make the following settings: configure only master1 and master2 provided on all hosts multi_tier_slave MHA MHA profile in the configuration file = 1 In this case, only the main MHA management master and the second floor from the server, the failover process, three from the server can still work properly. mysql version 5.0 or higher support MHA or later mysql5.0. Because the format from the binary log (binlog v4 format) changed from mysql5.0 version. When parsing the binary MHA relay log log to determine the target location, using v4 format. MySQL version 5.0.60 shall not be less than. mysqlbinlog version 3.3 or later MHA use mysqlbinlog in the target application binaries from the server event. If the primary server-based line format copy, write to the binary file format based on the event line, this binary log file format can only be resolved later or MySQL5.1 of mysqlbinlog. MySQL5.0. 60 following versions of mysqlbinlog does not support line-based format. Candidate master log-bin must be turned on if the current log-bin is not open from the server, it will not become the primary server. MHA management node detects whether there are configuration log-bin. If you do not have all the current settings from the server log-bin, then the MHA does not fail over. Binary log and relay log filtering rules must be the same on all servers binlog-do-db, and replicate-ignore-db must be the same. MHA will start when the detection filter rules, if different filtering rules, MHA does not start monitoring and failover. Copy the candidate user must be present when the primary server after failover, all of it from the server to execute the command change master. Reservations relay log and cleaned regularly by default, from the relay log on the server will be automatically deleted after the implementation of the SQL thread. But these other relay logs may be used in the recovery time from the server, it is necessary to disable automatic clearing relay logs and periodic purges old relay logs. Periodically clear the relay logs need to consider issues replication delay. In the ext3 file system, delete large files will take some time, can cause serious delays replication. In order to avoid replication delays, temporarily create a hard link to the relay log. MHA node contains pure_relay_logs command tool that can create hard links for the relay log, execute SET GLOBAL relay_log_purge = 1, wait a few seconds in order to switch to the new SQL thread relay log, then perform SET GLOBAL relay_log_purge = 0. pure_relay_logs parameters are as follows: --user mysql username --password mysql password --host mysql server address --port port number --workdir create and delete relay logs directory hard links. After the successful execution of the script, a hard link relay log file will be deleted. The default directory is / var / tmp. --disable_relay_log_purge If relay_log_purge = 1, purge_relay_logs script exits without doing anything. Set --disable_relay_log_purge parameters, purge_relay_logs script does not recede, and automatically set relay_log_purge = 0. Regular basis purge_relay_logs script: Purge_relay_logs script to delete relay logs will not block SQL thread. So set scheduled tasks from the server on each relay periodically clear the log. 00 00 * * * / usr / bin / purge_relay_logs --user = root --password = passwd --disable_relay_log_purge >> /data/masterha/log/purge_relay_logs.log preferably each different time points from the server 2> & 1 perform scheduled tasks. 11. LOAD DATA INFILE Do not use the relay log events based on the statement of type binary log if you use non-transactional storage engine, in executing the LOAD DATA INFILE statement based binary log type, the primary server crashes, MHA may not result in differences . Use LOAD DATA INFILE statement based on type binary log There are some known problems in mysql5.1 version is not recommended, and would cause serious delays copy, so there is no reason to use it. three. 1. MHA process monitoring and failover detection and determination of copy provided to monitor the current master server the master server when the primary server detects arranged to close off again when the detector off from the master server (optional) to restore a new activation of the new primary master 2. the rest of the server recovery process detect copy-line switches to set and determine the current primary server to determine the new primary server to block written to the current primary server waits for all copied from the server to catch up to the new primary grant written warning from the server (optional) server back four from the server. MHA MHA installation script contains three nodes, dependent perl modules. save_binary_logs: save and copy pawned master binary log apply_diff_relay_logs: Identify differences relay log events, and salve applied to other servers purge_relay_logs: Clear relay log files need to be installed on all nodes MHA mysql server, MHA also need to install the management server. Internal node management module depends MHA MHA node module. MHA management node connection management mysql server and execute the script MHA node by ssh. MHA dependent node of perl DBD :: mysql module. Installation MHA Node installed on all the mysql server # apt-get install libdbd-mysql-perl # wget http://mysql-master-ha.googlecode.com/files/mha4mysql-node-0.52.tar.gz # perl Makefile .PL # make # make install install MHA Manager # apt-get install libdbd-mysql-perl # wget http://mysql-master-ha.googlecode.com/files/mha4mysql-node-0.52.tar.gz # perl Makefile .PL # make # make install # apt-get install libconfig-tiny-perl # apt-get install liblog-dispatch-perl # apt-get install libparallel-forkmanager-perl # apt-get install libnet-telnet-perl # wget http : //mysql-master-ha.googlecode.com/files/mha4mysql-manager-0.52.tar.gz # tar zxvf mha4mysql-manager-0.52.tar.gz -C ../software/ # perl Makefile.
Reproduced in: https: //my.oschina.net/766/blog/211373