Shulou(Shulou.com)05/31 Report--

This article mainly explains "mha daily maintenance command summary", the content of the article is simple and clear, easy to learn and understand, now please follow the editor's train of thought slowly in depth, together to study and learn "mha daily maintenance command summary"!

Mha daily maintenance command 1. Check whether ssh login is successful masterha_check_ssh-- conf=/etc/masterha/app1.cnf2. Check to see if replication has established masterha_check_repl-- conf=/etc/masterha/app1.cnf3. Start mhanohup masterha_manager-- conf=/etc/masterha/app1.cnf > / tmp/mha_manager.log

& 1 & it cannot be started when a slave node is down, plus-- ignore_fail_on_start can start mhanohup masterha_manager even if a node is down-- conf=/etc/masterha/app1.cnf-- ignore_fail_on_start > / tmp/mha_manager.log

& 1 & 4. Check the startup status of masterha_check_status-- conf=/etc/masterha/app1.cnf5. Stop mhamasterha_stop-the next time you restart conf=/etc/masterha/app1.cnf6.failover, a file app1.failover.complete will be generated in the management directory after each failover switch. The next time you switch, you will find that this file causes the switch to be unsuccessful and needs to be cleaned manually. Rm-rf / masterha/app1/app1.failover.complete can also be added with the parameter-ignore_last_failover7. Manual failover manual failover scenario, master is dead, but masterha_manager is not turned on, and can be manually failover:masterha_master_switch-conf=/etc/masterha/app1.cnf-dead_master_host=10.50.2.10-master_state=dead-new_master_host=10.50.2.12-ignore_last_failover8.masterha_manager is a monitoring and failover program. The masterha_master_switch program, on the other hand, does not monitor the main library. Masterha_master_switch can be used for main library failover or online master switch. 9. Manual online switching masterha_master_switch-- conf=/etc/app1.cnf-- master_state=alive-- new_master_host=192.168.119.74-- orig_master_is_new_slave or masterha_master_switch-- conf=/etc/app1.cnf-- master_state=alive-- new_master_host=192.168.119.74-- orig_master_is_new_slave-- running_updates_limit=10000-- orig_master_is_new_slave when switching, add this parameter to change the original master into a slave node If this parameter is not added, the original master will not start-if there is a delay in the candidate master during the running_updates_limit=10000 handover, the mha handover cannot be successful. In addition, this parameter means that the delay can be switched within this time range (in s), but the handover time is determined by the size of the relay log during the recover. The mha can be switched online manually during the handover. During the handoff, the mha can be switched off after the running mha is stopped. Execute DDL before preparing the database, generally stop slave first, and generally do not record mysql logs, which can be achieved by set SQL_LOG_BIN = 0. Then perform a master / slave switch operation, and then execute DDL on the original master library. This method is suitable for adding or decreasing indexes, and additional attention is required if fields are added. You can use the following command to stop mhamasterha_stop-- conf=/etc/app1.cnf common parameters:-- master_state=dead mandatory parameters, the parameter value is "dead" or "alive". If set to alive mode, masterha_master_switch starts the online master library switching operation. -- dead_master_host= (hostname) mandatory parameter, the name of the host where the master library of the outage resides. -- dead_master_ip and-- dead_master_port are optional parameters. If these parameters are not set,-- dead_master_ip is-- the IP address that dead_master_host resolves. -- dead_master_port is 3306 novel mastery host = (hostname) the new host address, optional parameter, this parameter is very useful when you know the host of the new main library. This means that you don't need to let MHA decide on the new master library. If this parameter is not set, MHA will use the rules of automatic failover to select a new master library. If set-new_master_host,MHA chooses this host as the new master library, if it cannot become the master library, MHA will exit-- interactive= (0 | 1) if set to 0, in masterha_master_switch, it automatically performs failover (non-interactive). This is actually the same as the internal operation of masterha_manager, this kind of non-interactive failover is useful if you have confirmed that master is dead, but you want to do a failover as soon as possible. Non-interactive failover is also useful if you use other existing primary monitoring software and non-interactive failover command software to be invoked. A typical example is masterha_master_switch calls from cluster software like pacemakers. -- ssh_reachable= (0 | 1 | 2) specifies whether master is reachable via SSH. 0: unreachable, 1: reachable, 2: unknown (default). If set to 2, this command internally detects whether master can be reached through SSH and follows the new SSH status. If reachable, set master_ip_failover_script or shutdown_script. "--command=stopssh" will be executed. Otherwise, execute "--command=stop". In addition, if the down master is reachable through SSH, the failover script attempts to copy the binlog that has not been sent from the down master machine. -- skip_change_master if this parameter is set, when failover occurs, MAH exits after applying different relay log, ignoring CHANGE MASTER and START SLAVE operations. So slaves will not point to the new master. When this parameter is enabled, it is convenient to manually check whether the slave recovery is successful. If skip_disable_read_only sets this parameter, MHA will not perform the SET GLOBAL read_only = 0 operation on the new main library. Useful for manual operation-last_failover_minute= (minutes) reference master_manager-- ignore_last_failover reference master_manager--wait_on_failover_error= (seconds) is similar to master_manager, this parameter is only used for automatic / non-interactive failover. If it is not set-interval=0,wait_on_failover_error will be ignored and sleep will not occur when an error occurs. -- remove_dead_master_conf reference masterha_manager--wait_until_gtid_in_sync (0 | 1) this parameter is available from version 0.56. If set to 1, when GITD-based failover, MHA will wait for all GITD--skip_change_master from the library to catch up with the new primary library. This parameter is available from version 0.56, if this option is enabled. MHA skips CHANGE MASTER operation-skip_disable_read_only this parameter is available from version 0.56. If this option is enabled, MHA will skip SET GLOBAL read_only = 0 in the new master. -- ignore_binlog_server_error this parameter is available since version 0.56. If this option is turned on, MHA ignores any errors on binlog server when executing failover. Non-interactive Failover automatically performs failover (non-interactive) if "--interactive=0" is set in masterha_master_switch. This is actually the same as the internal operation of masterha_manager, this kind of non-interactive failover is useful if you have confirmed that master is dead, but you want to do a failover as soon as possible. Non-interactive failover is also useful if you use other existing primary monitoring software and non-interactive failover command software to be invoked. A typical example is masterha_master_switch calls from cluster software like pacemakers. [online] switch Scheduled (Online) Master Switch sometimes you may want to make a scheduled master switch, even if the current master is running. A typical example is to replace partially damaged hardware or upgrade the primary server. You can't replace a RAID controller or add memory without stopping the server. In this case, you need to allocate a scheduled maintenance time, and you must migrate to a different server's master. The masterha_master_switch command can be used to run the schedule master switch. Masterha_master_switch-- master_state=alive-- conf=/etc/app1.cnf-- new_master_host=host2--master_state=alive must be set. The program flow for scheduling the master switch is slightly different from the slave master failover. For example, you don't need to shut down the main server, but you need to make sure that the write query is not executed on the master. By setting the main ip web change script, you can control blocking the current master does not allow writing (that is, drop writable users, setting read_only = 1, etc.) in the execution of FLUSH TABLES WITH READ LOCK, and how to make writing in the new master. Online master switch starts only if all the following conditions are met. 1. IO threads on all slaves are running / / the IO thread runs on all slave. 2. The SQL threads on all slaves are running / / SQL thread runs normally on all slave. 3. Seconds_Behind_Master on all slaves are less or equal than-- running_updates_limit seconds / / Seconds_Behind_Master is less than or equal to running_updates_limit seconds 4 on all slaves. On master, none of update queries take more than-- running_updates_limit seconds in the show processlist output / / on the main, there is no update query operation more than running_updates_limit seconds on the show processlist output. The reason for these restrictions is for security reasons and switch to the new main library as soon as possible. Masterha_master_switch requires the following parameters to switch when the master is online. -- new_master_host= (hostname) the new host address, optional parameter, this parameter is very useful when you identify the host of the new main library. This means that you don't need to let MHA decide on the new master library. If this parameter is not set, MHA will use the rules of automatic failover to select a new master library. If set-new_master_host,MHA chooses this host as the new master library, if it cannot become the master library, MHA will exit-- orig_master_is_new_slave when the master library switch is completed, the original master library will run as the slave of the current master library. Default: not enabled (the original main library will not be added to the new replication environment). If this option is enabled, you need to set the repl_password parameter in the configuration file, because the current Master does not know the password of the new Master's replication-if remove_orig_master_conf sets this parameter, when failover is successful, MHA manager will automatically delete the configuration option about dead master in the configuration file. -- skip_lock_all_tables when switching between master libraries, MHA will perform FLUSH TABLES WITH READ LOCK operations on the original master library to ensure that there are no new operations, but FLUSH TABLES WITH READ LOCK operations are very resource-consuming, and you can make sure that there are no new operations in the original main library (through the kill all clients operation in master_ip_online_change_script, etc.). You can use this option to avoid locking the table. Thank you for your reading, the above is the content of "summary of mha daily maintenance commands". After the study of this article, I believe you have a deeper understanding of the summary of mha daily maintenance commands, and the specific use needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.