Distributed multi-mode database online upgrading method

Abstract

The invention discloses an online upgrading method for a distributed multi-mode database, and belongs to the technical field of distributed multi-mode databases. When database version upgrading is carried out in a distributed database cluster, for an upgraded node, a copy lease held by the node is preferentially migrated to other nodes, it is guaranteed that reading and writing are available without interruption in the upgrading period, and the upgrading efficiency is improved. Meanwhile, the copy is forbidden to migrate, and copy migration is recovered until upgrading is completed. For version upgrading and binary system replacement between different versions of the distributed multi-mode database, read-write support can still be provided for the outside during upgrading, online availability of data is guaranteed, and copy migration is avoided during upgrading.

Description

Technical Field

[0001] The present invention relates to the technical field of distributed multi-mode databases, and in particular to a method for online upgrading of distributed multi-mode databases. Background Art

[0002] A distributed database is a multi-node database cluster deployed on multiple servers. Compared with a single-machine database, a distributed database can use multiple independent computers to solve storage and computing problems that a single server cannot handle. When the amount of data exceeds the load limit of a server, a single-machine database can only replace a higher-performance server, while a distributed database can solve this problem by horizontal expansion and adding servers.

[0003] High availability means that when an abnormal event occurs in a database node and causes downtime, the database can still provide read and write services to the outside world without causing the database to be unavailable. In common distributed clusters, high availability is provided through a multi-copy mode. Multiple copies of user write data are saved. Generally speaking, three copies of each user's write data are saved, and each copy of the data is called a replica. These three replicas elect a leader, and the other two are called followers. The leader will hold the replica for a certain period of time (lease). During the lease period, the leader is also the leaseholder of the replica. At the same time, the user's write data will be written to the leader node, and then the leader will synchronize the data to all followers. In such a structure, all read and write operations are completed by the leader. When the leader node has a problem and goes down or is unavailable, the other two followers will elect a new leader, and then the new leader will provide subsequent read and write support.

[0004] Time series data is a collection of data recorded in chronological order. It is generally collected by various devices at certain time intervals or timestamps. Time series data has some characteristics. Time series data written is almost always new data, and the timestamp of time series data generated by the same device is almost always increasing. Time series data always performs insert operations, and update and delete operations are generally only performed in abnormal states. Compared with relational data, time series data has more quantity, and rarely executes AP (analytical processing) statements. It is more necessary to aggregate data after a period of time. The importance of historical data that has been generated for a long time is significantly reduced.

[0005] Online upgrade corresponds to offline upgrade, which means that when replacing the database version for upgrading, services can still be provided to the outside world. Some distributed database clusters can quickly switch nodes when a node goes down through multi-copy disaster recovery. The service interruption time is short, which will only affect the read and write needs for a short period of time. Based on this principle, online upgrades can also be guaranteed by in-situ upgrades. The specific approach is to kill a node service in a planned manner, ensure online functions by high availability, replace the database binary version at the same time, and finally restart and upgrade with the new binary version.

[0006] Generally, a distributed database cluster can complete the upgrade operation by killing the node and then replacing the binary. However, after killing the node, there is a time window during which the leaseholder of the dead node is re-elected. Although the time window is short, it will still be unable to provide services to the outside world during this period. In addition, if the node upgrade takes too long, it will trigger the automatic migration of the replica. Since the node dies, the cluster does not know whether the node is down abnormally or has a planned upgrade operation. At this time, the replica of the dead node has been lost from the cluster's perspective. To ensure high availability, the cluster needs to complete the data replica as soon as possible. For multi-mode databases that contain time series data, since the amount of time series data is much larger than that of relational data, the migration of replicas of time series data will place a heavy burden on the CPU, storage, and network. After the new node is added, whether it is waiting for the migration replica to complete or canceling the replica being migrated, additional performance overhead is required. Summary of the invention

[0007] The technical task of the present invention is to address the above shortcomings and provide a method for online upgrading of a distributed multi-mode database. For version upgrades and binary replacements between different versions of the distributed multi-mode database, it can still provide external read and write support during the upgrade, ensure that data is available online, and avoid copy migration during the upgrade.

[0008] The technical solution adopted by the present invention to solve its technical problem is:

[0009] A distributed multi-mode database online upgrade method. When upgrading a database version in a distributed database cluster, for an upgrade node, the replica leaseholder held by the node is preferentially migrated to other nodes to ensure that read and write are available without interruption during the upgrade. At the same time, replica migration is prohibited until the upgrade is completed and the replica migration is resumed.

[0010] During the upgrade process, this method plans to migrate the leaseholders held by the upgraded node and prevents the migration of replicas in the migration operation. By first transferring all the leaseholders held by the database node when upgrading the database version and prohibiting the migration of replicas of the node, it ensures that data reading and writing are available throughout the upgrade process and reduces unnecessary replica migration.

[0011] Furthermore, the specific implementation steps of the method include:

[0012] S1. Provide an upgrade command and prioritize the migration of leaseholders of upgraded nodes to other nodes;

[0013] S2. Add an upgrade command. After receiving the upgrade command, the node to be upgraded is upgraded and marked as upgraded. The data copies held by the node are prohibited from being migrated within the specified time.

[0014] S3. Update the environment configuration and replace the new version binary and related files;

[0015] S4. Start the new version of the database, allow replica migration, and allow leaseholders to migrate back.

[0016] Furthermore, the upgrade command is provided to preferentially migrate the leaseholder of the upgraded node to other nodes, which is specifically implemented as follows:

[0017] User manually triggers upgrade<node_id> The command specifies the upgrade node;

[0018] The node status switches to upgrading;

[0019] Switch database binary version;

[0020] Start the new version database with the start+upgrade-complete command;

[0021] Complete the online upgrade.

[0022] Furthermore, the added upgrade command is upgrade, and the usage is as follows:

[0023] database node upgrade--node-id$node_id--host$host

[0024] Among them, $node_id is the node ID to be upgraded, $host is the IP and port address that accepts the database connection. After receiving the command, the database sends the command to the specified $node_id to prepare for the upgrade operation.

[0025] Furthermore, for the node $node_id to be upgraded, after receiving the upgrade command, all leaseholders held by the node itself are searched, and for each leaseholder, the status of all its replicas is queried;

[0026] For replica repl-1, query all its replicas located on nodes 1, 2, and 3. At this time, the leaseholders are distributed on node 1; query the number of leaseholders held on nodes 2 and 3, select the node with the lowest number of leaseholders, and assume that the node is node 2. Build AdminTransferLeaseRequest, which contains the replica repl-1 to be migrated and the target node 2 to be migrated;

[0027] Mark the node as upgraded and prohibit the migration of data copies held by the node within the specified time.

[0028] Furthermore, the new version of the database needs to be started with a special command to indicate that the upgrade is complete. The syntax is as follows:

[0029] database start—upgrade-complete—host$host

[0030] For the startup parameters, an additional configuration - upgrade-complete is added. For the started database node, this parameter indicates that the node is started by online upgrade, rather than downtime recovery or new expansion node; for the database node, the database is reinitialized, the node status is marked from the upgrade status to the normal node status, the node is rejoined to the cluster network, and the replica is allowed to migrate.

[0031] If the cluster has a leaseholder balancing mechanism, there is no need to process the leaseholder. As time goes by, the leaseholder will automatically tend to balance, and during this process the leaseholder will elect the upgraded node.

[0032] Furthermore, after replacing the binary, an initialization operation is performed when starting the database with the new version.

[0033] Furthermore, the distributed multi-mode database includes a relational database and a time series database.

[0034] The present invention also claims a distributed multi-mode database online upgrade implementation device, comprising: at least one memory and at least one processor;

[0035] The at least one memory is used to store a machine-readable program;

[0036] The at least one processor is used to call the machine-readable program to implement the above method.

[0037] The present invention also claims protection for a computer-readable medium having computer instructions stored thereon, which can implement the above method when executed by a processor.

[0038] Compared with the prior art, the method for online upgrading of a distributed multi-mode database of the present invention has the following beneficial effects:

[0039] 1. Since the active leaseholder migration is performed during the upgrade, compared with the high availability of other distributed clusters, the leaseholder exists throughout the process and remains available.

[0040] 2. During the online upgrade of a node, the migration of the data copies held by the node is prohibited, which can greatly reduce performance consumption.

[0041] 3. When the upgrade is complete, additional initialization operations can be added, which is more controllable and customizable than direct replacement or offline upgrade. BRIEF DESCRIPTION OF THE DRAWINGS

[0042] Figure 1 is a flowchart of a node online upgrade provided by an embodiment of the present invention;

[0043] Figure 2 This is a diagram illustrating replica migration during node upgrade provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0044] The present invention will be further described below in conjunction with specific embodiments.

[0045] An embodiment of the present invention provides a method for online upgrading of a distributed multi-mode database. When performing a database version upgrade in a distributed database cluster, for an upgrade node, the replica leaseholder held by the node is preferentially migrated to other nodes to ensure that reading and writing are available without interruption during the upgrade, and at the same time, the replica migration is prohibited until the upgrade is completed. The migration of the replica is restored. During the upgrade process, the method plans to migrate the leaseholder held by the upgrade node, and prevents the migration of the replica in the migration operation. When performing a database version upgrade, all leaseholders held by the database node are first transferred, and at the same time, the replica migration of the node is prohibited, thereby ensuring that data reading and writing are available throughout the upgrade process and reducing unnecessary replica migration. The replica data on the upgrade node during the upgrade period is prevented from migrating in and out, including relational data and time series data for a multi-mode database.

[0046] The specific implementation steps of this method include:

[0047] S1. Provide an upgrade command and prioritize the migration of the leaseholder of the upgraded node to other nodes. The process is as follows: Figure 1 As shown, the specific implementation is as follows:

[0048] User manually triggers upgrade<node_id> The command specifies the upgrade node;

[0049] The node status switches to upgrading;

[0050] Switch database binary version;

[0051] Start the new version database with the start+upgrade-complete command;

[0052] Complete the online upgrade.

[0053] S2. Add upgrade commands, such as upgrade. For usage, refer to:

[0054] database node upgrade--node-id$node_id--host$host

[0055] Among them, $node_id is the node ID to be upgraded, $host is the IP and port address that accepts the database connection. After receiving the command, the database sends the command to the specified $node_id to prepare for the upgrade operation.

[0056] For the node $node_id to be upgraded, after receiving the upgrade command, such as Figure 2 As shown, find all leaseholders held by the node itself, and for each leaseholder, query the status of all its replicas;

[0057] For replica repl-1, query all its replicas located on nodes 1, 2, and 3. At this time, the leaseholders are distributed on node 1; query the number of leaseholders held on nodes 2 and 3, select the node with the lowest number of leaseholders, assuming that the node is node 2, and construct AdminTransferLeaseRequest, which contains the replica repl-1 to be migrated and the target node 2 to be migrated;

[0058] Mark the node as upgraded and prohibit the migration of data copies held by the node within the specified time.

[0059] S3. Update the environment configuration and replace the new version binary and related files. Between different versions, in addition to the changes in the database functions themselves, the system environment and database startup behavior may also change, so it is necessary to adjust the configuration environment before startup.

[0060] After replacing the binary, perform initialization operations when starting the database with the new version.

[0061] S4. Start the new version of the database, allow replica migration, and allow leaseholders to migrate back.

[0062] The new version of the database needs to be started with a special command to complete the upgrade. The syntax is as follows:

[0063] database start—upgrade-complete—host$host

[0064] For the startup parameters, an additional configuration - upgrade-complete is added. For the started database node, this parameter indicates that the node is started by online upgrade, rather than downtime recovery or new expansion node; for the database node, the database is reinitialized, the node status is marked from the upgrade status to the normal node status, the node is rejoined to the cluster network, and the replica is allowed to migrate.

[0065] If the cluster has a leaseholder balancing mechanism, there is no need to process the leaseholder. As time goes by, the leaseholder will automatically tend to balance, and during this process the leaseholder will elect the upgraded node.

[0066] The embodiment of the present invention also provides a distributed multi-mode database online upgrade implementation device, including: at least one memory and at least one processor;

[0067] The at least one memory is used to store a machine-readable program;

[0068] The at least one processor is used to call the machine-readable program to implement the method for implementing online upgrade of the distributed multi-mode database described in the above embodiment.

[0069] The embodiment of the present invention further provides a computer-readable medium, on which computer instructions are stored, and when the computer instructions are executed by a processor, the method for implementing online upgrade of a distributed multi-mode database described in the above embodiment can be implemented. Specifically, a system or device equipped with a storage medium can be provided, on which a software program code implementing the functions of any of the above embodiments is stored, and a computer (or CPU or MPU) of the system or device can read and execute the program code stored in the storage medium.

[0070] In this case, the program code itself read from the storage medium can realize the function of any one of the above-mentioned embodiments, and thus the program code and the storage medium storing the program code constitute a part of the present invention.

[0071] The storage medium embodiments for providing the program code include a floppy disk, a hard disk, a magneto-optical disk, an optical disk (such as CD-ROM, CD-R, CD-RW, DVD-ROM, DVD-RAM, DVD-RW, DVD+RW), a magnetic tape, a non-volatile memory card, and a ROM. Alternatively, the program code can be downloaded from a server computer by a communication network.

[0072] In addition, it should be clear that the functions of any of the above embodiments can be implemented not only by executing the program code read by the computer, but also by enabling an operating system operating on the computer to complete part or all of the actual operations based on instructions from the program code.

[0073] In addition, it can be understood that the program code read from the storage medium is written to a memory provided in an expansion board inserted into the computer or written to a memory provided in an expansion unit connected to the computer, and then based on the instructions of the program code, a CPU installed on the expansion board or the expansion unit is enabled to perform part or all of the actual operations, thereby realizing the functions of any of the above-mentioned embodiments.

[0074] The present invention is shown and described in detail above through the accompanying drawings and preferred embodiments. However, the present invention is not limited to these disclosed embodiments. Based on the above multiple embodiments, those skilled in the art can know that the code review methods in the above different embodiments can be combined to obtain more embodiments of the present invention, and these embodiments are also within the protection scope of the present invention.

Claims

1. A method for online upgrading of a distributed multi-mode database, characterized in that: When upgrading the database version in a distributed database cluster, for the upgraded node, the replica lease held by the node is migrated to other nodes first to ensure that read and write are available without interruption during the upgrade. At the same time, replica migration is prohibited until the upgrade is completed and replica migration is resumed.

2. A method for online upgrading of a distributed multi-mode database according to claim 1, characterized in that: The specific implementation steps of this method include: S1. Provide an upgrade command and prioritize the migration of the leaseholder of the upgraded node to other nodes; S2. Add an upgrade command. After receiving the upgrade command, the node to be upgraded is upgraded and marked as upgraded. The data copies held by the node are prohibited from being migrated within the specified time. S3. Update the environment configuration and replace the new version binary and related files; S4. Start the new version of the database, allow replica migration, and allow leaseholders to migrate back.

3. A method for online upgrading of a distributed multi-mode database according to claim 2, characterized in that: The upgrade command is provided to preferentially migrate the leaseholder of the upgraded node to other nodes. The specific implementation is as follows: User manually triggers upgrade<node_id> The command specifies the upgrade node; The node status switches to upgrading; Switch database binary version; Start the new version database with the start+upgrade-complete command; Complete the online upgrade.

4. A method for online upgrading of a distributed multi-mode database according to claim 2, characterized in that: The command to add the upgrade is upgrade, and the usage is as follows: database node upgrade--node-id$node_id--host$host Among them, $node_id is the node ID to be upgraded, $host is the IP and port address that accepts the database connection. After receiving the command, the database sends the command to the specified $node_id to prepare for the upgrade operation.

5. A method for online upgrading of a distributed multi-mode database according to claim 4, characterized in that: For the node $node_id to be upgraded, after receiving the upgrade command, find all leaseholders held by the node itself, and for each leaseholder, query the status of all its replicas; For replica repl-1, query all its replicas located on nodes 1, 2, and 3. At this time, the leaseholders are distributed on node 1; query the number of leaseholders held on nodes 2 and 3, select the node with the lowest number of leaseholders, set that node as node 2, and construct AdminTransferLeaseRequest, which contains the replica repl-1 to be migrated and the target node 2 to be migrated; Mark the node as upgraded and prohibit the migration of data copies held by the node within the specified time.

6. A method for online upgrading of a distributed multi-mode database according to claim 2 or 4, characterized in that: The new version of the database is started with a special command, indicating that the upgrade is complete. The syntax is as follows: database start--upgrade-complete--host$host For startup parameters, an additional configuration --upgrade-complete is added. For the started database node, this parameter indicates that the node is started by online upgrade, rather than downtime recovery or new expansion node; For the database node, the database is reinitialized, the node status is marked from upgraded to normal, the node is rejoined to the cluster network, and the replica is allowed to migrate.

7. A method for online upgrading of a distributed multi-mode database according to claim 2, characterized in that: After replacing the binary, perform initialization operations when starting the database with the new version.

8. A method for online upgrading of a distributed multi-mode database according to claim 1, characterized in that: The distributed multi-mode database includes a relational database and a time series database.

9. A distributed multi-mode database online upgrade implementation device, characterized in that: include: at least one memory and at least one processor; The at least one memory is used to store a machine-readable program; The at least one processor is used to call the machine-readable program to implement the method described in any one of claims 1 to 8.

10. A computer-readable medium, characterized in that The computer readable medium stores computer instructions, which, when executed by a processor, can implement the method according to any one of claims 1 to 8.

Images