CN112667711B - MySQL read-only instance management method, system and computer readable medium - Google Patents
MySQL read-only instance management method, system and computer readable medium Download PDFInfo
- Publication number
- CN112667711B CN112667711B CN202011596472.XA CN202011596472A CN112667711B CN 112667711 B CN112667711 B CN 112667711B CN 202011596472 A CN202011596472 A CN 202011596472A CN 112667711 B CN112667711 B CN 112667711B
- Authority
- CN
- China
- Prior art keywords
- instance
- read
- haproxy
- group
- configuration
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Abstract
The invention discloses a MySQL read-only instance management method, a system and a computer readable medium, belonging to the technical field of Internet, wherein the method comprises the steps of expanding read-only instance nodes, accessing a write request to a database main instance, and accessing a read request to a read-only instance; the instance node is provided with an HAProxy and a Keepalld, manages the state of the read-only instance in the read-only instance group through the HAProxy and the Keepalld, keeps the high availability of the read-only instance, and comprises the steps of creating the read-only instance group, creating the read-only instance, updating HAProx configuration management read-only instance load, deleting the read-only instance and deleting the read-only instance group. The invention can realize automatic management of the read-only instance of the cloud database, improve the deployment operation and maintenance efficiency and reduce the misoperation risk.
Description
Technical Field
The invention relates to the technical field of Internet, in particular to a MySQL read-only instance management method, a MySQL read-only instance management system and a computer readable medium.
Background
In an application scene of the internet, the read request data volume of the database is large, the concurrency requirement is high, and the database architecture needing read-write separation meets the requirement. The read-only instance group is an implementation of read-write separation.
Under the application scenario that a small amount of write requests exist for a database but a large amount of read requests exist, the read requests of the database become the bottleneck of the database, and the conventional database example cannot simultaneously meet the quick response of the read requests and the write operations.
Disclosure of Invention
The technical task of the invention is to provide a MySQL read-only instance management method, a MySQL read-only instance management system and a computer readable medium, which can realize automatic management of read-only instances by a cloud database, improve deployment operation and maintenance efficiency and reduce misoperation risks.
The technical scheme adopted by the invention for solving the technical problems is as follows:
a MySQL read-only instance management method is characterized in that a write request is accessed to a database main instance and a read request is accessed to a read-only instance by expanding read-only instance nodes;
the instance node is provided with an HAProxy and a Keepallved, manages the state of the read-only instances in the read-only instance group through the HAProxy and the Keepallyd, and keeps the high availability of the read-only instances, including creating the read-only instance group, creating the read-only instances, updating the HAProx configuration management read-only instance load, deleting the read-only instances and deleting the read-only instance group.
Creating one or more read-only instances to form a read-only instance group, configuring virtual IP (namely VIP) of a main instance address and a read-only instance address in an application program, realizing the forwarding of a write request to the main instance, and the forwarding of a read request to the read-only instance, and realizing the read-write separation.
Further, the read-only instance nodes are created and destroyed by using Terraform tool management, and the android tool orchestrates and manages HAProxy and Keepalived deployment operation and maintenance scripts.
Preferably, the creating of the read-only instance group and the creating of the read-only instance,
creating a read-only instance, and distributing a read-only instance group for the new read-only instance;
the read-only instance is used as a slave node of the master instance and forms a master-slave cluster together with the master instance;
the main instance node of the read-only instance can be a high-availability main-slave database cluster or a single-instance database of a single node;
the read-only instance group is a HAproxy load balancing group consisting of a plurality of read-only instances, and the HAproxy is responsible for forwarding read request loads.
Preferably, when the front-end page requests the main MySQL instance to create a first read-only instance, a read-only instance group is created first, then the read-only instance is created, and the HAproxy configuration management read-only instance load is updated; when deleting the read-only instance, if the read-only instance group only has one read-only instance, deleting the read-only instance, updating the HAproxy configuration management read-only instance load, and then deleting the read-only instance group.
Preferably, in the process of creating the read-only instance and deleting the read-only instance, the HAProxy configuration on the read-only instance node is updated, including the configuration of the existing instance in the read-only instance group and the configuration of the created read-only instance, and the parameters include the port, the load balancing weight and the health check failure times.
Specifically, the steps of creating the read-only instance are as follows:
1) Judging whether the main instance in operation has a read-only instance group or not;
2) If the read-only instance group exists, the read-only instance already exists, and step 3) is executed; if the read-only instance group does not exist, creating the read-only instance group and allocating VIP for the read-only instance group;
3) The Terraform executor calls a Terraform script to create a MySQL instance node;
4) And the exception executor calls an exception script to initialize the read-only instance.
Specifically, after the read-only instance is created successfully, the read-only instance is initialized, and the step of configuring the HAProxy is as follows:
1) Judging whether the read-only instance in the read-only instance group is empty, if so, determining that the read-only instance is the first instance of the read-only instance group, and if so, determining that the read-only instance is a new read-only instance, and branching a flow;
if not, the read-only instance group is described to have the read-only instance, and the newly created read-only instance goes to branch two;
if the read-only instance is not empty, the existing read-only instance needs to be added with the configuration of the newly created read-only instance, and then a branch flow is taken;
the branch is a flow: the following steps 2), 3), 4), 5), 6), 7) are performed in sequence; and (4) branching a second flow: the following steps 2), 3), 4), 8), 6), 7) are performed in sequence; and (3) branching a three-flow process: the following steps 9), 10) are performed in sequence:
2) Initializing HAproxy and Keepalld configuration, and copying an HAproxy and Keepalld initial configuration file and a health check script to the created read-only instance node;
3) Calling an xtrabackup command to remotely backup a master instance on a read-only instance, and if the master instance is a master-slave cluster, remotely backing up data of a slave node instance; continuing with step 4);
4) Calling an xtrabackup command to recover the content of the master instance to the current read-only instance, and accessing the current read-only instance as a slave node of the master instance to the master-slave cluster;
5) Adding the configuration of the created MySQL read-only instance in the HAProxy configuration, and determining parameters including ports, load balancing weight and health check failure times;
6) Calling and starting an HAproxy command, and providing load forwarding for accessing a read request on the MySQL read-only instance by the HAproxy;
7) Calling a Keepallved starting command and starting a Keepallved state detection function;
8) Acquiring the HAproxy configuration of the existing read-only instance in the read-only instance group, adding the configuration of a newly created read-only instance node, and determining parameters including a port, a load balancing weight and health check failure times;
9) After a new read-only instance is created, adding the HAproxy configuration of the newly created read-only instance to the existing read-only instance in the original read-only instance group, and determining parameters including ports, load balancing weight and health check failure times;
10 Call reload command, where the reload configuration is sufficient if the existing read-only instance has already executed the start-up HAProxy command at the time of creation.
Specifically, when the read request traffic volume decreases, the read-only instance node is deleted, and the steps are as follows:
1) The front end requests to delete the read-only instance node, and the Terraform executor calls a Terraform script to delete the read-only instance node;
2) If the deletion fails, recording abnormal information and returning to the end;
3) If the deletion is successful, entering into an updating HAproxy configuration flow 4), 5) and 6); if the updating fails, executing the step 2);
4) Judging whether an existing read-only instance exists in the read-only instance group, and if so, executing the steps 5) and 6); if the existing read-only instance is not stored, no operation is carried out;
5) Updating the HAproxy configuration of the read-only instances in the existing read-only instance group, and determining parameters including ports, load balancing weight and health check failure times;
6) The existing read-only instance calls a reload command, the existing read-only instance already executes the starting HAproxy command when being created, and the reloading configuration is only needed;
7) After the HAProxy configuration is updated successfully, judging whether the read-only instance group is empty, if so, indicating that no read-only instance exists in the read-only instance group, and executing step 8); if not, no operation is carried out, and the process returns;
8) And deleting the empty read-only instance group and recycling the VIP address.
The writing request is accessed to the main database instance by expanding the read-only instance nodes, and the reading request is accessed to the read-only instance, so that the horizontal expansion of the MySQL instance is realized, and a large number of database reading service requests are met.
By using the Terraform and Ansible tools and packaging the script, the automatic management of the read-only instance by the cloud database can be realized, the HAproxy load configuration related to the read-only instance can be automatically added, modified and deleted, the deployment operation and maintenance efficiency is improved, and the misoperation risk is reduced.
The invention also claims a MySQL read-only instance management system, which comprises: at least one memory and at least one processor;
the at least one memory to store a machine readable program;
the at least one processor is used for calling the machine readable program and executing the method.
The invention also claims a computer readable medium having stored thereon computer instructions which, when executed by a processor, cause the processor to perform the above-described method.
Compared with the prior art, the MySQL read-only instance management method, the MySQL read-only instance management system and the computer readable medium have the following beneficial effects:
the method accesses the write request to the main database instance and the read request to the read-only instance by expanding the read-only instance nodes, thereby realizing the horizontal expansion of the MySQL instance and separating the read and the write of the instance database business;
the method supports dynamic increase and decrease of the read-only instance, load balance of the read-only instance nodes, fault transfer of the read-only instance nodes and continuous uninterrupted read request service.
According to the method and the system, through the use of Terraform and ansable tools and the encapsulation of scripts, the read-only instance service can be provided for the read-only instance group by automatically managing the read-only instance group through the cloud database, the relevant configuration of the read-only instance is automatically added, modified and deleted, compared with the read-only instance node which is manually operated, the efficiency is improved, and the misoperation risk is reduced.
Drawings
FIG. 1 is a diagram of the overall steps provided by one embodiment of the present invention to create a read-only instance;
fig. 2 is a flowchart of an anchor initializing read-only instance and configuring hash according to an embodiment of the present invention;
fig. 3 is a flowchart of a delete read-only implementation provided by an embodiment of the present invention.
Detailed Description
The invention is further described with reference to the following figures and specific examples.
In order to improve the reading performance of the database and share the pressure of the database, one or more read-only instances can be created to form a read-only instance group, and a large amount of database reading requirements are met by using the read-only instances. After the read-only instance group is created, the virtual IP (namely VIP) of the main instance address and the read-only instance address is configured in the application program, so that the writing request can be forwarded to the main instance, the reading request can be forwarded to the read-only instance, and the reading and writing separation can be realized.
The embodiment of the invention provides a MySQL read-only instance management method, which accesses a write request to a database main instance and accesses a read request to a read-only instance by expanding read-only instance nodes, thereby realizing horizontal expansion of the MySQL instance and meeting a large number of database read service requests. The instance node is provided with an HAProxy and a Keepalld, manages the state of the read-only instance in the read-only instance group through the HAProxy and the Keepalld, keeps the high availability of the read-only instance, and comprises the steps of creating the read-only instance group, creating the read-only instance, updating HAProx configuration management read-only instance load, deleting the read-only instance and deleting the read-only instance group.
And managing the creation and destruction of the read-only instance nodes by using a Terraform tool, and arranging and managing an HAProxy and a Keepalld deployment operation and maintenance script by using an android tool. By using the Terraform and Ansible tools and packaging the script, the automatic management of the read-only instance by the cloud database can be realized, the HAproxy load configuration related to the read-only instance can be automatically added, modified and deleted, the deployment operation and maintenance efficiency is improved, and the misoperation risk is reduced.
The MySQL database is used as a mainstream relational database and is widely applied to the fields of public cloud environment and Internet, and a read-only reading mode is a common implementation mode of a database instance read-write separation architecture. And managing the creation and destruction of the read-only instance nodes by using a Terraform tool, and arranging and managing an HAProxy and a Keepalld deployment operation and maintenance script by using an android tool. The state of the read-only instance in the read-only instance group is managed through HAProxy and Keepallyd software, and the read-only instance is kept highly available.
Terraform is a tool for safely and efficiently building, modifying and versioning infrastructure (an orchestration tool for infrastructure automation). The method can manage and maintain IT resources by using the Terraform code, and automatically complete a part of tasks needing manual operation by a program, so that the effect of doing the task is high-efficiency and is not easy to make mistakes.
The infrastructure is an automatic operation and maintenance tool, and can realize functions of batch system configuration, batch program deployment, batch operation commands and the like. By compiling an audible script editing management HAproxy and a Keepalld deployment operation and maintenance script, the configuration of software can be automatically modified, and the misoperation risk is reduced.
The HAproxy is a proxy software based on TCP and HTTP application, can also be used as a load balancer, can support tens of thousands of concurrent connections, can protect a server from being exposed on a network through port mapping, and is provided with a page for monitoring the state of the server.
The Keepalived is a high-performance server high-availability solution, can be used for preventing the occurrence of single-point faults of the server, monitors the state of the HAProxy, and when the HAProxy provides a MySQL service and fails, dynamically drifts the VIP to a normally-running MySQL instance in the read-only instance group, so as to keep the high availability of the read-only instance function.
The precondition for implementing the method comprises the following steps:
the database instance deployed in the public cloud environment can normally run;
the cluster state of the database instance is normal;
the instance node is installed with HAProxy and Keepalived software.
Aiming at a database instance deployed in a public cloud environment, writing an automated operation and maintenance management read-only instance script by means of a Terraform resource management tool and an android automated operation and maintenance management tool, and automatically modifying an HAproxy and a Keepallved configuration file to realize the management function of the read-only instance.
When a front-end page requests a main MySQL instance to create a first read-only instance, firstly creating a read-only instance group, then creating the read-only instance, and updating an HAproxy configuration management read-only instance load; when deleting the read-only instance, if the read-only instance group only has one read-only instance, deleting the read-only instance, updating the HAproxy configuration management read-only instance load, and then deleting the read-only instance group.
The creating of the read-only instance group and the creating of the read-only instance,
creating a read-only instance, and distributing a read-only instance group for the new read-only instance;
the read-only instance is used as a slave node of the master instance and forms a master-slave cluster together with the master instance;
the main instance node of the read-only instance can be a high-availability main-slave database cluster or a single-instance database of a single node;
the read-only instance group is a HAproxy load balancing group consisting of a plurality of read-only instances, and the HAproxy is responsible for forwarding read request loads.
The steps for creating a read-only instance are as follows:
s201, judging whether a read-only instance group exists in the running main instance;
s202, if a read-only instance group exists, which indicates that a read-only instance already exists, executing the step S203; if the read-only instance group does not exist, creating the read-only instance group and allocating VIP for the read-only instance group;
s203, calling a Terraform script by a Terraform executor to create a MySQL instance node;
s204, the exception executor calls an exception script to initialize the read-only instance.
In the process of creating the read-only instance and deleting the read-only instance, the HAproxy configuration on the read-only instance node is updated, the HAproxy configuration comprises the configuration of the existing instance in the read-only instance group and the configuration of the created read-only instance, and the parameters comprise ports, load balancing weight and health check failure times.
The flow is shown in figure 1.
Initializing the read-only instance after the read-only instance is successfully created, and configuring the HAproxy according to the following steps:
s301, judging whether the read-only instance in the read-only instance group is empty, if so, determining the read-only instance as a first instance of the read-only instance group, and if so, determining the read-only instance as a new read-only instance, and branching to a flow;
if not, the read-only instance group is described to have the read-only instance, and the newly created read-only instance goes to branch two;
if the read-only instance is not empty, the existing read-only instance needs to be added with the configuration of the newly created read-only instance, and then a branch flow is taken;
the branch is a flow: the following steps S302, S303, S304, S305, S306, S307 are sequentially performed; and (4) branching a second flow: the following steps S302, S303, S304, S308, S306, S307 are sequentially performed; and (3) branching a three-flow process: the following steps S309, S310 are performed in order:
s302, initializing HAProxy and Keepallyd configuration, and copying an HAProxy and Keepalld initial configuration file and a health check script to the created read-only instance node;
s303, calling a xtrabackup command to remotely backup the master instance on the read-only instance, and if the master instance is a master-slave cluster, remotely backing up the data of the slave node instance; continuing to step S304;
s304, calling an xtrabackup command to recover the content of the master instance to the current read-only instance, and accessing the current read-only instance as a slave node of the master instance to the master-slave cluster;
s305, adding the configuration of the created MySQL read-only instance in the HAproxy configuration, and determining parameters such as ports, load balancing weight, health check failure times and the like;
s306, calling a command for starting the HAproxy, and providing load forwarding for accessing the read request on the MySQL read-only instance by the HAproxy;
s307, calling a Keepalld starting command, and starting a Keepalld state detection function;
s308, acquiring the HAproxy configuration of the existing read-only instances in the read-only instance group, increasing the configuration of newly created read-only instance nodes, and determining parameters such as ports, load balancing weight, health check failure times and the like;
s309, after a new read-only instance is created, adding the HAproxy configuration of the newly created read-only instance to the existing read-only instance in the original read-only instance group, and determining parameters such as ports, load balancing weight, health check failure times and the like;
s310, calling a reload HAProxy command, wherein the starting HAProxy command is already executed when the existing read-only instance is created, and the configuration can be reloaded.
The specific flow is shown in fig. 2.
When the read request traffic volume decreases, the read-only instance node may be deleted, as shown in fig. 3, and the flow is as follows:
s401, the front end requests to delete the read-only instance node, and the Terraform executor calls a Terraform script to delete the read-only instance node;
s402, if the deletion fails, recording abnormal information, and returning to the end;
s403, if the deletion is successful, entering into an HAproxy configuration updating process S404, S405 and S406; if the update fails, step S402 is executed;
s404, judging whether the read-only instance exists in the read-only instance group, if so, executing the steps S405 and S406; if the existing read-only instance is not stored, no operation is carried out;
s405, updating HAproxy configuration of the read-only instances in the existing read-only instance group, and determining parameters such as ports, load balancing weight, health check failure times and the like;
s406, the existing read-only instance calls a reload command, the existing read-only instance already executes the starting HAproxy command when being created, and the reloading configuration is only needed;
s407, after the HAProxy configuration is updated successfully, judging whether the read-only instance group is empty, if so, indicating that no read-only instance exists in the read-only instance group, executing the step S408; if not, no operation is carried out, and the process returns;
and S408, deleting the empty read-only instance group and recycling the VIP address.
The method comprises the steps that a management terminal service program calls a Terraform script and an Ansine script to manage MySQL read-only instance nodes, one or more read-only instances are created to meet different pressure requirements of users, and database pressure is shared; the database read-only instance can be managed by one key, and misoperation risks caused by manual creation of the database instance are reduced; the method comprises the steps that a high-availability cluster is built through the HAProxy and the Keepalived to keep the service of the read-only instance uninterrupted, the Keepalived keeps the virtual VIP to automatically drift to the normal read-only instance node through monitoring the state of the HAProxy software in the read-only instance group when the HAProxy of the read-only instance node fails, and the high availability of the read-only instance service is kept.
The embodiment of the invention also provides a MySQL read-only instance management system, which comprises: at least one memory and at least one processor;
the at least one memory to store a machine readable program;
the at least one processor is configured to invoke the machine-readable program to execute the MySQL read-only instance management method in the above embodiment of the present invention.
An embodiment of the present invention further provides a computer-readable medium, where a computer instruction is stored on the computer-readable medium, and when the computer instruction is executed by a processor, the processor is caused to execute the MySQL read-only instance management method in the foregoing embodiment of the present invention. Specifically, a system or an apparatus equipped with a storage medium on which software program codes that realize the functions of any of the above-described embodiments are stored may be provided, and a computer (or a CPU or MPU) of the system or the apparatus is caused to read out and execute the program codes stored in the storage medium.
In this case, the program code itself read from the storage medium can realize the functions of any of the above-described embodiments, and thus the program code and the storage medium storing the program code constitute a part of the present invention.
Examples of the storage medium for supplying the program code include a floppy disk, a hard disk, a magneto-optical disk, an optical disk (e.g., CD-ROM, CD-R, CD-RW, DVD-ROM, DVD-RAM, DVD-RW, DVD + RW), a magnetic tape, a nonvolatile memory card, and a ROM. Alternatively, the program code may be downloaded from a server computer via a communications network.
Further, it should be clear that the functions of any one of the above-described embodiments may be implemented not only by executing the program code read out by the computer, but also by causing an operating system or the like operating on the computer to perform a part or all of the actual operations based on instructions of the program code.
Further, it is to be understood that the program code read out from the storage medium is written to a memory provided in an expansion board inserted into the computer or to a memory provided in an expansion unit connected to the computer, and then causes a CPU or the like mounted on the expansion board or the expansion unit to perform part or all of the actual operations based on instructions of the program code, thereby realizing the functions of any of the above-described embodiments.
While the invention has been particularly shown and described with reference to the preferred embodiments and drawings, it is not intended to be limited to the specific embodiments disclosed, and it will be understood by those skilled in the art that various other combinations of code approval means and various embodiments described above may be made, and such other embodiments are within the scope of the present invention.
Claims (8)
1. A MySQL read-only instance management method is characterized in that a write request is accessed to a database main instance and a read request is accessed to a read-only instance by expanding read-only instance nodes;
the instance node is provided with an HAProxy and a Keepalld, manages the state of the read-only instance in the read-only instance group through the HAProxy and the Keepalld, and keeps the high availability of the read-only instance, including creating the read-only instance group, creating the read-only instance, updating the HAProx configuration management read-only instance load, deleting the read-only instance and deleting the read-only instance group;
the steps for creating a read-only instance are as follows:
1) Judging whether the running main instance has a read-only instance group or not;
2) If the read-only instance group exists, the read-only instance already exists, and step 3) is executed; if the read-only instance group does not exist, creating the read-only instance group and allocating a VIP to the read-only instance group;
3) The Terraform executor calls a Terraform script to create a MySQL instance node;
4) The anchor executor calls an anchor script to initialize the read-only instance;
initializing the read-only instance after the read-only instance is successfully created, and configuring the HAproxy according to the following steps:
1) Judging whether the read-only instance in the read-only instance group is empty, if so, determining that the read-only instance is the first instance of the read-only instance group, and if so, determining that the read-only instance is a new read-only instance, and branching a flow;
if not, the read-only instance group is described to have the read-only instance, and the newly created read-only instance goes to branch two;
if the read-only instance is not empty, the existing read-only instance needs to be added with the configuration of the newly created read-only instance, and then a branch flow III is taken;
the branch is a flow: the following steps 2), 3), 4), 5), 6), 7) are performed in sequence; and (4) branching a second flow: the following steps 2), 3), 4), 8), 6), 7) are performed in sequence; and (4) branching a three-flow: the following steps 9), 10) are performed in sequence:
2) Initializing HAproxy and Keepalld configuration, and copying an HAproxy and Keepalld initial configuration file and a health check script to the created read-only instance node;
3) Calling a xtrabackup command to remotely backup a master instance on a read-only instance, and remotely backing up data of a slave node instance if the master instance is a master-slave cluster; continuing with step 4);
4) Calling the xtrabackup command to restore the content of the main instance to the current read-only instance, and accessing the current read-only instance as a slave node of the main instance to the main and slave clusters;
5) Adding the configuration of the created MySQL read-only instance in the HAproxy configuration, and determining parameters including ports, load balancing weight and health check failure times;
6) Calling and starting an HAproxy command, and providing load forwarding for accessing a read request on the MySQL read-only instance by the HAproxy;
7) Calling a Keepalived starting command, and starting a Keepalived state detection function;
8) Acquiring the HAproxy configuration of the existing read-only instance in the read-only instance group, adding the configuration of a newly created read-only instance node, and determining parameters including a port, a load balancing weight and health check failure times;
9) After the new read-only instance is created, adding the HAproxy configuration of the newly created read-only instance to the existing read-only instance in the original read-only instance group, and determining parameters including ports, load balancing weight and health check failure times;
10 Call reload command, existing read-only instance has already executed start-up HAProxy command when being created, where the reload configuration is only needed;
the steps for deleting read-only instance nodes are as follows:
1) The front end requests to delete the read-only instance node, and the Terraform executor calls a Terraform script to delete the read-only instance node;
2) If the deletion fails, recording abnormal information and returning to the end;
3) If the deletion is successful, entering into an updating HAproxy configuration flow 4), 5) and 6); if the updating fails, executing the step 2);
4) Judging whether an existing read-only instance exists in the read-only instance group, and if so, executing the steps 5) and 6); if the existing read-only instance does not exist, no operation is carried out;
5) Updating the HAproxy configuration of the read-only instances in the existing read-only instance group, and determining parameters including ports, load balancing weight and health check failure times;
6) The existing read-only instance calls a reload command, the starting of the HAproxy command is already executed when the existing read-only instance is created, and the configuration can be reloaded;
7) After the HAProxy configuration is updated successfully, judging whether the read-only instance group is empty, if so, indicating that no read-only instance exists in the read-only instance group, and executing the step 8); if not, no operation is carried out, and the process returns;
8) And deleting the empty read-only instance group and recycling the VIP address.
2. The MySQL read-only instance management method according to claim 1, wherein creating and destroying read-only instance nodes are managed by using a Terraform tool, and an audible tool organizes and manages HAProxy and keep deployed operation and maintenance scripts.
3. The MySQL read-only instance management method according to claim 2, wherein the creating of the read-only instance group and the creating of the read-only instance,
creating a read-only instance, and distributing a read-only instance group for the new read-only instance;
the read-only instance is used as a slave node of the master instance and forms a master-slave cluster together with the master instance;
the main instance node of the read-only instance is a high-availability main-slave database cluster or a single-instance database of a single node;
the read-only instance group is a HAproxy load balancing group consisting of a plurality of read-only instances, and the HAproxy is responsible for forwarding read request loads.
4. The MySQL read-only instance management method according to claim 1, 2 or 3, characterized in that when a front-end page requests a main MySQL instance to create a first read-only instance, a read-only instance group is created first, then a read-only instance is created, and HAProxy configuration management read-only instance load is updated; when the read-only instance is deleted, if the read-only instance group only has one read-only instance, the read-only instance is deleted, the HAproxy configuration management read-only instance load is updated, and then the read-only instance group is deleted.
5. The MySQL read-only instance management method according to claim 4, wherein in the process of creating and deleting the read-only instance, the HAproxy configuration on the read-only instance node is updated, including the configuration of the existing instance in the read-only instance group and the configuration of the created read-only instance, and the parameters include port, load balancing weight and health check failure times.
6. The MySQL read-only instance management method according to claim 4, wherein when the read request traffic volume is reduced, the read-only instance node is deleted.
7. A MySQL read-only instance management system is characterized by comprising: at least one memory and at least one processor;
the at least one memory to store a machine readable program;
the at least one processor configured to invoke the machine readable program to perform the method of any of claims 1 to 6.
8. A computer readable medium having stored thereon computer instructions which, when executed by a processor, cause the processor to perform the method of any of claims 1 to 6.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202011596472.XA CN112667711B (en) | 2020-12-29 | 2020-12-29 | MySQL read-only instance management method, system and computer readable medium |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202011596472.XA CN112667711B (en) | 2020-12-29 | 2020-12-29 | MySQL read-only instance management method, system and computer readable medium |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN112667711A CN112667711A (en) | 2021-04-16 |
| CN112667711B true CN112667711B (en) | 2022-12-27 |
Family
ID=75410239
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202011596472.XA Active CN112667711B (en) | 2020-12-29 | 2020-12-29 | MySQL read-only instance management method, system and computer readable medium |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN112667711B (en) |
Families Citing this family (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113836179B (en) * | 2021-08-23 | 2023-10-27 | 辽宁振兴银行股份有限公司 | Transaction read-write separation device |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN105224527A (en) * | 2014-05-27 | 2016-01-06 | 北京宸瑞科技有限公司 | Be applicable to the general ETL method of multiple object table update mode |
| CN109542611A (en) * | 2017-09-21 | 2019-03-29 | 中国移动通信集团重庆有限公司 | Database, that is, service system, database dispatching method, equipment and storage medium |
Family Cites Families (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN107493327B (en) * | 2017-08-11 | 2020-05-15 | 杭州顺网科技股份有限公司 | Distributed cache management method, system and data management system |
| US11138198B2 (en) * | 2018-10-19 | 2021-10-05 | Oracle International Corporation | Handling of unresponsive read only instances in a reader farm system |
| CN110297867B (en) * | 2019-06-28 | 2021-08-17 | 浪潮软件集团有限公司 | Database cluster operation method and system based on domestic CPU and distributed container cluster |
| CN110569307A (en) * | 2019-09-09 | 2019-12-13 | 四川长虹电器股份有限公司 | MySQL read-write separation method based on ProxySQL and MGR |
-
2020
- 2020-12-29 CN CN202011596472.XA patent/CN112667711B/en active Active
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN105224527A (en) * | 2014-05-27 | 2016-01-06 | 北京宸瑞科技有限公司 | Be applicable to the general ETL method of multiple object table update mode |
| CN109542611A (en) * | 2017-09-21 | 2019-03-29 | 中国移动通信集团重庆有限公司 | Database, that is, service system, database dispatching method, equipment and storage medium |
Also Published As
| Publication number | Publication date |
|---|---|
| CN112667711A (en) | 2021-04-16 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN111522628B (en) | Kubernetes cluster building deployment method, framework and storage medium based on OpenStack | |
| CN107515776B (en) | Method for upgrading service continuously, node to be upgraded and readable storage medium | |
| US10237118B2 (en) | Efficient application build/deployment for distributed container cloud platform | |
| CN108664496B (en) | Data migration method and device | |
| US7958210B2 (en) | Update management method and update management unit | |
| CN107741852B (en) | Service deployment method based on cluster software | |
| CN113296792B (en) | Storage method, device, equipment, storage medium and system | |
| CN104272292A (en) | Network resource deployment for cloud-based services | |
| CN111897558A (en) | Kubernets upgrading method and device for container cluster management system | |
| US11588698B2 (en) | Pod migration across nodes of a cluster | |
| CN111124475A (en) | Method for storage management, electronic device and computer-readable storage medium | |
| CN110673923A (en) | XWIKI system configuration method, system and computer equipment | |
| US10019345B2 (en) | Executing multi-version tests against a multi-version application | |
| WO2021120968A1 (en) | Server capacity expansion method and capacity expansion system | |
| CN111880738A (en) | Method for automatically creating and mounting LVM (logical volume manager) volume in K8s environment | |
| CN111240892A (en) | Data backup method and device | |
| CN112667711B (en) | MySQL read-only instance management method, system and computer readable medium | |
| CN104793981A (en) | Online snapshot managing method and device for virtual machine cluster | |
| CN104517067A (en) | Method, device and system for data access | |
| CN102023857A (en) | ServiceOS-based multi-platform application program service management method and system | |
| CN112130953A (en) | Application deployment method for Windows Hyper-V virtualization | |
| CN113626144B (en) | Method, device, equipment and readable medium for creating and storing double live volumes by clusters | |
| EP3340048A1 (en) | System and method for content - application split | |
| US11461131B2 (en) | Hosting virtual machines on a secondary storage system | |
| CN110377397B (en) | Stock application rapid deployment and expansion method based on virtual machine replication |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |