A database management method and system based on a container platform

Abstract

This invention discloses a database management method and system based on a container platform. The method is applied to an automatic failover model, including: logging into node nodes at preset time intervals to read the database's heartbeat table, and querying the health status of each database node based on the heartbeat table; detecting the health status of node nodes; if a node node is detected as healthy, but the database master node fails, performing database failover through cluster high availability components and automatically switching the database master node to a database slave node; if a node node fails, performing database migration through unit service high availability components and automatically switching the database master node to a database slave node. The technical solution provided by this invention can improve fault handling speed, reduce erroneous failovers, reduce manual maintenance, and make the system highly available.

Description

Technical Field

[0001] This invention relates to the field of database technology, and in particular to a database management method and system based on a container platform. Background Technology

[0002] Containers are a lightweight virtualization technology that can provide multiple independent processes, files, and network spaces simultaneously on a single physical machine. Experiments show that, in almost all cases, containers exhibit performance equal to or better than virtual machines. With the increasing popularity of container technology, major database vendors provide corresponding container images, making it easy to host data within containers. Containerizing databases, through methods such as mounting directories and data volumes, can significantly improve the efficiency of database expansion and contraction.

[0003] In existing technologies, high availability for container platforms is typically achieved through either automated lifecycle management based on native Kubernetes (k8s) or master-slave replication and read-write separation based on MHA (Master High Availability). The former restarts failed container Pods to replace them and terminates Pods that are unresponsive to user-defined health checks. When a database container fails, it can be restarted to restore the database and resume data services. The latter consists of a single master node and multiple slave nodes. Applications perform write operations on the master node and read operations on the slave nodes. If the master node of the database cluster fails, the application can be switched to a slave node, and data synchronization between nodes uses database replication technology.

[0004] In the process of developing this invention, the inventors discovered the following shortcomings in existing technologies: Automated management of container lifecycles based on native Kubernetes will interrupt business operations during container Pod restarts. Furthermore, when multiple database nodes fail, the restart order becomes problematic; the database cluster requires priority startup of the master node. This necessitates significant manual intervention. High-availability methods based on MHA master-slave replication and read-write separation require the database to maintain transparency of master-slave switching to the application, making them unsuitable for large-scale cluster deployments. Moreover, data consistency relies on native database semi-synchronous replication, which carries the risk of data inconsistency, requires manual intervention, and may result in erroneous failovers, significantly slowing down fault handling. Summary of the Invention

[0005] This invention provides a database management method and system based on a container platform, which can improve fault handling speed, reduce false failovers, reduce manual maintenance, and enable the system to have high availability. ；

[0006] In a first aspect, embodiments of this application provide a database management method for a container-based platform, the method comprising:

[0007] Log in to the node at preset time intervals to read the heartbeat table of the database, and query the health status of each database node based on the heartbeat table;

[0008] Check the health status of the node;

[0009] If a node is detected to be healthy, but the database master node fails, the cluster high availability component will be used to perform database failover and automatically switch the database master node and database slave node.

[0010] If a node failure is detected, the database will be migrated through the unit service high availability component, and the database master node and database slave node will be automatically switched.

[0011] Secondly, embodiments of this application provide a database management device for a container-based platform, the device comprising:

[0012] The query module is used to log in to the node at preset time intervals to read the heartbeat table of the database and query the health status of each database node based on the heartbeat table.

[0013] The detection module is used to detect the health status of node nodes;

[0014] The cluster high availability component is used to perform database failover and automatically switch the database master node and database slave node if a healthy node is detected and the database master node fails.

[0015] The unit service high availability component is used to perform database migration and automatically switch between the database master node and the database slave node if a node failure is detected.

[0016] The technical solution of this invention, by reading the database heartbeat table to query the health status of database nodes, enables the following: Firstly, when a node is healthy but the database master node fails, the cluster high-availability component performs database failover and automatically switches between the database master and slave nodes. Secondly, when a node fails, the unit service high-availability component performs database migration and automatically switches between the database master and slave nodes. This improves fault handling speed, reduces erroneous switches, and minimizes manual maintenance, thus ensuring high system availability. It solves the problem of databases failing to operate normally during maintenance in existing technologies, ensuring data stability during node switching in container platforms and improving the operational performance of the container platform's database.

[0017] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of the present invention, nor is it intended to limit the scope of the invention. Other features of the invention will become readily apparent from the following description. Attached Figure Description

[0018] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1a This is a flowchart of a database management method based on a container platform according to Embodiment 1 of the present invention;

[0020] Figure 1b This is a flowchart of a failover operation or an online switchover operation that initiates a failure when a failure occurs, obtained according to the method provided in Embodiment 1.

[0021] Figure 1c This is a MySQL database node topology table obtained by the method provided in Embodiment 1 of the present invention;

[0022] Figure 1d This is a flowchart of a node fault determination method provided in Embodiment 1 of the present invention.

[0023] Figure 2 This is a flowchart of a database management method based on a container platform according to Embodiment 2 of the present invention;

[0024] Figure 3 This is a schematic diagram of the structure of a container-based platform database management device according to Embodiment 3 of the present invention;

[0025] Figure 4 This is a schematic diagram of the structure of a container-based platform database management system provided in Embodiment 4 of the present invention. Detailed Implementation

[0026] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0027] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0028] To enable those skilled in the art to better understand the present invention, a brief introduction to existing container-based database management methods is provided first. Specifically, MySQL is currently the most popular open-source relational database, and its low cost, ease of deployment, and high performance are gradually making it the mainstream database solution. Its open-source nature, in particular, is widely welcomed by developers, significantly reducing development costs. Containers are a lightweight virtualization technology that can simultaneously provide multiple independent processes, files, and network spaces on a single physical machine. Containerized applications offer better performance than virtual machines and bare metal. With the popularity of container technology, mainstream database vendors provide corresponding container images, making it easy to host databases in containers. Containerizing a MySQL database, through methods such as mounting directories and data volumes, achieves IO efficiency similar to direct deployment on a physical machine, but with significant improvements in scaling up and down. Therefore, more and more companies are choosing to containerize their MySQL database systems.

[0029] Kubernetes (k8s) is currently the mainstream container orchestration and management tool. It's an open-source container cluster management platform that enables automated deployment, scaling, and maintenance of container clusters. Although native k8s technology has developed rapidly in recent years, from supporting stateless to stateful applications, the inherent requirements of databases necessitate further development and improvements to k8s to enable rapid deployment and more flexible scaling of MySQL database clusters. Furthermore, database clusters based on the k8s container platform offer advantages such as resource savings, improved resource utilization, and automated operation and maintenance.

[0030] Whether it's a traditional platform or a MySQL database management architecture based on a Kubernetes container platform, it should possess the following characteristics:

[0031] First, the database is transparent to the front-end business, and the business will not be interrupted due to database failure;

[0032] Second, the data on non-master nodes should be consistent with the data on master nodes in real time or eventually.

[0033] Third, when a business needs to switch databases due to a high availability mechanism, the database content before and after the switch should be consistent, and the business should not be affected by data loss or inconsistency.

[0034] Currently, there are several ways to manage MySQL based on the Kubernetes container platform:

[0035] Method 1: Implement MySQL database management based on native Kubernetes' automated management of container lifecycle.

[0036] Kubernetes (k8s) restarts failed container Pods to replace the faulty ones and kills Pods that are unresponsive to user-defined health checks. When a MySQL database container fails, it can be recovered by restarting the container and then providing data services again. However, the restart process will interrupt business operations. Furthermore, when multiple database nodes fail, the restart order becomes an issue. The database cluster needs to start the master node first. This requires significant manual intervention. Therefore, this method cannot meet the high availability requirements of enterprise-level MySQL database clusters on container platforms.

[0037] Method 2 employs a master-slave replication and read-write separation approach based on MHA (Master High Availability), consisting of a single master node and multiple slave nodes. Business applications perform write operations on the master node and read operations through the slave nodes. When the master node of the MySQL cluster fails, the business application can be switched to a slave node, with data synchronization between nodes using MySQL replication technology. This method utilizes native Kubernetes container technology to monitor the status of both master and slave nodes. However, this method requires maintaining transparency of master-slave switching to the application and is not suitable for large-scale cluster deployments.

[0038] Among the existing management methods for MySQL database clusters based on the Kubernetes platform, Method 1 mainly has the following problems:

[0039] (1) It cannot achieve online automatic failover and automatic master-slave node switching, requiring a lot of manual operation and maintenance intervention; in particular, when a master-slave failure occurs, it is also necessary to manually switch the master-slave nodes of the MySQL database.

[0040] (2) If a node physical machine fails or resources are insufficient, or if the MySQL database master and slave nodes are on the same node and cannot be switched, the database service cannot be restored even by restarting the container. In this case, manual operation and maintenance intervention is still required.

[0041] Method 2 has the following main problems:

[0042] (1) Data consistency is guaranteed by native MySQL database semi-synchronous replication, which poses a risk of data inconsistency. When a failure occurs, if the replication status of the database cluster is passively switched to asynchronous, then when the master node recovers, whether the last part of the data needs to be flashed back is not something that can be automatically achieved by the MHA-based high availability method, and manual operation and maintenance intervention is required.

[0043] (2) If a network failure occurs between master and slave nodes, automatic master-slave switching is prone to split-brain phenomena. For example, if the master node becomes inaccessible for a short period due to switch jitter, automatic master-slave switching is triggered, and the VIP is moved to the new master node. Subsequently, the network is restored, and the original master node can be accessed. However, since the VIP has not been removed from the original master node, both the old and new nodes simultaneously possess the VIP, resulting in a split-brain phenomenon.

[0044] (3) If a physical machine node fails, the database service cannot be started normally even if the container is restarted, and manual operation and maintenance intervention is required.

[0045] (4) The management node in the MHA that is switching over also has a single point of failure;

[0046] There is a possibility of misdiagnosis of faults, resulting in erroneous switching.

[0047] To address the aforementioned issues, this invention employs a custom fault detection mechanism to automatically detect and identify faults. It checks the health status of node nodes; if a node is healthy and the database master node is not showing a heartbeat, a custom high-availability cluster component (Colony Master High Availability, CMHA) can be used for automatic failover and master-slave node switching. If an unhealthy node is detected, a unit high-availability (unitHA) component can be used to migrate the database container and perform master-slave switching, quickly rebuilding the original MySQL database container Pod on an idle physical node, thus ensuring high availability of container resources. Furthermore, Consul Server and Consul Agent components are used to ensure the HA of each high-availability component, thereby resolving the single point of failure issue. To maintain the continuity of overall external services, a ProxySQL middleware is added to make business access more transparent and to prevent split-brain problems. Master-slave data synchronization leverages the inherent strong consistency of the database cluster, employing an enhanced lossless semi-synchronous replication mode. In the event of a failure, the database does not automatically degrade to asynchronous synchronous mode, thus ensuring strong data consistency. This approach effectively solves the problems of existing methods and also reduces manual maintenance costs.

[0048] Example 1

[0049] Figure 1aThis invention provides a flowchart of a container platform-based database management method according to Embodiment 1. This method can be executed by a container platform-based database management device, which can be implemented in hardware and / or software. The device can be configured in an electronic device executing the container platform-based database management method. The database can be a MySQL database, and the database can be a database cluster deployed on a Kubernetes (k8s) container platform. The k8s container platform is deployed on a physical machine server, and the MySQL database cluster runs on the k8s platform. The method can be applied to an intelligent automatic failover model, which includes high-availability components to increase the versatility of the MySQL database in handling different scenarios, thereby improving the overall performance of the MySQL database system. The technical solution provided in this embodiment effectively utilizes the master-slave replication supported by the MySQL database to ensure strong data consistency. Furthermore, it can automatically determine whether a fault has occurred and automatically switch over using a custom high-availability method. This improves fault handling speed and achieves high availability for the MySQL database simply and flexibly, reducing accidental failovers and manual maintenance, thus ensuring high system availability.

[0050] like Figure 1a As shown, the method includes:

[0051] S110. Log in to the node at preset time intervals to read the heartbeat table of the database, and query the health status of each database node based on the heartbeat table.

[0052] The database can be a MySQL database, and the database node can be a MySQL database node.

[0053] In this embodiment of the invention, the preset time is a custom time frequency. Optionally, the preset time period can be 10 seconds, 30 seconds, or can be set as needed.

[0054] In this embodiment, optionally, the health status of each MySQL database node is queried based on the heartbeat table. Specifically, a custom fault detection mechanism is used to automatically detect and identify faults. A scheduled task is set to log in to the node at preset intervals to read the MySQL database heartbeat table and check the status of each MySQL database node to further determine its health status. Specifically, the interval can be between 10 and 30 seconds, depending on the system configuration. Successful login to the physical node's IP address via a ping command, and a successful return of a heartbeat from the MySQL database on the node, indicates that the corresponding MySQL database node is in normal status.

[0055] S120, Check the health status of the node;

[0056] In this embodiment, the specific steps for detecting the health of a node are as follows:

[0057] Step 1: Check the nodes in the cluster via the Kubernetes interface to ensure they are functioning correctly;

[0058] Step 2: Check that the services registered by the corresponding node in the first Consul (Server High-End Availability Cluster) module are healthy.

[0059] Step 3: A Pod exists on the corresponding node; where the Pod is the smallest management unit in Kubernetes, and a Pod can encapsulate one or more containers.

[0060] The above three steps can be used to detect the health status of a node.

[0061] S130. If a healthy node is detected and the database master node fails, the database failover is performed through the cluster high availability component, and the database master node and database slave node are automatically switched.

[0062] In this embodiment of the invention, optionally, the database master node can be a MySQL database node; optionally, database failover and automatic switching between the database master node and the database slave node are performed through CMHA (Cross-Master High Availability), including: storing database topology information through the first Consul module in the CMHA component; querying the database topology information from the first Consul module through the Switchover Manager (SWM) module in the CMHA component, and automatically switching between the database master node and the database slave node based on the queried topology information, as well as performing database failover.

[0063] The CMHA component supports automatic repair functionality. Specifically, when the MySQL database process fails, the repair function automatically starts the MySQL database using the Kubernetes container platform and attempts to maintain consistency between the database and the state in the topology tables. If the MySQL slave node replication fails, the repair function automatically attempts to perform repairs to maintain consistency with the state maintained in the topology. When the MySQL master node fails, after the automatic failover is triggered, the original master node will automatically start and rejoin the MySQL database cluster as a slave node.

[0064] In this embodiment of the invention, the CMHA component includes a Consul module and a Switch Manager (SWM) module; wherein, the CMHA component Consul module serves as the first Consul module. The first Consul module is a module that supports service registration and service health checks based on the GOSSIP (anti-entropy) algorithm and the RAFT (consensus) consensus algorithm. The RAFT protocol is used to ensure high availability of services, and the GOSSIP protocol manages members and broadcast messages. Furthermore, the Consul module includes a complete key-value store for storing the cluster topology table. The structure of the topology table storing cluster information is shown in Table 1:

[0065] Table 1

[0066]

[0067]

[0068] Optionally, the SWM module can query topology information from the first Consul component in real time according to the set switching strategy, and switch data routes accordingly. The SWM module maintains topology data in the first Consul and key-value storage. Furthermore, the SWM module checks the database status by running scripts and then updates the information in the topology table of the first Consul module. The SWM module operates in a three-node (master and backup) mode, consisting of one master SWM module and two slave SWM modules. The SWM module and the first Consul module are deployed in the same container, and the election of the master SWM module is automatically completed through Consul session locks (session control thread), thus ensuring the high availability of the SWM module itself through the first Consul module. Furthermore, the SWM module also supports fault detection and discovery, initiating failover or online switchover operations when the MySQL database master node fails. Figure 1b As shown.

[0069] In this embodiment of the invention, optionally, when the database is a MySQL database, CMHA supports an automatic repair function. When the MySQL database process fails, the repair function automatically starts the MySQL database using the Kubernetes container platform and attempts to maintain consistency between the state of the MySQL database and the topology table. If the replication of the MySQL database slave node fails, the repair function automatically attempts to perform repair to maintain consistency with the state maintained in the topology. When the MySQL database master node fails, after the automatic failover is triggered, the original MySQL database master node will automatically start and rejoin the MySQL database cluster as a MySQL database slave node.

[0070] Among them, a failure was detected in the MySQL database master node, including:

[0071] If the SWM module detects n consecutive instances that the database master node has no heartbeat, then the status of the database master node is set to offline, indicating that the database master node has failed.

[0072] In this embodiment, specifically, the SWM module will periodically check the status of the database service. It reads the heartbeat table of the MySQL database from the logged-in node to ensure that each MySQL database node is "online" and is responsible for updating the topology information to the first Consul module. If there is still no heartbeat after 10 polling checks, the "STATUS" field of that node will be set to "offline," confirming a MySQL database node failure. A specific topology table example is shown below. Figure 1c As shown.

[0073] In this embodiment of the invention, the switching rules between the MySQL database master node and the MySQL database slave node after a failure occur are as follows:

[0074] (1) If the MySQL database master node fails and the MySQL database status in the topology table is offline, then an automatic failover operation will be performed.

[0075] (2) If a MySQL database slave node fails and the database status in the topology table is offline, no operation is performed, and the MySQL database service is marked as abnormal;

[0076] (3) If the MySQL database slave node fails and the MySQL database status in the topology table is online and the replication status is abnormal, that is, the IO thread or SQL thread is abnormal, then the replication thread start operation is executed.

[0077] (4) If the MySQL database slave node fails and both are semi-synchronous, and the MySQL database status in the topology table is "offline" or the replication status is abnormal, the MySQL database master node will actively downgrade to asynchronous mode.

[0078] In this embodiment of the invention, optionally, when the MySQL database master node fails, a failover operation will be automatically performed, and the specific switching process is as follows:

[0079] Step 1: Clean up the MySQL database master node information in the ProxySQL middleware;

[0080] Step 2: Stop all I / O threads on slave nodes;

[0081] Step 3: From the candidate database of semi-synchronous replication mode, find the node that receives the most registrations as the target to be switched;

[0082] Step 4: Promote the selected node to be switched to the new MySQL database master node, including: waiting for the node to be promoted to complete the application of all relay logs; updating the topology table, clearing the "replication" information and disabling read-only mode at the same time, setting the parameter read_only=0; enabling the semi-synchronous replication mode of the current new master node, setting the parameter rpl_semi_sync_master_enabled=1; updating the existing status to the topology table; and reassigning other slave nodes to the new master node.

[0083] Step 5: Change the status of the original MySQL database master node from offline to isolated;

[0084] Step 6: Update the new MySQL database master node information back into the ProxySQL middleware;

[0085] Step 7: After the original MySQL database master node is repaired, set it to online status and make it the new MySQL database slave node. A preset mechanism will be used to determine if the data on the current MySQL database master node is consistent with the original MySQL database master node. If data synchronization is complete, the original MySQL database master node will be set as the MySQL database slave node.

[0086] If automatic failover fails after a failure occurs, a manual failover operation can be performed. The specific operation procedure is as follows:

[0087] Step 1: Provide the IP address and port number of the node to be switched;

[0088] Step 2: Determine whether the node to be switched is a candidate node, and whether the current topology table status is "online" and whether its replication thread is in a normal state;

[0089] Step 3: Once the conditions of the above steps are met, the normal switching process begins, and the node being switched is promoted to the new master node, as described in steps 3 to 6 above.

[0090] To provide greater convenience and operability, this embodiment proposes a high-availability MySQL database system that supports online one-click switchover. Switchover is typically a manual, planned exchange of master and slave roles, usually lossless (i.e., no data loss). In this embodiment, when the MySQL database master node and MySQL database slave node automatically switch over, the following conditions must be met to enter the normal switchover process:

[0091] (1) All MySQL database nodes are online.

[0092] (2) The node replication status is normal.

[0093] (3) The node being switched is a candidate node.

[0094] The specific switchover triggering process is as follows:

[0095] Step 1: Set the current MySQL database master node 'a' as a read-only node and set its status to read_only = 1;

[0096] Step 2: Use a preset mechanism to determine if the information registered in the current MySQL database master node 'a' and the preset MySQL database master node 'b' are consistent. The preset MySQL database master node 'b' is any node other than the current MySQL database master node 'a'. If the registration information is inconsistent, wait for it to complete registration until they match. Once the registration is consistent, clear the information of the current MySQL database master node 'a' in the first Consul module.

[0097] Step 3: Stop the IO threads of all slave nodes and set all nodes to read-only state;

[0098] Step 4: Promote the preset MySQL database master node b to the current master node b, including: waiting for the MySQL database node b to be promoted to complete the application of all relay logs; updating the topology table and clearing information; enabling the semi-synchronous replication mode of the current new MySQL database master node by setting the parameter rpl_semi_sync_master_enabled = 1; and updating the existing status to the topology table.

[0099] Step 5: Configure other MySQL database slave nodes to replicate the current MySQL database master node b;

[0100] Step 6: Set the current MySQL database master node b to copy the information of the new MySQL database master node c to any node that is not the current MySQL database master node b, and set it to become the MySQL database slave node c;

[0101] Step 7: Update the current MySQL database master node b information to the ProxySQL middleware.

[0102] Among them, a failure was detected in the MySQL database master node, including:

[0103] If the SWM module detects n consecutive times that the MySQL database master node has no heartbeat, then the status of the MySQL database master node is set to offline, indicating that the MySQL database master node has failed.

[0104] S140. Perform database migration through the unit service high availability component, and automatically switch the database master node and database slave node.

[0105] In this embodiment of the invention, optionally, the specific steps for detecting node faults are as follows:

[0106] Step 1: Check the node nodes in the cluster via the Kubernetes interface to see if they are functioning correctly;

[0107] Step 2: The corresponding node fails to register services in the first Consul module;

[0108] Step 3: A Pod exists on the corresponding node; where the Pod is the smallest management unit in Kubernetes, and a Pod can encapsulate one or more containers.

[0109] In this embodiment of the invention, a unit can be the smallest managed object in a service, consisting of a container, multiple logical volume objects and directory objects, a network interface card (NIC) device and an IP (Internet Protocol) file, and a configuration file object. By separating the computation, storage, and network of resource services, different types of resources can be managed, and the basic core requirements of stateful services in daily operation and maintenance, online expansion, and online changes can be met. Furthermore, the logical volume object can be a virtual disk object formed by logical disks.

[0110] The unitHA (unitHigh Availability) component includes a Consul module and a SWMPOD (Switch Manager Pod) module; the Consul module serves as the second Consul module. Optionally, the second Consul module in the unitHA component operates in a three-node mode, consisting of a service status monitoring executor and a service status management service. The service status monitoring executor is responsible for executing monitoring actions according to the monitoring commands defined by the resource service and feeding back the monitoring results to the service status management service. The service status management service is responsible for receiving resource service status data and providing service status queries externally. Optionally, the service status monitoring executor in the second Consul module can monitor the service status of node nodes according to monitoring instructions and feed back the monitoring results to the service status management server in the second Consul module; the service status of the node node can be healthy or faulty; furthermore, the service status of the node node can be determined by the SWMPOD module in the unitHA component. The service status of the node node is fed back through the service status management server.

[0111] In this embodiment of the invention, the SWMPOD module in the unitHA component is used to detect and determine faults in node nodes, and decide whether to migrate Pod containers based on the determination results.

[0112] In this embodiment of the invention, optionally, if a node failure is detected, MySQL database migration is performed through the unitHA component, including: if the node status in the MySQL database cluster is found to be abnormal n times consecutively, and there are pod containers on the node, and the service status registered by the node in the second Consul module of the unitHA component is abnormal, then it is determined that the node has failed; where n is greater than 1; Figure 1d The diagram shows the flowchart for determining if a node has failed.

[0113] In this embodiment of the invention, optionally, the database migration via the unitHA component includes: using the unitHA component to select idle node nodes as target nodes for container migration, and setting the label of the target nodes to non-idle. The container migration can be the migration of container Pods. In this embodiment of the invention, container migration is performed through the SWMPOD module in the unitHA component; wherein, the container migration can be Pod container migration; further, Pod container migration includes both Pod migration and Pod reconstruction.

[0114] In this embodiment of the invention, the specific migration process of a container Pod is as follows:

[0115] Step 1: Select an idle spare node via the Kubernetes interface: When adding physical machine resources to the database, set the node's role to either "node" or "spare". If defined as "node", the node will be used as a resource for the MySQL database instance; if defined as "spare", it will be used as a candidate resource for Pod container migration. In this embodiment, the ratio of physical machine resources to the number of independent idle physical machines is set to 1:6, i.e., 7 physical machine resources, with 1 independent idle physical machine reserved. Using an independent spare resource as the target node for migration can improve the success rate of migration and avoid the impact of the thundering herd effect.

[0116] Step 2: Verify the resources of the found nodes. Make sure that the resources of the target node for the migration action are greater than or equal to the resources of the node to be evacuated. Ensure that the evacuation action is feasible at the resource level. If no target is found, terminate the evacuation action.

[0117] Step 3: Automatically send migration actions, as well as container rebuilding and disk remounting actions, through the cluster_manager migration interface;

[0118] Step 4: After the migration is complete, use cluster_manager to set the target node's role to the node label to ensure it enters the scheduled check task.

[0119] In this embodiment of the invention, optionally, the database adopts an enhanced semi-synchronous replication mode, including a master-slave and master-multiple-slave structure; wherein the database can be a MySQL database; furthermore, in the enhanced semi-synchronous replication mode, the MySQL database will not automatically degrade to asynchronous synchronous mode. Only when two of the three MySQL master and slave nodes fail, the master node can choose to configure whether to degrade the replication mode to asynchronous synchronous mode or to read-only mode. When degraded to asynchronous mode, the MySQL database still provides services to the business, ensuring uninterrupted business operations; if degraded to read-only mode, the MySQL database continues to provide services to the business, but write operations will fail, ensuring strong consistency of business data.

[0120] The technical solution of this invention reads the MySQL database heartbeat table at each preset time period to query the health status of the MySQL database nodes. On the one hand, when the node is healthy but the MySQL database master node fails, the CMHA component is used to perform failover of the MySQL database and automatically switch the MySQL database master node to the MySQL database slave node. On the other hand, when the node fails, the unitHA component is used to perform database migration and automatically switch the MySQL database master node to the MySQL database slave node. When a physical machine node fails, automatic MySQL database container migration is also supported, which improves the high availability and fault handling speed of container resources, reduces false failovers, reduces manual maintenance, and makes the system more available.

[0121] Example 2

[0122] Figure 2 The flowchart below shows a database management method based on a container platform provided in Embodiment 2 of the present invention. The method may further include: creating multiple ProxySQL middleware and deploying the ProxySQL middleware in a container.

[0123] Optionally, if a healthy node is detected and the database master node fails, and the database failover is performed through the CMHA component and the database master node and database slave node are automatically switched, the method further includes: if the database master node fails, the service is switched to a new database master node through the ProxySQL middleware.

[0124] If the ProxySQL middleware fails, it can be restarted via the container or switched.

[0125] like Figure 2 As shown, the method includes:

[0126] S210. Create multiple ProxySQL middleware and deploy the ProxySQL middleware in a container.

[0127] Optionally, in this embodiment, multiple ProxySQL instances are created for redundancy, typically two by default, and are automatically deployed in a container. When a MySQL database fails over, the ProxySQL middleware will automatically switch the service to the new MySQL master node.

[0128] S220. Log in to the node at preset time intervals to read the heartbeat table of the database, and query the health status of each database node based on the heartbeat table;

[0129] S230, Check the health status of the node;

[0130] S240. If a healthy node is detected and the database master node fails, the database failover is performed through the CMHA component, and the database master node and database slave node are automatically switched.

[0131] S250. If the database master node fails, the business will be switched to the new database master node through the ProxySQL middleware.

[0132] In this embodiment of the invention, the ProxySQL middleware can be a proxy layer for a MySQL database; furthermore, the ProxySQL middleware supports read-write separation, can customize user-based and statement-based rules for routing SQL statements, and has a powerful rule routing engine.

[0133] Optionally, the ProxySQL middleware can be a middleware that conforms to ProxySQL rules, which can make business access to the MySQL database transparent and prevent split-brain problems.

[0134] S250. If a node failure is detected, the database is migrated through the unitHA component, and the database master node and database slave node are automatically switched.

[0135] S260. If the database master node fails, the business will be switched to the new database master node through the ProxySQL middleware.

[0136] In this embodiment of the invention, the ProxySQL middleware can be a proxy layer for a MySQL database; furthermore, the ProxySQL middleware supports read-write separation, can customize user-based and statement-based rules for routing SQL statements, and has a powerful rule routing engine.

[0137] Optionally, the ProxySQL middleware can be a middleware that conforms to ProxySQL rules, which can make business access to the MySQL database transparent and prevent split-brain issues. Multiple ProxySQL middleware can be created; for example, two can be created and automatically deployed in a container.

[0138] S270. If the ProxySQL middleware fails, restart the ProxySQL middleware through the container or switch the ProxySQL middleware.

[0139] If the ProxySQL middleware fails, it can be restarted either through the container or by adding an F5 load balancer at the application layer to automatically switch to another ProxySQL middleware node. When a node connecting to the ProxySQL middleware fails, the application will automatically switch to another ProxySQL middleware node, and the container will also restart the failed ProxySQL middleware to repair it.

[0140] The technical solution of this invention creates multiple ProxySQL instances, reads the database heartbeat table, and queries the health status of the database nodes. On one hand, when the node is healthy but the database master node fails, the CMHA component performs database failover, and the ProxySQL middleware switches the business to the new database master node. If the ProxySQL middleware fails, it can be restarted via a container or switched. On the other hand, when a node fails, the unitHA component performs database migration and automatically switches the database master node and database slave node. This solves the problem of databases not running normally during maintenance in the prior art, isolates traffic from faulty nodes, makes business access to the MySQL database transparent, and prevents the split-brain problem.

[0141] Example 3

[0142] Figure 3 This is a schematic diagram of a container-based platform database management device provided in Embodiment 3 of the present invention. This device is configured within an automatic switching module. Figure 3 As shown, the device includes:

[0143] The query module 310 is used to log in to the node at preset time intervals to read the heartbeat table of the database and query the health status of each database node based on the heartbeat table;

[0144] Detection module 320 is used to detect the health status of node nodes;

[0145] Cluster high availability component 330 is used to perform database failover and automatically switch the database master node and database slave node if a healthy node is detected and the database master node fails.

[0146] The unit service high availability component 340 is used to perform database migration and automatically switch the database master node and database slave node if a node failure is detected.

[0147] The technical solution of this invention, by reading the database heartbeat table to query the health status of the database nodes, on the one hand, performs database failover and automatically switches the database master node and database slave node through the CMHA component when the node node is healthy and the database master node fails; on the other hand, when the node node fails, the unitHA component performs database migration and automatically switches the database master node and database slave node, thus solving the problem of database failure during maintenance in the prior art, ensuring the high availability of each component of the container platform's database, and solving the problem of single point of failure.

[0148] Optionally, in this embodiment, the CMHA component 330 is further used for:

[0149] The database topology information is stored in the first Consul module of the CMHA component;

[0150] The CMHA component uses the Switchover Manager (SWM) module to query the database topology information from the first Consul module, and automatically switches the database master node and the database slave node based on the queried topology information, as well as performs database failover.

[0151] If the SWM module detects n consecutive instances that the database master node has no heartbeat, then the status of the database master node is set to offline, indicating that the database master node has failed.

[0152] Optionally, in this example, the unitHA component 340 can also be used for:

[0153] If a node in the database cluster is found to be in an abnormal state after n consecutive checks, and the node contains a pod container, and the service registered by the node in the second Consul module of the unitHA component is in an abnormal state, then the node is determined to be faulty; where n is greater than 1.

[0154] Container drift is performed using the SWMPOD module in the unitHA component;

[0155] The service status monitoring executor in the second Consul module executes the monitoring instructions to monitor the service status of the node and feeds back the monitoring results to the service status management server in the second Consul module.

[0156] The service status of the node is fed back through the service status management server;

[0157] The unitHA component is used to select idle nodes as target nodes for container migration and to set the label of the target nodes to non-idle.

[0158] Optionally, this embodiment may also include a middleware application unit 340, which is used to create multiple ProxySQL middlewares and deploy the ProxySQL middlewares in a container;

[0159] Optionally, the middleware application module 340 includes:

[0160] The service switching unit is used to switch the service to a new database master node through the ProxySQL middleware if the database master node fails.

[0161] The middleware switching unit is used to restart the ProxySQL middleware through the container or switch the ProxySQL middleware if the ProxySQL middleware fails.

[0162] The container-based platform database management device provided in this embodiment of the invention can execute the container-based platform database management method provided in any embodiment of the invention, and has the corresponding functional modules and beneficial effects of the method execution.

[0163] Example 4

[0164] Figure 4 This invention provides a container-based platform database management system, as described in Embodiment 4 of the present invention. Figure 4 As shown, the system includes a container platform-based database management device provided in this embodiment of the invention. The device is configured at the database layer and also includes a middleware layer, a container platform, and a storage layer. The middleware layer includes ProxySQL middleware. The container platform can be a Kubernetes containerized cluster platform. The database layer includes a monitoring module; the container platform includes a storage module and a scheduling module; the database layer also includes a backup and recovery module. The container platform uses macvlan network virtualization technology. The storage layer uses distributed storage and has a multi-replica fault tolerance mechanism. The storage module uses custom resource objects to achieve persistent data storage and provides stateful services during container restarts and migrations.

[0165] This invention proposes a container-based database management system. Further, this system includes a container-based high-availability database system, wherein the database can be a MySQL container database. Furthermore, the high-availability system includes a complete system encompassing network, storage, scheduling, monitoring, backup and recovery, log storage, and analysis. In this embodiment, network virtualization technology is employed, and each container is assigned a fixed IP address. After migration or cross-machine rebuild operations, the database container's IP address remains unchanged. At the underlying storage level, distributed storage is used, separating storage and computation, and a multi-replica fault tolerance mechanism is employed to improve data reliability. Simultaneously, custom Kubernetes resource objects are used to achieve storage persistence, enabling stateful services for the MySQL database and ensuring no data loss during restarts or migrations.

[0166] like Figure 4 As shown, the load balancing component can distribute the work across multiple operation units for execution, such as web servers, FTP servers, enterprise critical application servers, and other mission-critical servers, thereby enabling them to work together to complete the task.

[0167] Among them, such as Figure 4 The storage layer shown adopts distributed storage; specifically, distributed storage is a data storage technology that uses the disk space on each machine in an enterprise through a network and combines these dispersed storage resources into a virtual storage device, with data stored in various parts of the enterprise; in this embodiment, distributed storage improves the system's reliability, availability, access efficiency, and ease of expansion.

[0168] It should be understood that the various forms of processes shown above can be used, with steps reordered, added, or deleted. For example, the steps described in this invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this invention can be achieved, and this is not limited herein.

[0169] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

Claims

1. A database management method of a container-based platform, characterized by, The method is applied to automatic model switching, and the method includes: Log in to the node at preset time intervals to read the heartbeat table of the database, and query the health status of each database node based on the heartbeat table; Check the health status of the node; If a node is detected to be healthy, but the database master node fails, the cluster high availability component will be used to perform database failover and automatically switch the database master node and database slave node. If a node failure is detected, the database will be migrated through the unit service high availability component, and the database master node and database slave node will be automatically switched. The method of using cluster high-availability components for database failover and automatic switching between the database master node and database slave node includes: The database topology information is stored in the first Consul module of the cluster high availability component; The Switchover Manager (SWM) module in the high availability component of the cluster queries the database topology information from the first Consul module, and automatically switches the database master node and the database slave node based on the queried topology information, as well as performs database failover.

2. The method of claim 1, wherein, A database master node failure was detected, including: If the SWM module detects n consecutive instances that the database master node has no heartbeat, then the status of the database master node is set to offline, indicating that the database master node has failed.

3. The method of claim 1, wherein, If a node failure is detected, database migration is performed through the unit service high availability component, including: If the status of a node in the database cluster is found to be abnormal for n consecutive checks, and there is a pod container on the node, and the service registered by the node in the second Consul module of the unit service high availability component is abnormal, then the node is determined to have failed; where n is greater than 1. Container migration is performed using the SWMPOD module in the Unit Service High Availability Component.

4. The method according to claim 3, characterized in that, Also includes: The service status monitoring executor in the second Consul module executes the monitoring instructions to monitor the service status of the node and feeds back the monitoring results to the service status management server in the second Consul module. The service status of the node is fed back through the service status management server.

5. The method of claim 1, wherein, The database migration via the unit service high availability component includes: The unit service high availability component uses idle node nodes as target nodes for container migration and sets the label of the target node to non-idle.

6. The method of claim 1, wherein, Also includes: Create multiple ProxySQL middleware and deploy them in a container; If the database master node fails, the business will be switched to the new database master node through the ProxySQL middleware.

7. The method of claim 6, wherein, Also includes: If the ProxySQL middleware fails, it can be restarted via the container or switched.

8. A database management apparatus of a container-based platform, characterized by, The device is configured in the automatic switching module, and the device includes: The query module is used to log in to the node at preset time intervals to read the heartbeat table of the database and query the health status of each database node based on the heartbeat table. The detection module is used to detect the health status of node nodes; The cluster high availability component is used to perform database failover and automatically switch the database master node and database slave node if a healthy node is detected and the database master node fails. The unit service high availability component is used to perform database migration and automatically switch the database master node and database slave node if a node failure is detected. The cluster high availability component is also used for: The database topology information is stored in the first Consul module of the cluster high availability component; The Switchover Manager (SWM) module in the high availability component of the cluster queries the database topology information from the first Consul module, and automatically switches the database master node and the database slave node based on the queried topology information, as well as performs database failover.

9. A database management system for a container-based platform, characterized by, Including the apparatus as described in claim 8, the apparatus is configured in the database layer, and further includes a middleware layer, a container platform, and a storage layer, wherein the middleware layer includes ProxySQL middleware; The database layer also includes a monitoring module; the container platform includes a storage module and a scheduling module; the database layer also includes a backup and recovery module. The container platform employs macvlan network virtualization technology. The storage layer adopts distributed storage and has a multi-replica fault tolerance mechanism; The storage module uses custom resource objects to achieve persistent data storage and provides stateful services during container restarts and container migrations.

Images