A method and device for reducing the capacity of a distributed storage system, an electronic device and a medium

Abstract

The present disclosure provides a method and device for scaling down a distributed storage system, electronic equipment and medium, relating to the technical field of computers, in particular to the technical field of cloud storage and distributed system management. The specific implementation scheme is: receiving a scaling down request, wherein the scaling down request is used to request to migrate a to-be-migrated data table stored in a first shard to a second shard. Then, full data of the to-be-migrated data table stored in a node of the first shard is obtained, and the full data of the to-be-migrated data table is migrated to each node included in the second shard. Then, a corresponding relationship between an identifier of the to-be-migrated data table and an identifier of the second shard is recorded, and the corresponding relationship indicates that the to-be-migrated data table is stored in the second shard. Then, the first shard is deleted. The flexibility and efficiency of scaling down the distributed storage system are improved.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, and in particular to the fields of cloud storage and distributed system management technology. Background Technology

[0002] In distributed storage systems, data tables are stored in the form of shards. When data tables stored in a sharded cluster are transferred to other systems, or when a large-capacity sharded cluster built to cope with business peaks needs to reduce its capacity after the peak, there is a need to reduce the number of shards in the distributed storage system. In this case, it is necessary to shrink the distributed storage system, that is, delete some shards in the distributed storage system. Summary of the Invention

[0003] This disclosure provides a method, apparatus, electronic device, and medium for scaling down a distributed storage system.

[0004] A first aspect of this disclosure provides a method for scaling down a distributed storage system, the distributed storage system including a first shard and a second shard, each shard including multiple nodes, and the data tables stored on the nodes within the same shard being identical. The method includes:

[0005] Receive a scaling-down request, the scaling-down request being used to request the migration of the data table to be migrated stored in the first shard to the second shard;

[0006] Obtain the full data of the data table to be migrated stored in one node of the first shard;

[0007] The full data of the data table to be migrated is migrated to each node included in the second shard;

[0008] Record the correspondence between the identifier of the data table to be migrated and the identifier of the second shard, wherein the correspondence indicates that the data table to be migrated is stored in the second shard;

[0009] Delete the first fragment.

[0010] A second aspect of this disclosure provides a scaling-down device for a distributed storage system, the distributed storage system including a first shard and a second shard, each shard including multiple nodes, and the data tables stored on the nodes within the same shard being identical. The device includes:

[0011] A receiving module is used to receive a scaling-down request, wherein the scaling-down request is used to request the migration of the data table to be migrated stored in the first shard to the second shard;

[0012] The acquisition module is used to acquire the full data of the data table to be migrated stored in one node of the first shard;

[0013] The migration module is used to migrate the full data of the data table to be migrated to each node included in the second shard;

[0014] A recording module is used to record the correspondence between the identifier of the data table to be migrated and the identifier of the second shard, wherein the correspondence indicates that the data table to be migrated is stored in the second shard;

[0015] The deletion module is used to delete the first fragment.

[0016] A third aspect of this disclosure provides an electronic device, including:

[0017] At least one processor; and

[0018] A memory communicatively connected to the at least one processor; wherein,

[0019] The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the method described in any one of the first aspects.

[0020] A fourth aspect of this disclosure provides a non-transitory computer-readable storage medium storing computer instructions, wherein the computer instructions are configured to cause the computer to perform the method according to any one of the first aspects.

[0021] A fifth aspect of this disclosure provides a computer program product including a computer program that, when executed by a processor, implements the method according to any one of the first aspects.

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

[0023] The accompanying drawings are provided to better understand this solution and do not constitute a limitation of this disclosure. Wherein:

[0024] Figure 1 This is a flowchart of a method for scaling down a distributed storage system according to an embodiment of this disclosure;

[0025] Figure 2 This is a flowchart of a method for synchronizing distributed metadata on a scaling-down server, provided in an embodiment of this disclosure.

[0026] Figure 3 This is an exemplary schematic diagram of the scaling-down process of a distributed storage system provided in this disclosure embodiment;

[0027] Figure 4 This is a signaling diagram of the scaling-down process of a distributed storage system provided in an embodiment of this disclosure;

[0028] Figure 5 This is an exemplary schematic diagram of another distributed storage system scaling down according to an embodiment of this disclosure;

[0029] Figure 6 This is a schematic diagram of the structure of a scaling-down device for a distributed storage system provided in an embodiment of this disclosure;

[0030] Figure 7 This is a block diagram of an electronic device used to implement the scaling-down method of the distributed storage system according to embodiments of the present disclosure. Detailed Implementation

[0031] The exemplary embodiments of this disclosure are described below with reference to the accompanying drawings, including various details of the embodiments to aid understanding, and should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of this disclosure. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0032] Currently, the shard where a data table is stored in a distributed storage system is generally determined by the data table's data identifier (id). That is, the hash value obtained by performing a hash operation on the data table's data id is the shard id of a shard, indicating that the data table is stored in the shard corresponding to that shard id.

[0033] In this scenario, if a data table stored in shard 1 needs to be migrated to shard 2, the table's storage location cannot be correctly determined using its ID and existing hash calculations. Therefore, the only way to ensure accurate location of the migrated data is to modify the table's ID or perform a different hash calculation. This approach is complex and results in low scaling efficiency for the distributed storage system.

[0034] To address this problem, this disclosure provides a method for scaling down a distributed storage system. Before introducing this method, the terms used in this disclosure will be explained:

[0035] The distributed storage system includes multiple shards. To distinguish the two shards involved in the scaling-down process, in this embodiment of the disclosure, the shard to be deleted is referred to as the first shard, and the shard that needs to store the data table in the first shard is referred to as the second shard. The first shard can also be called the shard to be scaled down, and the second shard can also be called the reserved shard.

[0036] A shard consists of multiple nodes, and all nodes within the same shard store the same data tables. Each node is software that runs on a storage server, and the nodes within the same shard can run on the same storage server or different storage servers.

[0037] The master node of a shard is used to perform write operations on the data table, enabling functions such as adding, deleting, and modifying data. In cases where there are no slave nodes in the shard or the data table is read frequently, the master node can be configured to handle read operations on the data table.

[0038] The sharded slave node is used to synchronize the data tables stored in the master node and to implement the function of reading the data tables.

[0039] The sharded standby nodes are used to synchronize the data tables stored in the master node.

[0040] A scaling-down server is used to execute the scaling-down method of the distributed storage system provided in the embodiments of this disclosure, thereby scaling down the distributed storage system and reducing the number of shards included in the distributed storage system.

[0041] A metadata server stores the metadata of each shard in a distributed storage system, as well as the correspondence between each data table and its respective shard. For example, shard metadata includes: the Internet Protocol (IP) address and port number of the storage server where each node in the shard resides, the master / slave status of each node, and the available and used storage space of the shard. The master / slave status indicates whether a node is currently a master, slave, or standby node.

[0042] The proxy server is used to receive read and write commands from users, locate the shard where the data table is located, and perform read and write operations on that shard.

[0043] See Figure 1 The method for scaling down a distributed storage system provided in this disclosure, applied to a scaling-down server, includes the following steps:

[0044] S101. Receive a scaling-down request, wherein the scaling-down request is used to request the migration of the data table to be migrated stored in the first shard to the second shard.

[0045] The distributed storage system includes a first shard and a second shard. The first shard and the second shard can be user-specified, randomized, or preset; this disclosure does not specifically limit their selection.

[0046] Scaling down requests can be user-triggered or automatically triggered. For example, when a monitoring server detects that the ratio between the total amount of data stored in each shard of a distributed storage system and the total capacity of each shard is less than a preset ratio, it sends a scaling down request to the scaling down server.

[0047] S102. Obtain the full data of the data table to be migrated stored in one node of the first shard.

[0048] Since each node in the first shard stores the same data, it is possible to obtain the full data of the data table to be migrated stored in only one node of the first shard.

[0049] S103. Migrate all the data of the data table to be migrated to each node included in the second shard.

[0050] Optionally, before S103, the nodes included in the second shard may store other data tables, or they may not store any data tables. If the nodes included in the second shard store other data tables before S103, executing S103 will not affect the data tables already stored in the nodes included in the second shard. That is, during the data migration process, the data tables to be migrated will not overwrite the data tables already stored in the nodes of the second shard, so that after executing S103, each node of the second shard stores both the originally stored data tables and the data tables to be migrated.

[0051] S104. Record the correspondence between the identifier of the data table to be migrated and the identifier of the second shard, wherein the correspondence indicates that the data table to be migrated is stored in the second shard.

[0052] The identifier for a data table can be a unique identifier such as the table name or table ID. The identifier for a shard can be a unique identifier such as the shard name or shard number.

[0053] For example, the correspondence is: "123:11111", where 123 is the identifier of the data table and 11111 is the identifier of the second partition.

[0054] S105, Delete the first fragment.

[0055] Since the data tables to be migrated in the first shard have been stored in each node of the second shard, the first shard can be deleted, thus achieving the scaling down of the distributed storage system.

[0056] In the process of scaling down a distributed storage system, this embodiment of the disclosure allows the scaling-down server to store all data of the data table to be migrated in the first shard and migrate the entire data to each node of the second shard. This means the first shard does not need to directly migrate data with the second shard, thus avoiding blocking read and write operations on the first shard and reducing the impact of the scaling-down process on business operations. Furthermore, this embodiment of the disclosure allows direct setting of the correspondence between data tables and shards in the distributed storage system. Therefore, when looking up the shard where a data table resides, it is not necessary to rely on the hash value of the data table's identifier, removing the restriction of hash operations on the shards where data tables are stored. This makes data table migration more flexible and improves the flexibility and efficiency of scaling down.

[0057] The following provides a detailed description of the steps included in the method for scaling down a distributed storage system provided in this disclosure:

[0058] In some embodiments of this disclosure, each shard includes at least one spare node. In this case, the method by which the scaling-down server in S102 obtains the full data of the data table to be migrated stored on one node of the first shard can be implemented as follows: obtaining the full data of the data table to be migrated stored on a spare node of the first shard.

[0059] That is, the scaling-down server can send a full backup request to a standby node of the first shard, so that the standby node can perform a full backup of the data tables to be migrated stored on its own, and obtain the full data of the data tables to be migrated in a preset format. For example, the standby node can use the dump function to export the full data of the data tables to be migrated stored on its own in a preset format.

[0060] In some embodiments of this disclosure, in order to improve the success rate of scaling down, the scaling down server may also perform a pre-check on the distributed storage system before executing the above-described S102 to obtain the full data of the data table to be migrated stored in a node of the first shard.

[0061] That is, the scaling-down server can also: check whether the preset scaling-down conditions are met. If the check passes, it executes step S102 to obtain the full data of the data table to be migrated stored on one node of the first shard. Otherwise, it does not continue to execute S102, and can output a prompt message to the user to inform the user that the distributed storage system cannot be scaled down at present.

[0062] The preset scaling-down conditions include: the available storage space of the second partition is greater than the product of the used storage space of the first partition and a preset multiple.

[0063] The available storage space of the second shard represents the unused storage space within the second shard. The used storage space of the first shard represents the storage space within the first shard that has been occupied by the data tables to be migrated.

[0064] The preset multiplier is greater than 1, for example, the preset multiplier is 1.5. In practical scenarios, the preset multiplier can be set by the personnel managing the distributed storage system based on experience.

[0065] The embodiments disclosed herein control the available storage space of the second shard to be greater than the product of the used storage space of the first shard and a preset multiple. This can prevent the second shard from being unable to store the data table to be migrated due to insufficient available storage space, thereby improving the success rate of migrating the data table to be migrated, which in turn improves the success rate of scaling down the distributed storage system.

[0066] In this embodiment of the disclosure, the aforementioned preset scaling-down condition may further include: there are currently no other scaling-down tasks in the distributed storage system.

[0067] The scaling-down server can record the task identifier of the scaling-down task corresponding to each scaling-down request received, and record the corresponding scaling-down status for that task identifier. For example, the scaling-down status can be: scaling down or scaling down completed.

[0068] Based on this, the scaling-down server can check whether there are any other scaling-down tasks besides the one corresponding to the scaling-down request received by S101, and whether there are any other scaling-down tasks currently in operation. If yes, it determines that there are other scaling-down tasks in the distributed storage system; otherwise, it determines that there are no other scaling-down tasks in the distributed storage system.

[0069] By controlling the distributed storage system to perform scaling down only when there are no other scaling down tasks, it is possible to avoid errors in data table migration and incorrect recording of the correspondence between data table identifiers and shard identifiers caused by executing different scaling down tasks simultaneously, thus ensuring the accuracy of scaling down the distributed storage system.

[0070] In some embodiments of this disclosure, since the distributed storage system also includes a metadata server, and the metadata server stores the metadata of each shard in the distributed storage system, the scaling-down server can send a shard data retrieval request to the metadata server before checking whether the preset scaling-down conditions are met, and then receive a shard information retrieval response from the metadata server.

[0071] The shard data retrieval request is used to request the metadata of the first shard and the second shard. The shard information retrieval response includes the metadata of the first shard and the second shard, and the shard metadata includes used storage space and available storage space.

[0072] A monitoring module can be configured in the metadata server to monitor and update metadata such as the used and available storage space of each shard in the distributed storage system in real time.

[0073] The metadata of the shards may also include: the IP address and port number of the storage server where each node in the shard is located, and the master-slave status of each node.

[0074] After obtaining the IP address and port number of the storage server where the node resides, the scaling-down server can subsequently communicate with that storage server using the same IP address and port number, thereby instructing the storage server to perform corresponding operations on the node. For example, based on the IP address and port number of the storage server where a node in the first shard resides, the scaling-down server sends a request to that storage server to retrieve the full data of the data table to be migrated stored on that node. This allows the storage server to retrieve the full data of the data table to be migrated stored on that node and send it to the scaling-down server.

[0075] The scaling-down server can obtain the metadata of the first and second shards from the metadata server, so as to perform pre-checks on the distributed storage system based on this, thereby improving the stability and accuracy of scaling-down.

[0076] After the distributed storage system passes the pre-check, the scaling-down server executes step S102 above to obtain the full data of the data table to be migrated stored on one node of the first shard. During S102, if the scaling-down server cannot successfully obtain the full data of the data table to be migrated from a spare node of the first shard, it can select another spare node of the first shard and obtain the full data from that spare node. If the acquisition still fails, the scaling-down failure is reported to the metadata server so that the metadata server records the failure of this scaling-down task in its log.

[0077] In some embodiments of this disclosure, the method by which the above-mentioned S103 scaling-down server migrates the full data of the data table to be migrated to each node included in the second shard includes the following steps:

[0078] Step 1: Migrate all data to each non-master node included in the second shard.

[0079] The second shard consists of one master node and at least one non-master node.

[0080] Since the scaling server can obtain the metadata of the second shard from the metadata server, and the metadata of the second shard records the master-slave status of each node, the scaling server can determine each non-master node included in the second shard based on the master-slave status of each node included in the second shard, and then migrate the full amount of data to each non-master node included in the second shard.

[0081] During migration, the scaling-down server can initiate data migration tasks in batches. Each data migration task is used to migrate all data to a non-master node included in the second shard. The scaling-down server can also check the status of each data migration task repeatedly until the status of each data migration task is "migration complete".

[0082] Step 2: Switch the master node included in the second shard to a non-master node, and switch one of the non-master nodes included in the second shard to a master node, and migrate all data to the master node of the second shard before the master-slave switch.

[0083] The scaling-down server can send a master-slave switch command to the storage server where the master node of the second shard is located, so that the storage server switches the master node to a non-master node and selects a slave node of the second shard to switch the slave node to a master node.

[0084] In this embodiment, when migrating the full data of the data table to be migrated to the second shard, the full data is first migrated to the non-master nodes of the second shard. Then, a master-slave switch is performed on the second shard, and the full data is migrated to the master node before the switch. This ensures that each data migration targets only the slave nodes of the second shard. Since the master node of each shard needs to perform data write operations, and the data migration process may affect these operations, leading to inaccurate data stored in the master node or delays in the response of data write operations, this embodiment only performs data migration on the slave nodes, ensuring the continuity of data read and write services.

[0085] In some embodiments of this disclosure, before performing step two above to switch the master node included in the second shard to a non-master node, the scaling server may also check whether the full data has been successfully stored in each non-master node included in the second shard.

[0086] The inspection process can be implemented as follows: check whether each non-master node included in the second shard has completely stored all the data.

[0087] If any non-master node fails to store all the data completely, and the number of retries for that non-master node has not reached the first preset number, then the entire data is re-stored in that non-master node, and the number of retries for that non-master node is incremented by 1. The first preset number can be set according to actual needs, for example, to 3.

[0088] If any non-master node fails to store all data completely, and the number of retries for that non-master node reaches the first preset number, then delete all data stored in each non-master node included in the second shard. That is, perform a data rollback operation on each non-master node included in the second shard, and delete all data stored in the shrinking server itself.

[0089] If all non-master nodes in the second shard completely store all the data, then the step of switching the master nodes in the second shard to non-master nodes is executed.

[0090] Specifically, the scaling-down server can compare the difference between its own stored Global Transaction Identifier (GTID) and the GTID in the non-master node to see if it is less than a preset difference. If so, it determines that the non-master node has stored complete full data; otherwise, it determines that the full data stored by the non-master node is incomplete.

[0091] To reduce the impact of long data migration times on the inspection process, the scaling-down server can cyclically check the data migration status of each non-master node in the second shard. When the data migration status of each non-master node is complete, the above inspection process is executed.

[0092] Using the above method, the shrinking server can retry when the non-master node of the second shard fails to store all the data. If the full data still cannot be successfully stored in the non-master node after the first preset number of retries, it means that the second shard cannot store the data table to be migrated. Therefore, the current shrinking task fails. The shrinking server can delete the full data stored in each non-master node included in the second shard as well as the full data stored in itself, reducing the situation of storing useless data in the second shard and the shrinking server.

[0093] In some embodiments of this disclosure, the second shard may include: a master node, at least one slave node, and a standby node. In this case, the non-master node includes: a slave node and a standby node. The master node provides data writing functionality, the slave node provides data reading functionality, and the standby node is used to back up the data stored on the master node, thereby improving the disaster recovery capability of the distributed storage system.

[0094] In this scenario, the scaling-down server can perform step two, which involves switching the master node in the second shard to a slave node, and then switching one of the slave nodes in the second shard to a master node.

[0095] By switching from master to slave, it can be ensured that after the switch, the original master node becomes a slave node and stores the data in the table to be migrated as a slave node. Moreover, a former slave node can continue to provide the data writing functions that a master node can provide when it becomes a master node, reducing the impact of data table migration on read and write operations.

[0096] In some embodiments of this disclosure, the second shard may include a primary node and at least one standby node. In this case, the non-primary node is the standby node. The primary node provides data write and read functions, and the standby node is used to back up the data stored by the primary node. In this scenario, the second shard does not include slave nodes, thus reducing the types of nodes included in the shard and decreasing the number of nodes in the shard. For example, the second shard may include only one primary node and one standby node, reducing storage costs.

[0097] In this scenario, the scaling-down server can perform step two, which involves switching the master node in the second shard to a standby node, and then switching one of the standby nodes in the second shard to a master node.

[0098] By switching between primary and standby nodes, it can be ensured that after the switch, the original primary node becomes the standby node, and thus stores the data in the data table to be migrated as the standby node. Moreover, one of the original standby nodes becomes the primary node, continuing to provide the data writing and data reading functions that the primary node can provide, reducing the impact of data table migration on read and write operations.

[0099] After the full data is stored in each node of the second shard in S103, the user can still read and write the data table to be migrated stored in the first shard during the full data migration process. This causes the data table to be migrated to be modified during the full data migration process, resulting in incremental data other than the full data.

[0100] To ensure consistency between the data tables to be migrated in the first shard and the second shard, before the scaling server records the correspondence between the identifier of the data table to be migrated and the identifier of the second shard in S103, it can also synchronize the incremental data (excluding the full data) in the data table to be migrated stored in the first shard to the master nodes included in the second shard.

[0101] In other words, the scaling-down server can determine the data tables to be migrated during the scaling-down process based on the differences between the distribution metadata of the distributed storage system before and after scaling-down. Here, the distribution metadata represents the shard where each data table in the distributed storage system resides. Then, the scaling-down server sends an incremental migration command to the master node of the second shard, causing the master node of the second shard to initiate a differential synchronization process with the master node of the first shard. The master node of the second shard is a logical slave node in the differential synchronization process, and the master node of the first shard is a logical master node in the differential synchronization process. This synchronizes incremental data from the master node of the first shard to the master node of the second shard, while also preventing the overwriting of data already stored in the master node of the first shard.

[0102] Because there is a data synchronization mechanism between the master node and non-master node of the second shard, the non-master node of the second shard can synchronize the incremental data stored in the master node of the second shard.

[0103] By synchronizing incremental data (excluding full data) from the data table to be migrated stored in the first shard to the master nodes in the second shard, the consistency of the data to be migrated stored in the master nodes of the first and second shards can be ensured, improving the accuracy of data migration. Furthermore, the volume of incremental data is generally small, so the incremental data migration process has minimal impact on the read / write operations of the data table to be migrated.

[0104] In some embodiments of this disclosure, the metadata server of the distributed storage system records distribution metadata, which represents the shard where each data table stored in the distributed storage system resides. For example, the distribution metadata records the shard identifier corresponding to the identifier of each data table in the distributed storage system.

[0105] Before recording the correspondence between the identifier of the data table to be migrated and the identifier of the second shard, the scaling server can also send a metadata retrieval request to the metadata server and receive a metadata retrieval response from the metadata server.

[0106] The metadata retrieval request is used to request the distributed metadata of the distributed storage system, and the metadata retrieval response includes the distributed metadata.

[0107] Based on this, the way the scaling-down server executes the above-mentioned S104 to record the correspondence between the identifier of the data table to be migrated and the identifier of the second shard can be implemented as follows: in the distribution metadata, update the shard identifier corresponding to the identifier of the data table to be migrated to the identifier of the second shard.

[0108] If the identifier of the data table to be migrated recorded in the distribution metadata before the update corresponds to the identifier of the first shard, the identifier of the first shard in the correspondence can be modified to the identifier of the second shard.

[0109] Alternatively, if the distribution metadata before the update only records the identifier of the data table to be migrated, but not the shard identifier corresponding to that identifier, then the identifier of the second shard corresponding to the identifier of the data table to be migrated can be recorded. In the case where the distribution metadata only records the identifier of the data table to be migrated, a hash value can be obtained by performing a hash operation on the identifier of the data table to be migrated, and the shard containing the data table to be migrated can be determined based on the hash value.

[0110] The scaling-down server can update the shard identifier corresponding to the identifier of the data table to be migrated in the distribution metadata to the identifier of the second shard, thereby realizing unified management of the data tables stored in the distributed storage system and improving management efficiency and accuracy.

[0111] After recording the correspondence between the data table to be migrated and the second shard in S104, and before deleting the first shard in S105, the scaling-down server can also synchronize the updated distribution metadata to other devices included in the distributed management system. For example... Figure 2 As shown, the synchronization process of distributed metadata by the scaling-down server includes the following steps:

[0112] S201. Send migration status information to the metadata server. The distributed storage system also includes a proxy server. The migration status information includes updated distributed metadata, so that the metadata server modifies its own stored distributed metadata to the updated information, and also modifies the distributed metadata stored on the proxy server to the updated information.

[0113] Optionally, the scale-down server can be run during off-peak hours. Figure 2 The steps shown are designed to reduce the impact of changes to distributed metadata on data read / write operations in a distributed storage system. The off-peak period can be a preset time frame, such as 00:00 to 05:00.

[0114] When the metadata server modifies the distribution metadata of the proxy server, it can send a modification instruction to the proxy server, so that the proxy server can obtain the updated distribution metadata from the metadata server and modify its own stored distribution metadata to the updated distribution metadata.

[0115] The migration status information may also include: metadata of the first shard, metadata of the second shard, and / or progress information of the differential synchronization from the first shard to the second shard, etc., which are not specifically limited in this embodiment.

[0116] S202. If it is detected that the metadata server has failed to modify the distributed metadata, delete the data table to be migrated stored in its own storage, and delete the data table to be migrated stored in each node included in the second shard.

[0117] In some embodiments of this disclosure, the metadata server may also generate a task identifier for this scaling-down task and include the task identifier in the aforementioned metadata retrieval response. In this case, the migration status information sent by the scaling-down server to the metadata server in S201 also includes the task identifier extracted from the metadata retrieval response, enabling the metadata server to check whether the task identifier included in the migration status information is the same as the task identifier it generated.

[0118] After the scaling-down server sends migration status information to the metadata server in S201, if it receives a modification failure message from the metadata server, it determines that the metadata server's modification of the distribution metadata information was unsuccessful. The scaling-down failure message is sent by the metadata server when it checks that the task identifier included in the migration status information differs from the task identifier it generated, indicating that the modification of the distribution metadata information has failed.

[0119] When the metadata server detects that the task identifier in the migration status information is different from the task identifier it generated, it will not modify the distribution metadata stored in itself or in the proxy server.

[0120] Conversely, if the scaling-down server receives a successful modification message from the metadata server, or if it does not receive a scaling-down failure message within a preset time after sending the migration status information, it determines that the metadata server has successfully modified the distribution metadata. The successful scaling-down message is sent by the metadata server when it checks that the task identifier included in the migration status information matches the task identifier it generated, indicating that the modification of the distribution metadata was successful.

[0121] When the metadata server detects that the task identifier included in the migration status information is the same as the task identifier it generated, it performs the steps of modifying the distribution metadata information stored in its own storage to the updated distribution metadata information, and modifying the distribution metadata information stored in the proxy server to the updated distribution metadata information.

[0122] Using the above method, the scaling-down server can detect whether the metadata server has successfully modified the distribution metadata stored in itself, ensuring the consistency of the distribution metadata stored in the scaling-down server and the metadata server.

[0123] If the metadata server fails to modify the distribution metadata, it indicates that the scaling down task has failed and the previously executed scaling down steps need to be rolled back. That is, the scaling down server deletes the data tables to be migrated stored in its own storage and deletes the data tables to be migrated stored in each node included in the second shard.

[0124] S203. If it is detected that the proxy server failed to modify the distribution metadata, the distribution metadata stored in the metadata server and the proxy server will be modified to the distribution metadata before the update, the data table to be migrated stored in the proxy server will be deleted, and the data table to be migrated stored in each node of the second shard will be deleted.

[0125] If the proxy server fails to modify the distribution metadata, it indicates that the scaling down task has failed and the previously executed scaling down steps need to be rolled back. That is, the scaling down server modifies the distribution metadata stored in the metadata server and proxy server to the distribution metadata before the update, deletes the data tables to be migrated stored in its own storage, and deletes the data tables to be migrated stored in each node included in the second shard.

[0126] The method for determining whether the proxy server has successfully modified the distribution metadata can be found in the following description.

[0127] S204. If it is detected that both the metadata server and the proxy server have successfully modified the distribution metadata, then execute step S105 to delete the first fragment.

[0128] If both the metadata server and the proxy server successfully modify the distribution metadata, the scaling-down task is successful. At this point, the first shard and the data tables to be migrated stored in the scaling-down server can be deleted, reducing the storage space occupied by useless data. Read and write operations on the data to be migrated are now handled by the second shard.

[0129] After deleting the first shard in S105, the metadata of the first shard stored in the metadata server can also be deleted, and the storage server where the first shard is located can be removed from the distributed storage system, thereby reducing the number of physical devices included in the distributed storage system.

[0130] Using the above method, the scaling-down server can synchronize the updated distribution metadata of the distributed storage system to the metadata server and the proxy server. This avoids the proxy server from having to look up the shard of the data table targeted by the read / write command based on the incorrect distribution metadata it stores before the update, thus reducing the probability of data read / write errors.

[0131] In this embodiment of the disclosure, there are multiple proxy servers in the distributed storage system. In this case, after the scaling-down server sends migration status information to the metadata server in S201, it can also perform consistency verification on the distributed metadata stored by each proxy server.

[0132] If the consistency check fails, it is determined that each proxy server has failed to modify the distribution metadata.

[0133] If the consistency check passes, it is determined that each proxy server has successfully modified the distribution metadata.

[0134] The scaling-down server can retrieve the distribution metadata stored in each proxy server and compare it with the updated distribution metadata stored in the scaling-down server itself. If the comparison results are all the same, the consistency check is considered successful; if there are any differences, the consistency check is considered unsuccessful.

[0135] Alternatively, the scaling-down server can obtain the distribution metadata stored in each proxy server and compare whether the obtained distribution metadata is the same. If the comparison results are all the same, the consistency check is determined to have passed; if there are comparison results that are different, the consistency check is determined to have failed. It is also determined that the proxy server containing the distribution metadata that is different from all other distribution metadata has not been successfully modified. Alternatively, the consistency of the distribution metadata stored in each proxy server can be checked through other methods, which are not specifically limited in this embodiment.

[0136] After the metadata server modifies the distribution metadata stored on each proxy server to the updated distribution metadata, the distribution metadata stored on each proxy server should normally be identical. Therefore, the scaling server performs a consistency check on the distribution metadata stored on each proxy server. If the consistency check succeeds, it means that each proxy server has stored the updated distribution metadata, thus confirming that each proxy server has successfully modified the distribution metadata. If the consistency check fails, it means that some proxy servers have not stored the updated distribution metadata, thus confirming that the modification of the distribution metadata by each proxy server has failed.

[0137] The scaling-down server can perform consistency checks on the distributed metadata stored in each proxy server, thereby ensuring that the distributed metadata stored in each proxy server is the same. This avoids situations where some proxy servers store incorrect distributed metadata, which could lead to errors in reading and writing data tables in the distributed storage system.

[0138] In this embodiment of the disclosure, in order to improve the success rate of synchronizing distributed metadata with the proxy servers, if the scaling-down server fails the consistency check, before determining that each proxy server has failed to modify the distributed metadata, it can also identify the proxy servers that failed to modify the metadata and determine whether the number of retries for the proxy servers to be retried has reached a second preset number. The second preset number can be set according to actual needs, for example, the second preset number is 5 times.

[0139] If so, proceed with the steps to determine if each proxy server failed to modify the distribution metadata.

[0140] If not, the distribution metadata stored in the proxy server to be retried is modified to the updated distribution metadata, and the number of retries to the proxy server to be retried is incremented by 1.

[0141] The scaling-down server can send a retry command to the metadata server, so that the metadata server can notify the proxy server waiting to be retried to retrieve the updated distribution metadata from the metadata server and modify its own stored distribution metadata to the updated distribution metadata.

[0142] Alternatively, the scaling-down server can send updated distribution metadata to the proxy server waiting to be retried, so that the proxy server waiting to be retried can modify its stored distribution metadata to the updated distribution metadata.

[0143] Alternatively, the distribution metadata stored in the proxy server to be retried can be updated in other ways, and this disclosure does not specifically limit this method.

[0144] Using the above method, the scaling-down server can retry proxy servers that have failed to modify the distribution metadata, that is, re-modify the distribution metadata stored in the proxy server with the updated distribution metadata, thereby improving the success rate of updating the distribution metadata of the proxy server and thus improving the success rate of scaling down the distributed storage system.

[0145] See Figure 3 The following describes the distributed storage system involved in the embodiments of this disclosure in conjunction with practical application scenarios:

[0146] The distributed storage system includes: a scaling server, a metadata server, a proxy server, a first shard, and a second shard. The nodes in each of the first and second shards run on the storage server. The first shard includes master node 1 and slave node 1, and the second shard includes master node 2 and slave node 2. The servers communicate with each other via a network, which can be wired, wireless, or fiber optic cable communication, etc.

[0147] The proxy server can communicate with the metadata server and the storage server where each shard is located via the network. It can receive read and write instructions for data tables sent by users, find the shard identifier corresponding to the identifier of the data table based on the distribution metadata stored in its own storage, and perform data read and write operations on the data tables included in the shard corresponding to the shard identifier.

[0148] Metadata servers can communicate with proxy servers and scaling servers over the network to store metadata of each shard in a distributed storage system, as well as distributed metadata of the distributed storage system.

[0149] The scaling-down server can communicate with the storage server and the metadata server via the network to execute the scaling-down method of the distributed storage system provided in the embodiments of this disclosure.

[0150] It should be noted that the proxy server, metadata server, scaling server, and storage server can all be hardware or software. When the proxy server, metadata server, scaling server, and storage server are hardware, each type of server can be one or more physical servers, or various servers can be integrated into the same physical server. When the proxy server, metadata server, scaling server, and storage server are software, each type of server can be an independent software module, or various servers can be integrated into the same software module. This disclosure does not impose specific limitations on these aspects.

[0151] It should be understood that Figure 3 The distributed storage system shown includes only illustrative examples of the number of proxy servers, metadata servers, sharding servers, and scaling servers. Depending on implementation needs, a distributed storage system can have any number of proxy servers, metadata servers, sharding servers, and scaling servers.

[0152] See Figure 4 The following provides a detailed description of the interaction process involved in the scaling-down method of the distributed storage system provided in this disclosure embodiment:

[0153] S401, The scaling-down server receives scaling-down requests.

[0154] S402. The scaling-down server sends a metadata retrieval request to the metadata server.

[0155] S403. The metadata server sends a metadata retrieval response to the scaling-down server. This response includes: metadata for the first shard, metadata for the second shard, distribution metadata of the distributed storage system, and a task identifier generated by the metadata server for this scaling-down task.

[0156] S404. The scaling-down server sends a data retrieval request to the standby node of the first shard.

[0157] S405. The standby node of the first shard sends the full data of the data table to be migrated to the scaling-down server.

[0158] S406. The shrinking server migrates all the data of the data table to be migrated to each node included in the second shard.

[0159] S407. Differential synchronization is performed between the master nodes of the first shard and the master nodes of the second shard. This synchronizes the incremental data (excluding the full data) in the data table to be migrated stored on the master node of the first shard to the master nodes of the second shard.

[0160] S408. The scaling-down server sends migration status information to the metadata server, enabling the metadata server to update its own distributed metadata and the distribution metadata stored in the proxy server.

[0161] S409, Shrink server deletes first shard.

[0162] Traditional scaling-down methods require blocking write operations on the affected tables during data migration until the migration is complete. This means users will perceive the data migration process while using the service, thus degrading the user experience.

[0163] In the scaling-down process of this embodiment, the full data of the data table to be migrated is obtained by the scaling-down server from the spare node of the first shard and synchronized to each node of the second shard, without the need for synchronization from the master node of the first shard to the second shard. Therefore, there is no need to block the master and slave nodes of the first shard, meaning the first shard can continue to perform read and write operations, reducing the impact of the full data migration process on the read and write operations of the first shard. Moreover, after the full data synchronization is completed, the master node of the first shard synchronizes the incremental data to the master node of the second shard. Since the amount of incremental data is generally small, the synchronization time is short, thus having a minimal impact on the read and write operations of the first and second shards. Therefore, this embodiment can improve the efficiency and stability of scaling down a distributed storage system and ensure the utilization rate of storage resources.

[0164] See Figure 5 The following describes the complete process of the scaling-down method of the distributed storage system executed by the scaling-down server in this embodiment of the disclosure, combined with practical application scenarios:

[0165] S501. Receive the scaling-down request, obtain the metadata of the first shard, the metadata of the second shard, the distribution metadata of the distributed storage system, and the task identifier generated by the metadata server for this scaling-down task from the metadata server, and obtain the full data of the data table to be migrated from the standby node of the first shard.

[0166] S502. Determine whether the full data of the data table to be migrated has been successfully obtained from the standby node of the first shard. If yes, proceed to S503; otherwise, proceed to S504.

[0167] S503. Migrate all data of the data table to be migrated to each node included in the second shard, and synchronize the incremental data of the data table to be migrated, excluding the full data, stored in the master node of the first shard to the master node included in the second shard.

[0168] S504. Report the scaling failure to the metadata server and delete itself and the data tables to be migrated stored in the second shard.

[0169] S505. Determine whether the second shard has successfully stored the full data and incremental data. If yes, proceed to S506; otherwise, proceed to S504.

[0170] S506. Send migration status information to the metadata server so that the metadata server updates its own and the distribution metadata stored in the proxy server.

[0171] S507. Determine whether the metadata server and each proxy server have successfully modified the distributed metadata. If yes, proceed to S508; otherwise, proceed to S509.

[0172] S508. Delete the first shard and delete the data table to be migrated stored within it.

[0173] S509. Modify the distribution metadata stored in the metadata server and the proxy server to the distribution metadata before the update, delete the data table to be migrated stored in itself, and delete the data table to be migrated stored in each node included in the second shard.

[0174] As can be seen in this embodiment, even if an anomaly occurs during the scaling down process, causing data migration to be interrupted, the steps executed in the scaling down process can be rolled back, thereby returning the scaling down server, the second shard, the metadata server, and the proxy server to their state before scaling down, reducing the impact of scaling down errors on the stability of the distributed storage system.

[0175] The collection, storage, use, processing, transmission, provision, and disclosure of data tables involved in this technical solution comply with relevant laws and regulations and do not violate public order and good morals.

[0176] Based on the same inventive concept, corresponding to the above method embodiments, this disclosure also provides a scaling-down device for a distributed storage system. The distributed storage system includes a first shard and a second shard, each shard including multiple nodes, and the data tables stored on the nodes within the same shard are identical. Figure 6 As shown, the device includes: a receiving module 601, an acquisition module 602, a migration module 603, a recording module 604, and a deletion module 605.

[0177] The receiving module 601 is used to receive a scaling-down request, which requests the migration of the data table to be migrated stored in the first shard to the second shard.

[0178] The acquisition module 602 is used to acquire the full data of the data table to be migrated stored in a node of the first shard;

[0179] Migration module 603 is used to migrate the full data of the data table to be migrated to each node included in the second shard;

[0180] The recording module 604 is used to record the correspondence between the identifier of the data table to be migrated and the identifier of the second shard, and the correspondence indicates that the data table to be migrated is stored in the second shard;

[0181] The deletion module 605 is used to delete the first fragment.

[0182] In some embodiments of this disclosure, the second shard includes a master node and at least one non-master node, and the migration module 603 is specifically used for:

[0183] The entire dataset is migrated to each non-master node included in the second shard.

[0184] Switch the primary node included in the second shard to a non-primary node, and switch one of the non-primary nodes included in the second shard to a primary node;

[0185] The entire dataset will be migrated to the second shard on the master node before the master-slave switchover.

[0186] In some embodiments of this disclosure, the non-master node includes slave nodes and standby nodes, and the migration module 603 is specifically used for:

[0187] Switch the master node included in the second shard to a slave node, and switch one of the slave nodes included in the second shard to a master node.

[0188] In some embodiments of this disclosure, the non-master node is a standby node, and the migration module 603 is specifically used for:

[0189] Switch the primary node included in the second shard to a standby node, and switch one of the standby nodes included in the second shard to a primary node.

[0190] In some embodiments of this disclosure, an inspection module is also included; the inspection module is configured to:

[0191] Before switching the primary node included in the second shard to a non-primary node, check whether each non-primary node included in the second shard has completely stored all the data;

[0192] If any non-master node fails to store all the data completely, and the number of retries for that non-master node has not reached the first preset number, then store all the data back into that non-master node, and increment the number of retries for that non-master node by 1.

[0193] If any non-master node fails to store all data completely, and the number of retries for that non-master node reaches the first preset number, then delete all data stored in each non-master node included in the second shard, and delete all data stored in itself.

[0194] If all non-master nodes in the second shard completely store all the data, then the step of switching the master nodes in the second shard to non-master nodes is executed.

[0195] In some embodiments of this disclosure, each shard includes a master node; the apparatus further includes:

[0196] The synchronization module is used to synchronize incremental data (excluding full data) from the data table to be migrated stored in the first shard to the master nodes included in the second shard before recording the correspondence between the identifier of the data table to be migrated and the identifier of the second shard.

[0197] In some embodiments of this disclosure, the distributed storage system further includes a metadata server; the apparatus also includes:

[0198] The sending module is used to send a metadata retrieval request to the metadata server before recording the correspondence between the identifier of the data table to be migrated and the identifier of the second shard. The metadata retrieval request is used to request the distribution metadata of the distributed storage system. The distribution metadata is used to represent the shard where each data table stored in the distributed storage system is located.

[0199] The receiving module 601 is also used to receive a metadata acquisition response sent by the metadata server, the metadata acquisition response including distributed metadata;

[0200] Recording module 604 is specifically used for:

[0201] In the distribution metadata, update the shard identifier corresponding to the identifier of the data table to be migrated to the identifier of the second shard.

[0202] In some embodiments of this disclosure, the distributed storage system further includes a proxy server; the apparatus also includes:

[0203] The sending module is also used to send migration status information to the metadata server before deleting the first fragment. The migration status information includes the updated distribution metadata information, so that the metadata server modifies the distribution metadata information stored in itself to the updated distribution metadata information and modifies the distribution metadata information stored in the proxy server to the updated distribution metadata information.

[0204] The deletion module is also used to delete the data tables to be migrated stored in itself and the data tables to be migrated stored in each node included in the second shard if it is detected that the metadata server has failed to modify the distributed metadata.

[0205] The modification module is used to modify the distribution metadata stored in the metadata server and the proxy server to the distribution metadata before the update if it is detected that the proxy server has failed to modify the distribution metadata. It also deletes the data tables to be migrated stored in its own storage and deletes the data tables to be migrated stored in each node included in the second shard.

[0206] The calling module is used to call the deletion module to perform the step of deleting the first shard if it is detected that both the metadata server and the proxy server have successfully modified the distribution metadata.

[0207] In some embodiments of this disclosure, the migration status information further includes a task identifier extracted from the metadata acquisition response, wherein the task identifier is an identifier generated by the metadata server for this scaling-down task; the apparatus further includes a determining module, which is used to:

[0208] After sending migration status information to the metadata server, if a modification failure message is received from the metadata server, it is determined that the metadata server has failed to modify the distribution metadata. The scaling failure message is sent by the metadata server when it checks that the task identifier included in the migration status information is different from the task identifier it generated, indicating that the modification of the distribution metadata has failed.

[0209] If a modification success message is received from the metadata server, or if no scaling down failure message is received within a preset time after sending the migration status information, it is determined that the metadata server has successfully modified the distribution metadata information. The scaling down success message is sent by the metadata server when it checks that the task identifier included in the migration status information is the same as the task identifier it generated, indicating that the modification of the distribution metadata information was successful.

[0210] In some embodiments of this disclosure, there are multiple proxy servers; the apparatus further includes a verification module, which is used to:

[0211] After sending migration status information to the metadata server, a consistency check is performed on the distributed metadata stored on each proxy server.

[0212] If the consistency check fails, it is determined that each proxy server has failed to modify the distributed metadata.

[0213] If the consistency check passes, it is determined that each proxy server has successfully modified the distribution metadata.

[0214] In some embodiments of this disclosure, the apparatus further includes a determination module, which is configured to:

[0215] Before determining that each proxy server has failed to modify the distributed metadata, identify the proxy servers that have failed to modify and need to be retried, and determine whether the number of retries for the proxy servers to be retried has reached the second preset number.

[0216] If yes, the verification module is invoked to determine if each proxy server failed to modify the distribution metadata. If no, the distribution metadata stored in the proxy server to be retried is modified to the updated distribution metadata, and the retry count for the proxy server to be retried is incremented by 1.

[0217] In some embodiments of this disclosure, the apparatus further includes an inspection module and a detection module, for:

[0218] Before acquiring the full data of the data table to be migrated stored in a node of the first shard, check whether the preset shrinkage conditions are met. The preset shrinkage conditions include: the available storage space of the second shard is greater than the product of the used storage space of the first shard and a preset multiple, and the preset multiple is greater than 1.

[0219] If the check passes, the acquisition module is invoked to retrieve the full data of the data table to be migrated stored in one node of the first shard.

[0220] In some embodiments of this disclosure, the distributed storage system further includes a metadata server; the apparatus also includes:

[0221] The sending module is used to send a fragment information retrieval request to the metadata server before checking whether the preset scaling conditions are met. The fragment information retrieval request is used to request the metadata of the first fragment and the metadata of the second fragment.

[0222] The receiving module 601 is also used to receive a fragment information acquisition response sent by the metadata server. The fragment information acquisition response includes metadata of the first fragment and metadata of the second fragment, wherein the fragment metadata includes used storage space and available storage space.

[0223] In some embodiments of this disclosure, the preset scaling-down condition further includes: there are currently no other scaling-down tasks in the distributed storage system.

[0224] According to embodiments of this disclosure, this disclosure also provides an electronic device, a readable storage medium, and a computer program product.

[0225] Figure 7A schematic block diagram of an example electronic device 700 that can be used to implement embodiments of the present disclosure is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device may also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the present disclosure described and / or claimed herein.

[0226] like Figure 7 As shown, the electronic device 700 includes a computing unit 701, which can perform various appropriate actions and processes based on a computer program stored in a read-only memory (ROM) 702 or a computer program loaded from a storage unit 708 into a random access memory (RAM) 703. The RAM 703 may also store various programs and data required for the operation of the electronic device 700. The computing unit 701, ROM 702, and RAM 703 are interconnected via a bus 704. An input / output (I / O) interface 705 is also connected to the bus 704.

[0227] Multiple components in electronic device 700 are connected to I / O interface 705, including: input unit 706, such as keyboard, mouse, etc.; output unit 707, such as various types of displays, speakers, etc.; storage unit 708, such as disk, optical disk, etc.; and communication unit 709, such as network card, modem, wireless transceiver, etc. Communication unit 709 allows electronic device 700 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0228] The computing unit 701 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 701 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 701 performs the various methods and processes described above, such as the scaling-down method of a distributed storage system. For example, in some embodiments, the scaling-down method of a distributed storage system can be implemented as a computer software program tangibly contained in a machine-readable medium, such as storage unit 708. In some embodiments, part or all of the computer program can be loaded and / or installed on the electronic device 700 via ROM 702 and / or communication unit 709. When the computer program is loaded into RAM 703 and executed by the computing unit 701, one or more steps of the scaling-down method of the distributed storage system described above can be performed. Alternatively, in other embodiments, the computing unit 701 can be configured to perform the scaling-down method of the distributed storage system by any other suitable means (e.g., by means of firmware).

[0229] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), complex programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0230] The program code used to implement the methods of this disclosure may be written in any combination of one or more programming languages. This program code may be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus, such that when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may be executed entirely on a machine, partially on a machine, as a standalone software package partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0231] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0232] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device for displaying information to the user (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor); and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0233] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as a data server), or computing systems that include middleware components (e.g., an application server), or computing systems that include frontend components (e.g., a user computer with a graphical user interface or web browser through which a user can interact with embodiments of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., a communication network). Examples of communication networks include local area networks (LANs), wide area networks (WANs), and the Internet.

[0234] Computer systems can include clients and servers. Clients and servers are generally located far apart and typically interact via communication networks. Client-server relationships are created by computer programs running on the respective computers and having a client-server relationship with each other. Servers can be cloud servers, servers in distributed systems, or servers incorporating blockchain technology.

[0235] It should be understood that the various forms of processes shown above can be used to rearrange, add, or delete steps. For example, the steps described in this disclosure can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution disclosed in this disclosure can be achieved, and this is not limited herein.

[0236] The specific embodiments described above do not constitute a limitation on the scope of protection of this disclosure. 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 disclosure should be included within the scope of protection of this disclosure.

Claims

1. A method for scaling down a distributed storage system, the distributed storage system comprising a first shard, a second shard, and a metadata server, each shard comprising multiple nodes, and the data tables stored on the nodes within the same shard being identical; The method is applied to a scaling-down server, and the method includes: Receive a scaling-down request, the scaling-down request being used to request the migration of the data table to be migrated stored in the first shard to the second shard; Obtain the full data of the data table to be migrated stored in one node of the first shard; The full data of the data table to be migrated is migrated to each node included in the second shard; Send a metadata retrieval request to the metadata server. The metadata retrieval request is used to request the distribution metadata of the distributed storage system. The distribution metadata is used to represent the shard where each data table stored in the distributed storage system is located. Receive the metadata information retrieval response sent by the metadata server, wherein the metadata information retrieval response includes the distributed metadata; In the distribution metadata, the shard identifier corresponding to the identifier of the data table to be migrated is updated to the identifier of the second shard, and the correspondence indicates that the data table to be migrated is stored in the second shard; Delete the first fragment.

2. The method according to claim 1, wherein, The second shard includes one primary node and at least one non-primary node. The step of migrating all data from the data table to be migrated to each node in the second shard includes: The full data is then migrated to each non-master node included in the second shard; The master node included in the second shard is switched to a non-master node, and one of the non-master nodes included in the second shard is switched to a master node; The full data is migrated to the master node of the second shard before the master-slave switch.

3. The method according to claim 2, wherein, The non-master nodes include slave nodes and standby nodes. The step of switching the master node included in the second shard to a non-master node, and switching one of the non-master nodes included in the second shard to a master node, includes: Switch the master node included in the second shard to a slave node, and switch one of the slave nodes included in the second shard to a master node.

4. The method according to claim 2, wherein, The non-master node is a standby node. The step of switching the master node included in the second shard to a non-master node, and switching one of the non-master nodes included in the second shard to a master node, includes: The primary node included in the second shard is switched to a standby node, and one of the standby nodes included in the second shard is switched to a primary node.

5. The method according to any one of claims 2-4, further comprising, before switching the master node included in the second shard to a non-master node: Check whether each non-master node included in the second shard completely stores the full amount of data; If any non-master node fails to store the full data completely, and the number of retries for that non-master node has not reached the first preset number, then the full data is stored again in that non-master node, and the number of retries for that non-master node is incremented by 1. If any non-master node fails to store the full data completely, and the number of retries for that non-master node reaches the first preset number, then delete the full data stored in each of the non-master nodes included in the second shard, and delete the full data stored in itself. If all non-master nodes included in the second shard completely store the full amount of data, then the step of switching the master nodes included in the second shard to non-master nodes is executed.

6. The method according to claim 1, wherein each shard includes a master node; and before recording the correspondence between the identifier of the data table to be migrated and the identifier of the second shard, further comprising: Incremental data other than the full data stored in the data table to be migrated in the first shard are synchronized to the master nodes included in the second shard.

7. The method according to claim 1, wherein the distributed storage system further includes a proxy server; and before deleting the first shard, it further includes: Send migration status information to the metadata server, the migration status information including updated distribution metadata, so that the metadata server modifies the distribution metadata stored in itself to the updated distribution metadata, and modifies the distribution metadata stored in the proxy server to the updated distribution metadata. If it is detected that the metadata server has failed to modify the distributed metadata, the data table to be migrated stored in the server itself is deleted, and the data table to be migrated stored in each node of the second shard is also deleted. If it is detected that the proxy server has failed to modify the distribution metadata, then the distribution metadata stored in the metadata server and the proxy server will be modified to the distribution metadata before the update, the data table to be migrated stored in itself will be deleted, and the data table to be migrated stored in each node included in the second shard will be deleted. If it is detected that both the metadata server and the proxy server have successfully modified the distribution metadata, then the step of deleting the first shard is executed.

8. The method according to claim 7, wherein the migration status information further includes a task identifier extracted from the metadata acquisition response, the task identifier being an identifier generated by the metadata server for this scaling-down task; After sending the migration status information to the metadata server, the process further includes: If a modification failure message is received from the metadata server, it is determined that the metadata server has failed to modify the distribution metadata. The scaling failure message is a message sent by the metadata server when it checks that the task identifier included in the migration status information is different from the task identifier it generated, indicating that the modification of the distribution metadata has failed. If a modification success message is received from the metadata server, or if the scaling down failure message is not received within a preset time after sending the migration status information, it is determined that the metadata server has successfully modified the distribution metadata information. The scaling down success message is a message sent by the metadata server indicating that the modification of the distribution metadata information is successful when the task identifier included in the migration status information is the same as the task identifier it generated.

9. The method according to claim 7, wherein there are multiple proxy servers; after sending migration status information to the metadata server, it further includes: Perform consistency verification on the distributed metadata stored on each proxy server; If the consistency check fails, it is determined that each proxy server has failed to modify the distributed metadata. If the consistency check passes, it is determined that each proxy server has successfully modified the distribution metadata.

10. The method according to claim 9, further comprising, before determining that each proxy server has failed to modify the distribution metadata: Identify the proxy server that failed to be modified and needs to be retried, and determine whether the number of retries for the proxy server has reached the second preset number; If so, then proceed with the steps described above to determine if each proxy server has failed to modify the distribution metadata. If not, the distribution metadata stored in the proxy server to be retried is modified to the updated distribution metadata, and the number of retries to the proxy server to be retried is incremented by 1.

11. The method according to claim 1, further comprising, before obtaining the full data of the data table to be migrated stored in a node of the first shard: Check whether the preset shrinkage conditions are met. The preset shrinkage conditions include: the available storage space of the second shard is greater than the product of the used storage space of the first shard and a preset multiple, wherein the preset multiple is greater than 1. If the check passes, proceed with the step of obtaining the full data of the data table to be migrated stored in one node of the first shard.

12. The method according to claim 11, wherein the distributed storage system further comprises a metadata server; Before checking whether the preset reduction conditions are met, the method further includes: A shard information retrieval request is sent to the metadata server. The shard information retrieval request is used to request the metadata of the first shard and the metadata of the second shard. The metadata of the shard includes used storage space and available storage space. The system receives a sharding information retrieval response sent by the metadata server. The sharding information retrieval response includes the metadata of the first shard and the metadata of the second shard.

13. The method according to claim 11 or 12, wherein, The preset scaling-down condition also includes: there are currently no other scaling-down tasks in the distributed storage system.

14. A scaling-down device for a distributed storage system, the distributed storage system comprising a first shard, a second shard, and a metadata server, each shard comprising multiple nodes, and the data tables stored on the nodes within the same shard being identical; The device is used in a scaling-down server, and the device includes: A receiving module is used to receive a scaling-down request, wherein the scaling-down request is used to request the migration of the data table to be migrated stored in the first shard to the second shard; The acquisition module is used to acquire the full data of the data table to be migrated stored in one node of the first shard; The migration module is used to migrate the full data of the data table to be migrated to each node included in the second shard; The sending module is used to send a metadata information acquisition request to the metadata server. The metadata information acquisition request is used to request the acquisition of the distribution metadata of the distributed storage system. The distribution metadata is used to represent the shard where each data table stored in the distributed storage system is located. The receiving module is further configured to receive a metadata acquisition response sent by the metadata server, the metadata acquisition response including the distributed metadata; The recording module is used to update the shard identifier corresponding to the identifier of the data table to be migrated in the distribution metadata to the identifier of the second shard, and the correspondence indicates that the data table to be migrated is stored in the second shard; The deletion module is used to delete the first fragment.

15. The apparatus according to claim 14, wherein, The second shard includes one master node and at least one non-master node, and the migration module is specifically used for: The full data is then migrated to each non-master node included in the second shard; The master node included in the second shard is switched to a non-master node, and one of the non-master nodes included in the second shard is switched to a master node; The full data is migrated to the master node of the second shard before the master-slave switch.

16. The apparatus according to claim 15, wherein, The non-master node includes slave nodes and standby nodes, and the migration module is specifically used for: Switch the master node included in the second shard to a slave node, and switch one of the slave nodes included in the second shard to a master node.

17. The apparatus according to claim 15, wherein, The non-master node is a standby node, and the migration module is specifically used for: The primary node included in the second shard is switched to a standby node, and one of the standby nodes included in the second shard is switched to a primary node.

18. The apparatus according to any one of claims 15-17, further comprising an inspection module; the inspection module being configured to: Before switching the master node included in the second shard to a non-master node, check whether each non-master node included in the second shard has completely stored the full amount of data; If any non-master node fails to store the full data completely, and the number of retries for that non-master node has not reached the first preset number, then the full data is stored again in that non-master node, and the number of retries for that non-master node is incremented by 1. If any non-master node fails to store the full data completely, and the number of retries for that non-master node reaches the first preset number, then delete the full data stored in each of the non-master nodes included in the second shard, and delete the full data stored in itself. If all non-master nodes included in the second shard completely store the full amount of data, then the step of switching the master nodes included in the second shard to non-master nodes is executed.

19. The apparatus of claim 14, wherein each shard includes a master node; the apparatus further includes: The synchronization module is used to synchronize the incremental data (excluding the full data) in the data table to be migrated stored in the first shard to the master node included in the second shard before recording the correspondence between the identifier of the data table to be migrated and the identifier of the second shard.

20. The apparatus of claim 14, wherein the distributed storage system further comprises a proxy server; the apparatus further comprises: The sending module is further configured to send migration status information to the metadata server before deleting the first fragment. The migration status information includes updated distribution metadata, so that the metadata server modifies the distribution metadata stored in itself to the updated distribution metadata and modifies the distribution metadata stored in the proxy server to the updated distribution metadata. The deletion module is further configured to delete the data table to be migrated stored in itself and delete the data table to be migrated stored in each node included in the second shard if it is detected that the metadata server has failed to modify the distributed metadata. The modification module is used to modify the distribution metadata stored in the metadata server and the proxy server to the distribution metadata before the update if it is detected that the proxy server has failed to modify the distribution metadata. It also deletes the data table to be migrated stored in its own storage and deletes the data table to be migrated stored in each node included in the second shard. The calling module is used to call the deletion module to execute the step of deleting the first shard if it is detected that both the metadata server and the proxy server have successfully modified the distribution metadata.

21. The apparatus according to claim 20, wherein the migration status information further includes a task identifier extracted from the metadata acquisition response, the task identifier being an identifier generated by the metadata server for this scaling-down task; the apparatus further includes a determining module, the determining module being configured to: After sending migration status information to the metadata server, if a modification failure message is received from the metadata server, it is determined that the metadata server's modification of the distribution metadata was unsuccessful. The scaling down failure message is a message sent by the metadata server when it checks that the task identifier included in the migration status information is different from the task identifier it generated, indicating that the modification of the distribution metadata has failed. If a modification success message is received from the metadata server, or if the scaling down failure message is not received within a preset time after sending the migration status information, it is determined that the metadata server has successfully modified the distribution metadata information. The scaling down success message is a message sent by the metadata server indicating that the modification of the distribution metadata information is successful when the task identifier included in the migration status information is the same as the task identifier it generated.

22. The apparatus according to claim 20, wherein there are multiple proxy servers; the apparatus further includes a verification module, the verification module being configured to: After sending migration status information to the metadata server, a consistency check is performed on the distributed metadata stored by each proxy server. If the consistency check fails, it is determined that each proxy server has failed to modify the distributed metadata. If the consistency check passes, it is determined that each proxy server has successfully modified the distribution metadata.

23. The apparatus according to claim 22, further comprising a determining module, the determining module being configured to: Before determining that each proxy server has failed to modify the distribution metadata, identify the proxy servers that have failed to modify and need to be retried, and determine whether the number of retries for the proxy servers to be retried has reached the second preset number; If so, the verification module is invoked to perform the step of determining that each proxy server failed to modify the distributed metadata. If not, the distribution metadata stored in the proxy server to be retried is modified to the updated distribution metadata, and the number of retries to the proxy server to be retried is incremented by 1.

24. The apparatus of claim 14, further comprising an inspection module, the inspection module being configured to: Before obtaining the full data of the data table to be migrated stored in one node of the first shard, it is checked whether a preset scaling-down condition is met. The preset scaling-down condition includes: The available storage space of the second fragment is greater than the product of the used storage space of the first fragment and a preset multiple, wherein the preset multiple is greater than 1; If the check passes, the acquisition module is invoked to perform the step of acquiring the full data of the data table to be migrated stored in one node of the first shard.

25. The apparatus of claim 24, wherein the distributed storage system further comprises a metadata server; the apparatus further comprises: The sending module is used to send a fragment information acquisition request to the metadata server before checking whether the preset scaling-down conditions are met. The fragment information acquisition request is used to request the acquisition of the metadata of the first fragment and the metadata of the second fragment. The receiving module is further configured to receive a fragment information acquisition response sent by the metadata server. The fragment information acquisition response includes the metadata of the first fragment and the metadata of the second fragment, wherein the fragment metadata includes used storage space and available storage space.

26. The apparatus according to claim 24 or 25, wherein, The preset scaling-down condition also includes: there are currently no other scaling-down tasks in the distributed storage system.

27. An electronic device comprising: At least one processor; as well as A memory communicatively connected to the at least one processor; wherein, The memory stores instructions executable by the at least one processor, which, when executed by the at least one processor, enables the at least one processor to perform the method of any one of claims 1-13.

28. A non-transitory computer-readable storage medium storing computer instructions, wherein, The computer instructions are used to cause the computer to perform the method according to any one of claims 1-13.

29. A computer program product comprising a computer program that, when executed by a processor, implements the method according to any one of claims 1-13.

Images