Network Security Internet Technology Development Database Servers Mobile Phone Android Software Apple Software Computer Software News IT Information

In addition to Weibo, there is also WeChat

Please pay attention

WeChat public account

Shulou

How to collect MySQL MHA deployment and running status information through Python

2025-01-16 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Development >

Share

Shulou(Shulou.com)06/03 Report--

Today, I will talk to you about the function of how to collect MySQL MHA deployment and running status information through Python, which may not be well understood by many people. in order to make you understand better, the editor has summarized the following contents for you. I hope you can get something according to this article.

one。 Background introduction

When the number of MySQL database instances of the group reaches 2000 + and the scale of the MHA cluster is hundreds, the timely and efficient management of MHA is a challenge that DBA must face. The information and running status of MHA cluster nodes are the basis of management. This paper mainly introduces how to collect the information and running status of MHA cluster nodes through Python. This information will be an important part of CMDB information.

There are hundreds of MHA clusters, more than a dozen MHAManager nodes, and one MHAManager node manages 50-60 clusters. We hope that the developed program, only deployed and run in these more than ten MHAManager nodes, can collect all the required MHA Server node information, VIP information, running status information and other information, and save the collected data to the MySQL database.

two。 Implement the MHA tool program or file tool program or file function called by the logic 2.1program mha_appxxx.cnf configuration file

1. Extract Server information (Server IP) from this file

two。 Extract files for FailOver Script and Online Change Script.

The appxxx_master_ip_failover script file extracts the defined VIP and compares it horizontally with the VIP collected elsewhere to prevent configuration errors. The appxxx_master_ip_online_change script file extracts the defined VIP, and horizontal comparison prevents configuration errors. Masterha_check_repl tool program

1. Check MySQL replication status

two。 Parsing the IP of the current master node

3. Parsing slave Node IP

4. Parse out VIP.

Masterha_check_status

Check the current MHA running status (running OK or stop).

To make it easier to understand, we post the content of mha_appxxx.cnf.

[server default] manager_workdir=/var/log/masterha/app1.log / / set manager's working directory manager_log=/var/log/masterha/app1/manager.log / / set manager's log master _ binlog_dir=/data/mysql / / set master's location to save binlog, so that MHA can find master's log What I have here is the mysql data directory master_ip_failover_script= / usr/local/bin/appxxx_master_ip_failover / / when setting automatic failover, the switching script master_ip_online_change_script= / usr/local/bin/appxxx_master_ip_online_change / / setting the switching script password= user password for manual switching / / setting the password of the root user in mysql This password is the password of the monitoring user created in the previous article. The user=root setting monitoring user rootping_interval=1 / / sets the monitoring main library. The time interval for sending ping packets is 3 seconds by default. Automatically railoverremote_workdir=/tmp / / set remote mysql when there is no response three times when switching occurs, repl_password= user password / / set replication user password / / set replication user name report_script=/usr/local/send_report / / set the script shutdown for alarm sent after switching in replication environment _ script= "/ / close the failed host script after a failure occurs (the main function of this script is to shut down the host and place it in the event of a brain fissure Do not use) ssh_user=root / / to set the login user name of ssh [server1] hostname=110.110.110.50port= 3306 [server2] hostname=110.110.110.60port=3306candidate_master=1 / / as candidate master If this parameter is set, the master-slave database will be promoted to the master library after the master-slave switch occurs, even if the master database is not the latest slavecheck_repl_delay=0 / / of the events in the cluster. By default, if a slave lags behind the relay logs of master 100m, MHA will not select the slave as a new master, because it will take a long time to recover this slave. Setting check_repl_delay=0,MHA to trigger a handover will ignore replication delay when selecting a new master. This parameter is useful for hosts with candidate_master=1 set, because the candidate must be the new master [server 3] hostname=110.110.110.70port=33062.2 during the handover. A simple flow chart

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.

Views: 0

*The comments in the above article only represent the author's personal views and do not represent the views and positions of this website. If you have more insights, please feel free to contribute and share.

Share To

Development

Wechat

© 2024 shulou.com SLNews company. All rights reserved.

12
Report