Distributed database node online upgrading system and method

Abstract

The invention discloses a distributed database node online upgrading system and method, and relates to the technical field of distributed databases, the system comprises a distributed database cluster comprising a plurality of database nodes, and each node is responsible for operating database basic service, connecting the cluster to which the node belongs, and obtaining node state information in the cluster; the cluster management module is responsible for monitoring node states in a cluster, receiving an upgrading command and triggering a corresponding process; the distributed consistency management module is responsible for generating a state view and implementing a change operation; the database execution module is responsible for executing statements; the database storage engine is responsible for regularly reporting a copy state; the node upgrading strategy module is responsible for judging whether the node supports online upgrading or not, informing to disable DDL statements and determining the migration direction of a lease holder and a data copy; and the version verification and rollback module is responsible for storage format compatibility verification, sending a rollback notification and notifying recovery of a node health state. According to the invention, the node can be simply and efficiently upgraded.

Description

Technical Field

[0001] The present invention relates to the technical field of distributed databases, and in particular to a distributed database node online upgrade system and method. Background Art

[0002] Modern database applications are characterized by multiple load types, fast update iterations, and often require query analysis based on large amounts of data. When users need to perform uninterrupted data operations through a distributed node and need to update the database engine version on the node before a deadline specified by certain businesses, it will cause great trouble for database administrators, who will find it difficult to decide whether to terminate data operations and upgrade first, or to postpone the version upgrade. This requires database developers to provide online upgrade solutions.

[0003] Some data operations that cannot be shut down are the main reason why node upgrades cannot be carried out normally. However, various application scenarios have increasingly higher requirements for database reliability and continuity. Service interruptions may cause certain losses to users, so the database is required to remain in normal operation. In addition, there may be certain risks in the upgrade process of the database engine. If the online upgrade method is used, even if an unexpected situation occurs or the upgrade fails, the system can continue to run on the original version without causing serious impact.

[0004] At present, the commonly used solutions on the market are usually to back up the data of the current node first, then manually stop the write operation to the node, install the new version of the database engine, configure the various parameters of the new version of the engine, and then restore the write service of the node; this method is relatively simple, but has many requirements and restrictions on users. For example, it does not support write operations and requires users to manually perform many configurations. In addition, data backup incurs additional time and space overhead, especially for node replicas with large data volumes. The cost of implementing data backup and the upgrade delay are high. Some more complex solutions on the market use a data copy migration, then synchronize the copy after the upgrade, and support the execution of DDL statements during the upgrade by recording the execution log of the data definition language and transaction management records. In this method, most of the data is not migrated back, but a new copy is created after the upgrade and the copies of other nodes are synchronized, and then the local copy is deleted. This method can only alleviate the delay when the upgrade starts, and still consumes additional space. In addition, if the copy is not migrated back, it may lead to uneven resource utilization. If the copy load on some nodes is high and the copy load on other nodes is low, it may cause resource waste and poor performance. In addition, if the database system spans multiple data centers or geographical locations, and the copy is not migrated back, resulting in some copies being migrated to a remote data center, it may increase the network cost and latency between data centers, thereby affecting the performance and availability of the system. In addition, although the solution that still supports DDL statements during the upgrade using the data copy migration solution is more user-friendly, considering its more complex implementation solution and the various types of log information generated, as well as the probability that users actually execute DDL statements during the node upgrade, its cost-effectiveness is still questionable.

[0005] Therefore, it is necessary to establish a node online upgrade solution that can not interrupt services, does not require too much time and space consumption, and does not seriously affect the replica distribution and cause potential performance risks, so as to provide users with a more friendly database engine upgrade method. Summary of the invention

[0006] In view of the needs and shortcomings of current technological development, the present invention provides a distributed database node online upgrade system and method, which utilizes the migration and re-migration of node lease holders and replicas, and helps users realize online upgrades of cluster nodes based on the status of cluster nodes in combination with simple upgrade and exit upgrade commands.

[0007] In a first aspect, the present invention provides a distributed database node online upgrade system, and the technical solution adopted to solve the above technical problems is as follows:

[0008] A distributed database node online upgrade system, comprising:

[0009] A distributed database cluster consists of multiple database nodes. The database nodes in the same cluster use different versions of database storage engines that are compatible with each other.

[0010] Database nodes are responsible for running various basic database services, connecting to the cluster to which the node where the application is located, and obtaining the status information of each node in the cluster and its associated data objects;

[0011] The cluster management module is responsible for monitoring the status, load, and monitoring indicators of each node in the cluster. After receiving the upgrade command, it switches the nodes that support the upgrade to the upgrade state and triggers the corresponding migration and execution process.

[0012] Distributed consistency management module, which is responsible for generating a state view describing the distribution of each node, replica, and data in the cluster, and is responsible for uniformly implementing changes to node lease holders and hot data replicas;

[0013] The database execution module is responsible for the execution of data definition statements and data operation statements;

[0014] The database storage engine is responsible for receiving and storing data objects of application loads, collecting storage statistics and operation data, and regularly reporting the replica status to the distributed consistency management module, including the number, location, and data integrity of replicas;

[0015] The node upgrade strategy module is responsible for determining whether the current node supports online upgrades based on preset rules, notifying the cluster to which the current node to be upgraded belongs to temporarily disable DDL statements, upgrading the current node in a rolling manner, and determining the migration destination of lease holders and data replicas;

[0016] The version verification and rollback module is responsible for verifying the compatibility of the database storage engine after the upgrade, deciding whether to trigger a rollback, and notifying the cluster management module through the node upgrade strategy module to restore the node status to healthy after the node upgrade is successful.

[0017] Optionally, the database nodes involved are responsible for running various basic database services, including cluster node management, distributed consistency management, node upgrade strategy, database execution management, lease holder and replica migration execution involved in the node upgrade function.

[0018] Optionally, the node upgrade strategy module determines whether the current node supports online upgrade according to preset rules. The preset rules specifically include:

[0019] a) Whether the current node status is healthy;

[0020] b) Whether the number of healthy nodes in the distributed cluster to which the current node belongs can support high availability;

[0021] c) Whether there is no node being upgraded in the distributed cluster to which the current node belongs.

[0022] Further optionally, the node upgrade strategy module involved first determines whether the current node supports online upgrade according to preset rules. If the current node satisfies the three rules a), b), and c), it is determined that the current node supports online upgrade. If the current node does not satisfy any of the rules a), b), and c), it is determined that the current node does not support online upgrade.

[0023] The node upgrade strategy module then performs the following operations based on the determination result: if it is determined that the current node supports online upgrade, the cluster management module is notified to change the current node status to upgrade; if it is determined that the current node does not support online upgrade, an error message and reason are returned to the user;

[0024] The node upgrade strategy module then notifies the cluster to which the node to be upgraded online belongs to temporarily disable DDL statements and start upgrading the current node in a rolling manner;

[0025] Finally, the node upgrade strategy module takes each data partition of the current node as a unit. For the partition whose lease holder is the current upgraded node, it configures three data copies for each partition, one of which is on the current node and two are on two healthy nodes in the cluster to which the current node belongs. The data copy on the current node is removed, and the node with the smaller load among the two healthy nodes is found as the new lease holder of the partition through the rebalancing algorithm. The distributed consistency management module is notified to implement the change of the lease holder.

[0026] Optionally, the version verification and rollback module is responsible for verifying the compatibility of the upgraded database storage engine, deciding whether to trigger a rollback, and notifying the cluster management module to restore the node status to healthy through the node upgrade strategy module after the node upgrade is successful. Specifically, it includes:

[0027] Through predefined verification operations, verify whether the new version of the database storage engine can read and write data compatible with the data copy in the original data storage engine;

[0028] If the verification fails, the lease holder and replica migration is triggered, and a rollback notification is sent back to the user, informing him that the database storage engine version needs to be changed. The user updates the database storage engine execution file and tries to exit the upgrade again. At this time, the distributed consistency management module normally migrates the lease holder and data replica back to the state before the upgrade.

[0029] After the node is upgraded successfully, the upgrade success notification is sent to the node upgrade strategy module. After the node upgrade strategy module receives the upgrade success notification from the version verification and rollback module, it migrates the lease holder and data replica back to the state before the upgrade through the distributed consistency management module. After the migration is completed, the node upgrade strategy module notifies the cluster management module to restore the node status to healthy, and notifies the database execution module to restart support for DDL statements.

[0030] In a second aspect, the present invention provides a distributed database node online upgrade method, and the technical solution adopted to solve the above technical problems is as follows:

[0031] Based on the upgrade system described in the first aspect, a distributed database node online upgrade method includes the following steps:

[0032] S1. Start the upgrade: The user issues an upgrade command to node A in the distributed database cluster. After receiving the upgrade command, the cluster management module marks node A as upgraded and starts monitoring the status and load of node A. At the same time, the node upgrade strategy module determines whether node A supports online upgrade. If so, the cluster to which node A belongs is notified to temporarily disable the execution of DDL statements and start upgrading node A in a rolling manner.

[0033] S2, data replica and lease holder configuration: For node A, the node upgrade strategy module configures the number of copies of the data partition to be 3, of which 1 data copy is retained on node A, and 2 data copies are migrated to two healthy nodes B and C in the cluster to which node A belongs; then, the data copy on node A is removed, and a node with a smaller load is selected from the healthy nodes B and C as the new lease holder through the rebalancing algorithm, and the distributed consistency management module is notified to implement the change of the lease holder;

[0034] S3, Distributed consistency management: The distributed consistency management module is responsible for the lease holders and data replicas during the change period, and is also responsible for generating a state view of the cluster to which node A belongs, including the distribution of each node, replica, and data;

[0035] S4, version verification and rollback: Before upgrading, the version verification and rollback module verifies the compatibility of the new version of the database storage engine with the data copy in the original data storage engine, and triggers the migration of the lease holder and the data copy when the verification fails, notifying the user that a version rollback is required;

[0036] S5. Execute the upgrade: After the preparation is completed, the database storage engine update begins, and Node A will be gradually replaced with the new version of the storage engine. During the entire upgrade process, the database execution module is responsible for pausing and resuming the execution of DDL statements.

[0037] S6. Upgrade success and recovery: After the upgrade is successful, the version verification and rollback module will send a success notification to the node upgrade strategy module. The node upgrade strategy module will restore the lease holder and data replica to the state before the upgrade through the distributed consistency management module, and restart the support for DDL statements through the database execution module. The entire cluster will resume normal operation.

[0038] Optionally, the distributed database cluster involved includes multiple database nodes, and the database nodes under the same cluster use different versions of compatible database storage engines. The database node is responsible for running various basic database services, and is also responsible for connecting to the cluster to which the node where the application is located belongs, and obtaining the status information of each node in the cluster and its associated data objects.

[0039] Further optionally, the database nodes involved are responsible for running various basic database services, including cluster node management, distributed consistency management, node upgrade strategy, database execution management, lease holder and replica migration execution involved in the node upgrade function.

[0040] Optionally, step S1 is performed, and the node upgrade strategy module determines whether node A supports online upgrade according to preset rules, and the preset rules specifically include:

[0041] a) Whether the status of node A is healthy;

[0042] b) Whether the number of healthy nodes in the distributed cluster to which node A belongs can support high availability;

[0043] c) Whether there is no node being upgraded in the distributed cluster to which node A belongs;

[0044] If node A meets the three rules a), b), and c), the node upgrade strategy module determines that node A supports online upgrade.

[0045] If node A does not satisfy any of the rules a), b), and c), the node upgrade strategy module determines that node A does not support online upgrade.

[0046] Optionally, execute step S4, the version verification and rollback module verifies the compatibility of the new version of the database storage engine with the data copy in the original data storage engine through a predefined verification operation. If the verification fails, it triggers the migration of the lease holder and the copy, and sends a rollback notification to the user, informing him that the version of the database storage engine needs to be changed. The user updates the database storage engine execution file and tries to exit the upgrade again.

[0047] Compared with the prior art, the distributed database node online upgrade system and method of the present invention has the following beneficial effects:

[0048] 1. The present invention utilizes the migration and relocation of node lease holders and replicas, and according to the status of each node in the cluster, combined with simple upgrade and exit upgrade commands, helps users to achieve online upgrades of each node in the cluster, while ensuring the continuous availability of distributed database data operations, reducing upgrade waiting delays and additional space resource consumption caused by general replica replication methods, making the upgrade process simpler and more efficient; in addition, replica migration is usually more stable and reliable than replica replication, and can effectively avoid data replication delays, data inconsistency and other problems; the relocation of node lease holders and replicas further ensures uniform distribution of cluster workloads, which helps to optimize the performance, availability and resource utilization of distributed systems;

[0049] 2. The present invention supports users to roll over and upgrade any node in the cluster, and introduces an automatic detection mechanism for cluster node status before upgrading. When the cluster node status is abnormal, the database system will automatically prompt the user why the node cannot be upgraded, ensuring that at least one node in the cluster remains online and available, which can minimize the impact on the business;

[0050] 3. The present invention supports users to use concise upgrade commands to specify the node number that needs to be upgraded to put the node into the upgrade state. By simply replacing the required new / old version of the database execution file, and then restarting the node during any idle period of the node, the online upgrade of any node in the cluster can be achieved. The advantages are simple operation, user-friendliness, and no impact on the data operation of each node in the cluster. In addition, since the upgrade mode uses the node lease owner and replica migration instead of the common replica replication, the delay for the database node to enter and exit the upgrade mode is greatly shortened, thereby optimizing system performance and resource utilization. BRIEF DESCRIPTION OF THE DRAWINGS

[0051] Attached Figure 1 It is a module connection block diagram of the first embodiment of the present invention. DETAILED DESCRIPTION

[0052] In order to make the technical solution, the technical problem solved and the technical effect of the present invention more clearly understood, the technical solution of the present invention is clearly and completely described below in conjunction with specific embodiments.

[0053] Embodiment 1:

[0054] Combined with Figure 1 This embodiment proposes a distributed database node online upgrade system, which includes:

[0055] A distributed database cluster consists of multiple database nodes. The database nodes in the same cluster use different versions of database storage engines that are compatible with each other.

[0056] Database nodes are responsible for running various basic database services, including cluster node management, distributed consistency management, node upgrade strategy, database execution management, lease holder and replica migration execution involved in node upgrade functions. They are also responsible for connecting to the cluster to which the node where the application is located belongs, and obtaining the status information of each node in the cluster and its associated data objects;

[0057] The cluster management module is responsible for monitoring the status, load, and monitoring indicators of each node in the cluster. After receiving the upgrade command, it switches the nodes that support the upgrade to the upgrade state and triggers the corresponding migration and execution process.

[0058] Distributed consistency management module, which is responsible for generating a state view describing the distribution of each node, replica, and data in the cluster, and is responsible for uniformly implementing changes to node lease holders and hot data replicas;

[0059] The database execution module is responsible for the execution of data definition statements and data operation statements;

[0060] The database storage engine is responsible for receiving and storing data objects of application loads, collecting storage statistics and operation data, and regularly reporting the replica status to the distributed consistency management module, including the number, location, and data integrity of replicas;

[0061] The node upgrade strategy module is responsible for determining whether the current node supports online upgrades based on preset rules, notifying the cluster to which the current node to be upgraded belongs to temporarily disable DDL statements, upgrading the current node in a rolling manner, and determining the migration destination of lease holders and data replicas;

[0062] The version verification and rollback module is responsible for verifying the compatibility of the database storage engine after the upgrade, deciding whether to trigger a rollback, and notifying the cluster management module through the node upgrade strategy module to restore the node status to healthy after the node upgrade is successful.

[0063] In this embodiment, the node upgrade strategy module determines whether the current node supports online upgrade according to preset rules. The preset rules specifically include:

[0064] a) Whether the current node status is healthy;

[0065] b) Whether the number of healthy nodes in the distributed cluster to which the current node belongs can support high availability;

[0066] c) Whether there is no node being upgraded in the distributed cluster to which the current node belongs.

[0067] The node upgrade strategy module determines whether the current node supports online upgrades based on preset rules, notifies the cluster to which the current node to be upgraded belongs to temporarily disable DDL statements, and determines the migration destination of the lease holder and data replicas. The specific operations include the following:

[0068] First, determine whether the current node supports online upgrade according to the preset rules. If the current node meets the three rules a), b), and c), it is determined that the current node supports online upgrade. If the current node does not meet any of the rules a), b), and c), it is determined that the current node does not support online upgrade.

[0069] Then, the following operations are performed based on the determination result: if it is determined that the current node supports online upgrade, the cluster management module is notified to change the current node status to upgrade; if it is determined that the current node does not support online upgrade, an error message and the reason are returned to the user;

[0070] Then, notify the cluster to which the node to be upgraded online belongs to temporarily disable DDL statements and start upgrading the current node in a rolling manner;

[0071] Finally, taking each data partition of the current node as a unit, for the partition whose lease holder is the current upgraded node, configure three data copies of each partition, one of which is on the current node and two are on two healthy nodes in the cluster to which the current node belongs. Remove the data copy on the current node, and use the rebalancing algorithm to find the node with the smaller load among the two healthy nodes as the new lease holder for the partition, and notify the distributed consistency management module to implement the change of the lease holder.

[0072] In this embodiment, the version verification and rollback module is responsible for verifying the compatibility of the upgraded database storage engine, deciding whether to trigger a rollback, and notifying the cluster management module to restore the node status to healthy through the node upgrade strategy module after the node upgrade is successful, specifically including:

[0073] Through predefined verification operations, verify whether the new version of the database storage engine can read and write data compatible with the data copy in the original data storage engine;

[0074] If the verification fails, the lease holder and replica migration is triggered, and a rollback notification is sent back to the user, informing him that the database storage engine version needs to be changed. The user updates the database storage engine execution file and tries to exit the upgrade again. At this time, the distributed consistency management module normally migrates the lease holder and data replica back to the state before the upgrade.

[0075] After the node is upgraded successfully, the upgrade success notification is sent to the node upgrade strategy module. After the node upgrade strategy module receives the upgrade success notification from the version verification and rollback module, it migrates the lease holder and data replica back to the state before the upgrade through the distributed consistency management module. After the migration is completed, the node upgrade strategy module notifies the cluster management module to restore the node status to healthy, and notifies the database execution module to restart support for DDL statements.

[0076] Embodiment 2:

[0077] Combined with Figure 1 Based on the upgrade system described in the first embodiment, this embodiment further proposes a distributed database node online upgrade method, including the following steps:

[0078] S1. Start the upgrade: The user issues an upgrade command to node A in the distributed database cluster. After receiving the upgrade command, the cluster management module marks node A as upgraded and starts monitoring the status and load of node A. At the same time, the node upgrade strategy module determines whether node A supports online upgrade. If so, the cluster to which node A belongs is notified to temporarily disable the execution of DDL statements and start upgrading node A in a rolling manner.

[0079] The distributed database cluster described in this step includes multiple database nodes. The database nodes under the same cluster use different versions of compatible database storage engines. The database nodes are responsible for running various basic database services, including cluster node management, distributed consistency management, node upgrade strategy, database execution management, lease holder and replica migration execution involved in the node upgrade function. They are also responsible for connecting to the cluster to which the node where the application is located belongs, and obtaining the status information of each node in the cluster and its associated data objects.

[0080] When executing step S1, the node upgrade strategy module determines whether node A supports online upgrade according to preset rules. The preset rules specifically include:

[0081] a) Whether the status of node A is healthy;

[0082] b) Whether the number of healthy nodes in the distributed cluster to which node A belongs can support high availability;

[0083] c) Whether there is no node being upgraded in the distributed cluster to which node A belongs;

[0084] If node A meets the three rules a), b), and c), the node upgrade strategy module determines that node A supports online upgrade.

[0085] If node A does not satisfy any of the rules a), b), and c), the node upgrade strategy module determines that node A does not support online upgrade.

[0086] S2. Data replica and lease holder configuration: For node A, the node upgrade strategy module configures the number of copies of the data partition to be 3, of which 1 data copy is retained on node A, and 2 data copies are migrated to two healthy nodes B and C in the cluster to which node A belongs; then, the data copy on node A is removed, and a node with a smaller load is selected from the healthy nodes B and C through the rebalancing algorithm as the new lease holder, and the distributed consistency management module is notified to implement the change of the lease holder.

[0087] S3. Distributed consistency management: The distributed consistency management module is responsible for the lease holders and data copies during the change period, and is also responsible for generating a status view of the cluster to which node A belongs, including the distribution of each node, copy, and data.

[0088] S4. Version verification and rollback: Before upgrading, the version verification and rollback module verifies the compatibility of the new version of the database storage engine with the data copy in the original data storage engine through predefined verification operations. If the verification fails, it triggers the migration of the lease holder and the copy, and sends a rollback notification to the user to inform him that the version of the database storage engine needs to be changed. The user updates the database storage engine execution file and tries to exit the upgrade again.

[0089] S5. Execute the upgrade: After the preparation work is completed, the database storage engine update begins, and node A will be gradually replaced with the new version of the storage engine. During the entire upgrade process, the database execution module is responsible for pausing and resuming the execution of DDL statements.

[0090] S6. Upgrade success and recovery: After the upgrade is successful, the version verification and rollback module will send a success notification to the node upgrade strategy module. The node upgrade strategy module will restore the lease holder and data replica to the state before the upgrade through the distributed consistency management module, and restart the support for DDL statements through the database execution module. The entire cluster will resume normal operation.

[0091] It should be added that the upgrade method described in this embodiment supports users to specify nodes for online upgrades through concise commands. After receiving the upgrade command, the cluster management module of the distributed database marks the node specified in the upgrade command as an upgrade state and starts to monitor the node's state and load. At the same time, the node upgrade strategy module determines whether the node supports online upgrades. If it does, it notifies the cluster to which the node belongs to temporarily disable the execution of DDL statements and starts to upgrade node A in a rolling manner. After the data user executes the upgrade command, the database storage engine execution file can be replaced with the target version. At this time, the application being executed on the cluster will not be affected. For applications with a long execution time, users no longer need to weigh whether to interrupt the service for upgrading the engine. They can freely complete the database storage engine upgrade uniformly at any time according to business needs, and then restart the service when the node is idle to use the new version of the database storage engine.

[0092] The upgrade mode supported by the present invention is rolling upgrade. By upgrading nodes one by one, the upgrade risk is effectively reduced and the rollback process is simplified. Even if the upgrade is abnormal, the user can continue to use the old version of the engine to execute the file and execute the exit upgrade command to quickly implement automatic rollback. The rollback process is also simple and intuitive and does not generate a large amount of additional space overhead, which enhances the security and efficiency of database node upgrades. After exiting the upgrade mode, the executor restarts support for DDL statements and migrates back the lease holders and data copies of the affected data partitions. The advantage of this approach is that it can restore the cluster workload. When the node is restored to health, it ensures that the cluster has a more uniform load distribution, and can better utilize existing hardware resources and network bandwidth, which is conducive to improving the response speed and throughput of the database.

[0093] In summary, a distributed database node online upgrade system and method of the present invention utilizes the migration and relocation of node lease holders and replicas, and according to the status of each node in the cluster, combined with simple upgrade and exit upgrade commands, helps users to realize online upgrades of each node in the cluster, while ensuring the continuous availability of distributed database data operations, reducing upgrade waiting delays and additional space resource consumption caused by general replica replication methods, making the upgrade process simpler and more efficient; in addition, replica migration is usually more stable and reliable than replica replication, and can effectively avoid data replication delays, data inconsistencies and other problems; the relocation of node lease holders and replicas further ensures the uniform distribution of cluster workloads, which helps to optimize the performance, availability and resource utilization of distributed systems.

[0094] The above specific examples are used to explain the principles and implementation methods of the present invention in detail. These examples are only used to help understand the core technical content of the present invention. Based on the above specific embodiments of the present invention, any improvements and modifications made by technicians in this technical field without departing from the principles of the present invention should fall within the scope of patent protection of the present invention.

Claims

1. A distributed database node online upgrade system, characterized in that: It includes: A distributed database cluster consists of multiple database nodes. The database nodes in the same cluster use different versions of database storage engines that are compatible with each other. Database nodes are responsible for running various basic database services, connecting to the cluster to which the node where the application is located, and obtaining the status information of each node in the cluster and its associated data objects; The cluster management module is responsible for monitoring the status, load, and monitoring indicators of each node in the cluster. After receiving the upgrade command, it switches the nodes that support the upgrade to the upgrade state and triggers the corresponding migration and execution process. Distributed consistency management module, responsible for generating a state view describing the distribution of each node, replica, and data in the cluster, and responsible for uniformly implementing changes to node lease holders and hot data replicas; The database execution module is responsible for the execution of data definition statements and data operation statements; The database storage engine is responsible for receiving and storing data objects of application loads, collecting storage statistics and operation data, and regularly reporting the replica status to the distributed consistency management module, including the number, location, and data integrity of replicas; The node upgrade strategy module is responsible for determining whether the current node supports online upgrades based on preset rules, notifying the cluster to which the current node to be upgraded online belongs to temporarily disable DDL statements, upgrading the current node in a rolling manner, and determining the migration destination of lease holders and data replicas; The version verification and rollback module is responsible for verifying the compatibility of the database storage engine after the upgrade, deciding whether to trigger a rollback, and notifying the cluster management module through the node upgrade strategy module to restore the node status to healthy after the node upgrade is successful.

2. A distributed database node online upgrade system according to claim 1, characterized in that: The database node is responsible for running various basic database services, including cluster node management, distributed consistency management, node upgrade strategy, database execution management, lease holder and replica migration execution involved in the node upgrade function.

3. A distributed database node online upgrade system according to claim 1, characterized in that: The preset rules include: a) Whether the current node status is healthy; b) Whether the number of healthy nodes in the distributed cluster to which the current node belongs can support high availability; c) Whether there is no node being upgraded in the distributed cluster to which the current node belongs.

4. A distributed database node online upgrade system according to claim 3, characterized in that: The node upgrade strategy module first determines whether the current node supports online upgrade according to preset rules. If the current node meets the three rules a), b), and c), it is determined that the current node supports online upgrade. If the current node does not meet any of the rules a), b), and c), it is determined that the current node does not support online upgrade. The node upgrade strategy module then performs the following operations based on the determination result: if it is determined that the current node supports online upgrade, the cluster management module is notified to change the current node status to upgrade; if it is determined that the current node does not support online upgrade, an error message and the reason are returned to the user; The node upgrade strategy module then notifies the cluster to which the node to be upgraded online belongs to temporarily disable DDL statements and start upgrading the current node in a rolling manner; The node upgrade strategy module finally takes each data partition of the current node as a unit. For the partition whose lease holder is the current upgraded node, it configures three data copies of each partition, one of which is on the current node and two are on two healthy nodes in the cluster to which the current node belongs. The data copy on the current node is removed, and the node with less load among the two healthy nodes is found through the rebalancing algorithm as the new lease holder of the partition, and the distributed consistency management module is notified to implement the change of the lease holder.

5. A distributed database node online upgrade system according to claim 4, characterized in that: The version verification and rollback module is responsible for verifying the compatibility of the upgraded database storage engine, deciding whether to trigger a rollback, and notifying the cluster management module to restore the node status to healthy through the node upgrade strategy module after the node upgrade is successful. Specifically, it includes: Through predefined verification operations, verify whether the new version of the database storage engine can read and write data compatible with the data copy in the original data storage engine; If the verification fails, the lease holder and replica migration is triggered, and a rollback notification is sent back to the user, informing him that the database storage engine version needs to be changed. The user updates the database storage engine execution file and tries to exit the upgrade again. At this time, the distributed consistency management module normally migrates the lease holder and data replica back to the state before the upgrade. After the node is upgraded successfully, an upgrade success notification is sent to the node upgrade strategy module. After the node upgrade strategy module receives the upgrade success notification from the version verification and rollback module, it migrates the lease holder and data replica back to the state before the upgrade through the distributed consistency management module. After the migration is completed, the node upgrade strategy module notifies the cluster management module to restore the node status to healthy, and notifies the database execution module to restart support for DDL statements.

6. A distributed database node online upgrade method, characterized in that: It is based on the online upgrade system as claimed in claim 1, comprising the following steps: S1. Start the upgrade: The user issues an upgrade command to node A in the distributed database cluster. After receiving the upgrade command, the cluster management module marks node A as upgraded and starts monitoring the status and load of node A. At the same time, the node upgrade strategy module determines whether node A supports online upgrade. If so, the cluster to which node A belongs is notified to temporarily disable the execution of DDL statements and start upgrading node A in a rolling manner. S2, data replica and lease holder configuration: For node A, the node upgrade strategy module configures the number of copies of the data partition to be 3, of which 1 data copy is retained on node A, and 2 data copies are migrated to two healthy nodes B and C in the cluster to which node A belongs; then, the data copy on node A is removed, and a node with a smaller load is selected from the healthy nodes B and C as the new lease holder through the rebalancing algorithm, and the distributed consistency management module is notified to implement the change of the lease holder; S3, Distributed consistency management: The distributed consistency management module is responsible for the lease holders and data replicas during the change period, and is also responsible for generating a state view of the cluster to which node A belongs, including the distribution of each node, replica, and data; S4, version verification and rollback: Before upgrading, the version verification and rollback module verifies the compatibility of the new version of the database storage engine with the data copy in the original data storage engine, and triggers the migration of the lease holder and the data copy when the verification fails, notifying the user that a version rollback is required; S5. Execute the upgrade: After the preparation is completed, the database storage engine update begins, and Node A will be gradually replaced with the new version of the storage engine. During the entire upgrade process, the database execution module is responsible for pausing and resuming the execution of DDL statements. S6. Upgrade success and recovery: After the upgrade is successful, the version verification and rollback module will send a success notification to the node upgrade strategy module. The node upgrade strategy module will restore the lease holder and data replica to the state before the upgrade through the distributed consistency management module, and restart the support for DDL statements through the database execution module. The entire cluster will resume normal operation.

7. A distributed database node online upgrade method according to claim 6, characterized in that: The distributed database cluster includes multiple database nodes. The database nodes under the same cluster use different versions of compatible database storage engines. The database nodes are responsible for running various basic database services, connecting to the cluster to which the node where the application is located, and obtaining the status information of each node in the cluster and its associated data objects.

8. A distributed database node online upgrade method according to claim 7, characterized in that: The database node is responsible for running various basic database services, including cluster node management, distributed consistency management, node upgrade strategy, database execution management, lease holder and replica migration execution involved in the node upgrade function.

9. A distributed database node online upgrade method according to claim 6, characterized in that: Execute step S1, the node upgrade strategy module determines whether node A supports online upgrade according to preset rules, and the preset rules specifically include: a) Whether the status of node A is healthy; b) Whether the number of healthy nodes in the distributed cluster to which node A belongs can support high availability; c) Whether there is no node being upgraded in the distributed cluster to which node A belongs; If node A satisfies the three rules a), b), and c), the node upgrade strategy module determines that node A supports online upgrade. If node A does not satisfy any of the rules a), b), and c), the node upgrade strategy module determines that node A does not support online upgrade.

10. A distributed database node online upgrade method according to claim 6, characterized in that: Execute step S4. The version verification and rollback module verifies the compatibility of the new version of the database storage engine with the data copy in the original data storage engine through predefined verification operations. If the verification fails, it triggers the migration of the lease holder and the copy, and sends a rollback notification to the user to inform him that the version of the database storage engine needs to be changed. The user updates the database storage engine execution file and tries to exit the upgrade again.

Images