Data access method, cloud service system and device

By acquiring and outputting cross-region write progress information and configuring response time and high availability in the data access method, the problem of data loss caused by failure during data storage is solved, and efficient and reliable cross-region data access and storage are achieved.

CN122309606APending Publication Date: 2026-06-30HUAWEI TECH CO LTD

Patent Information

Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
HUAWEI TECH CO LTD
Filing Date
2024-12-28
Publication Date
2026-06-30

AI Technical Summary

Technical Problem

Existing data access methods are prone to data loss during data storage due to equipment failure, user misoperation, natural disasters, or hacker attacks, making reliable cross-regional data access impossible.

Method used

After receiving a data write request in the first database system, the system obtains and outputs a response result including write progress information for the first and second regions, thereby enabling cross-regional data access. Furthermore, by configuring preset response duration and high availability, the system optimizes the processing of data write requests, reducing response latency and computational overhead.

Benefits of technology

It improves the flexibility and reliability of data access, reduces client response latency and business interruption, ensures high availability and disaster recovery of data, and enhances the efficiency of data recovery and the reliability of storage.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN122309606A_ABST
    Figure CN122309606A_ABST
Patent Text Reader

Abstract

This application provides a data access method, cloud service system, and device. The method includes: a first database system receiving a first data write request; the first database system writing first data based on the first data write request and obtaining first write progress information for a first region; the first database system sending the first data to a second database system; the first database system obtaining second write progress information for a second region; and the first database system outputting a first response result to the first data write request, the first response result including the first write progress information for the first region and the second write progress information for the second region. For example, the first database system can output the first response result to the client that sent the data write request. This allows the client to obtain the write progress of the first data in different regions based on the response result, thereby facilitating cross-regional data access and enabling global business operations.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This application relates to the field of cloud computing technology, and in particular to a data access method, cloud service system and device. Background Technology

[0002] In today's digital age, massive amounts of data are generated. This data can be stored on physical servers or cloud servers for clients to access according to their business needs. However, this stored data may be lost due to equipment failure, user error, natural disasters, hacker attacks, or other reasons, thus preventing clients from accessing the data.

[0003] To avoid unreliable data access due to data loss, backups of the data can be performed simultaneously when accessing data (e.g., writing data) to physical or cloud servers. In related technologies, data backup can be achieved through synchronous or asynchronous replication during data access; however, current data access methods are not conducive to efficient data processing. Summary of the Invention

[0004] This application provides a data access method, cloud service system, and device. The response result output by a client in a first region for a data access request can include not only the writing progress information of the first data in the first region where the data access request is located, but also the writing progress information of the first data in a second region outside the first region, which facilitates cross-regional data access and is beneficial for carrying out global business.

[0005] Firstly, this application provides a data access method. This method can be applied to a cloud service system, which may include a cloud management platform and multiple database systems. The multiple database systems include a first database system and a second database system. The cloud management platform is used to manage the infrastructure providing cloud services. This infrastructure deploys one or more database instances included in the first database system and one or more database instances included in the second database system. The first database system is located in a first region, and the second database system is located in a second region.

[0006] The method includes: a first database system receiving a first data write request, the first data write request indicating first data to be written; the first database system writing the first data based on the first data write request and obtaining first write progress information for a first region, the first write progress information indicating the write progress of the first data in the first region; the first database system sending the first data to a second database system; the first database system obtaining second write progress information for a second region, the second write progress information indicating the write progress of the first data in the second region; and the first database system outputting a first response result for the first data write request, the first response result including the first write progress information for the first region and the second write progress information for the second region.

[0007] In one possible implementation, this data access method can also be applied to physical devices under the cloud.

[0008] This data access method may involve multiple regions for implementing data access, meaning that each region can independently implement data access. For example, the multiple regions may include a first region and a second region. In one possible implementation, the number of second regions may be N, where N is a positive integer.

[0009] The first data is the data to be persistently stored, such as data to be written. For example, the first data could be data to be written to a storage node or storage system.

[0010] The first database system can receive the first data write request.

[0011] The first area can be used to respond to a first data write request and write the first data. The second area is used to back up and store the first data written in the first area. When there are multiple second areas, each second area can be used to store a copy of the first data. In this way, the first data can be stored in the first area and also in multiple second areas, thereby realizing cross-area storage of data and ensuring high availability of data.

[0012] For example, in a cloud scenario, the aforementioned areas (such as the first or second area) can be regions or availability zones.

[0013] For example, in a cloud scenario, a region may include multiple servers within at least one data center. Servers may include compute nodes and storage nodes.

[0014] For example, in scenarios outside of cloud environments, a region can be a data center (DC) located within a physical region.

[0015] In one possible implementation, the first write progress information includes at least one of the following: information indicating that first data has been received; information indicating that first data has been written; information indicating that access to the first data is supported. Similarly, the second write progress information includes at least one of the following: information indicating that first data has been received; information indicating that first data has been written; information indicating that access to the first data is supported.

[0016] In related technologies, the main engine of a primary site can only return a single response to a client's data write request, and this response only indicates whether the data access was successful on the primary site side, preventing clients from accessing services across regions. However, in the method provided in this application, the response output by the first database system to a data write request (here, a data write request) for a first region can include not only the write progress information of the first region receiving the data write request, but also the write progress information of the first data for the second region. For example, the first database system can send a first response to the client that sent the data write request. This allows the client to obtain the write progress of the first data for different regions based on the first response, determining which region to forward subsequent data write requests to, facilitating cross-regional data access and enabling global business operations.

[0017] In one possible implementation, the method further includes: a first database system acquiring first information, the first information being used to indicate the response duration of a first data write request; the first database system, starting from the moment it receives the first data write request, outputting a second response result to the first data write request within the response duration, the second response result including first write progress information, the first write progress information including information indicating that a first area has supported access to the first data.

[0018] In the data access method provided in this application, the first data access request can carry first information. This allows the first database system to obtain the first information based on the first data write request, and subsequently, the response duration of the first data write request. Thus, the device sending the first data write request (e.g., a client) can flexibly set the response duration for this data access based on the service corresponding to the request. This enables the first database system to provide a timely response to different data write requests within the response duration indicated by the first information carried in the data write request, thereby improving the flexibility of data access.

[0019] For example, when the response duration is determined by the client, the response durations for different data write requests can be the same or different. This application does not impose a specific limit on the size of the response duration.

[0020] The first information can also be a database system pre-configured in different regions to respond to data write requests, such as a node or virtual instance within the database system. When the cloud service system includes a cloud management platform, the first information can also be pre-configured on the cloud management platform, and the cloud management platform can send the first information to the database system so that the database system can obtain it.

[0021] This application does not restrict whether the response time indicated by the first information pre-configured in different regions is the same.

[0022] In this way, by presetting the first information, the response duration indicated by the first information can be preset. In the method provided by this application, the first database system can respond to different data write requests received according to the uniformly preset response duration, without having to extract the first information from the data write request to obtain the response duration corresponding to the data write request. This can reduce the computational overhead of the method provided by this application, improve the response speed of the data write request, and effectively reduce the response latency of the data write request, thereby reducing the latency of the client.

[0023] In the method provided in this application, the first database system, starting from the moment it receives the first data write request, can output a second response result within the response duration indicated by the first information. This ensures that the client, starting from the moment it sends the first data write request, can receive the second response result within the response duration indicated by the first information. The second response result includes the response result of at least one database system, for example, a database system located in the same region as the client (e.g., the first region). Thus, even if the database system in another region (e.g., the second region) used to process the first data write request fails, and / or the communication link between database systems in different regions fails, the timely response to the first data write request will not be affected. This reduces the response latency to the first data write request in fault scenarios, allowing the client to receive the response result promptly and reducing client service interruptions. The client can then decide whether to issue subsequent data write requests based on the received response result, thereby avoiding interruptions between multiple services corresponding to a single client.

[0024] In one possible implementation, the method further includes: a first database system acquiring second information, the second information indicating the minimum number of regions N+1 for writing the first data in response to a first data write request, where N is an integer greater than or equal to 1; the first database system sending the first data to N second database systems; each of the N second database systems writing the first data based on the first data sent by the first database system and sending second write progress information to the first database system; and the first database system acquiring the second write progress information of the N second database systems for the first data.

[0025] Among them, the N+1 regions may include the first region and N second regions.

[0026] In the data access method provided in this application, the first data write request can carry second information, which can be used to indicate the high availability corresponding to the first data write request. In this way, the device sending the first data write request (e.g., a client) can flexibly determine the minimum number of backups required for the first data in the request based on the service corresponding to the request, thereby flexibly setting the high availability corresponding to the data write request. This allows the first database system, when responding to different data write requests, to output a second response result based on the high availability indicated by the second information carried in the data write request, when the number of backups of the first data in the request has met the high availability requirement, without waiting for all data backups to complete. This reduces client response latency while meeting the backup requirements of the data write request.

[0027] The high availability corresponding to different data write requests can be the same or different. In this application, the high availability is an integer greater than or equal to 1.

[0028] The second information can also be a database system pre-configured in different regions to write corresponding data in response to data write requests; for example, it can be a node or virtual instance configured to the database system. When the cloud service system includes a cloud management platform, the second information can also be pre-configured to the cloud management platform, and the cloud management platform can send the second information to the database system so that the database system can obtain the second information.

[0029] This application does not impose any restrictions on whether the high availability corresponding to the pre-configured second information in different regions is the same.

[0030] In this way, by presetting the second information, the high availability indicated by the second information can be preset. In the method provided by this application, the first database system can write the data corresponding to different data write requests according to the unified high availability for different data write requests, without having to extract the second information from the data write request to obtain the high availability corresponding to the data write request. This can reduce the computational overhead of the method provided by this application, improve the response speed of the data write request, and effectively reduce the response latency of the data write request, thereby reducing the latency of the client.

[0031] In the method provided in this application, the first database system can output the first response result after backing up the first data to the number of copies corresponding to the high availability (e.g., the number mentioned above) according to the high availability requirements of each data access. This ensures the disaster recovery of the data while meeting the data backup requirements of the business and reducing the response latency of the client.

[0032] In one possible implementation, before the first database system outputs a first response result to the first data write request, the method further includes: the first database system receiving a second data write request, wherein the second data write request and the first data write request are data write requests processed in the same batch by the first database system, the response order of the second data write request precedes the response order of the first data write request, and the second data write request is used to indicate the second data to be written; the first database system sending the second data to the second database system; the first database system obtaining third write progress information of the second region, the third write progress information being used to indicate the write progress of the second region for the second data corresponding to the most recently responded second data write request; and the first database system outputting a third response result to the first data write request, the third response result including the first write progress information and the third write progress information.

[0033] When a second data write request indicates that data should be written, then the second data write request can be named a second data write request.

[0034] The third write progress information may include at least one of the following: information indicating that the second data has been received; information indicating that the second data has been written; information indicating that access to the second data has been supported.

[0035] The third write progress information is similar to the second write progress information of the second region mentioned above. The difference is that the third write progress information is the write progress of the second region on the second data, while the second write progress information is the write progress of the second region on the first data.

[0036] In this possible implementation, the first database system already supports access to the second data, and the second database system's most recent write data is the second data. Therefore, the write progress of the second data in the second region could be that it has been persisted, access is now supported, or the second data has been received. Meanwhile, the first database system has persisted and supports access to the second data, and is further writing to the first data; that is, the first database system's write progress for a batch of data write requests is faster than the second database system's. Therefore, the third response result could include the first region's first write progress information for the first data, and the second region's third write progress information for the second data.

[0037] In the method provided in this application, the first database system can obtain write progress information from each database system in different regions, indicating the most recently successfully responded data write request, and then output the response result. In this way, the client can obtain write progress information from the database systems of at least two regions (the first region and at least one second region), indicating the most recently successfully responded data write request. Thus, the client can decide whether to issue the next transaction based on the received write progress information; for example, the client can issue the next transaction after receiving the write progress information from the database system in the first region. Furthermore, if the database system in the first region fails, the client in the first region can select the database system in the region with the latest write progress information to execute subsequent data write requests, thereby minimizing client response latency. Alternatively, the client can flexibly select a suitable database system to execute subsequent data write requests by combining write progress information, database system failure status, business requirements, proximity principles, etc. In addition, if a data write request in the current region fails, the client can flexibly select a suitable region based on the received write progress information and quickly route the data write request to that region for execution, thereby minimizing continuous business errors.

[0038] When the aforementioned client routes data write requests to other regions for execution, load balancing can be used to distribute the traffic, ensuring that the database system in each region has good overall processing efficiency.

[0039] In one possible implementation, the method further includes: a first database system obtaining synchronization delay information of a second region based on first write progress information of a first region and third write progress information of a second region, wherein the synchronization delay information is used to indicate the time required for the data stored in the second region to be synchronized with the data stored in the first region; and the first database system outputting a fourth response result for the first data write request, wherein the fourth response result includes the synchronization delay information of the second region.

[0040] In the method provided in this application, the response result of the data write request output by the first database system may further include synchronization delay information with a second region, which is used to store data copies of the first region. This allows the client to obtain the synchronization delay information of the second region. For a given second region, the client can determine the time required for the data stored in that second region to be synchronized to the data stored in the first region based on the synchronization delay information. Thus, after a certain period, the client can identify which second regions have synchronized their stored data to the data stored in the first region, and can then, based on business needs or in the event of a database system failure in the first region, selectively choose a second region that has completed data synchronization to execute subsequent data write requests, based on proximity.

[0041] In addition, if the client does not wait for at least one second region to complete the synchronization of stored data, it can select the second region with the smallest recovery time objective (RTO) (the smallest difference between the data stored in the first region) to execute the subsequent data write request when the read operation corresponds to the subsequent data write request, based on the write progress information or synchronization delay information. This can increase the probability that the subsequent data write request will successfully read the required data, and thus increase the probability that the subsequent data write request will be executed successfully.

[0042] In one possible implementation, the method further includes: a first database system determining third data to be synchronized from the first region to the second region based on first write progress information of the first region and third write progress information of the second region; and the first database system sending the third data to the second database system.

[0043] In this application, during or after the first database system responds to a first data write request, at least one second database system in a second region may fail, or the transmission link between the second database system and the first database system may fail, resulting in the first data (data written based on the data write request) not being synchronously written from the first region to the second database system in the second region, thus the second region does not store a data copy of the first data. After the database system in the second region repairs the fault, or after the aforementioned transmission link failure is resolved, the method of this application can send a copy of the data (third data) that is not backed up in the second region compared to the first region to the second database system, ensuring that the data stored between the database systems of the first and second regions is consistent, thereby meeting high availability requirements.

[0044] In related technologies, during the process of synchronizing data from the master site to the slave site, if the slave site fails, there is a certain time delay between the failure of the slave site and the detection of the failure by the master engine. The master engine can only return the response result of the data write request to the client after detecting the failure. Therefore, if the slave site fails during the data synchronization process, it will cause the client's business on the master site to experience a delay of seconds or even minutes, affecting business performance.

[0045] In the method provided in this application, after the database system in the second region recovers from a failure, the first database system can determine the missing data copy (third data) in the second region compared to the first region based on the first write progress information of the first region and the third write progress information of the second region. Therefore, when performing data recovery on the second region, it is not necessary to clear the stored data in the database system of the second region (such as the second database system itself). Instead, the first database system can synchronize the missing data copy from the first database system to the second database system to achieve incremental data recovery. Compared to the full data recovery methods in related technologies, the method provided in this application requires a smaller amount of data to be recovered after the database system in the second region has recovered from the failure, thereby improving the efficiency of data recovery and shortening the data recovery time.

[0046] In one possible implementation, the first database system includes a first storage device on a first region where the first database system is located, and the second database system includes a second storage device on a second region where the second database system is located. The first database system writes first data based on a first data write request, including: the first database system writes the first data to the first storage device based on the first data write request; the first database system sends the first data to the second database system, including: the first storage device sends the first data to the second storage device.

[0047] Unlike related technologies that synchronize stored data through a server (e.g., a master server and a slave server), the method provided in this application, after writing the first data to a first storage device based on a first database system, can send the first data to a second storage device located in a different region through the first storage device. In related technologies, when synchronizing data through a server, the synchronized data may be, for example, database operations related to the first data. These database operations involve data encapsulation and have a large data volume. However, in this embodiment, the data synchronized on the storage side (e.g., the first storage device and the second storage device) is the data actually stored on the storage device side (e.g., the first data). Thus, the synchronized data does not involve data encapsulation, has a smaller data volume, thereby reducing the data synchronization time, and consequently reducing the response latency to the first data write request and the response latency to the client that sent the first data write request.

[0048] Furthermore, the method provided in this application, to prevent the loss of data stored in the first storage device (e.g., the first data itself) due to a failure of the first storage device, allows the first data to be synchronously written to the second storage device after it has been written to the first storage device, ensuring backup storage. In this way, when the first database system outputs a response, the first data has already been persistently stored in the second storage device, thereby guaranteeing reliable storage of data on both the first and second storage devices and achieving high data availability.

[0049] In one possible implementation, the method further includes: the cloud management platform receiving a first data write request; the cloud management platform sending the first data write request to a first database system; the cloud management platform receiving a first response result output by the first database system; and the cloud management platform outputting the first response result.

[0050] In the method provided in this application, the cloud management platform can serve as a communication interface between the upper layer (e.g., the client) and the database system. This allows the client to interact with the database system through the cloud management platform, thereby enabling the issuance of data write requests and the acquisition of response results. Compared to the client directly operating the database system, this reduces operational complexity. Furthermore, the cloud management platform allows for comprehensive monitoring of the database system, such as request tracing and logging, facilitating problem diagnosis and system optimization.

[0051] Secondly, this application provides another data access method that can be applied to a cloud management platform. The cloud management platform is used to manage the infrastructure that provides cloud services. The infrastructure is deployed with one or more database instances including a first database system and one or more database instances including a second database system. The second database system is located in a second region and is used to back up and store data written to the first database system located in the first region.

[0052] The method includes: a cloud management platform receiving a first data write request, the first data write request indicating first data to be written to a first region; the cloud management platform notifying a first database system located in the first region to write the first data based on the first data write request; the cloud management platform receiving first write progress information of the first region and second write progress information of a second region, the first write progress information indicating the write progress of the first data in the first region and the second write progress information indicating the write progress of the first data in the second region; and the cloud management platform outputting a first response result to the first data write request, the first response result including the first write progress information and the second write progress information.

[0053] In one possible implementation, the method further includes: a cloud management platform acquiring first information, and second information used to indicate the response duration of the first data write request; the cloud management platform, starting from the moment it receives the first data write request, outputs a second response result to the first data write request within the response duration, the second response result including first write progress information, the first write progress information including information indicating that the first area has supported access to the first data.

[0054] In one possible implementation, the method further includes: a cloud management platform obtaining second information, the second information indicating the minimum number of regions N+1 for writing the first data in response to the first data write request; and the cloud management platform, based on the second information, notifying the first database system to send the written first data to N second database systems in N second regions, where N is a positive integer.

[0055] In one possible implementation, before the cloud management platform outputs a first response result to the first data write request, the method further includes: the cloud management platform receiving a second data write request, wherein the second data write request and the first data write request are data write requests processed in the same batch by the first database system, the response order of the second data write request precedes the response order of the first data write request, and the second data write request is used to indicate second data to be written to the first area; based on the second data write request, the cloud management platform notifies the first database system to write the second data and notifies the first database system to send the written second data to the second area; the cloud management platform obtains third write progress information of the second area, the third write progress information being used to indicate the write progress of the second data corresponding to the most recently responded second data write request in the second area; and the cloud management platform outputting a third response result to the first data write request, the third response result including the first write progress information and the third write progress information.

[0056] In one possible implementation, the method further includes: the cloud management platform obtaining synchronization latency information of the second region based on the first write progress information of the first region and the third write progress information of the second region, the synchronization latency information being used to indicate the time required for the data stored in the second region to be synchronized with the data stored in the first region; the cloud management platform outputting a fourth response result for the first data write request, the fourth response result including the synchronization latency information of the second region.

[0057] In one possible implementation, the method further includes: the cloud management platform determining the third data to be synchronized from the first region to the second region based on the first write progress information of the first region and the third write progress information of the second region; and the cloud management platform notifying the first database system to send the third data to the second region.

[0058] In one possible implementation, the first database system includes a first storage device in a first region where the first database system is located, and the second database system includes a second storage device in a second region where the second database system is located. The cloud management platform notifies the first database system located in the first region to write first data based on a first data write request, including: the cloud management platform notifies the first database system to write first data to the first storage device based on the first data write request; the method further includes: the cloud management platform notifies the first storage device to send the first data to the second storage device.

[0059] The effects of the methods described above for each implementation of the cloud management platform are similar to those of the data access methods described in the first aspect above, and will not be repeated here.

[0060] Thirdly, this application provides a cloud service system, which includes a cloud management platform and multiple database systems, including a first database system and a second database system. The cloud management platform manages the infrastructure providing cloud services. This infrastructure deploys one or more database instances of the first database system and one or more database instances of the second database system. The first database system is located in a first region, and the second database system is located in a second region. The first database system is used to receive a first data write request, which indicates the first data to be written. The first database system is also used to write the first data based on the first data write request and obtain first write progress information of the first region, which indicates the write progress of the first data in the first region. The first database system is also used to send the first data to the second database system. The first database system is also used to obtain second write progress information of the second region, which indicates the write progress of the first data in the second region. The first database system is also used to output a first response result for the first data write request, which includes the first write progress information of the first region and the second write progress information of the second region.

[0061] In one possible implementation, the first database system is further configured to acquire first information, which indicates the response duration of the first data write request; the first database system is further configured to output a second response result to the first data write request within the response duration, starting from the moment the first data write request is received, the second response result including first write progress information, which includes information indicating that the first area has supported access to the first data.

[0062] In one possible implementation, the first database system is further configured to receive a second data write request, wherein the second data write request and the first data write request are the same batch of data write requests processed by the first database system in a batch, and the response order of the second data write request precedes the response order of the first data write request. The second data write request is used to indicate the second data to be written. The first database system is further configured to send the second data to the second database system. The first database system is further configured to obtain third write progress information of the second region, wherein the third write progress information is used to indicate the write progress of the second region in response to the second data write request corresponding to the most recently responded second data write request. The first database system is further configured to output a third response result to the first data write request, wherein the third response result includes the first write progress information and the third write progress information.

[0063] In one possible implementation, the first database system is further configured to obtain synchronization delay information of the second region based on the first write progress information of the first region and the third write progress information of the second region. The synchronization delay information is used to indicate the time required for the data stored in the second region to be synchronized with the data stored in the first region. The first database system is further configured to output a fourth response result to the first data write request. The fourth response result includes the synchronization delay information of the second region.

[0064] In one possible implementation, the first database system is further configured to determine the third data to be synchronized from the first region to the second region based on the first write progress information of the first region and the third write progress information of the second region; the first database system is further configured to send the third data to the second database system.

[0065] In one possible implementation, the first database system includes a first storage device in a first region where the first database system is located, and the second database system includes a second storage device in a second region where the second database system is located. Specifically, the first database system is used to write first data to the first storage device based on a first data write request; the first storage device is used to send the first data to the second storage device.

[0066] In one possible implementation, the cloud management platform is also used to receive a first data write request; the cloud management platform is also used to send a first data write request to a first database system; the cloud management platform is also used to receive a first response result output by the first database system; and the cloud management platform is also used to output a first response result.

[0067] The effects of the cloud service systems implemented in the above-mentioned ways are similar to the effects of the data access methods implemented in the first aspect, and will not be repeated here.

[0068] Fourthly, embodiments of this application provide a computing device cluster, including at least one computing device, each computing device including a processor and a memory, wherein the processor of the at least one computing device is used to execute instructions stored in the memory of the at least one computing device, so that the computing device cluster performs the data access method in the first aspect or any possible implementation of the first aspect.

[0069] Fifthly, embodiments of this application provide a computer program product containing instructions that, when executed by a computing device cluster, cause the computing device cluster to perform the data access method in the first aspect or any possible implementation thereof.

[0070] In a sixth aspect, embodiments of this application provide a computer-readable storage medium including computer program instructions, which, when executed by a cluster of computing devices, enable the cluster of computing devices to perform a data access method in the first aspect or any possible implementation thereof. Attached Figure Description

[0071] Figure 1a This is a flowchart illustrating a data access method in related technologies;

[0072] Figure 1b This is a flowchart illustrating a data access method in a fault scenario within a related technology.

[0073] Figure 1c This is a timing diagram of a data access method in a fault scenario from a related technology.

[0074] Figure 2a A schematic diagram illustrating an implementation scenario of a data access method provided in this application embodiment;

[0075] Figure 2b A schematic diagram of the infrastructure in a cloud service system provided in an embodiment of this application;

[0076] Figure 3 This is a schematic diagram of the structure of a cloud service system provided in an embodiment of this application;

[0077] Figure 4a A flowchart illustrating a data access method provided in an embodiment of this application;

[0078] Figure 4b A flowchart illustrating another data access method provided in an embodiment of this application;

[0079] Figure 4c A flowchart illustrating another data access method provided in an embodiment of this application;

[0080] Figure 4dA flowchart illustrating another data access method provided in an embodiment of this application;

[0081] Figure 4e A flowchart illustrating another data access method provided in an embodiment of this application;

[0082] Figure 4f A flowchart illustrating another data access method provided in an embodiment of this application;

[0083] Figure 5a This is a schematic diagram illustrating a data access method provided in an embodiment of this application;

[0084] Figure 5b A schematic diagram illustrating another data access method provided in this application embodiment;

[0085] Figure 5c A schematic diagram illustrating another data access method provided in this application embodiment;

[0086] Figure 6 This is a schematic diagram of the structure of another cloud service system provided in an embodiment of this application;

[0087] Figure 7 This is a schematic diagram of the structure of a computing device provided in an embodiment of this application;

[0088] Figure 8 This is a schematic diagram of the structure of a computing device provided in an embodiment of this application;

[0089] Figure 9 This is a schematic diagram of the structure of a computing device cluster provided in an embodiment of this application. Detailed Implementation

[0090] The technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings.

[0091] In this article, the term "and / or" is merely a description of the relationship between related objects, indicating that there can be three relationships. For example, A and / or B can represent three situations: A exists alone, A and B exist simultaneously, and B exists alone.

[0092] The terms "first" and "second," etc., used in the specification and claims of this application are used to distinguish different objects, not to describe a specific order of objects. For example, "first target object" and "second target object," etc., are used to distinguish different target objects, not to describe a specific order of target objects.

[0093] In the embodiments of this application, the terms "exemplary" or "for example" are used to indicate that something is an example, illustration, or description. Any embodiment or design that is described as "exemplary" or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design. Specifically, the use of the terms "exemplary" or "for example" is intended to present the relevant concepts in a specific manner.

[0094] In the description of the embodiments in this application, unless otherwise stated, "multiple" means two or more. For example, multiple processing units means two or more processing units; multiple systems means two or more systems.

[0095] Before describing the technical solutions of the embodiments of this application, a brief introduction to the technical background and technical terms involved in the embodiments of this application will be given first:

[0096] 1) Public cloud: This refers to a cloud platform provided by a third-party public cloud provider to a wide range of individuals or businesses. In a public cloud, the hardware, software, and other infrastructure are owned and managed by the third-party public cloud provider.

[0097] 2) Private Cloud: This is a dedicated cloud platform provided for a single enterprise or organization. A private cloud can be operated internally by the corresponding enterprise or organization. Private clouds are primarily geared towards enterprise users and are also known as enterprise clouds.

[0098] 3) Hybrid Cloud: This refers to a cloud platform formed by different cloud platforms. A hybrid cloud includes at least two cloud platforms, also known as a multi-cloud platform or multi-cloud. Optionally, a hybrid cloud integrates public and private clouds. For security reasons, some enterprise users prefer to store data in a private cloud, but at the same time want to obtain the computing resources of a public cloud. In this case, hybrid clouds, which include both public and private clouds, are increasingly being adopted. Hybrid clouds combine and match public and private clouds to achieve optimal performance.

[0099] 4) Database Management System (DBMS), also known as a database engine or computing engine: A DBMS is a software system used for storing, managing, and retrieving data. It enables centralized data management and provides an efficient, secure, and reliable way to process large amounts of data. A DBMS can use a relational or non-relational database.

[0100] 5) Relational Databases: Data is organized based on tables (tables, rows, columns), and data is interconnected through relationships (foreign keys, primary keys, etc.). They can be used to store structured data and manipulate it using Structured Query Language (SQL), supporting complex queries, aggregations, and joins. Examples of relational databases include MySQL, PostgreSQL, Oracle, and SQL Server. Relational databases are suitable for applications requiring strong consistency, complex queries, and transaction management, and are commonly used in fields such as finance and inventory management.

[0101] 6) NoSQL databases: These do not rely on table structures and support various data models, such as key-value (KV) pairs, documents, column families, and graphs. They can be used to store semi-structured or unstructured data, such as JavaScript object notation (JSON), extensible markup language (XML), and binary data. They lack a unified query language and typically rely on specific application programming interfaces (APIs) or query languages ​​(such as MongoDB's query syntax and Cassandra's Cassandra query language (CQL)). Examples of NoSQL databases include MongoDB, Cassandra, Redis, CouchDB, and Elasticsearch. NoSQL databases are suitable for big data, high concurrency, flexible data models, and rapidly scalable applications, and are commonly used in scenarios such as social networks and real-time data analysis.

[0102] 7) Key-value store: This is a type of non-relational database that stores data in the form of key-value pairs. Key-value stores can be applied to large-scale distributed systems. It is one implementation method of non-relational databases.

[0103] 8) Transactions: Transactions can be in relational databases or non-relational databases. A transaction may include at least one data operation, which may be an operation in a non-relational database (e.g., key-value operations) or an operation in a relational database (e.g., insert, delete, update, query, etc.).

[0104] For example, key-value (KV) operations can be read, write, or delete operations. In a KV operation, K can be the identifier of the image to be operated on (written, read, or deleted), and V is the image data. Alternatively, K can be the path to the cloud drive to be operated on, and V can be the file located at that path.

[0105] 9) Logs: In relational databases, the execution of each transaction generates a corresponding log. Each operation within a transaction (such as insert, delete, and update operations) is recorded in the transaction log. When a transaction is committed, the record in the log is marked as committed; if the transaction is rolled back, the log records the undo information. Through the log file, the database can be restored to the state before or after the transaction execution, ensuring data consistency and durability.

[0106] 10) Main Server: The server running the main computing engine (referred to as the "main engine"). For example, when data is stored through a database, the main computing engine can be a DBSM (also called the "main DBMS"), used to receive data access requests.

[0107] 11) Slave Server: A server running a slave computing engine (referred to as "slave engine"). To ensure data backup storage, a slave server may store a copy of the data on the master server. For example, when data is stored through a database, the slave computing engine may be a slave DBMS.

[0108] 12) Primary storage device: Communicates with the primary server and is used to store data requested to be written by the primary server. When data is stored through a database, this primary storage device is also referred to as the "primary database" or "primary storage".

[0109] 13) Slave storage device: A data copy that communicates with the slave server and is used to store the data (also called "original data") in the master storage device. When the data is stored through a database, this slave storage device is also referred to as "slave database" or "slave database".

[0110] 14) Primary site: Represents a site that includes the primary server and primary storage devices; Secondary site: Represents a site that includes secondary servers and secondary storage devices. Different sites represent two geographically distant regions. In cloud scenarios, a site can be a region or an availability zone (AZ). Outside of the cloud, a site can be a data center where servers and storage devices are deployed.

[0111] 15) Logical log (binary log): This can be a log stored and used on the master server. It is used to record all events that change the database state.

[0112] 16) Relay log: This can be a log used by the slave server to record operations extracted from the master server's binlog. These operations are written to the relay log in sequence to ensure that the slave server can correctly replay the operations, thereby achieving data consistency between the master and slave servers.

[0113] 17) Recovery Time Objective (RTO): This refers to the maximum time required for a system to return to normal operation after a disaster or failure.

[0114] In today's digital age, massive amounts of data are generated, which can be stored on physical servers or cloud servers. However, this stored data may be lost due to equipment failure, user error, natural disasters, hacker attacks, or other reasons.

[0115] To ensure high availability of stored data, backups can be performed during the storage of original data to prevent the inability to use applications or services (such as cloud services) due to data loss. In some scenarios, to avoid the simultaneous corruption or loss of the original data and its corresponding copy, the original data and copy can be stored separately on physical devices or cloud servers in two physically distant regions. This allows data storage and access services to be provided even if data is lost on a physical device in one region (due to reasons such as device failure), by using data stored in the other region, thus achieving disaster recovery (DR).

[0116] Please refer to Figures 1a to 1c A data access method is provided in related technologies. For example... Figure 1a As shown, the data is stored in a database. The system may include two physically distant sites, designated as the first site (also called the master site) and the second site (also called the slave site). The first site includes multiple clients, MySQL database engine 1 (also called the master engine), and the master database. The second site includes two clients, MySQL database engine 2 (also called the slave engine), and the slave database. MySQL database engine 1 and MySQL database engine 2 run on the master server and slave server, respectively. The database management system running on the servers at both sites is MySQL.

[0117] The methods in the related technologies can be implemented in two ways, and implementation method 1 and implementation method 2 are introduced below.

[0118] Implementation Method 1

[0119] Please refer to Figure 1aIn steps 1 to 6 (solid lines), firstly, as shown in step 1, client 1 sends a data access request to MySQL database engine 1. MySQL database engine 1 obtains a transaction based on the received data access request and executes the transaction (e.g., write operations such as inserting, deleting, and modifying data in memory). Then, as shown in step 2, MySQL database engine 1 writes the corresponding data (e.g., data 1) to the main database according to the database operations involved in the transaction, thereby achieving persistent storage of the data (data 1) corresponding to the database operations at the first site. During the execution of the above transaction, MySQL database engine 1 can generate a binlog to record the database operations within this transaction.

[0120] Subsequently, in order to back up the data stored in the primary database to the second site, as shown in step 3, MySQL database engine 1 can synchronize the data to MySQL database engine 2. Specifically, the binlog mentioned above can be sent to MySQL database engine 2 at the second site for log synchronization.

[0121] After receiving the binlog, MySQL Database Engine 2 synchronizes the database operations recorded in the binlog to the relay log and reads the recorded database operations from the relay log into memory to ensure that MySQL Database Engine 2 can correctly replay the database operations of the transaction, thereby achieving data consistency between the master and slave servers.

[0122] Next, as shown in step 4, MySQL database engine 2 can persist the above data 1 to the slave database according to the synchronized relay log, so as to achieve backup of the stored data (e.g., data 1) corresponding to transaction 1.

[0123] Then, as shown in step 5, MySQL database engine 2 can send a message indicating that the write is complete (e.g., an acknowledgment message (ACK)) to MySQL database engine 1 to indicate that the data for transaction 1 has been synchronized.

[0124] Finally, as shown in step 6, MySQL database engine 1 can send a response result to client 1, which indicates that the data access request was executed successfully, for example, it can be reflected as the transaction corresponding to the data access request being executed successfully.

[0125] The data access method described above in the related technologies can also be implemented through implementation method 2, which can be achieved through, for example... Figure 1a The solid line steps 1 to 3, the dashed line steps 4 to 5, and the solid line step 6 shown are used to implement this.

[0126] The following describes only the differences between implementation method 2 and implementation method 1. In implementation method 2, as shown in step 4 (dashed line), after synchronizing the database operations recorded in the binlog to the relay log, the MySQL database engine 2 of the second site sends a message indicating that the write is complete (e.g., the ACK mentioned above) to the MySQL database engine 1 of the first site, so that the MySQL database engine 1 can send a response result to the client 1 in a timely manner. As shown in step 5 (dashed line), after the MySQL database engine 2 sends the message indicating that the write is complete to the MySQL database engine 1, the MySQL database engine 2 will persist the data involved in the write of transaction 1 to the slave database according to the synchronized relay log.

[0127] However, in the aforementioned technologies, regardless of implementation method 1 or 2, for a single data access request, MySQL database engine 1 can only send a response result to client 1. This response result only reflects the transaction execution status (success or failure) of the first site and cannot reflect the transaction execution status of other sites (second site). That is, client 1 (e.g., an application running on client 1) can only obtain the transaction execution status of the local master site (e.g., the first site) and cannot obtain the transaction execution status of the slave sites. Therefore, client 1 cannot access the services of slave sites across geographical regions.

[0128] For example, consider an online shopping website with multiple sites. The first site is in country 1, the second in country 2, and client 1, located in country 1, submits an order request via session 1 (using account information). The aforementioned technology would route this order request to the nearest MySQL database engine 1 located in country 1. Client 1 would receive a response from MySQL database engine 1, which only indicates whether the order was successfully placed in country 1; it wouldn't provide information on whether the order data was synchronized to other sites (e.g., country 2). Therefore, client 1 in country 1 cannot access the online shopping website in country 2 to submit an order. Client 1's order request can only be processed by the first site in country 1, not by the second site in country 2, thus preventing global business operations.

[0129] Meanwhile, regardless of implementation method 1 or implementation method 2, during the data backup process, since MySQL database engine 1 transmits the data in memory (binlog) (specifically, the log formed based on database operations in transactions) to MySQL database engine 2, the transmitted log data involves data encapsulation, which results in a large amount of data being transmitted, thereby increasing the transmission latency of data synchronization. Furthermore, MySQL database engine 1 can only send the response result of the data access request to client 1 after successfully synchronizing the data with MySQL database engine 2, which leads to an even longer response latency for client 1. For example, the latency caused by the above reasons can reach the sub-second level.

[0130] Additionally, in the data backup process described in Method 1, after a transaction completes on the primary database, it must wait for the same transaction to also complete on the secondary database (e.g., ...). Figure 1a As shown in steps 3, 4 (solid line), and 5 (solid line), a response result can only be returned to client 1 via step 6. This results in a longer response delay for client 1, affecting client 1's ability to initiate other business (e.g., submitting another order). Furthermore, during the synchronization of data from the master database to the slave database, data transfer occurs between MySQL database engine 1 and MySQL database engine 2, as well as between MySQL database engine 2 and the slave database. In cases where the physical distance between the master and slave sites is large (e.g., the two sites are in different regions), data transfer between MySQL database engine 1 and MySQL database engine 2 takes longer, leading to an even longer response delay for client 1.

[0131] Compared to implementation method 1, in implementation method 2, although after synchronizing data from MySQL database engine 1 to MySQL database engine 2 via step 3, it is not necessary to wait for the persistence process shown in step 5 (dotted line) to complete before MySQL database engine 1 can return a response result to client 1, after returning a response result (success) via step 6, the persistence process shown in step 5 (dotted line) may not be completed due to reasons such as failure of MySQL database engine 2 or the slave database in the second site. This would result in the storage data of transaction 1 in the master database not being successfully backed up to the slave database. Therefore, if MySQL database engine 1 or the master database in the first site fails, the data not backed up to the slave database will be lost, failing to meet the requirements of high data availability.

[0132] Furthermore, in some cases, combined with Figure 1a Please refer to Figure 1bDuring the process of synchronizing data from MySQL database engine 1 to MySQL database engine 2, the second site may fail (e.g., MySQL database engine 2 fails, slave database fails), and / or the communication link between the two sites may be broken. The failure scenarios are described below:

[0133] like Figure 1b and Figure 1c As shown, at time t0, client 1 of the first site (also called the primary site) sends request 1 (i.e., data access request 1) to MySQL database engine 1. MySQL database engine 1 writes the corresponding data (e.g., data 1) to the primary database according to the database operations involved in transaction 1, so as to achieve persistent storage of the data (data 1) corresponding to the database operations at the first site. Then, at time t1, MySQL database engine 1 begins to synchronize data to MySQL database engine 2.

[0134] In the aforementioned technologies, if the second station fails at time t2, any of the following situations may occur: the second station may fail to receive the binlog normally; or, the second station may fail to synchronize the database operations recorded in the binlog to the relay log; or, the second station may fail to read the database operations recorded in the relay log into memory; or, the second station may fail to persist data 1 to the slave database based on the database operations recorded in the relay log, etc. All of these situations will cause MySQL database engine 2 to fail to send a message indicating a successful write to MySQL database engine 1.

[0135] During the data synchronization process from MySQL database engine 1 to MySQL database engine 2, at time t2, the second site fails, and / or the communication link between the two sites is broken. Since MySQL database engine 2 can return an ACK to MySQL database engine 1 during data synchronization, in the event of the aforementioned failure, MySQL database engine 1 does not receive an ACK from MySQL database engine 2 for an extended period, causing MySQL database engine 1 to... Figure 1c The failure of the second site and / or the disconnection of the communication link between the two sites are detected only at time t4. After time t4, for example at time t5, MySQL database engine 1 will return a response to data access request 1 to client 1 (e.g., order submission successful).

[0136] So in such Figure 1cDuring the execution of data access request 1, a failure at the second site and / or a break in the communication link between the two sites will cause a delay from time t2 to time t4. From the time the second site or link fails at time t2 until MySQL database engine 1 detects the failure at time t4, there is a significant delay. During this time, MySQL database engine 1 is unable to return a response to data access request 1 to client 1. Consequently, client 1 waits for a response after submitting data access request 1 (e.g., client 1 waits for a message indicating successful order submission), causing a delay in the client's current business operations.

[0137] Furthermore, client 1 cannot send the next data access request (data access request 2) until it receives the response to data access request 1. Therefore, if a failure occurs at the slave site during data synchronization, it will affect the business processing progress of client 1 at the master site.

[0138] As can be seen, in fault scenarios, whether it's a site failure or a break in the communication link between the master and slave sites, it will cause service interruptions for client 1 at the master site, and will also affect the timely processing of subsequent services. These impacts may cause service interruptions of client 1 at the first site for seconds or even minutes, affecting service performance.

[0139] Furthermore, regardless of whether it's implementation method 1 or method 2, after the slave site recovers from a failure and restarts, the master site needs to synchronize data to the slave site. Specifically, because the master database cannot know which request the slave database executed that caused the failure and prevented the subsequent synchronization of persistent data, when the master site restores the slave site's data, it can clear the data in the slave database and synchronize all the stored data in the master database of the master site to the slave database of the slave site. This results in a huge amount of data being synchronized, leading to long data recovery time and low data recovery efficiency after the slave site recovers from a failure.

[0140] In summary, in the relevant technologies, the main engine of the main site can only return one response result for a data access request from a client, and this response result can only indicate whether the data access was successful on the main site side, making it impossible for the client to access services across regions.

[0141] Furthermore, when synchronizing data from the master site to the slave site, the master engine on the server (i.e., the server-side) transmits log data related to database operations and other data to the slave engine to achieve data synchronization between the master and slave sites. This log data is quite large, resulting in a long data synchronization time. After data synchronization, the master engine can only respond to the client's data access request, further increasing the client's response time. Moreover, when the two sites are far apart, the long communication link further increases transmission latency, which in turn further increases the client's response latency.

[0142] Furthermore, in implementation method 1 of the related technologies, when the main engine returns the response result to the client, the slave database of the slave site has not yet performed persistent processing on the data accessed by the client, which cannot reliably guarantee the storage of data on the main site and the slave site, and cannot meet the high availability requirement.

[0143] In addition, during the process of synchronizing data from the master site to the slave site, if the slave site fails, there is a certain time delay between the master engine detecting the failure and the failure. The master engine can only return the response result of the data access request to the client after detecting the failure. Therefore, if the slave site fails during the data synchronization process, it will cause the client's business on the master site to experience a delay of seconds or even minutes, affecting business performance.

[0144] Furthermore, after the fault is repaired at the slave site, when restoring the stored data at the slave site, the master site needs to synchronize the data between the master engine and the slave engine to restore the data in the master database to the slave database. The amount of data to be restored is extremely large, resulting in long data recovery time and low data recovery efficiency.

[0145] Based on this, embodiments of this application provide a data access method that can output a response result for a data access request, and the response result can include the writing progress of the first data corresponding to the data access request in different regions. This allows the client to determine which region to send subsequent data access requests to for processing based on the writing progress of the first data in different regions within the response result, facilitating cross-regional data access, improving data access efficiency, and enhancing data access effectiveness.

[0146] The method described in this application can be applied to cloud scenarios or to physical devices under the cloud, without limitation.

[0147] The following describes the method of this application embodiment using a cloud scenario as an example. In this embodiment, the cloud system involved in the method is a public cloud. In other embodiments, the cloud system may also be a private cloud and / or a hybrid cloud, which is not limited in this application. That is to say, the data access method in the following embodiments of this application can also be applied to a private cloud or a hybrid cloud, which is not limited in this application.

[0148] Figure 2a This is a schematic diagram illustrating an implementation scenario of a data access method provided in an embodiment of this application. For example... Figure 2a As shown, this implementation scenario includes: data center 1 and client 1. Data center 1 and client 1 can establish a communication connection via a network. Optionally, this network can be the Internet, or other networks; this embodiment is not limited to any particular network. Tenants can interact with data center 1 through client 1. For example, a tenant can send data access requests (e.g., data write requests) to data center 1 through client 1. Data center 1 responds based on the information sent by client 1.

[0149] Data Center 1 houses a large amount of infrastructure owned by the cloud service provider, such as computing resources, storage resources, and network resources. For example, computing resources can be computing devices (such as servers) capable of providing computing power. Figure 2a As shown, data center 1 includes a cloud management platform and infrastructure ( Figure 2a (Not shown in the image). The cloud management platform and the infrastructure are connected via an internal data center network. The cloud management platform is used to manage the infrastructure. The infrastructure is used to provide public cloud services. In this application, the infrastructure includes servers and storage. The servers in the infrastructure are used to implement the compute node cluster in the cloud service system of this application, and the storage in the infrastructure is used to implement the storage node cluster in the cloud service system of this application. Virtual instances used to implement tenant services are optionally deployed in the compute nodes of the compute node cluster. Tenants can send data access requests (e.g., data write requests) and related information to the compute nodes through their client 1. The compute nodes can process the data access requests (e.g., data write requests) and related information, and provide cloud services to the tenants based on the processed data access requests (e.g., data write requests) and related information.

[0150] The cloud management platform can be logically divided into: tenant console, compute management service, network management service, storage management service, authentication service, and image management service. The tenant console provides a user interface or application programming interface (API) for interaction with tenants. The compute management service manages servers running virtual instances and bare metal servers. The network management service manages network services (such as gateways and firewalls). The storage management service manages storage services (such as data bucket services). The authentication service manages tenant accounts and passwords. The image management service manages virtual instance images.

[0151] exist Figure 2a In the illustrated implementation scenario, a data center contains multiple servers. The servers consist of a hardware layer and a software layer. The hardware layer comprises the standard server configuration, including processors, memory, network interface cards (NICs), disks, and buses. The software layer includes the operating system installed and running on the server. The operating system relative to the virtual machine can be called the host operating system. The host operating system runs a virtual machine manager (VMM, also known as a hypervisor). The VMM's role is to implement compute virtualization, network virtualization, and storage virtualization, and to manage the virtual machines.

[0152] A cloud management platform client runs in the virtual machine manager. The cloud management platform client can receive data write requests sent by the cloud management platform and, through the server and storage, respond to the data write requests and store and back up the data to be written as indicated by the data write request. The virtual machines running on the server can output their response results to the cloud management platform through the cloud management platform client, thus outputting the response results to client 1. The specific process will be described in detail in the following embodiments.

[0153] In one implementation, such as Figure 2bAs shown, the location of infrastructure in a data center can be described using cloud resource deployment regions (regions) and availability zones (AZs). Tenants can choose to deploy cloud services based on resources within a specific region or AZ. A region is defined by geographical location and network latency. Using the same resource pool within the same region can be understood as sharing common services such as elastic computing, block storage, object storage, virtual private cloud (VPC) networks, elastic internet protocol (EIP) addresses, and images. Regions are divided into general-purpose regions and dedicated regions. A general-purpose region refers to a region that provides general cloud services to public tenants. A dedicated region refers to a region that hosts the same type of business or provides business services to specific tenants. A region typically includes multiple AZs. Multiple AZs within a region are connected via high-speed fiber optic cables to meet the needs of tenants building high-availability systems across AZs. An AZ is one or more... Figure 2a The data center shown is a collection of data centers. Within an Availability Zone (AZ), computing, networking, and storage resources are logically divided into multiple clusters.

[0154] Tenants can use their services such as Figure 2a The client 1 shown sends instructions to the cloud management platform to create, manage, log in to, and operate virtual instances on the server, and to use the cloud services provided by these virtual instances. For example, the cloud management platform can provide an access interface. This access interface can be provided either as a user interface or an API. Tenants can operate the client to remotely access the access interface to register a cloud account and password on the cloud management platform, and then log in using the cloud account and password. The cloud management platform can also authenticate the cloud account and password. After successful authentication, the tenant can further select and purchase a virtual instance of a specific specification (processor, memory, disk) on the cloud management platform. After the tenant successfully purchases the virtual instance, the cloud management platform provides the tenant with a remote login account and password for the purchased virtual instance. The tenant can use the remote login account and password to remotely log in to the virtual instance on the client, install and run the tenant's application within the virtual instance, and use the application to realize the tenant's business.

[0155] Client 1 can be selected from computers, personal computers, laptops, mobile phones, smartphones, tablets, cloud servers, portable mobile terminals, multimedia players, e-book readers, wearable devices, smart home appliances, artificial intelligence devices, smart wearable devices, smart in-vehicle devices, or Internet of Things devices, etc.

[0156] In one implementation, the data access method provided in this application embodiment can be implemented by running an executable program on a computing device in data center 1. Optionally, the data access method provided in this application embodiment can be applied to a cloud service system. The cloud service system can implement the data access method provided in this application embodiment by running the executable program. Furthermore, the executable program implementing the data access method can optionally be presented in the form of an application installation package. After the computing node installs the application installation package, it can implement the data access method provided in this application embodiment by running the executable program therein.

[0157] It should be understood that the above content is an exemplary description of the implementation scenarios of the data access method provided in the embodiments of this application, and does not constitute a limitation on the implementation scenarios of the data access method. As those skilled in the art know, as business needs change, the implementation scenarios can be adjusted according to application requirements, and the embodiments of this application do not specifically limit them.

[0158] Combination Figure 2a , Figure 2b Please refer to Figure 3 , Figure 3 This application provides a cross-regional cloud service system as an embodiment. Based on... Figure 3 The system described herein can provide cross-regional data access services as provided in the embodiments of this application.

[0159] like Figure 3 As shown, the system may include a data center cluster 1000 deployed in region 1 and a client cluster 800 communicating with it. Combined with Figure 2a ,like Figure 3 The client cluster 800 and the data center cluster 1000 shown interact through a cloud management platform to access cloud services.

[0160] For example, client cluster 800 may include client 102, or more clients. Data center cluster 1000 may include, but is not limited to, compute cluster 500 and storage cluster 300. Compute cluster 500 may include one or more compute nodes, such as compute node 11, or more compute nodes. Storage cluster 300 may include storage node 21, or more storage nodes.

[0161] For example, let's take compute node 11 on compute cluster 500 as an example. The same applies to other compute nodes. Compute node 11 can run compute instance 1, or it can run more compute instances.

[0162] For example, storage node 21 on storage cluster 300 can be used as an example. The same applies to other storage nodes. Storage node 21 can run storage instance 1, or it can run more storage instances.

[0163] Compute instances run on compute nodes and are primarily responsible for computation, while storage instances run on storage nodes and are primarily responsible for data storage.

[0164] Both compute instances and storage instances can be called "virtual instances," and they can run on virtual machines, containers, or physical machines (compute nodes or storage nodes themselves).

[0165] Taking compute instance 1 as an example, compute instance 1 can run on compute node 11, or on a virtual machine in compute node 11, or on a container in compute node 11.

[0166] A storage instance can be a storage system running on a storage node or storage cluster, such as a block storage system, object storage system, or file storage system. For example, a storage instance can also be a storage unit within a corresponding storage system; such as a storage pool in a block storage system or a storage bucket in an object storage system.

[0167] In some embodiments, a compute instance is also referred to as a compute engine, database (DB) engine, or DBMS. One or more compute instances can provide compute services, and one or more storage instances can provide storage services (e.g., block storage services, file storage services, object storage services, etc.).

[0168] Continue to refer to Figure 3 The system may include a data center cluster 1001 deployed in region 2 and a client cluster 801 communicating with it. Combined with Figure 2a ,like Figure 3 The client cluster 801 and the data center cluster 1001 shown interact through a cloud management platform to access cloud services.

[0169] For example, client cluster 801 may include client 103, or more clients. Data center cluster 1001 may include, but is not limited to, computing cluster 501 and storage cluster 301. Computing cluster 501 may include one or more computing nodes, such as computing node 12, or more computing nodes. Storage cluster 301 may include one or more storage nodes, such as storage node 22, or more storage nodes.

[0170] For example, compute node 12 on compute cluster 501 can be used as an example. The same applies to other compute nodes. Compute node 12 can run compute instance 2, or it can run more compute instances.

[0171] For example, storage node 22 on storage cluster 301 can be used as an example. The same applies to other storage nodes. Storage node 22 can run storage instance 2, or it can run more storage instances.

[0172] Continue to refer to Figure 3 The system may also include a data center cluster 1002 deployed in region 3 and a client cluster 802 communicating with it. Combined with Figure 2a ,like Figure 3 The client cluster 802 and the data center cluster 1002 interact through a cloud management platform to access cloud services.

[0173] For example, client cluster 802 may include client 104, or more clients. Data center cluster 1002 may include, but is not limited to, compute cluster 502 and storage cluster 302. Compute cluster 502 may include one or more compute nodes, such as compute node 13, or more compute nodes. Storage cluster 302 may include one or more storage nodes, such as storage node 23, or more storage nodes.

[0174] For example, compute node 13 on compute cluster 502 can be used as an example. The same applies to other compute nodes. Compute instance 3 can be run on compute node 13, or more compute instances can be run.

[0175] For example, storage node 23 on storage cluster 302 can be used as an example. The same applies to other storage nodes. Storage node 23 can run storage instance 3, or it can run more storage instances.

[0176] exist Figure 3 In the system shown, a computing instance running on a single computing node is used as an example. In other embodiments, a computing instance can also run distributedly on multiple computing nodes. For example, computing instance 1 can also run distributedly on multiple computing nodes in computing cluster 500. This application does not limit this.

[0177] Similarly, such as Figure 3 The system shown is illustrated using the example of a storage instance running on a single storage node. In other embodiments, a storage instance can also run distributed across multiple storage nodes. For example, storage instance 2 can also run distributed across multiple computing nodes in computing cluster 501. This application does not impose any restrictions on this.

[0178] In the embodiments described below, for ease of explanation, such as Figure 3 The computation instance 1 shown is also referred to as the "main engine", the storage instance 1 is also referred to as the "main database", the computation instance 2 is also referred to as the "slave engine 2", the storage instance 2 is also referred to as the "slave database 2", the computation instance 3 is also referred to as the "slave engine 3", and the storage instance 3 is also referred to as the "slave database 3".

[0179] The following describes a data access method provided by an embodiment of this application.

[0180] Please refer to Figure 4a , Figure 4a This is a flowchart illustrating a data access method provided in an embodiment of this application.

[0181] In some embodiments, the data access method can be applied to Figures 2a to 2b ,as well as Figure 3 The cloud service system described in any of the embodiments can be applied to a cloud management platform, or to one or more computing nodes, or to one or more computing instances, or to one or more storage nodes, or to one or more storage instances, or to any two or a combination of the above objects, and this application does not limit this.

[0182] Alternatively, in some embodiments, the data access methods of various embodiments of this application can also be applied to physical devices under the cloud.

[0183] The physical device may include, but is not limited to, terminal devices and physical servers. Terminal devices may include, but are not limited to, mobile phones, personal computers (PCs), virtual reality (VR) devices, augmented reality (AR) devices, tablets, and laptops.

[0184] Terminal devices can also be smart TVs, smart speakers, mobile internet devices (MIDs), wearable devices (such as smartwatches, smart glasses, or smart helmets), smart cars, wireless terminal devices in industrial control, wireless terminal devices in self-driving, wireless terminal devices in remote medical surgery, wireless terminal devices in smart grids, wireless terminal devices in transportation safety, wireless terminal devices in smart cities, and wireless terminal devices in smart homes. This application does not impose any special restrictions on the specific form of the terminal device.

[0185] A physical server may include, but is not limited to, at least one processor.

[0186] The processor can be a central processing unit (CPU) or a graphics processing unit (GPU), or it can be any type of processor or any combination thereof, such as an application-specific integrated circuit (ASIC), a programmable logic device (PLD), a complex programmable logical device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL), a system-on-chip (SoC), a software-defined infrastructure (SDI) chip, an AI chip, or a data processing unit (DPU).

[0187] Furthermore, the number of processors included in the server can be arbitrary, and the types of processors included can be one or more. The specific number and types of processors can be set according to the actual business needs of the application, and this application does not limit this.

[0188] For example, the data access methods of various embodiments of this application can be applied to one or more physical servers, or to a server cluster or distributed system composed of multiple physical servers.

[0189] The following describes the methods of various embodiments of this application by taking the application of the method of this application to the cloud management platform as an example.

[0190] This method can also be applied to other objects in cloud scenarios, such as cloud service systems.

[0191] In some embodiments, the cloud service system may include a cloud management platform and multiple database systems, including a first database system and a second database system. The cloud management platform is used to manage the infrastructure that provides cloud services. The infrastructure deploys one or more database instances of the first database system and one or more database instances of the second database system. The first database system is located in a first region, and the second database system is located in a second region.

[0192] This data access method may involve multiple regions for implementing data access, meaning that each of the multiple regions can independently implement data access. For example, the multiple regions may include a first region and a second region. In some embodiments, the number of second regions may be N, where N is a positive integer.

[0193] In other embodiments, the method can also be applied to physical devices under the cloud, and the principle of its implementation is similar, so it will not be described again here.

[0194] like Figure 4a As shown, the data access method may include, but is not limited to, the following steps: step S401, step 4011, step 4012, and step S403.

[0195] Step S401: The cloud management platform receives the first data access request.

[0196] For example, the first data access request can be as described above. Figure 2a The first data access request is sent by the client (or tenant) 102 shown. For example, the first data access request may be sent by an application running on the client (referred to as the client application).

[0197] For example, the cloud management platform can provide an interface. The client can send a first data access request to the cloud management platform by calling this interface, so that the cloud management platform can receive data access requests sent by any client through this interface.

[0198] In some embodiments, a first data access request may be used to instruct a request to write first data.

[0199] The first data is the data to be persistently stored, such as data to be written. For example, the first data could be data to be written to a storage node or storage system.

[0200] The first area can be used to respond to the first data access request to write the first data, and the second area is used to back up and store the first data written in the first area.

[0201] The first region can be the region that receives the first data access request, while the second region is the region that backs up and stores the first data written in the first region. When there are multiple second regions, each second region can be used to store a copy of the first data. In this way, the first data can be stored in the first region and also in multiple second regions, thereby realizing cross-regional storage of data and ensuring high availability of data.

[0202] For example, in a cloud scenario, the aforementioned areas (such as the first or second area) can be regions or availability zones.

[0203] For example, in a cloud scenario, a region can include multiple servers within at least one data center. For example... Figure 3 As shown, the server located in Region 1 (an example of a region in a cloud scenario) may include compute node 11 or other compute nodes, and storage node 21 or other storage nodes.

[0204] For example, outside of cloud scenarios, a region can be a data center (DC) located within a physical region. For instance, Region 1 could be a data center in North China, and Region 2 could be a data center in South China. Alternatively, Region 1 could be a data center in one city, and Region 2 in another city; for example, Region 1 could be a data center in Beijing, China, and Region 2 could be a data center in Shanghai, China. Or, Region 1 and Region 2 could be data centers in different countries. If there are multiple Region 2s, they correspond to different countries. A data center can include one or more servers; therefore, when a region is described as a data center in this document, that region can include one or more servers.

[0205] In some embodiments, a region may be located at a site, for example, a first region may be located at a first site, and a second region may be located at a second site.

[0206] The data access method of this application embodiment can involve multiple regions, and thus the data access method of this application embodiment can involve multiple sites. For the multiple sites of this application embodiment, the multiple sites may include a first site and at least one second site. In some embodiments, the first site may also be called the master site and the second site may be called the slave site. For example, the site that can receive the first data access request may be called the master site, and the site that performs data backup on the first data written by the master site may be called the slave site.

[0207] In some embodiments, a first data write request is used to indicate first data to be written to the first site, in which case the first site is the master site.

[0208] In some embodiments, when the method is applied to a cloud service system, a first data write request is used to indicate first data to be written.

[0209] For example, Figure 3 The client 102 shown sends a first data access request to a server in region 1, such as compute instance 1, through a cloud management platform (not shown). Region 1 can then be referred to as the primary site. The primary site can be used to write first data based on this first data access request, while the secondary sites communicating with the primary site (e.g., ...) Figure 3 At least one of the areas shown in area 2 and area 3 is used to back up the first data.

[0210] In some embodiments, the first data access request may or may not carry the first data directly, depending on the actual application requirements.

[0211] Furthermore, the first data may differ depending on the entity executing the method.

[0212] For example, the first data access request sent by client 102 may differ based on the business logic. For instance, if the business is order submission, then the first data access request could be an order submission request. An order submission request might carry, but is not limited to, the identifier information of the purchased goods, the quantity information of the goods, and the delivery address information of the goods. In this case, the order submission request might not directly carry the first data, but the information carried by the aforementioned submission request could be used to indicate updates to the inventory quantity and order information. Therefore, the updated inventory quantity and the updated order information could be considered the first data.

[0213] by Figure 3Taking the architecture as an example, when the execution subject of this method is a computing instance, for example, computing instance 1 can receive an order submission request sent by client 102 through the cloud management platform. Taking the scenario where the data is stored in a relational database as an example, computing instance 1 can obtain a transaction based on the order submission request. The transaction can include one or more database operations corresponding to the order submission request. For example, the database operations in the transaction can include at least one of the following: insert operation, delete operation, or modify operation on at least one field in the data table. Then the first data can be the data written by the one or more database operations respectively, such as the inserted data, the deleted data, the modified data, etc.

[0214] by Figure 3 Taking the architecture shown as an example, when the execution subject of this method is a storage instance, the first data access request can be a transaction received by storage instance 1 from computing instance 1 corresponding to the data access request sent by client 102. Storage instance 1 can write data to the corresponding field in the corresponding data table according to the database operation indicated by the transaction.

[0215] For example, this transaction instructs to increment the data in the third row of field 1 in data table 1 by 1. Here, the first data access request may not carry the first data, but only the execution location information of the write operation and the corresponding write operation (data table 1, field 1, third row, and the operation being incremented by 1). Then, storage instance 1 can increment the data in the third row of field 1 of data table 1 (e.g., the current value is 2) by 1. The data in storage instance 1 corresponding to the storage location of the third row of field 1 of data table 1 will be modified from 2 to 3, so as to write the first data "3" (i.e., the "modified data" in the example above).

[0216] For example, the first data access request may be constructed by the client or computing instance according to business needs. This application embodiment does not limit the specific data format of the first data access request or the transmission protocol used by the first data access request.

[0217] Furthermore, when the data is stored in a relational database, the data access request mentioned in the various embodiments of this application can be a transaction in the relational database (e.g., the transaction may include at least one database operation). When the data is stored in a non-relational database, the data access request mentioned in the various embodiments of this application can be a transaction in the non-relational database (e.g., the transaction may include at least one key-value operation), etc. This application does not impose specific limitations in this regard.

[0218] In some embodiments, when a data access request indicates that data should be written, the data access request may be named a data write request.

[0219] Step 4011: Based on the first data write request, the cloud management platform notifies the first database system located in the first region to write the first data.

[0220] In a cloud scenario, taking three regions as an example, there is one main site and two slave sites. It should be understood that when the number of multiple sites is two or more, the method of this application embodiment is the same.

[0221] Please refer to Figure 3 The three regions used to implement data access are Region 1, Region 2, and Region 3. Each region may include one or more compute nodes and one or more storage nodes.

[0222] For example, the first database system located in region 1 may include, but is not limited to: compute node 11 (an example of a master server) and storage node 21 (an example of a master storage device).

[0223] Among them, compute node 11 runs compute instance 1 (hereinafter referred to as the "main engine"), and storage node 21 runs storage instance 1 (hereinafter referred to as the "main library").

[0224] The first database system may include one or more database instances, such as computing instances, like computing instance 1 mentioned above.

[0225] The first database system located in region 1 can also be described as including the main engine and the main database (or storage node 21).

[0226] The second database system located in region 2 may include, but is not limited to: compute node 12 (an example from a server) and storage node 22 (an example from a storage device).

[0227] Among them, compute node 12 runs compute instance 2 (hereinafter also referred to as "engine 2"), and storage node 22 runs storage instance 2 (hereinafter also referred to as "database 2").

[0228] The second database system may include one or more database instances, such as computing instances, like computing instance 2 mentioned above.

[0229] The second database system located in region 2 can also be described as including engine 2 and slave database 2 (or storage node 22).

[0230] Another second database system located in region 3 may include, but is not limited to: compute node 13 (another example from a server) and storage node 23 (another example from a storage device).

[0231] Among them, compute node 13 runs compute instance 3 (hereinafter also referred to as "engine 3"), and storage node 23 runs storage instance 3 (hereinafter also referred to as "database 3").

[0232] The second database system located in region 3 can also be described as including engine 3 and slave database 3 (or storage node 23).

[0233] In some embodiments, the first region may include a primary storage device (an example of a first storage node), and each second region may include a secondary storage device (an example of a second storage node).

[0234] exist Figure 3 In the scenario shown, there is one primary storage device (specifically storage node 21) and two secondary storage devices (storage node 22 and storage node 23, respectively). In other embodiments, the primary storage device can be one or more storage nodes, and a single secondary storage device can also be one or more storage nodes; there is no limitation here.

[0235] In some embodiments, taking the application of this method in a cloud scenario as an example, please refer to... Figure 3 The cloud management platform can notify the first database system in region 1 to write the first data based on the first data access request from client 102 (e.g., an instruction to send to region 1).

[0236] In some embodiments, the first database system includes a first storage device in a first region, and the second database system includes a second storage device in a second region. Specifically, in... Figure 3 In this scenario, a second database system in a second region may include at least one second storage device. For example, a second database system in region 2 may include storage node 23.

[0237] In some embodiments, the cloud management platform may, based on a first data write request, notify the first database system to write first data to the first storage device; the cloud management platform may also notify the first storage device to send the first data to N second storage devices.

[0238] The cloud management platform can notify the first storage device through the main server to send the first data to the second storage device.

[0239] In some embodiments, when the first database system writes first data based on a first data access request, it may write the first data to the storage node 21.

[0240] For example, computing node 11 in the first database system of region 1 can write database operations about the first data in computing node 11 according to the first data access request, and write the first data to storage node 21 (an example of the main storage device) according to the database operations, so as to realize the writing of the first data in the database system of region 1.

[0241] Subsequently, the first database system in region 1 can send the first data to the second database systems in region 2 and region 3 to request the synchronization of the first data already written in region 1 to region 2 and region 3.

[0242] In some embodiments, storage node 21 in region 1 may send first data to storage node 22 (an example from a storage device) located in region 2, and to storage node 23 (an example from a storage device) located in region 3. Whether storage node 22 and storage node 23 completely write the first data when the cloud management platform or the first database system outputs the first response result is not limited here.

[0243] As an example, if the data center clusters in Region 1, Region 2, and Region 3 mentioned above are data center clusters in Beijing, Shanghai, and Shenzhen respectively, the method of this application embodiment, after writing the first data corresponding to the data access request to the main storage device in the Beijing data center cluster, can also use the main storage device to synchronously write the first data to the slave storage device in the Shanghai data center cluster, and use the main storage device to synchronously write the first data to the slave storage device in the Shenzhen data center cluster. This ensures that if a device in any region fails, the first data stored in other regions can still be used, thus ensuring high availability of stored data in cloud scenarios.

[0244] In some embodiments, taking the application of this method to scenarios outside of cloud environments (e.g., physical servers) as an example, the three regions can be data centers in two administrative districts within Beijing (e.g., Chaoyang District and Haidian District) and a data center in another city (e.g., Shanghai). The physical servers (including master servers and master storage devices) in the Chaoyang District data center can serve as the master site, the physical servers (including slave server 1 and slave storage device 1) in the Haidian District data center can serve as slave sites, and the physical servers (including slave server 2 and slave storage device 2) in the Shanghai data center can serve as another slave site. For example, the physical servers in the aforementioned two administrative districts within Beijing can constitute one data center cluster, and the physical servers in Shanghai can constitute another data center cluster.

[0245] As an example, after writing the first data corresponding to the data access request to the main storage device in the Beijing data center cluster, the method of this application embodiment can also use the main storage device to synchronously write the first data to the slave storage devices in the Shanghai data center cluster and the slave storage devices in the Shenzhen data center cluster. This ensures that if a device in any region fails, the first data stored in other regions can still be used, thus ensuring high availability of stored data in cloud scenarios.

[0246] As an example, in this embodiment of the method, after the first data corresponding to the data access request is written to the main storage device in the Beijing data center (i.e., to the main storage device in Chaoyang District), the main storage device in Chaoyang District can synchronize the first data to the slave storage device 1 in Haidian District within a short time (e.g., 0.5 seconds, not limited). After the first data is synchronized to the slave server and slave storage device in Haidian District, the main storage device in Chaoyang District can return a response result first, without waiting for the response result of the first data being synchronized from the main storage device to the slave storage device 2 in Shanghai. This achieves synchronous replication of the first data within the same data center cluster and asynchronous replication between different data center clusters.

[0247] Unlike related technologies that synchronize stored data through a server (e.g., a master server and a slave server), in this embodiment, after the first data is written to the first storage device based on the first database system, the first data can be sent to a second storage device located in a different region through the first storage device. In related technologies, when synchronizing data through a server, the synchronized data may be, for example, database operations related to the first data. These database operations involve data encapsulation and have a large data volume. However, in this embodiment, the data synchronized on the storage side (e.g., the first storage device and the second storage device) is the data actually stored on the storage device side (e.g., the first data). Thus, the synchronized data does not involve data encapsulation, has a smaller data volume, thereby reducing the data synchronization time and consequently reducing the response latency to the first data access request and the response latency to the client that sent the first data access request.

[0248] Furthermore, in this embodiment, to prevent the loss of data stored in the first storage device (e.g., the first data itself) due to a failure of the first storage device, the first data can be synchronously written to the second storage device after being written to the first storage device, thus ensuring backup storage. In this way, when the first database system outputs a response, the first data has already been persistently stored in the second storage device, ensuring reliable storage of data in both the first and second storage devices and achieving high data availability.

[0249] Step 4012: The cloud management platform receives the first write progress information of the first region and the second write progress information of the second region.

[0250] The first write progress information is used to indicate the write progress of the first data in the first area, and the second write progress information of the second site is used to indicate the write progress of the first data in the second area.

[0251] In some embodiments, the first write progress information includes at least one of the following: information indicating that first data has been received; information indicating that first data has been written; information indicating that access to the first data has been supported.

[0252] The second write progress information includes at least one of the following: information indicating that the first data has been received; information indicating that the first data has been written; information indicating that access to the first data has been supported.

[0253] The first write progress information is the write progress of the first region on the first data. The write progress can be at least one of the following: the first region has received the first data, the first region has written the first data, and the first region has supported access to the first data.

[0254] The second write progress information is the write progress of the second region on the first data. This write progress can be at least one of the following: the second region has received the first data, the second region has written the first data, or the second region has supported access to the first data.

[0255] In some embodiments, the writing progress information (first writing progress information or second writing progress information) of any region for the first data may include at least one of the following: information indicating that the region has received the first data; information indicating that the region has written the first data; information indicating that the region has supported access to the first data.

[0256] Information indicating that the first data has been written to this area: This indicates that the first data has been persistently stored in this area.

[0257] For example, with Figure 3 For example, if the computing node 11 writes the first data to the storage node 21 based on the first data access request sent by the client 102, it means that the first data has been written to region 1, that is, the first data has been written based on the first data access request.

[0258] If the compute node 11 does not write the first data to the storage node 21 based on the first data access request sent by the client 102, it means that the first data has not been written to region 1, that is, the first data has not been written based on the first data access request.

[0259] If the first data has been persistently stored on storage node 22 in region 2, for example, if the first data has been synchronously stored on storage node 21 in region 2, it means that the first data has been written to region 2, that is, the first data has been written based on the first data access request.

[0260] If storage node 22 in region 2 does not receive the first data from storage node 21 or does not persist the first data, it means that the first data has not been written to region 2.

[0261] If the first data has been persistently stored on storage node 23 in region 3, for example, if the first data has been synchronously stored on storage node 23 in region 3, it means that the first data has been written to region 3, that is, the first data has been written based on the first data access request.

[0262] If storage node 23 in region 3 does not receive the first data from storage node 21 or does not persist the first data, it means that the first data has not been written to region 3.

[0263] Information indicating that the region supports access to the first data: This means that the region has persisted the first data (i.e., it has been written to the first data) and that the region has stored the target operation related to the first data. For example, the target operation is the target operation involved in the transaction corresponding to the first data access request. When the transaction is a database transaction, the target operation can be a database operation (e.g., add, delete, or modify operations); or when the transaction is a key-value transaction, the target operation can be a key-value operation.

[0264] Continue with Figure 3 For example, when computing node 11 in region 1 generates a corresponding transaction based on the first data access request sent by client 102 and stores the database operation in the transaction in computing node 11, it means that region 1 has stored the target operation related to the first data. Then, if the target operation is stored in region 1 and the first data is also stored in storage node 21 in region 1, it means that region 1 supports access to the first data.

[0265] If the computing node 11 in region 1 does not store the target operation, and / or the storage node 21 in region 1 does not store the first data, then region 1 does not support access to the first data.

[0266] If the computing node 12 in region 2 stores the target operation related to the first data, and the storage node 22 in region 2 also stores the first data, then region 2 supports access to the first data.

[0267] If the computing node 12 in region 2 does not store the target operation, and / or the storage node 22 in region 2 does not store the first data, then region 2 does not support access to the first data.

[0268] If the computing node 13 in region 3 stores the target operation related to the first data, and the storage node 23 in region 3 also stores the first data, then region 3 supports access to the first data.

[0269] If the target operation is not stored in compute node 13 within region 3, and / or the first data is not stored in storage node 23 within region 3, then region 3 does not support access to the first data.

[0270] The message indicating that first data has been received indicates that the region has not written the first data and has not stored the target operation related to the first data. For example, the region may have received a first data access request or received some or all of the first data sent to it by another region, or it may not have received the first data sent by another region; and the region has not written the first data.

[0271] Continue with Figure 3 For example, if the first database system in region 1 receives a first data access request but does not store the target operation on the computing node 11 side and does not persist the first data on the storage node 21 side, it means that region 1 has received the first data.

[0272] If storage node 22 in region 2 receives the first data sent by storage node 21 in region 1, but has not yet completed the persistence of the first data, and computing node 12 has not stored the target operation, then it means that region 2 has received the first data.

[0273] If storage node 22 in region 2 does not receive the first data synchronized by storage node 21 in region 1, and computing node 12 also does not store the target operation, then it means that region 2 has not received the first data.

[0274] Similarly, if storage node 23 in region 3 receives the first data synchronized by storage node 21 in region 1, but has not yet completed the persistence of the first data, and computing node 13 has not stored the target operation, it means that region 3 has received the first data.

[0275] If storage node 23 in region 3 does not receive the first data synchronized by storage node 21 in region 1, and computing node 13 also does not store the target operation, then it means that region 3 has not received the first data.

[0276] The above example, taking the writing of the first data and the target operation related to the first data at the node granularity of the computing nodes and storage nodes in the region as an example, illustrates the specific situation of the three types of information in the writing progress information of data (here, the first data) in a region. However, the above example is not intended to limit the scope of these three types of information.

[0277] In other examples, the specific details of the three types of information in the writing progress information of a region for data (e.g., the first data) can be illustrated by writing the first data and the target operation related to the first data at the granularity of virtual instances such as compute instances and storage instances within the region.

[0278] For example in Figure 3 In the scenario shown, the data center cluster 1000 in region 1 may include 5 compute instances and 5 storage instances. If at least one compute instance in region 1 performs a write operation on the target data and a storage instance (e.g., storage instance 1) that communicates with the compute instance (e.g., compute instance 1) writes the first data, then region 1 has supported access to the first data.

[0279] Conversely, if no computing instance in region 1 writes the first data to the storage instance communicating with that computing instance, and / or no computing instance stores the target operation, then region 1 does not support access to the first data.

[0280] Correspondingly, such as Figure 3 If storage instance 1 synchronizes the first data to at least one storage instance in region 2, and the computing instance communicating with the storage instance also stores the target operation, then region 2 supports access to the first data.

[0281] On the contrary, such as Figure 3 If storage instance 1 does not synchronize the first data to at least one storage instance in region 2, and / or the compute instance communicating with the at least one storage instance does not store the target operation, then region 2 does not support access to the first data.

[0282] Correspondingly, such as Figure 3 If storage instance 1, as shown, synchronously persists the first data to at least one storage instance in region 3, and the computing instance communicating with the storage instance also stores the target operation, then region 3 has supported access to the first data.

[0283] On the contrary, such as Figure 3 If the storage instance 1 shown does not synchronously persist the first data to at least one storage instance within region 3, and / or the computing instance communicating with the at least one storage instance does not store the target operation, then region 3 does not support access to the first data.

[0284] Continue to refer to Figure 3 ,exist Figure 3In the cloud scenario shown, the first database system located in region 1 can obtain the second write progress information of region 2 and region 3. The second write progress information of region 2 indicates the write progress of the first data in region 2, for example, indicating the write progress of the first data by the second database system within region 2. The second write progress information of region 3 indicates the write progress of the first data in region 3, for example, indicating the write progress of the first data by the second database system within region 3.

[0285] In this way, the primary database system can obtain the data writing progress of each of the secondary sites on the primary database.

[0286] Step S403: The cloud management platform outputs the first response result for the first data write request.

[0287] The first response result may include first write progress information of the first region and second write progress information of the second region.

[0288] In some embodiments, with Figure 3 For example, the first database system located in region 1 can output a first response result to the first data access request. This first response result can be output to the cloud management platform, allowing the cloud management platform to output the first response result. For example, it can be output to the client that sent the first data write request. Figure 3 The client shown is 102.

[0289] In the above embodiments, for example, multiple regions are data centers in Beijing, Shanghai, and Shenzhen, where the Beijing data center is located at the primary site (i.e., the first site), and the Shanghai and Shenzhen data centers are located at secondary sites (i.e., the second sites). The first response result could include information indicating the first write progress of the first data in Beijing (e.g., access to the first data is supported), information indicating the first write progress of the first data in Shanghai (e.g., the first data has been written), and information indicating the first write progress of the first data in Shenzhen (e.g., the first data has been received). Thus, the first response result received by the client is an access progress at the site level. The client is unaware of the specific physical server (e.g., node or virtual instance) within the site regarding the write progress of the first data.

[0290] In other embodiments, the write progress information for each region included in the first response result can be used to indicate the write progress of a specific physical server or virtual instance within the corresponding region for the first data. In this way, the client can perceive which server or virtual instance in the corresponding region is writing the first data. Both of the above scenarios are... Figure 4a Within the scope of the embodiments.

[0291] In other embodiments, the writing progress of a region for the first data may further include, in addition to indicating that access to the first data is supported, the receipt of the first data and the writing of the first data.

[0292] In other embodiments, the writing progress of a region for the first data may further include, in addition to indicating that the first data has been written, the receipt of the first data.

[0293] In some embodiments, the writing progress information of the first data in different regions in the first response result can be output as a single response result or as multiple response results, so that the writing progress information of the first data in different regions can be output at different times.

[0294] Furthermore, this application embodiment does not limit the specific data format of the first response result or the transmission protocol used to output the first response result.

[0295] For example, the cloud management platform or the first database system of the main site can determine the response result based on the response information of the data access request received from the database systems in different regions (such as the writing progress information of the data corresponding to the data access request, or the transaction execution progress information, without restriction).

[0296] For example, refer to Figure 3 Computing node 11 can receive response information 2 from computing node 12 and response information 3 from computing node 13. After writing the first data to storage node 21, computing node 11 can obtain response information 1. Then computing node 11 can send the above response information 1, response information 2 and response information 3 to the cloud management platform so that the cloud management platform can determine the first response result based on these three response information.

[0297] Alternatively, the cloud management platform can directly access the main site (e.g., Figure 3 The compute node 11 shown receives the first response result and then sends the first response result to the client. For example, the master server (e.g., Figure 3 The computing node 11 shown can receive the above response information from the database systems in different regions, obtain response results based on the above response information from different regions, and then the master server sends the obtained response results to the cloud management platform.

[0298] The first response result may include target information, wherein the target information may indicate first write progress information for a first region and second write progress information for N second regions. The first write progress information is used to indicate the write progress of the first data in the first region, and the second write progress information of a second region is used to indicate the write progress of the first data in that second region.

[0299] The first data access request indicates a request to write first data, and the write progress information of any region regarding the first data access request can be used to indicate the write progress information of that region for the first data.

[0300] For example, in step S403 above, the response result output by the cloud management platform to the first data access request can be one or more, such as the first response result in this embodiment and the second response result in the following embodiments. This application embodiment does not impose specific limitations on this.

[0301] The following is a summary of the above. Figure 4a The response results shown are presented in several possible forms of target information. In specific applications, the target information may have more or fewer forms of representation to indicate the writing progress information of the first data in each of the multiple areas used to achieve data access.

[0302] In some embodiments, Figure 4a The multiple servers in different regions of the embodiments can be physical servers (e.g., compute nodes, storage nodes, etc.) or virtual instances (e.g., compute instances, storage instances, etc.), and this application does not impose any restrictions on this.

[0303] The following example of writing the first data to a virtual instance illustrates the target information. The method is the same when writing the first data to a physical server, so it will not be repeated here.

[0304] In implementation method 1, the target information may include information indicating whether the virtual instance in each region has successfully written or failed to write the first data.

[0305] Each region is used for each of the first region and N second regions mentioned above.

[0306] For example in Figure 3 In the scenario shown, the target information may include information 1 indicating that computing instance 1 and storage instance 1 in region 1 have successfully written the first data, information 2 indicating that computing instance 2 and storage instance 2 in region 2 have successfully or unsuccessfully (i.e. failed) written the first data, and information 3 indicating that computing instance 3 and storage instance 3 in region 3 have successfully or unsuccessfully written the first data.

[0307] In this way, the target information can indicate whether the virtual instance of each region has successfully written the first data and target operation corresponding to the first data access request.

[0308] A successful data write indicates that the first data has been written to the storage instance, and the target operation corresponding to the first data (such as database operations related to a transaction) has also been written to the computing instance that communicates with the storage instance.

[0309] A data write failure indicates that the first data was not fully written to the storage instance, and / or that the target operation corresponding to the first data (e.g., database operations related to a transaction) was not fully written to the compute instance communicating with the storage instance.

[0310] In implementation method 2, the target information may include information indicating that at least one virtual instance in a region has successfully written the first data, while virtual instances in other regions that have not successfully written the first data may not be included in the target information.

[0311] by Figure 3 For example, the target information can carry information 1 indicating that the computing instance 1 and storage instance 1 in the indication area 1 have successfully written the first data. However, the information of virtual instances that have not successfully written the first data can be omitted from the target information, so as to indicate by default that the virtual instance not carried in the target information has not successfully written the first data to the virtual instance.

[0312] For example in Figure 3 In the scenario shown, the target information may include information 1 indicating that computing instance 1 and storage instance 1 in region 1 have successfully written the first data, but does not include information 2 indicating that computing instance 2 and storage instance 2 in region 2 have successfully or unsuccessfully (i.e. failed) written the first data, nor does it include information 3 indicating that computing instance 3 and storage instance 3 in region 3 have successfully or unsuccessfully written the first data, so as to indicate by default that computing instance 2 and storage instance 2 in region 2 have not successfully written the first data, and computing instance 3 and storage instance 3 in region 3 have also not successfully written the first data.

[0313] Implementation method 3, since compute instances or compute nodes can process multiple data access requests in batches, taking data stored in a relational database as an example, these multiple data access requests can correspond to multiple transactions, each with its own identifier (e.g., transaction number). Therefore, the target information can include transaction sequence information consisting of successfully executed transactions in each region's virtual instance. This transaction sequence information can be a sequence of transaction numbers; multiple transactions processed in batches are executed according to a unified order of transaction numbers, regardless of whether they are on the master or slave site.

[0314] by Figure 3 For example, the transaction numbers of 1000 transactions processed in batches in region 1 according to the execution order are 1 to 1000. The transaction number corresponding to the first data access request is 500, and this transaction is called "transaction 500".

[0315] For example, compute instance 1 and storage instance 1 in region 1 have successfully executed transactions 1 to 1000, compute instance 2 and storage instance 2 in region 2 have successfully executed transactions 1 to 600 (indicating that region 2 supports access to the first data of each of transactions 1 to 600), and subsequent transactions have not yet been successfully executed. compute instance 3 and storage instance 3 in region 3 have successfully executed transactions 1 to 400, and subsequent transactions have not yet been successfully executed.

[0316] The target information can include the transaction sequence information corresponding to computation instance 1 and storage instance 1 in region 1: 1, 2, ..., 1000; the transaction sequence information corresponding to computation instance 2 and storage instance 2 in region 2: 1, 2, ..., 600; and the transaction sequence information corresponding to computation instance 3 and storage instance 3 in region 3: 1, 2, ..., 400.

[0317] In this way, the cloud management platform can determine, based on the received target information, that compute instance 1 and storage instance 1 in region 1, compute instance 2 and storage instance 2 in region 2 have successfully executed transaction 500, while compute instance 3 and storage instance 3 in region 3 have not yet successfully executed transaction 500.

[0318] Implementation method 4 is based on the same principle as implementation method 3, the difference being that the target information can include transaction sequence information consisting of transactions that have been successfully executed by virtual instances in at least one region (including the first region, and optionally the second region). For virtual instances in the corresponding region where no transaction has been successfully executed, the transaction sequence information corresponding to the virtual instances in that region will not be reflected in the target information.

[0319] In other words, for virtual instances not mentioned in the target information, it means that these virtual instances did not obtain the sequence of successfully executed transactions, that is, it means that these virtual instances did not successfully execute any of the multiple transactions in the batch processing.

[0320] Taking the specific example of implementation method 3, if computation instance 2 and storage instance 2 in region 2, and computation instance 3 and storage instance 3 in region 3 have not successfully executed transactions 1 to 1000, then the transaction sequence information corresponding to computation instance 2 and storage instance 2 in region 2, and computation instance 3 and storage instance 3 in region 3 will not be reflected in the target information, so as to indicate that by default, computation instance 2 and storage instance 2 in region 2, and computation instance 3 and storage instance 3 in region 3 have not successfully executed all transactions.

[0321] The target information can include the transaction sequence information corresponding to computation instance 1 and storage instance 1 of region 1: 1, 2, ..., 1000, but does not include the transaction sequence information corresponding to computation instance 2 and storage instance 2 of region 2, nor does it include the transaction sequence information corresponding to computation instance 3 and storage instance 3 of region 3.

[0322] In this way, the cloud management platform can determine, based on the received target information, that compute instance 1 and storage instance 1 in region 1 have successfully executed transactions 1 to 1000, while compute instance 2 and storage instance 2 in region 2, and compute instance 3 and storage instance 3 in region 3 have not successfully executed any of the transactions.

[0323] In implementation method 5, the target information may include the transaction number of the most recently successfully executed transaction in each region (optionally, a virtual instance within a site). For example, the first and second write progress information described in the embodiments of this application may be used as transaction numbers to indicate the write progress of the most recently responded data access request (corresponding to the data to be written).

[0324] Referring to the specific example of implementation method 3, the transaction number of the most recently successfully executed transaction for compute instance 1 and storage instance 1 in region 1 is 1000; the transaction number of the most recently successfully executed transaction for compute instance 2 and storage instance 2 in region 2 is 600; and the transaction number of the most recently successfully executed transaction for compute instance 3 and storage instance 3 in region 3 is 400. The transaction number corresponding to the first data access request is 500.

[0325] The target information can include the transaction number of the most recently successfully executed transaction of compute instance 1 and storage instance 1 in region 1: 1000, the transaction number of the most recently successfully executed transaction of compute instance 2 and storage instance 2 in region 2: 600, and the transaction number of the most recently successfully executed transaction of compute instance 3 and storage instance 3 in region 3: 400.

[0326] In this way, the cloud management platform can determine, based on the received target information, that compute instance 1 and storage instance 1 in region 1, and compute instance 2 and storage instance 2 in region 2 have successfully executed transaction 500, while compute instance 3 and storage instance 3 in region 3 have not yet successfully executed transaction 500.

[0327] Implementation method 6 is based on the same principle as implementation method 5, the difference being that the target information may include the transaction number of the most recently successfully executed transaction of a virtual instance in at least one region. If a virtual instance in a region fails to execute any of the aforementioned batch of 1000 transactions (transactions 1 to 1000), the transaction number corresponding to the virtual instance in that region will not be reflected in the target information.

[0328] Because transactions are executed sequentially according to their transaction numbers, virtual instances not mentioned in the target information indicate that these virtual instances failed to successfully execute any of the multiple transactions in the batch processing.

[0329] For example, compute instance 1 and storage instance 1 in region 1 have successfully executed transactions 1 to 1000, compute instance 2 and storage instance 2 in region 2 have successfully executed transactions 1 to 600, while compute instance 3 and storage instance 3 in region 3 have not yet successfully executed transaction 1.

[0330] The target information can include the transaction number of compute instance 1 and storage instance 1 in region 1: 1000, and the transaction number of compute instance 2 and storage instance 2 in region 2: 600. It does not include the transaction number of compute instance 3 and storage instance 3 in region 3 (there is actually no corresponding transaction number), which means that compute instance 3 and storage instance 3 in region 3 have not yet successfully executed transaction 1.

[0331] In this way, the cloud management platform can determine, based on the received target information, that compute instance 1 and storage instance 1 in region 1, and compute instance 2 and storage instance 2 in region 2 have successfully executed transaction 500, while compute instance 3 and storage instance 3 in region 3 have not yet successfully executed transaction 500 (for example, they have not yet successfully executed transaction 1).

[0332] The following is combined Figure 5a The methods of the above embodiments will now be described. Figure 5a The architecture shown can be combined Figure 3 The architecture shown is used for implementation; no restrictions are imposed here.

[0333] Please refer to Figure 5a Taking data stored in a relational database as an example, the first data access request received by a computing node can be a transaction. A cross-regional cloud service system includes a first site (also called the "master site") and a second site (also called the "slave site") that are physically far apart. The first site may include, but is not limited to: client cluster 800 located in the first region, computing instance 1 (also called the "master engine") located in the first region, and storage instance 1 (also called the "master database") located in the first region. The second site may include, but is not limited to: client 103 located in the second region, computing instance 2 (also called the "slave engine 2") located in the second region, and storage instance 2 (also called the "slave database 2") located in the second region.

[0334] It should be understood that a master database can correspond to more or fewer slave databases, and a slave database can correspond to multiple different master databases. Here, we will use the example of one master database corresponding to one slave database as described above. Figure 3The system shown, with one master database and two slave databases, is a preferred cross-regional system.

[0335] For example, the main engine can process a batch (multiple) of transactions at a time, and the processing method for each transaction is similar. The following explanation uses a single transaction as an example. Figure 5a The calculation example shown is 1 (i.e., the main engine) to execute. Figure 4a The method shown is used as an example to illustrate the principle. The same principle applies when the executing subject is another object.

[0336] Please refer to Figure 5a Steps 1 and 2 in the process:

[0337] First, as shown in step 1, the main engine may receive a data access request (an example of a first data access request) sent by client 102 in client cluster 800. Then, the main engine obtains transaction 1 based on the received data access request and executes transaction 1 (e.g., writing the various database operations corresponding to transaction 1 into memory). The database operations are the target operations described in the above embodiments. And, as shown in step 2, the main engine writes first data (e.g., data 1) to the main database according to the database operations involved in transaction 1, so as to achieve persistent storage of the first data (data 1) corresponding to the database operations at the first site.

[0338] There are several ways to implement the subsequent process, which will be introduced below.

[0339] For the first implementation method, please refer to step 2. Figure 5a In step 3, after the primary database writes the first data, it sends a response indicating that transaction 1 has been successfully written to the primary database to the main engine.

[0340] For example, if the response result is information about the most recently successfully executed transaction of each computing instance in implementation method 5 above, then the response result may include information indicating that computing instance 1 has successfully executed transaction 1.

[0341] Meanwhile, after step 3, as shown in step 4, the master database of the first site also synchronizes the storage data of transaction 1 to the slave database 2 of the second site. That is, the master database sends the first data corresponding to transaction 1 to the slave database 2 so that the slave database 2 can write the first data to achieve persistent storage of the first data at the second site.

[0342] In some embodiments, after writing the first data, the slave 2 can also send write progress information (e.g., an example of second write progress information) to the master engine through the master library, indicating that the first data has been written to the second area.

[0343] Subsequently, as shown in steps 5.1 and 5.2, slave database 2 sends the simulated database operation (e.g., a log, an example of the target operation described above) obtained based on the written first data to slave engine 2. After receiving the simulated database operation, slave engine 2 returns the transaction execution progress information 1 (indicating that the most recently successfully executed transaction by slave engine 2 is transaction 1) to slave database 2. The explanation of transaction execution progress information 1 will be elaborated later. This transaction execution progress information 1 indicates that the second area now supports access to the information of the first data.

[0344] For example, if transaction 1 includes multiple database operations, slave database 2 can report a simulated database operation to slave engine 2 for each database operation data persisted. Alternatively, slave database 2 can also report simulated database operations corresponding to multiple data items after persisting multiple database operations to slave engine 2 in batches.

[0345] For example, Engine 2 can return transaction execution progress information once for each simulated database operation corresponding to a transaction, or after obtaining a batch of simulated database operations corresponding to transactions.

[0346] In this embodiment of the application, after receiving the first data sent by the master database from the slave database 2, the first data can be persistently written to a storage device (e.g., Figure 3 (See storage node 22). However, engine 2 has not yet recorded the database operations related to the first data in transaction 1, making it impossible for clients at the second site (e.g., client 103) to access the first data through engine 2. Therefore, slave database 2 can obtain simulated database operations based on the first data and send these operations to engine 2, allowing engine 2's memory to record the database operations for the synchronized first data. In this way, when the primary engine fails and data in the primary database becomes inaccessible, any client in the client cluster 800 or client 103 at the second site can access the data stored in slave database 2, such as the first data, through engine 2, ensuring high availability and cross-regional access.

[0347] Afterwards, following steps 4, 5.1, and 5.2, as shown in step 6, slave database 2 sends the response indicating successful first data write and transaction execution progress information 1 from slave engine 2 to master database in a single data interaction, so that master database receives the response indicating successful write from slave database 2 and the transaction execution progress information 1.

[0348] For example, when transaction 1 has multiple operations, during the process of persistently storing the first data in slave database 2, after each of the multiple operations, the slave database 2 can return a response indicating that the data was successfully written to the master database in real time, until the first data corresponding to all the multiple operations is persisted to slave database 2.

[0349] In the above Figure 5a In this embodiment, after the master database writes the first data, it can execute step 3 to send a response to the main engine to indicate that the master database has successfully written the data; after the slave database 2 writes the first data, the master database can send the response result from step 6 back to the main engine. This scheme is an asynchronous access scheme for the master database.

[0350] In other embodiments, when the master engine issues transaction 1 in step 2, it can instruct the master database to perform synchronous access. Specifically, after the master database writes the first data, it can not return a response in step 3. Instead, after receiving the response result of the slave database 2 writing successfully as shown in step 6, it can send the response result of transaction 1 in step 3 to the master engine. The response result can include information indicating that the master database has completed writing the first data and information indicating that the slave database 2 has completed writing the first data, so as to reduce communication overhead.

[0351] Referring to the above text Figure 1a The related technologies involve synchronizing data from the master site to the slave site. This is achieved by the master engine (server-side) transmitting database operation logs related to transactions to the slave engine. The large volume of this log data results in a lengthy synchronization process. Furthermore, the master engine can only respond to client requests after synchronization, leading to extended response times for client data access requests.

[0352] However, in this embodiment of the application, when synchronizing data from the first area located at the master site to the second area located at the slave site, the synchronized data is unloaded from the service layer to the storage layer. Specifically, data (e.g., physical logs) is synchronized between the master storage device (e.g., master database 1) and the slave storage device (e.g., slave database 2). The synchronized data is the actual data written to the master storage device based on data access requests, specifically the first data (e.g., physical logs). Compared to the data synchronized by the server (e.g., logical logs including various database operations), the first data does not involve data encapsulation. The physical logs have a smaller data volume than the logical logs, thereby reducing the time used for data synchronization and thus reducing the client's response latency.

[0353] Furthermore, the data synchronization process in related technologies involves data transfer from the main engine to the slave engine, data transfer from the slave engine to the slave database, and data transfer from the slave engine to the main engine (e.g., Figure 1a The data transmission process in solid steps 3 to 5 (as described in the solid line step), while the data synchronization process in this embodiment only requires one round trip data transmission between the master and slave databases (e.g., ...). Figure 5a The data transmission process in steps 4 to 6). Because the communication speed within the area is very fast, the data transmission within the second area (e.g.) Figure 5a Steps 5.1 and 5.2 are very fast and have almost no impact on latency. Compared with related technologies, the data synchronization process in this embodiment has a shorter path between different sites, which can further reduce the time used for data synchronization and thus further reduce the client's response latency.

[0354] Furthermore, in implementation method 1 of the related technologies, when the main engine returns the response result to the client, the slave database has not yet performed persistent processing on the data accessed by the client, which cannot reliably guarantee high availability of data in failure scenarios. However, in this embodiment, data replication is performed on the storage side. This ensures that when the main engine returns a response result to the client indicating that the slave server and slave storage device have successfully written the first data, the slave storage device has already completed the persistent storage of the first data, guaranteeing high availability of data in failure scenarios. Even if the main engine returns the response result to the client, such as... Figure 5a Steps 5.1 and 5.2 shown have not yet been completed, meaning the simulated database operations related to the first data have not yet been stored on the slave server (e.g., slave engine 2). However, after the second database system restarts, slave 2 can send the simulated database operations related to the first data to slave engine 2 to store the database operations, thus ensuring that access to the first data in the second region is not affected and that high data availability is guaranteed.

[0355] In this way, when the main engine fails and the data in the main database becomes inaccessible, any client in the client cluster 800 or client 103 of the second site can access the data stored in the slave database 2, such as the first data, through engine 2, to ensure high availability and cross-regional access to the data.

[0356] For example, the transaction execution progress information 1 received by the master engine from slave engine 2 indicates the most recently successfully executed transaction in the second region's computing instance 2. This means that transaction 1 was successfully executed in computing instance 2; in other words, the database operations of transaction 1 and the first data have been backed up and stored in the second region's computing instance 2 and storage instance 2, respectively. Thus, the transaction execution progress information sent by slave engine 2 indicates that the second region now supports access to the first data. The transaction number corresponding to this first data is the transaction number in the transaction execution progress information.

[0357] Then, as shown in step 7, the master database can send the response indicating that the slave database 2 has successfully written the transaction and the transaction execution progress information 1 regarding computation instance 2 to the master engine. In this way, the master engine can not only obtain the master database's response indicating that transaction 1 has successfully written the transaction through step 3, thereby obtaining the master engine's transaction execution progress information; moreover, the master engine can also obtain the slave engine 2's transaction execution progress information 1 through step 7.

[0358] Finally, as shown in step 8, the main engine can return a response indicating that the write to slave 2 was successful and transaction execution progress information 1 to client 1.

[0359] The second implementation differs from the first in that, after step 4, step 6 can be executed first, followed by steps 5.1 and 5.2. This way, the information indicating successful writing of the first data to slave database 2 can be returned to the master engine via step 6. After steps 5.1 and 5.2, slave engine 2 can send transaction execution progress information 1 to the master database via slave database 2 for return to the master engine. Thus, the master engine can first receive the response from slave database 2 indicating successful persistence of the first data, and then receive the transaction execution progress information 1 from slave engine 2.

[0360] In the second implementation, for a data access request, the second site sends two data to the first site: a response indicating that the first data was successfully written from the slave database 2 and transaction execution progress information 1 from the slave engine 2. This method can be used when bandwidth is large, while the first implementation method can be used when bandwidth is small.

[0361] The third implementation differs from the second in that, instead of sending the transaction execution progress information 1 to the first site through slave database 2, engine 2 does so as follows: Figure 5a As shown by the dashed arrow, the transaction execution progress information 1 is sent directly from engine 2 to the main engine to synchronize the transaction execution progress information 1 of computing instance 2 to computing instance 1. However, this also involves two data transmissions. Therefore, if bandwidth allows, the synchronization of transaction progress information 1 can be achieved through a third implementation method.

[0362] The fourth implementation differs from the first or second implementation in that, after step 2, the master database does not send the response indicating that transaction 1 was successfully written in the master database to the master engine. Instead, it sends the response indicating that transaction 1 was successfully written in the master database and the transaction execution progress information 1 sent by slave database 2 to the master engine.

[0363] Regardless of which of the first to fourth implementation methods mentioned above, the main engine can receive the response result of the main database to transaction 1 (e.g., the first data was successfully written) through step 3. Before step 2, the main engine has already stored the relevant database operations of transaction 1. In this way, the main engine can obtain its own transaction execution progress information (represented by transaction execution progress information 0).

[0364] Furthermore, regardless of which of the above implementation methods (first to fourth), after engine 2 saves the simulated database operations for transaction 1 in step 5.1, the main engine can obtain the transaction execution progress information 1 from engine 2. For example, Figure 5a The ① near engine 2 indicates that engine 2 has synchronized the stored data of transaction 1 and the corresponding first data written to the slave database 2 for transaction 1.

[0365] For example, if transaction 1 is the first transaction among multiple transactions processed by the main engine, then before the slave engine 2 saves the simulated database operations about transaction 1 in step 5.1, the main engine cannot receive the transaction execution progress of the slave engine 2, so the transaction execution progress of the slave engine 2 is 0, that is, no transaction has been completed.

[0366] Similarly, such as Figure 5a The ① next to the main engine indicates that the main engine writes the first data based on the data access request. Specifically, it means that the main engine has supported accessing the first data of transaction 1. For example, the main engine has saved the database operation of transaction 1 and the corresponding first data of transaction 1 written to the main database 1.

[0367] In some embodiments, in order to reduce the response latency of the client (e.g., client 102 in client cluster 800) to the data access request in step 1, the main engine may, after receiving the response result in step 3, indicate that the main engine and the main database have written the database operation and the first data corresponding to the data access request, and then return the first response result of the data access request to the client in step 8, so as to reduce the client's latency.

[0368] In this way, the first response result output by the first database system (specifically the main engine and the main database) can indicate that the first area has written the first data and supports access to the first data, but the second area has received the first data but has not yet written the first data.

[0369] In some embodiments, in order to ensure high availability of the first data written, the main engine may output the first response result based on the most recently successfully executed transaction corresponding to the two transaction execution progress information after receiving the response result of step 3 (thereby obtaining the transaction execution progress information 0 of the main engine) and after receiving the transaction execution progress information 1 of the slave engine 2.

[0370] For example, the first response result may indicate that both the main engine and the slave engine 2 have written to and supported access to the first data in the data access request.

[0371] In some embodiments, the number of virtual instances within each site is not limited to, for example, Figure 5a Given a set of instances (one compute instance and one storage instance), the main engine can return a response result to the client only if more than half of the compute instances in both sites successfully execute transaction 1.

[0372] For example, the first response result may indicate information about the computing instance for which the data access request has been successfully executed, and optionally may also include information about the computing instance for which the data access request has not been successfully executed.

[0373] This application embodiment does not limit the timing of the main engine or other execution entities outputting the first response result, and can be flexibly varied according to application scenarios and requirements. The key point is that the first response result output by the method of this application embodiment (output simultaneously or at different times) can reflect the writing progress of the first data corresponding to the data access request from different sites.

[0374] In some embodiments, the write progress of the same transaction's data (e.g., the first data) may differ across different regions. Therefore, the first response output by the main engine to the client may only include write progress information for the first region that supports access to the first data, excluding write progress information for the second region that supports access to the first data. The client can then obtain the write progress of the requested region, server, or computing instance for the first data from the main engine by sending a query request (indicating a query for the write progress of the first data) to the main engine.

[0375] In some embodiments, data access requests can be categorized into critical data access requests and non-critical data access requests.

[0376] The response process for critical data access requests may include storing the first data in a first area and backing up the first data to at least one second area.

[0377] The response process for non-critical data access requests may include storing the first data in a first area without copying the first data from the first area to at least one second area.

[0378] For example, non-critical data access requests may include, but are not limited to: log cleanup requests, file expansion requests, buffer swapping requests, checkpoint generation requests, snapshot backup requests, and add-to-cart requests. Therefore, when the data access request received by the first region is a non-critical data access request, the first region can write the target operation corresponding to the request through the main engine, and write the first data to the main database.

[0379] For example, a critical data access request can be a request other than the non-critical data access requests mentioned above, such as an order placement request. In this case, the first region not only needs to write the target operation and the first data in the first region based on the request, but also needs to synchronize the first data to the second region for storage.

[0380] Because the link bandwidth between different regions is limited, in order to make efficient use of the link bandwidth between different regions and improve the speed of business replication, non-critical business related to non-critical data access requests can be processed locally instead of being synchronized to other regions.

[0381] In related technologies, the main engine of a primary site can only return one response result to a client's data access request, and this response result can only indicate whether the data access was successful on the primary site side, preventing the client from accessing services across regions. However, in this embodiment, the response result output by the first database system to a client's data access request (here, a data write request) in a first region can include not only the write progress information of the first data in the first region that received the data access request, but also the write progress information of the first data in the second region. For example, the first database system can output the response result to the client that sent the data access request. This allows the client to obtain the write progress of the first data in different regions based on the response result, determining which region to forward subsequent data access requests to, facilitating cross-regional data access and enabling global business operations.

[0382] For example, consider a shopping website deployed across multiple regions. The first region is in country 1, and the second region is in country 2. Client 1, located in country 1, submits an order request via session 1 (e.g., account information). The solution in this embodiment routes this order request to server 1 in country 1, which is the closest available server. Client 1 receives a response, which includes not only information on whether the order was successfully placed in country 1 but also whether the order data has been synchronized to country 2. Thus, if the order data has been synchronized to country 2, client 1 can access the shopping website in country 2 and submit another order request, which will be processed by the second region in country 2, enabling global business operations. Furthermore, the data stored on storage devices in different countries is synchronized, ensuring data integrity and accuracy while facilitating client access to global business operations.

[0383] In some embodiments, the first data access request can also be a request to read data. The implementation process of this data access method is illustrated below using data reading at the granularity of a virtual instance as an example. The method is similar when reading data at the node granularity, and will not be repeated here.

[0384] Please refer to Figure 3 For example, after receiving the response to the first data access request, client 102 can issue a corresponding data access request for a read operation (such as data access request 2). Then, client 102 can first obtain the writing progress information of the first data in regions 1, 2, and 3 based on the response to the first data access request. Examples of several cases are given below.

[0385] Case 1: For example, client 102 receives information that compute instance 1 and storage instance 1 in region 1 have successfully executed the first data access request (an example of supporting access to the first data), and information that virtual instances in other regions have not successfully executed the first data access request (an example of indicating that the first data has not been received, or that the first data has not been written, or that access to the first data is not supported).

[0386] Then, client 102 can send data access request 2 through a cloud management platform (e.g., ...). Figure 2a The cloud management platform (as shown) issues a data access request 2 to compute instance 1. After receiving the data access request 2, compute instance 1 can read data from storage instance 1. After successfully reading the data, compute instance 1 can return the read data to client 102.

[0387] Scenario 2, for example, client 102 receives information that compute instance 1 and storage instance 1 in region 1, compute instance 2 and storage instance 2 in region 2 have successfully executed the first data access request, while the virtual instances in region 3 have not successfully executed the first data access request (an example indicating that the first data was not received).

[0388] Therefore, client 102 can operate as described in scenario 1 above, or it can route data access request 2 to client 103 in region 2. Client 103 can then access the data through a cloud management platform (e.g., ...). Figure 2a The cloud management platform shown sends data access request 2 to compute instance 2, enabling compute instance 2 to read data from read storage instance 2. After compute instance 2 successfully reads the data, it can send the read data to compute instance 1, which then sends the read data to client 102.

[0389] Case 3, for example, client 102 receives information that compute instance 1 and storage instance 1 in region 1, compute instance 2 and storage instance 2 in region 2, and compute instance 3 and storage instance 3 in region 3, all three regions have successfully executed the first data access request (an example that already supports access to the first data).

[0390] Then, client 102 can route to client 104 in region 3 as described in case 1 or case 2 above, or similarly to case 2 above, so that compute instance 3 and storage instance 3 can execute data access request 2.

[0391] In some embodiments, client 102 may also combine the proximity principle of the region and / or the agreed reading rules to determine the virtual instance to execute data access request 2. This application embodiment does not limit this.

[0392] Combined with Figures 3 to 5a For any of the embodiments, please refer to Figure 4b , Figure 4b This is a flowchart illustrating another data access method provided in an embodiment of this application. The application scenarios for this data access method can be referred to... Figure 4a The embodiments below describe the application scenarios. The following uses the application of the method of this application to the aforementioned cloud management platform as an example to illustrate the methods of various embodiments of this application. This method can also be applied to the aforementioned cloud service system.

[0393] Combined with Figure 4a Before step S403, the method may further include: steps S501, S502, S503, and S504.

[0394] In step S501, the cloud management platform receives the second data access request.

[0395] In some embodiments, when a second data access request indicates that data should be written, the second data access request can be named a second data write request. Similarly, when a first data access request indicates that data should be written, the first data access request can be named a first data write request.

[0396] In some embodiments, the second data write request and the first data write request are the same batch of data write requests processed by the first database system, and the response order of the second data write request precedes the response order of the first data write request.

[0397] In some embodiments, a second data write request is used to indicate second data to be written to a first region.

[0398] The first data write request and the second data write request can be the same batch of data access requests processed by the first database system. However, the first database system responds to the second data write request before responding to the first data write request, so that the second data can be written to the first database system before the first data.

[0399] In step S502, the cloud management platform, based on the second data access request, notifies the first database system to write the second data and notifies the first database system to send the written second data to the second area.

[0400] In some embodiments, the first database system receives a second data write request, which indicates the second data to be written.

[0401] In some embodiments, the first database system may write second data based on a second data write request and obtain write progress information for the second data in the first region. This process is similar to... Figure 4a The principle of the first database system obtaining the first write progress information of the first region as described in the embodiment is similar, the only difference being that the second data is the data written by the first database system before the first data.

[0402] Then, the first database system can send the second data to the second database system to facilitate highly available storage of the second data.

[0403] Step S503: The cloud management platform obtains the third write progress information of the second region.

[0404] In some embodiments, the third write progress information is used to indicate the write progress of the second data corresponding to the most recently responded second data write request in the second region.

[0405] In this embodiment, the second region has not yet been written with the first data, and its most recent response to a data write request is a second data write request from the first database system.

[0406] In some embodiments, the first database system may obtain third write progress information for the second region.

[0407] The third write progress information indicates the writing progress of the second data in the second area. The third write progress information may include at least one of the following: information indicating that the second data has been received; information indicating that the second data has been written; information indicating that access to the second data is supported.

[0408] Regarding the third write progress information and the above... Figure 4a The second write progress information of the second region mentioned in the embodiment is similar, except that the third write progress information is the write progress of the second region to the second data, while the second write progress information is the write progress of the second region to the first data. This will not be elaborated here.

[0409] In step S504, the cloud management platform outputs a third response result in response to the first data access request.

[0410] In some embodiments, the third response result includes first write progress information (e.g., as described above). Figure 4a The first write progress information and the third write progress information obtained from S4012.

[0411] In other words, in this embodiment, the first database system has completed writing the second data and related database operations, and synchronized the second data to the second database system. Thus, the first database system can obtain the third writing progress information of the second data in the second region where the second database system is located. Furthermore, the first database system can also write the first data and related database operations to obtain the first writing progress information of the first data in the first region.

[0412] Thus, in such Figure 4a Prior to S403, in some embodiments, the first database system may output a third response result to the first data write request, for example, outputting the third response result to the cloud management platform so that the cloud management platform outputs the third response result.

[0413] In this embodiment, the first database system already supports access to the second data, and the second database system's most recently written data is the second data. Therefore, the writing progress of the second data in the second region could be that it has been persisted, access is now supported, or the second data has been received. Meanwhile, the first database system has persisted and supports access to the second data, and is further writing the first data; that is, the first database system's data writing progress for a batch of data access requests is faster than that of the second database system. Therefore, the third response result can include the first writing progress information of the first region for the first data, and the third writing progress information of the second region for the second data.

[0414] by Figure 3 Taking the cloud scenario shown as an example:

[0415] For example, the first region is as follows: Figure 3 The area shown is region 1. The second region consists of two parts, region 2 and region 3.

[0416] Although the first data corresponding to the first data access request can be written to region 1 located at the main site and needs to be synchronized from region 1 to region 2 and region 3, the synchronization progress of each region may not be consistent, or a device in a certain region may fail, or the communication link between the first region and the second region may fail. Thus, computing instance 1 in region 1 can obtain the writing progress information of the first data in region 1 (including the writing progress of computing instance 1 and storage instance 1 respectively), computing instance 1 can obtain the writing progress information of the first data in region 2 (including the writing progress of computing instance 2 and storage instance 2 respectively), and computing instance 1 can obtain the writing progress information of the second data in region 3 (including the writing progress of computing instance 3 and storage instance 3 respectively). Because region 3 has not yet received the second data sent from the first database system of region 1 (e.g., computing instance 1 and storage instance 1) to the second database system of region 3 (e.g., computing instance 3 and storage instance 3), the most recent data access request responded to by region 3 was a second data access request, and therefore the writing progress information of the second region sent to the first database system is also the writing progress of the second data.

[0417] A database system's successful response to a data access request indicates that the system saves the database operation corresponding to the request and persistently stores the data to be written corresponding to that operation.

[0418] Taking data access requests as an example of transactions, the write progress information mentioned in any of the above embodiments can be as described above. Figure 5a The transaction execution progress information mentioned in the embodiment is, for example, information about the most recently successfully executed transaction of the corresponding server or virtual instance.

[0419] As described above, the method in this application embodiment can handle multiple transactions.

[0420] by Figure 5b For example, multiple clients within a client cluster of 800 can issue 1000 data access requests within a certain time (e.g., 1 second). The main engine can divide the received 1000 data access requests into multiple batches, processing each batch of data access requests at a time. For example, if divided into 10 batches, the main engine will process 100 data access requests at a time (e.g., transactions), such as transactions 1 to 100. These transactions are ordered sequentially, and different sites (e.g., ...) Figure 5b The first to third stations shown in the diagram perform data writing (the first station performs the writing) and backup (the second and third stations back up the data written by the first station) in the same transaction order.

[0421] In some embodiments, the write progress information of the first area where the first database system is located is generally up-to-date, because the first database system is used to write data based on the first data access request, while the second database system is used to store a data copy of the data written by the first database system to achieve a backup effect.

[0422] In some embodiments, when there are multiple second regions, the second data access request that was most recently successfully responded to in the third write progress information of the second database system on a second region may be the first data access request, indicating that the second database system has also written the first data synchronous backup to the local second database system. For example, if the first data access request is transaction 3 in transaction 1 to transaction 100, then the second data access request may be transaction 3.

[0423] In some embodiments, when there are multiple second regions, the second data access request that most recently responded successfully, as indicated in the third write progress information of the second database system on a second region, can also be a data access request whose execution order (also known as response order) precedes the first data access request. For example, if the first data access request is transaction 3 among transactions 1 to 100, then the second data access request can be either transaction 1 or transaction 2.

[0424] In some embodiments, due to a second database system (e.g., such as...) Figure 5b The computation instance 2 and storage instance 2 shown can also process multiple data access requests (e.g., transactions) in batches. In this case, the second database system can return write progress information once for each successful response to a data access request, or return write progress information again when multiple data access requests are successfully responded to. Thus, the second data access request corresponding to the third write progress information for one second database system can be one or more, without limitation.

[0425] For example, the write progress information mentioned in any of the above embodiments can be as described above. Figure 4a The transaction execution progress information is described in the embodiments.

[0426] In some embodiments, the cloud management platform can directly receive transaction execution progress information sent by the first database system and at least one second database system, or the cloud management platform can also receive response results indicating successful transaction write from the first database system and at least one second database system, and obtain the transaction execution progress information of the corresponding database system based on this.

[0427] The following is combined Figure 5b Let me explain the above process in detail. Figure 5b The architecture shown can be combined Figure 3 The architecture shown is used for implementation; no restrictions are imposed here.

[0428] Please refer to Figure 5b Using a relational database as an example, the first data access request can be a transaction. A cross-regional system can include a first site (also called the "master site"), a second site (also called "slave site 2"), and a third site (also called "slave site 3") that are physically far apart. In a cloud scenario, the first site can be as follows: Figure 3 The station shown is for area 1. The second station can be the station for area 2, and the third station can be the station for area 3.

[0429] In this embodiment, the master site can receive data access requests sent by any client (e.g., a first data access request from client cluster 800) and respond to the data access request to write first data. Slave sites 2 and 3 act as slave sites of the master site. The master site can not only write the first data on the master site but also synchronize the first data to slave sites 2 and 3, so that slave sites 2 and 3 can store data copies of the first data requested to be written by any data access request received by the master site.

[0430] For details regarding the first and second sites during this synchronization process, please refer to [link / reference]. Figure 5a Related information.

[0431] Figure 5b The interaction process between the first database system of the first site and the second database system of the third site, and Figure 5a The interaction process between the first database system at the first site and the second database system at the second site follows the same principle; and the process of the second database system at the third site backing up and storing data is also the same. Figure 5aThe backup and storage process for the second database system at the second site shown is the same. The differences will be explained below; for similarities, please refer to [link / reference needed]. Figure 5a Related information.

[0432] like Figure 5b As shown, the third site may include client 104, compute instance 3 (also referred to as "engine 3"), and storage instance 3 (also referred to as "database 3"). Compute instance 3 and storage instance 3 are located as follows: Figure 3 Area 3 is shown.

[0433] For example, such as Figure 5b The batch of data access requests received by the main engine from client cluster 800 corresponds to a batch of transactions, numbered sequentially from transaction 1 to transaction 100. For example, the first data access request currently being processed by the main engine is transaction 3 within transaction 1 to transaction 100.

[0434] like Figure 5b As shown, after the main engine writes the data of transactions 1 to 3 to the main database in sequence, it can obtain the transaction execution progress information 0' of the main engine (an example of the first write progress information). The transaction execution progress information 0' includes the information of the most recently successfully executed transaction of the main engine (here, transaction 3). The ③ next to the main engine represents transaction 3 in the transaction execution progress information 0'.

[0435] In addition, after the main engine writes the data of a transaction to the primary database, it can also synchronize the storage data of the transaction to the secondary database 2 at the second site and to the secondary database 3 at the third site through data synchronization between storage instances.

[0436] The process of synchronizing the stored data (including the initial data and corresponding database operations) for each transaction from the first site to the second site (or to the third site) can be referred to the above. Figure 5a Steps 4, 5.1, 5.2, and 6 will not be repeated here.

[0437] According to this data synchronization process, slave database 2 synchronized the data to be written corresponding to transactions 1 to 3 from the master database, and slave engine 2 also stored the database operations corresponding to transactions 1 to 3. Thus, the most recently successfully executed transaction indicated in the transaction execution progress 1' of slave engine 2 (the transaction among the aforementioned 100 transactions synchronizing data from the first site to the second site) is transaction 3. Figure 5b In the diagram, ③ next to engine 2 represents transaction 3 in transaction execution progress information 1'. This transaction execution progress information 1' indicates that the second area located at the second site has supported access to the first data corresponding to transaction 3.

[0438] In some embodiments, whether it is the main engine or the slave engine, it can update the transaction number (the transaction number of the most recently successfully executed transaction) in its own transaction execution progress information once after each successful execution of a transaction, or update the transaction number (the transaction number of the most recently successfully executed transaction) in its own transaction execution progress information once after each successful execution of multiple transactions. There is no limitation here.

[0439] After that, the main engine can receive the transaction execution progress information 1' sent from engine 2.

[0440] In some embodiments, after slave database 2 synchronizes the first data corresponding to transaction 3 from master database and writes the first data to slave database 2, slave database 2 can also send information to the master engine through master database indicating that the first data corresponding to transaction 3 has been written to the second area located at the second site. This information can be named the transaction execution progress information on the storage instance 2 side. Thus, in situations such as... Figure 5b Before step 5.2 shown, the writing progress of the first data corresponding to transaction 3 in the second area of ​​the second site is information indicating that the first data has been written to the second area.

[0441] Similarly, the main engine can also receive transaction execution progress information 2' sent from engine 3. This transaction execution progress information 2' may include the transaction number of the most recently successfully executed transaction among the aforementioned 100 transactions by engine 3. Figure 5b In the context of Engine 3, ② next to Engine 3 represents Transaction 2 in Transaction Execution Progress Information 2'. Transaction 2 is the most recently successfully executed transaction indicated in Transaction Execution Progress 2' of Engine 3 (which is one of the aforementioned 100 transactions synchronizing data from the first site to the second site).

[0442] In this way, the database system of the third site's region (an example of the second region) (specifically including engine 3 and slave database 3) most recently responded to the second data access request as transaction 2. Slave database 3 has persistently written the second data corresponding to transaction 2 from the master database (i.e., the second data requested to be written in the second data access request) to slave database 3. Furthermore, engine 3 has saved the database operation corresponding to the second data. Thus, the transaction execution progress information 2' can indicate that the second region located at the third site now supports access to the second data corresponding to transaction 2. Slave engine 3 can then send the transaction execution progress information 2' to the master engine through slave database 3 and the master database, enabling the master engine of the first region to receive the third write progress information (e.g., the transaction execution progress information 2') from the second region (e.g., region 3) where the third site is located.

[0443] In some embodiments, after the slave database 3 synchronizes the second data corresponding to transaction 2 from the master database and writes the second data to the slave database 3, the slave database 3 can also send transaction execution progress information indicating that the second area located at the third site has written the second data corresponding to transaction 2 to the master engine through the master database.

[0444] Then, the main engine can flexibly determine the timing of outputting the response result based on the transaction execution progress information 0' of the main engine, the transaction execution progress information 1' of the slave engine 2, and the transaction execution progress information 2' of the slave engine 3, and output the corresponding response result to the corresponding client in the client cluster 800.

[0445] For example in Figure 4b In the scenario of the embodiment, the main engine can output a third response result to the cloud management platform for the first data access request (here, transaction 3). The third response result may include: first write progress information and third write progress information.

[0446] The first write progress information can be as follows: Figure 5b The first site shown in the diagram is located in region 1. The write progress information (e.g., information that access is supported) for the first data (specifically, the data written to the primary database corresponding to transaction 3).

[0447] Figure 5b In this scenario, the second area consists of two regions: region 2, where the second station is located, and region 3, where the third station is located.

[0448] The third response result may include the third write progress information of region 2 and the third write progress information of region 3.

[0449] The third write progress information in region 2 can be as follows: Figure 5b The second site, located in region 2, shows the write progress information for the second data corresponding to the most recent response to the second data access request. Here, the second data access request in the most recent response from the second site is the same as the first data access request in the most recent response from the first site; the second data is the first data. Therefore, the third write progress information for region 2 indicates the write progress information (e.g., information indicating that access is now supported) for the first data (specifically, the data written to the primary database corresponding to transaction 3) in region 2.

[0450] The third write progress information in region 3 can be as follows: Figure 5b The third site shown in the diagram is located in region 3, and the write progress information (e.g., information that access is supported) is for the second data (specifically, the data written to the primary database corresponding to transaction 2) corresponding to the most recent response to the second data access request.

[0451] Afterwards, the cloud management platform can output the third-party response result, for example, to... Figure 5b The client 102 in the client cluster 800 shown sends the first data access request (e.g., transaction 3).

[0452] In this way, a client in the client cluster 800, such as client 102, can determine that the first data corresponding to its first data access request has been written to the first area where the first site is located, based on the transaction execution progress information of each of the three areas (or the third response result obtained based on the transaction execution progress information of the three areas), and that the first data has also been synchronized to the second area where the second site is located, but the first data has not yet been synchronized to the second area where the third site is located.

[0453] For example, if the first site is functioning correctly, and the first data access request corresponds to service 1, and the next data access request 2 to be sent by client 102 corresponds to service 2, and service 2 depends on service 1, then client 102 can route data access request 2 to client 103 at the second site, so that the slave engine 2 and slave database 2 at the second site can execute service 2. However, the slave engine 3 and slave database 3 at the third site have not yet synchronized the first data corresponding to the first data access request, making it unable to process the data access request 2 from client 102, and therefore will not route the data access request 2 to slave engine 3 for processing.

[0454] Alternatively, for example, a batch of data access requests issued by client cluster 800 could be considered transactions, executed in the order of transaction 1 to transaction 5, corresponding to business 1 to business 5 respectively, with each business in business 2 to business 5 depending on the adjacent previous business. Figure 5b For example, let ③ next to the main engine represent transaction 3 in transaction execution progress information 0', which is the most recently successfully executed transaction of the current main engine (transactions 1 to 5). Let ③ next to the secondary engine 2 represent transaction 3 in transaction execution progress information 1', which is the most recently successfully executed transaction of the secondary engine 2 (the transaction corresponding to the most recently synchronized data from the first site to the second site). Let ② next to the secondary engine 3 represent transaction 2 in transaction execution progress information 2', which is the most recently successfully executed transaction of the secondary engine 3 (the transaction corresponding to the most recently synchronized data from the first site to the second site).

[0455] For example, if a failure occurs at the first site or in the first region, client 102 will be unable to access the data within the first site. Client 102 can then determine the difference in business data between the second and third sites and the first site based on the aforementioned three transaction execution progress information (specifically, data from at least one of the aforementioned business processes 1 to 5 that were not synchronized from the first site). For instance, client 102 can choose the second site with a smaller difference in transaction execution progress from the first site and access the data from the second site. This achieves both remote data access and ensures that data from the second site is used to provide access functionality in the event of a failure at the first site, thus ensuring high data availability.

[0456] In the above Figure 5b In this embodiment, the implementation process of the method of this application embodiment is illustrated by taking the first station as the master station and the second and third stations as slave stations of the first station.

[0457] In some embodiments, the second site can also be the master site, and the first and third sites can be slave sites of the second site. In this case, the slave engine 2 and slave database 2 of the second site can write first data in response to data access requests received by the second site (wherein, the database operation corresponding to the writing of the first data by the slave engine 2, and the data to be stored by the slave database 2), for example, the data access request received by the database system of the second site instructs the writing of the first data. Furthermore, the second site can synchronously back up the first data to the first and third sites, the specific process of which is... Figure 5b The process of using the first station as the master station and the second and third stations as slave stations is similar, except that the second station is the master station and the first and third stations are slave stations.

[0458] Similarly, in some embodiments, such as Figure 5b The third station shown can be the master station, and the first and second stations can be slave stations of the third station, in order to implement the method of the embodiments of this application. The specific implementation principle is as follows: Figure 5b The process of having the first station as the master station and the second and third stations as slave stations is similar.

[0459] For example, such as Figure 5bThe computing instance 1 shown receives a batch of transactions: transactions 1 to 5 in the order of response. The first site can act as the master site, and the second and third sites can act as slave sites. Computing instance 1 can write the first data corresponding to transactions 1 to 5 to storage instance 1. Storage instance 1 can also synchronize the first data corresponding to transactions 1 to 5 to storage instances 2 and 3. Computing instances 2 and 3 can simulate the database operations of transactions 1 to 5 to obtain their respective transaction execution progress information and send it to computing instance 1. In addition, storage instances 2 and 3 can also send their respective persistence progress information (e.g., the transaction number corresponding to the most recently persisted first data) to computing instance 1.

[0460] Thus, computation instance 1 can record the transaction execution progress information of transactions 1 to 5 for computation instance 1, as well as the transaction execution progress information of transactions 1 to 5 for computation instance 2, and the transaction execution progress information of transactions 1 to 5 for computation instance 3. It can also record the persistence progress information of transactions 1 to 5 for storage instance 1, as well as the persistence progress information of transactions 1 to 5 for storage instance 2, and the persistence progress information of transactions 1 to 5 for storage instance 3. Based on the recorded transaction execution progress information of each computation instance and the persistence progress information of each storage instance, computation instance 1 can output the write progress information of the data corresponding to the most recent response transaction for each of the three sites. For example, the primary site has supported access to the data in transaction 5 (meaning it also supports access to transactions 1 to 4), the second site has written the data in transaction 4 (meaning it also supports access to transactions 1 to 3), and the third site has received the data in transaction 2 (meaning it supports access to transaction 1, but has not yet received data from transactions after transaction 2).

[0461] Furthermore, while compute instance 1 receives transactions 1 to 5, compute instance 2 receives transactions A to C. The second site can also act as the master site, with the first and third sites acting as slave sites. Compute instance 2 can write the first data corresponding to transactions A to C to storage instance 2. Storage instance 2 can also synchronize the first data corresponding to transactions A to C to storage instances 1 and 3. Compute instances 1 and 3 can simulate the database operations of transactions A to C to obtain their respective transaction execution progress information and send it to compute instance 2. Additionally, storage instances 1 and 3 can also send their respective persistence progress information (e.g., the transaction number corresponding to the most recently persisted first data write) to compute instance 2. Thus, computation instance 2 can record the transaction execution progress information of computation instance 2 regarding transactions A to C, as well as the transaction execution progress information of computation instance 1 regarding transactions A to C, and the transaction execution progress information of computation instance 3 regarding transactions A to C, and also record the persistence progress information of storage instance 1 regarding transactions A to C, as well as the persistence progress information of storage instance 2 regarding transactions A to C, and the persistence progress information of storage instance 3 regarding transactions A to C. Therefore, computation instance 2 can output three sets of response results for the three data access requests corresponding to transactions A to C, based on the recorded transaction execution progress information of each computation instance and the persistence progress information of each storage instance. For example, a response result may include the write progress information of the data corresponding to the most recent response of each of the three stations for transactions A to C. For example, the second station has supported access to the data of transaction C (that is, it also supports access to transactions A to B), the first station has written the data of transaction C (that is, it also supports access to transactions A to B), and the third station has received the data of transaction B (that is, it supports access to transaction A, but transactions after transaction B have not yet been received).

[0462] While compute instance 1 receives transactions 1 through 5, compute instance 2 receives transactions A through C, and compute instance 3 receives transactions α and β sequentially. The third site can also act as the master site, with the first and second sites acting as slave sites. Compute instance 3 can write the first data corresponding to transactions α and β to storage instance 3; and storage instance 3 can synchronize the first data corresponding to transactions α and β to storage instances 1 and 2. Compute instances 1 and 2 can simulate the database operations of transactions α and β to obtain their respective transaction execution progress information, which they then send to compute instance 3. Furthermore, storage instances 1 and 2 can also send their respective persistence progress information for the first data corresponding to transactions α and β (e.g., the transaction number corresponding to the most recently persisted first data write) to compute instance 3. Thus, computation instance 3 can record the transaction execution progress information of computation instance 3 regarding transactions α and β, as well as the transaction execution progress information of computation instance 1 regarding transactions α and β, and the transaction execution progress information of computation instance 2 regarding transactions α and β. It can also record the persistence progress information of storage instance 3 regarding transactions α and β, as well as the persistence progress information of storage instance 1 regarding transactions α and β, and the persistence progress information of storage instance 2 regarding transactions α and β. Based on the recorded transaction execution progress information of each computation instance and the persistence progress information of each storage instance, computation instance 3 can output two sets of response results for the two data access requests corresponding to transactions α and β, respectively. For example, a response result includes the writing progress information of the data corresponding to the most recent response of each of the three stations for transaction α and transaction β. For example, the third station has supported access to the data of transaction β (that is, it also supports access to transaction α), the first station has written the data of transaction β (that is, it also supports access to transaction α), and the third station has also supported access to transaction α (that is, it has not yet received the data of transaction β).

[0463] In the specific examples above, for transactions 1 to 5 received by computation instance 1 at the first station, the first station acts as the master station, and the second and third stations act as slave stations to back up the first data corresponding to each of transactions 1 to 5; for transactions A to C received by computation instance 2 at the second station, the second station acts as the master station, and the first and third stations act as slave stations to back up the first data corresponding to each of transactions A to C; for transactions α and β received by computation instance 3 at the third station, the third station acts as the master station, and the first and second stations act as slave stations to back up the first data of transaction α and the first data of transaction β.

[0464] In other words, at the same time or within the same time period, there can be multiple master sites in a system, and different sites can be master and slave sites to each other.

[0465] In some embodiments, the write progress information of the database systems in different regions may be the same or different. For example, the transaction execution progress information of the database systems in different regions may be the same or different. When the client that sent the first data access request issues subsequent data access requests, it can select a region from the different regions based on the response result to route the subsequent data access request to the database system in the selected region for data access.

[0466] For example, the client can determine the data system with the latest data access progress from different regional data systems based on the response result to execute subsequent data access requests. Alternatively, the client can also determine the database system with the latest data access progress and the closest distance to the client from different regional data systems based on the response result, combined with the fault status of database systems in different regions and the distance between different regions and the client's own region, to execute subsequent data access requests. Alternatively, the client can also combine other rules to determine the data system of the region to execute subsequent data access requests; this embodiment of the application does not impose limitations on this approach.

[0467] For example, in this embodiment of the application, the multiple regions are designated as Region 1, Region 2, Region 3, and Region 4. Region 1 may include, but is not limited to, Database System 1; Region 2 may include, but is not limited to, Database System 2; Region 3 may include, but is not limited to, Database System 3; and Region 4 may include, but is not limited to, Database System 4. Client 1 communicates with Database System 1 in Region 1. The client cluster in Region 1 issues a batch of transactions (an example of a data access request), namely Transaction 1 to Transaction 3, and Transaction 3 is issued by Client 1 in the client cluster. After issuing Transaction 3, Client 1 also needs to issue Transaction 4. Before issuing Transaction 4, Client 1 can, based on the received response results (see below), select the database system with the transaction number last in the transaction order from M database systems in different regions (M is a positive integer greater than or equal to 2, here M = 4) to execute Transaction 4.

[0468] For example, the response received by client 1 includes the following: Transaction number 3 in the transaction execution progress information for database system 1 in region 1 (indicating successful execution of transaction 3, i.e., access to the first data corresponding to transaction 3 is supported); transaction number 3 in the transaction execution progress information for database system 2 in region 2; transaction number 3 in the transaction execution progress information for database system 3 in region 3; and transaction number 1 in the transaction execution progress information for database system 4 in region 4 (indicating successful execution of transaction 1). Database system 2 in region 2 and database system 3 in region 3 are the database systems with the smallest difference in transaction execution progress from database system 1 in region 1 (no difference in this example), and are also the database systems whose transaction numbers are last in the transaction order in the transaction execution progress information.

[0469] Example 1: If the database system in region 1 is functioning correctly, client 1 can send transaction 4 to region 1 so that database system 1 can execute transaction 4, or route it to region 2 so that database system 2 can execute transaction 4, or route it to region 3 so that database system 3 can execute transaction 4.

[0470] Alternatively, in Example 2, if database system 1 in region 1 fails, and region 2 is closer to region 1 than region 3, then client 1 can route transaction 4 to region 2 so that database system 2 can execute transaction 4.

[0471] In this embodiment, the first database system can obtain write progress information from each database system in different regions, indicating the most recently successfully responded data access request, and then output a response result. In this way, the client can obtain write progress information from at least two regions (a first region and at least one second region) indicating the most recently successfully responded data access request. The client can then decide whether to issue the next transaction based on the received write progress information; for example, after receiving write progress information from the database system in the first region, the client can issue the next transaction. Furthermore, if the database system in the first region fails, the client in the first region can select the database system in the region with the latest write progress information to execute subsequent data access requests, thereby minimizing client response latency. Alternatively, the client can flexibly select a suitable database system to execute subsequent data access requests by combining write progress information, database system failure status, business requirements, proximity principles, etc. In addition, if a data access request in the current region fails, the client can flexibly select a suitable region based on the received write progress information and quickly route the data access request to that region for execution, thereby minimizing continuous business errors.

[0472] When the aforementioned client routes data access requests to other regions for execution, load balancing can be used to distribute the traffic, ensuring that the database system in each region has good overall processing efficiency.

[0473] In addition, in this embodiment of the application, the first database system can obtain the writing progress information of the second data corresponding to the most recent response to the second data access request in at least one second region (which is also the writing progress of the second database system of the second region to the second data), and can flexibly return the response result (e.g., the third response result) to the client based on the obtained writing progress information of the second region.

[0474] In some embodiments, the cloud management platform may also save write progress information for the first region and write progress information for the second region.

[0475] Both the write progress information for the first region and the write progress information for the second region represent the write progress of the data to be written corresponding to the most recent data access request responded to by the database system in the respective region.

[0476] In some embodiments, the first database system may also store the write progress information of the first region and the write progress information of the second region.

[0477] For example, as a transaction (an example of a data access request) is executed, the transaction execution progress information (an example of writing progress information) is constantly updated, and the transaction execution progress information stored by the first database system / cloud management platform is also constantly updated, so that the first database system / cloud management platform stores the latest data backup progress of the first and second regions for multiple transactions.

[0478] In other words, in this embodiment, the cloud management platform or the first database system can store the received write progress information for the first region and the second region. Furthermore, as data access requests are executed, the write progress information stored by the cloud management platform / first database system is continuously updated. This allows the cloud management platform / first database system to store the write progress information of the data to be written corresponding to the most recent data access request from different database systems. This facilitates subsequent client acquisition and querying of the write progress information, and / or facilitates subsequent incremental data recovery operations based on the write progress information.

[0479] like Figure 4b As shown, in some embodiments, after step S503, the data access method may further include step S601. This application embodiment does not limit the execution order of steps S601 and S504.

[0480] Step S601: The cloud management platform obtains the synchronization latency information of the second region based on the first write progress information of the first region and the third write progress information of the second region.

[0481] The synchronization delay information of the second region is used to indicate the time required for the data stored in the second region to be synchronized with the data stored in the first region.

[0482] In some embodiments, the first database system can obtain the synchronization delay information of the second region based on the first write progress information of the first region and the third write progress information of the second region.

[0483] Afterwards, the first database system can send the synchronization latency information of the second region to the cloud management platform. In this way, the cloud management platform can directly obtain the synchronization latency of the second region without having to process it according to S601 to obtain the synchronization latency.

[0484] Furthermore, the first write progress information of the first region used to obtain the synchronization latency information of the second region on the cloud management platform can be obtained through methods such as... Figure 4a As shown in S4012, the synchronization delay information of the second region obtained in the first database system is the first write progress information of the first region used. This can also be referred to... Figure 4a During the process, the first database system obtains a detailed description of the first write progress information of the first region, which will not be elaborated here.

[0485] In some embodiments, for example, the synchronization delay information of the second database system can be obtained by the first database system based on the third write progress information of the second data corresponding to the second data access request most recently responded to by the second database system, and the first write progress information of the first data corresponding to the data access request most recently responded to by the first database system. For example, it can be obtained by... Figure 5a The main engine in the system executes this step, and the process is similar to that performed by the cloud management platform.

[0486] For example, if a data access request is a transaction, and the number of transactions that a database system (e.g., a computing instance in the database system) can process per unit time (e.g., per second) is fixed, then for any second database system, the first database system can obtain the number of transactions that differ between the first and second database systems based on the transaction execution progress information of the first database system (an example of first write progress information) and the transaction execution progress information of the second database system (an example of third write progress information). Thus, based on the number of transactions that the database system can process per unit time, the synchronization latency information corresponding to each second database system can be obtained, that is, the synchronization latency information of the second region where the second database system is located.

[0487] like Figure 4b As shown, after step S601, the data access method may further include step S602.

[0488] Step S602: The cloud management platform outputs the fourth response result in response to the first data write request.

[0489] In some embodiments, the fourth response result may include synchronization delay information for the second region. The fourth response result may also include, for example, first write progress information and third write progress information.

[0490] In some embodiments, after obtaining the synchronization delay information of the second region, the first database system may output a fourth response result to the cloud management platform in response to the first data write request, so that the cloud management platform outputs the fourth response result.

[0491] For example, the cloud management platform can output a fourth response result to the client so that the client can obtain the synchronization latency information of the second region.

[0492] Combination Figure 5b To illustrate, such as Figure 5b The transactions processed by the main engine (in the first database system) are sequentially named Transaction 1 to Transaction 100. For example, if the transaction number in the current transaction execution progress information of the main engine is 100 (the transaction corresponding to the first data access request is Transaction 100), it means that the most recently successfully executed transaction by the main engine is Transaction 100. If the transaction number in the current transaction execution progress information of the slave engine 1 (in the second database system) is 30, it means that the most recently successfully executed transaction by the slave engine 1 is Transaction 30 (the transaction corresponding to the second data access request most recently responded to by region 2 where the second site is located is Transaction 30). If the transaction number in the current transaction execution progress information of the slave engine 2 (in another second database system) is 50 (the transaction corresponding to the second data access request most recently responded to by region 3 where the third site is located is Transaction 50), it means that the most recently successfully executed transaction by the slave engine 2 is Transaction 50.

[0493] For example, if a database system can process 100 transactions per second, then, for instance, the master engine can determine the synchronization latency of slave engine 1 as 0.3s based on the difference in transactions between the master engine and slave engine 1 (specifically, 30 transactions), meaning the synchronization latency of region 2, where the second site is located, is 0.3s. Similarly, for instance, the master engine can determine the synchronization latency of slave engine 2 as 0.5s based on the difference in transactions between the master engine and slave engine 2 (specifically, 50 transactions), meaning the synchronization latency of region 3, where the third site is located, is 0.5s.

[0494] In this way, the client can output a fourth response result based on the synchronization delay information of region 2 where the second site is located and region 3 where the third site is located. This fourth response result can be compared with the above... Figure 4a The first response results can be output simultaneously or sequentially, with no restriction on the order.

[0495] In this embodiment, the response result of the data access request output by the first database system may further include synchronization delay information with a second region, which is used to store data copies of the first region. This allows the client to obtain the synchronization delay information of the second region. For a given second region, the client can determine the time required for the data stored in that second region to be synchronized to the data stored in the first region based on the synchronization delay information. Thus, after a certain period, the client can identify which second regions have synchronized their stored data to the data stored in the first region. Based on business needs or in the event of a database system failure in the first region, the client can selectively choose a second region that has completed data synchronization to execute subsequent data access requests, based on proximity.

[0496] In addition, if the client does not wait for at least one second region to complete the synchronization of stored data, it can select the second region with the smallest RTO (the smallest difference between the data stored in the first region) to execute the subsequent data access request when the read operation is corresponding to the subsequent data access request, based on the write progress information or synchronization latency information. This can increase the probability that the subsequent data access request will successfully read the required data, and thus increase the probability that the subsequent data access request will be executed successfully.

[0497] Combined with Figures 3 to 4b ,as well as Figures 5a to 5b For any of the embodiments, please refer to Figure 4c , Figure 4c This is a flowchart illustrating another data access method provided in an embodiment of this application. The application scenarios for this data access method can be referred to... Figure 4a The following describes the application scenarios in the embodiments of this application. Taking the application of the method of this application to the above-mentioned cloud management platform as an example, we will introduce the methods of various embodiments of this application. This method can also be applied to the above-mentioned cloud service system.

[0498] like Figure 4c As shown, the data access method may include, but is not limited to, steps S401, S701, and S702.

[0499] Step S401: The cloud management platform can receive the first data access request.

[0500] For a description of step S401, please refer to the above. Figure 4aThe relevant descriptions of this step in the embodiments will not be repeated here.

[0501] like Figure 4c As shown, compared to the above Figure 4a In a corresponding embodiment, after step S401, the method may further include the following step S701.

[0502] Step S701: The cloud management platform can obtain the first information.

[0503] The first information can be used to indicate the response time of the first data access request. When the first data access request is named a first data write request, the first information is used to indicate the response time of the first data write request.

[0504] For example, response duration is used to indicate the expected response result for the first data access request within that response duration.

[0505] For example, the response duration can be the maximum acceptable time length from sending the first data access request to receiving the response result of the first data access request on the end side (e.g., the client).

[0506] In some embodiments, the cloud management platform may send the first information to the first database system, so that the first database system can obtain the first information from the cloud management platform. Alternatively, the first database system may have the first information pre-configured, for example, the computing instance or virtual instance in the first database system may be configured with the first information.

[0507] The explanation of this first database system can be found above, and will not be repeated here.

[0508] In some embodiments, the first data access request received through step S401 may include first information. The cloud management platform can obtain the first information carried in the first data access request to obtain the response time of the first data access request.

[0509] In some embodiments, the cloud management platform may also send the first information to the database system that responds to the first data access request (the database system is located in the same region as the client). For example, the database system may be the first database system mentioned in the above embodiments, so that the first database system can obtain the first information and thus obtain the response time of the first data access request.

[0510] As an example, such as Figure 3As shown, for example, if the client sending the first data access request is client 102 in region 1, then the first database system responding to the first data access request can be computing node 11 located in region 1. Alternatively, the first database system can be at the granularity of a virtual instance, in which case the first database system can be computing instance 1, meaning the cloud management platform can send the first information to computing instance 1.

[0511] In the data access method provided in this application embodiment, the first data access request may carry first information, which is used to indicate the response duration of the first data access request. In this way, the device (e.g., client) that sends the first data access request can flexibly set the response duration of this data access according to the service corresponding to the request. This allows the first database system in the method of this application embodiment to provide a timely response result to the corresponding data access request within the response duration indicated by the first information carried in the data access request, thereby improving the flexibility of data access.

[0512] For example, when the response time is determined by the client, the response time for different data access requests may be the same or different. This application embodiment does not specifically limit the size of the response time.

[0513] In other embodiments, the first information may be a database system pre-configured to a cloud management platform or different regions for responding to data access requests. For example, it may be configured to a node or virtual instance in the database system, wherein the node may be a compute node or a storage node, and the virtual instance may be a compute instance or a storage instance.

[0514] Continue with Figure 3 For example, the first information can be pre-configured in a compute node (e.g., compute node 11) or a storage node (e.g., storage node 12) within region 1, or a compute instance (e.g., compute instance 1) within a compute node, or a storage instance (e.g., storage instance 1) within a storage node, or a cloud management platform (not shown) located between client cluster 800 and data center cluster 1000.

[0515] For other regions outside of region 1 (e.g., region 2, region 3), the first information can also be pre-configured according to a similar principle. Furthermore, this application does not restrict whether the response time corresponding to the pre-configured first information in different regions is the same.

[0516] In this way, by presetting the first information, the response duration indicated by the first information can be preset. Then, in the method of this application embodiment, the first database system can respond to different data access requests received according to the uniform preset response duration, without having to extract the first information from the data access request to obtain the response duration corresponding to the data access request. This can reduce the computational overhead of the method (e.g., server) of this application embodiment, improve the response speed of the data access request, and effectively reduce the response latency of the data access request, thereby reducing the latency of the client.

[0517] exist Figure 4c In the illustrated embodiment, step S701 is executed after step S401. In other embodiments, S401 may be executed concurrently with S701, or step S401 may be executed after step S701. However, both steps S401 and S701 are executed before step S702. This application does not restrict the execution order between steps S401 and S701.

[0518] like Figure 4c As shown, after step S701, the method may further include step S702.

[0519] Step 702: Starting from the moment the cloud management platform receives the first data access request, it outputs the second response result to the first data request within the response time.

[0520] In some embodiments, the first database system may output a second response result to the first data write request within a response duration, starting from the moment it receives the first data write request.

[0521] The second response result includes the aforementioned first write progress information, which includes information indicating that the first region has supported access to the first data.

[0522] In some embodiments, the second response result may include information indicating that at least one region (including the first region) among multiple regions has supported access to the first data corresponding to the first data access request. As described above, for the first data access request, the first database system in the first region is the first to successfully execute the request; therefore, the at least one region may include the first region, and the at least one database system within the at least one region may include the first database system described above.

[0523] The second response result may include at least information indicating that the first database system has supported access to the first data corresponding to the first data request.

[0524] In one embodiment, the first database system can start from the moment it receives the first data write request and output a second response result to the cloud management platform within the response duration indicated by the first information within the time limit; the cloud management platform can receive the second response result and output the second response result to the client.

[0525] In combination with the above Figure 4a In this embodiment, since the first database system needs to send the first data that has been written to the second database system, the second response result output within the response time for the first data access request may include the first writing progress of the first data in the first region, and the first writing progress may indicate that the first region has supported access to the first data.

[0526] Taking the first data access request carrying the first information as an example, the method is the same when the first information is preset information.

[0527] The method of executing the embodiments of this application using a cloud management platform is used as an example for illustration. The same principle applies when other executing entities execute the method.

[0528] For example, based on the first information, the cloud management platform determines that the response time indicated by the first information is relatively short, for example, the response time is less than a preset threshold (e.g., 0.1s, with no specific limitation). The strategy for determining whether the response time is long or short is not limited. Then, in one possible implementation, after receiving, for example, the response information from the first database system (e.g., transaction execution progress information) within this response time, the cloud management platform can output a second response result to the client based on the response information from the first database system.

[0529] In this context, the response information from a database system to a first data access request can be the database system's progress information on writing the first data. For example, the response information could be information indicating whether the database system has supported access to the first data corresponding to the first data access request, etc., without limitation.

[0530] Afterwards, the cloud management platform can continue to receive information from the second database system indicating the writing progress of the second data or the first data, so as to determine the writing progress of the first data of the corresponding second database system in response to the first data access request. The client can query the writing progress of the first data of the second database system in response to the first data access request through the cloud management platform.

[0531] by Figure 3For example, let's say the client issuing the first data access request is client 102 in region 1, and the database system responding to the first data access request is the first database system (e.g., specifically compute instance 1 and storage instance 1). The cloud management platform (not shown) can determine, based on the first information, that the response time indicated by the first information is less than a preset threshold. For instance, if the cloud management platform receives a response from compute instance 1 indicating that it supports access to the first data corresponding to the first data access request within this response time, but does not receive a response from the second database system (e.g., compute instance 2 and storage instance 2 in region 2) indicating that it supports access to the first data corresponding to the first data access request, then the cloud management platform can output a second response result to client 102 to reduce the response latency to the first data access request. After the cloud management platform outputs the second response result, the client 102 can also send a request through the cloud management platform to any of the database systems in Region 1, Region 2, and Region 3 that are responding to the first data access request (e.g., compute instance 2 and storage instance 2 in Region 2). This allows the cloud management platform to output the writing progress of the first data corresponding to the first data access request from the aforementioned database systems to the client 102. This enables the client to determine the synchronization progress of the first data in different regions based on the writing progress of the first data in the first database system and the writing progress of the first data in the second database system.

[0532] For example, if the cloud management platform determines, based on the first information, that the response time indicated by the first information is relatively long, such as exceeding a preset threshold, then in one possible implementation, the cloud management platform can receive, within that response time, for example, the first write progress of the first data corresponding to the first data access request from the first database system, and the write progress of the first data from at least one second database system in a second region. Based on the write progress of the first data from the first database system and the write progress of the first data from at least one second database system in a second region, the cloud management platform can output a second response result to the client within that response time.

[0533] Continuing with the above Figure 3For example, a cloud management platform (not shown) determines, based on first information, that the response duration indicated by the first information is greater than a preset threshold, indicating that the response duration is relatively long. Within this response duration, the cloud management platform can receive the first write progress of the first data corresponding to the first data access request from compute instance 1 in region 1, and the write progress of the first data from compute instance 2 in region 2. Based on the received write progress from these regions, the cloud management platform outputs a second response result to client 102. After the cloud management platform outputs the second response result, client 102 can also send a request through the cloud management platform to any one of the database systems in regions 1, 2, and 3 that responded to the first data access request (e.g., compute instance 3 and storage instance 3 in region 3). This allows the cloud management platform to output the write progress of the first data corresponding to the first data access request from the aforementioned database systems to client 102, enabling the client to determine the synchronization progress of the first data in different regions based on the response information.

[0534] The following is combined Figure 5b This will illustrate the specific implementation method of the above process.

[0535] For example, such as Figure 5b The main engine shown (an example of a computing instance in the first database system) processes a batch of transactions, numbered 1 through 100. For example, the first data access request currently being processed by the main engine is transaction 3 out of transaction 1 through 100, and this first data access request is sent by client 102 in client cluster 800. This first data access request includes first information indicating the response duration. After receiving this first data access request, the main engine can obtain the response duration of transaction 3 corresponding to this first data access request based on the first information.

[0536] In some embodiments, the main engine may return a second response result to the client 102 based on the expected response time corresponding to transaction 3 (indicated by the first information).

[0537] In other embodiments, the main engine may send the response duration corresponding to transaction 3 to the main database, and the main database may obtain the second response result corresponding to transaction 3 according to the response duration indicated by the first information, and then feed back the second response result to the client 102 through the main engine.

[0538] For example, the master database can obtain the write progress information of the master engine, as well as the write progress information of slave engine 2 and slave engine 3 (see reference). Figure 4b(In the embodiment), based on the response time of transaction 3, within that response time, a second response result is output to the main engine based on the acquired write progress information, and then the main engine returns the second response result to the client 102. In this way, the computational overhead of the main engine can be reduced. Among the write progress information of the three regions acquired by the main database, at least one region's engine sends write progress information indicating that the region where the engine is located has supported access to the first data information.

[0539] For ease of understanding, it should be noted in advance that the main engine (or main library) can set a timer according to the response duration T1 indicated by the first information. Before the timer's duration T exceeds T1, the main engine can output the response result of the first data access request. Of course, in other embodiments, the response duration T1 can also be timed using technical means other than a timer, and this application does not limit this.

[0540] In the first implementation, the main engine can output the second response result to the client 102 based on the response time of transaction 1.

[0541] For example, before the timing time T reaches the response duration T1, the main engine can obtain, as follows: Figure 5b The transaction execution progress information 0' shown is an example of write progress information. This transaction execution progress information 0' includes information about the most recently successfully executed transaction by the main engine (here, transaction 3). Based on the transaction execution progress information 0', the main engine can output a second response result to the client 102. This second response result includes information indicating that the first database system (e.g., the main engine and the primary database) has supported access to the first data.

[0542] For example, before the timeout T reaches the response duration T1, the main engine can not only receive the transaction execution progress information 0' from the main engine, but also the transaction execution progress information 1' from the slave engine 2. This transaction execution progress information 1' includes information about the most recently successfully executed transaction by the slave engine 2 (here, transaction 3). The main engine can also receive the transaction execution progress information 2' from the slave engine 3, which includes information about the most recently successfully executed transaction by the slave engine 3 (here, transaction 2). Then, based on the transaction execution progress information 0', 1', and 2', the main engine can output a second response result to the client 102. This second response result includes information indicating that the first database system (e.g., the main engine and the master database) located in region 1 supports access to the first data corresponding to the first data access request, and information that the second database system (e.g., the slave engine 2 and the slave database 2) located in region 2 supports access to the second data corresponding to transaction 2.

[0543] The second implementation differs from the first implementation, where the main engine obtains transaction execution progress information from different regions of the database system (e.g., compute instances and storage instances) and outputs the second response result accordingly. In this embodiment, the main database obtains transaction execution progress information from servers in different regions (e.g., the main engine, slave engine 2, and slave engine 3) and the response duration corresponding to the first data access request (e.g., the response duration T1 corresponding to transaction 3 mentioned above). Based on the obtained transaction execution progress information and the response duration T1 of transaction 3, the main database outputs the second response result to the main engine, which then outputs the second response result so that the client 102 can obtain it. The principle of this implementation is similar to that of the implementation where the main engine is the execution subject, and will not be elaborated further here.

[0544] As can be seen from the above introduction, in the relevant technologies, refer to Figure 1b and Figure 1c During the process of synchronizing data from the master site to the slave site, if the slave site fails, there is a certain time delay between the failure of the slave site and the detection of the failure by the master engine. The master engine can only return the response result of the data access request to the client after detecting the failure. Therefore, if the slave site fails during the data synchronization process, it will cause the client's business on the master site to be stuck for seconds or even minutes, affecting business performance.

[0545] In the data access method provided in this application embodiment, the first database system can output a second response result within the response duration indicated by the first information, starting from the moment it receives the first data access request. This enables the client to receive the second response result within the response duration indicated by the first information, starting from the moment it sends the first data access request. The second response result includes the response result of at least one database system, for example, the at least one database system includes systems located in the same region as the client (e.g., ...). Figure 3 The database system of area 1 shown. Thus, even if other areas (e.g., such as...) are used to process this first data access request, ... Figure 3 Even if the database system in either Region 2 or Region 3 fails, and / or the communication link between database systems in different regions fails, it will not affect the timely response to the first data access request. In fault scenarios, the response latency to the first data access request can be reduced, allowing the client to receive the response result promptly and reducing client-side service interruptions. The client can then decide whether to issue subsequent data access requests based on the received response result, thereby avoiding interruptions between multiple services corresponding to a single client.

[0546] For example, combining Figure 5bTo illustrate, for example, if client cluster 800 issues 1000 transactions, the main engine processes each batch of transactions (e.g., 100 transactions) at a time. During the processing of each batch, the main engine first returns a response indicating its own successful write to client cluster 800, without waiting for slave engines 2 and 3 to complete data backup. This effectively reduces the client latency for each batch of transactions and also reduces the overall response latency of the client cluster's services. Therefore, even if the second and / or third site fails, or the communication link between the first and second sites fails, or the communication link between the first and third sites fails, the replication of the first data from the main site (e.g., the first site) to the slave sites (e.g., the second and / or third site) will not cause service interruptions on client cluster 800.

[0547] Combined with Figures 3 to 4c ,as well as Figures 5a to 5b For any of the embodiments, please refer to Figure 4d , Figure 4d This is a flowchart illustrating another data access method provided in an embodiment of this application. The application scenarios for this data access method can be referred to... Figure 4a The following describes the application scenarios in the embodiments of this application. Taking the application of the method of this application to the above-mentioned cloud management platform as an example, we will introduce the methods of various embodiments of this application. This method can also be applied to the above-mentioned cloud service system.

[0548] like Figure 4d As shown, this data access method may include, but is not limited to, methods such as Figure 4d The steps S401, S801 and S403 are shown.

[0549] Step S401: The cloud management platform receives the first data access request.

[0550] For a description of step S401, please refer to the above. Figure 4a The relevant descriptions of this step in the embodiments will not be repeated here.

[0551] like Figure 4d As shown, compared to the above Figure 4a In a corresponding embodiment, after step S401, the method may further include the following step S801.

[0552] Step S801: The cloud management platform obtains the second information.

[0553] The second information is used to indicate the minimum number of regions required to write the first data in response to the first data access request.

[0554] In some embodiments, the second information may be used to indicate the minimum number of regions N+1 for writing the first data in response to the first data write request, where N is an integer greater than or equal to 1.

[0555] Among them, the N+1 regions may include the first region and N second regions.

[0556] Thus, in some embodiments, the cloud management platform can, based on the second information, instruct the first database system to send the first data to N second database systems. These N second database systems are located in N second regions, and each second region may have one second database system to write the first data. In other embodiments, a second region may include multiple second database systems; this is not a limitation.

[0557] In this way, the first database system can not only write the first data, but also send the written first data to N second database systems.

[0558] Subsequently, each of the N second database systems can write the first data based on the first data sent by the first database system. In this way, any second database system can obtain the second writing progress information of the first data in its respective region.

[0559] Of course, at the same time, not every second database system in the second region has necessarily written the first data so that its second write progress can support access to the first data.

[0560] In some embodiments, any one of the second database systems can send the second write progress information of the first data to the first database system for the second region to which it belongs, so that the first database system can obtain the second write progress information of N second database systems.

[0561] In some embodiments, the first database system may also output the second write progress information of the N database systems to the cloud management platform, so that the cloud management platform can obtain the second write progress information of the N second database systems on the first data. Thus, the cloud management platform can output a first response result based on the aforementioned first write progress information and the second write progress information of the N database systems (see step S403 below in the embodiments of this application for details).

[0562] The explanations of the first and second database systems can be found above, and will not be repeated here.

[0563] For example, if the second information indicates that the minimum number of database systems that write the first data in response to the first data access request is 2, then the high availability of the first data corresponding to the first data access request is 2, and the database systems that write the first data in response to the first data access request include the first database system that is in the same region (first region) as the client that sends the first data access request, and the second data system that is in a second region that is different from the first region.

[0564] For ease of explanation, the term "minimum number of regions / database systems for the first data access request" will be referred to as "the high availability corresponding to the first data access request" in the following text.

[0565] In some embodiments, the first data access request received through step S401 may include second information. The cloud management platform can obtain the second information carried in the first data access request to obtain the high availability corresponding to the first data access request.

[0566] In some embodiments, the cloud management platform may send the second information to the first database system, so that the first database system can obtain the second information from the cloud management platform. Alternatively, the first database system may have the second information pre-configured, for example, the computing instances or virtual instances in the first database system may be configured with the first information. After obtaining the second information, the first database system can then determine the high availability corresponding to the first data access request.

[0567] As an example, such as Figure 3 As shown, for example, if the client sending the first data access request is client 103 in region 2, then the first database system can be computing node 12 located in region 2. Alternatively, the first database system can be at the granularity of a virtual instance, in which case the first database system can be computing instance 2, and the cloud management platform can send the second information to computing instance 2.

[0568] In the data access method provided in this application embodiment, the first data access request can carry second information. The second information can be used to indicate the high availability corresponding to the first data access request. In this way, the device (e.g., the client) that sends the first data access request can flexibly determine the minimum number of backups required for the first data in the request based on the service corresponding to the request, thereby flexibly setting the high availability corresponding to the data access request. This allows the first database system in the method of this application embodiment to output a second response result when the number of backups of the first data in the request meets the high availability requirement, based on the high availability indicated by the second information carried in the data access request, without waiting for all data backups to be completed. This reduces the client's response latency while meeting the backup requirements of the data access request.

[0569] The high availability corresponding to different data access requests can be the same or different. In this embodiment, the high availability is an integer greater than or equal to 1.

[0570] In other embodiments, the second information may be a database system pre-configured to a cloud management platform or different regions for writing corresponding data in response to data access requests. For example, it may be configured to a node or virtual instance of the database system, wherein the node may be a compute node or a storage node, and the virtual instance may be a compute instance or a storage instance.

[0571] Continue with Figure 3 For example, the second information can be pre-configured in a compute node (e.g., compute node 11) or a storage node (e.g., storage node 12) within region 1, or a compute instance (e.g., compute instance 1) within a compute node, or a storage instance (e.g., storage instance 1) within a storage node, or a cloud management platform (not shown) located between client cluster 800 and data center cluster 1000.

[0572] For other regions outside of region 1 (e.g., region 2, region 3), the same principle applies, and this application does not restrict whether the high availability corresponding to the pre-configured second information in different regions is the same.

[0573] In this way, by presetting the second information, the high availability indicated by the second information can be preset. In the method of this application embodiment, the first database system can write the data corresponding to different data access requests according to the unified high availability for different data access requests, without having to extract the second information from the data access request to obtain the high availability corresponding to the data access request. This can reduce the computational overhead of the method (e.g., server) of this application example, improve the response speed of the data access request, and effectively reduce the response latency of the data access request, thereby reducing the latency of the client.

[0574] exist Figure 4c In the illustrated embodiment, step S801 is executed after step S401. In other embodiments, S401 may be executed concurrently with S801, or step S401 may be executed after step S801. However, both steps S401 and S801 are executed before step S403. This application does not restrict the execution order between steps S401 and S801.

[0575] like Figure 4d As shown, after step S801, the method may further include step S403.

[0576] Step S403: The cloud management platform outputs the first response result for the first data write request.

[0577] Among them, step S403 and Figure 4a The similarities to step S403 described in the embodiments will not be repeated here; only the differences will be explained below:

[0578] The first response result may include information indicating the progress of writing the first data (e.g., access to the first data is now supported) to the number of regions (a high availability value, such as N+1).

[0579] For example, the number of regions may include the first region where the client that sent the first data access request described above is located, and N second regions.

[0580] In combination with the above Figure 4a In an example, if the second information indicates that the minimum number of regions for writing the first data to the first data in response to the first data access request is N+1, and since the first database system needs to send the written first data to N second database systems, the output first response result for the first data access request may include the first writing progress of the first data in the first region and the second writing progress of the first data in the N second regions. For example, the first writing progress may mean that the first region has supported access to the first data, and the N second writing progress may mean that the N second regions have supported access to the first data.

[0581] Taking the first data access request carrying the second information as an example, the method is the same when the second information is preset information.

[0582] The method of executing the embodiments of this application using a cloud management platform is used as an example for illustration. The same principle applies when other executing entities execute the method.

[0583] For example, based on the second information, the cloud management platform determines that the high availability indicated by the second information can be greater than 1 (e.g., high availability is 3). In one possible implementation, the cloud management platform can receive, for example, the writing progress information of the first database system on the first data, as well as the writing progress information of the first data of two second data systems located in different second regions. Then, based on the received writing progress information of the first data from multiple database systems (e.g., 3), the cloud management platform can output a first response result to the client.

[0584] Continuing with the above Figure 3For example, if the client issuing the first data access request is client 102 in region 1, and the responding client is compute node 11, the cloud management platform (not shown) can determine the high availability indicated by the second information as 3 based on the second information. For example, after compute node 11 writes the first data to storage node 21, it can obtain write progress 1, and compute node 11 can receive write progress 2 from compute node 12 and write progress 3 from compute node 13. Then, compute node 11 can send the above write progress 1, write progress 2, and write progress 3 to the cloud management platform. After receiving write progress 1, write progress 2, and write progress 3, the cloud management platform outputs a first response result to client 102 based on these three write progress information (specifically, for example, the first write progress and N second write progresses).

[0585] For example, if the high availability indicated by the second information is greater than 1, in one possible implementation, after the first database system successfully executes the first data access request, it synchronizes the first data with other database systems (such as the second database system mentioned above). For example, the number of other database systems can be the high availability value minus 1. For example, if the high availability is 3, after the first database system writes the first data to the first data access request, it can also synchronously write the first data to the two second database systems mentioned above. Afterwards, the first database system can output the response result.

[0586] This way, while ensuring data backup needs are met, the utilization rate of storage resources can be improved.

[0587] The following is combined Figure 5b This will illustrate the specific implementation method of the above process.

[0588] For example, such as Figure 5b The main engine shown (an example of a computing instance in the first database system) processes a batch of transactions, numbered 1 through 100. For example, the first data access request currently being processed by the main engine is transaction 3 out of transaction 1 through 100, and this first data access request is sent by client 102 in client cluster 800. This first data access request includes second information indicating high availability. After receiving this first data access request, the main engine can determine the high availability corresponding to transaction 3 based on the second information.

[0589] In some embodiments, the main engine may return a first response result to the client 102 based on the high availability corresponding to transaction 3 (indicated by the second information).

[0590] In other embodiments, the main engine can send the high availability corresponding to transaction 3 to the main database, and the main database can output the first response result according to the high availability indicated by the second information, so as to send the first response result to the client 102 through the main engine. In this way, the computational overhead of the main engine can be reduced.

[0591] The following example illustrates how the main engine returns the first response result to client 102 based on the high availability corresponding to transaction 3. The principle is similar when the execution subject is the main database.

[0592] For example, the high availability K corresponding to transaction 1 is greater than 1.

[0593] For example, the high availability K corresponding to transaction 1 is 2. The master engine can receive transaction execution progress information 0' from the master engine, and transaction execution progress information 1' from slave engine 2, and transaction execution progress information 2' from slave engine 3. Transaction execution progress information 0' may include information about the most recently successfully executed transaction by the master engine (here, transaction 3), transaction execution progress information 1' may include information about the most recently successfully executed transaction by slave engine 2 (here, transaction 3), and transaction execution progress information 2' may include information about the most recently successfully executed transaction by slave engine 3 (here, transaction 2). Based on the obtained transaction execution progress information from the three engines, the master engine can determine that the number of computing instances (also called computing engines) that have executed transaction 3 and written the first data has reached the high availability K (here, 2) corresponding to transaction 3. Therefore, the master engine can output the first response result to client 102 without waiting for the transaction execution progress of other servers (such as slave engine 3 and slave database 3) to reach the same level as transaction 3. For example, the first response result may include information indicating that the first database system (e.g., the main engine and the main database) has supported access to the first data, and information that the second database system (e.g., the slave engine 2 and the slave database 2) located in area 2 of the second site has supported access to the first data.

[0594] In the data access method provided in this application embodiment, the first database system can output the first response result after backing up the first data to the number of copies corresponding to the high availability (e.g., the number mentioned above) according to the high availability requirements of each data access. This ensures the disaster recovery of the data while meeting the data backup quantity requirements of the business and reducing the response latency of the client.

[0595] Combined with Figures 3 to 4d ,as well as Figures 5a to 5b For any of the embodiments, please refer to Figure 4e , Figure 4e This is a flowchart illustrating another data access method provided in an embodiment of this application. The application scenarios for this data access method can be referred to... Figure 4aThe following describes the application scenarios in the embodiments of this application. Taking the application of the method of this application to the above-mentioned cloud management platform as an example, we will introduce the methods of various embodiments of this application. This method can also be applied to the above-mentioned cloud service system.

[0596] like Figure 4e As shown, the data access method may include, but is not limited to, steps S401, S901, and S902.

[0597] Step S401: The cloud management platform receives the first data access request.

[0598] For a description of step S401, please refer to the above. Figure 4a The relevant descriptions of this step in the embodiments will not be repeated here.

[0599] like Figure 4e As shown, compared to the above Figure 4a In a corresponding embodiment, after step S401, the method may further include the following step S901.

[0600] Step S901: The cloud management platform obtains the first information and the second information.

[0601] The methods for obtaining the first and second information can be referred to the above. Figure 4c Implementation examples Figure 4d The relevant descriptions in the embodiments will not be repeated here.

[0602] exist Figure 4e In the illustrated embodiment, step S901 is executed after step S401. In other embodiments, S401 may be executed concurrently with S901, or step S401 may be executed after step S901. However, both steps S401 and S901 are executed before step S902. This application does not restrict the execution order between steps S401 and S901.

[0603] like Figure 4e As shown, after step S901, the method may further include step S902.

[0604] Step S403: Starting from the moment the cloud management platform receives the first data write request, it outputs the fifth response result to the first data write request within the response time indicated by the first information.

[0605] Among them, step S403 and Figure 4a Step S403 as described in the embodiment Figure 4b The similarities to step S504 in the embodiments will not be repeated here; only the differences will be explained below:

[0606] In some embodiments, the fifth response result may include a value indicating the number (a value for high availability, such as those described above). Figure 4d Information on the writing progress (e.g., access to the first data is supported) of the N+1 regions (respectively the first region and N second regions) in the embodiment.

[0607] Alternatively, in other embodiments, the fifth response result may include information indicating that the first data access request "failed to execute," where "failed to execute" means that the cloud management platform did not write the first data to the number of regions from the moment it received the first data access request until the response time indicated by the first information, such that only a portion of the number of regions had the first data written to them.

[0608] Alternatively, in other embodiments, in the case of the aforementioned "execution failure", the fifth response result output by the cloud management platform may include not only information indicating that the first data access request "failed", but may also include, in finer terms, information that the first data has been written based on the first data access request in at least one region, the number of which is less than the value of high availability.

[0609] Taking the first data access request carrying first information and second information as an example, the method is the same when the first information and / or the second information are preset information.

[0610] The method of executing the embodiments of this application using a cloud management platform is used as an example for illustration. The same principle applies when other executing entities execute the method.

[0611] The following is combined Figure 5b To illustrate the process by which the cloud management platform outputs the fifth response result based on the response time and high availability:

[0612] For example, such as Figure 5b The main engine shown (an example of a computing instance in the first database system) processes a batch of transactions, numbered 1 through 100. For example, the first data access request currently being processed by the main engine is transaction 3 out of transaction 1 through 100, and this first data access request is sent by client 102 in client cluster 800. This first data access request includes first information indicating the response time and second information indicating high availability. After receiving this data access request, the main engine can obtain the response time and high availability corresponding to transaction 3 based on the first and second information.

[0613] In some embodiments, the main engine may return a fifth response result to the client 102 based on the response duration (indicated by the first information) and high availability (indicated by the second information) corresponding to transaction 3.

[0614] In other embodiments, the main engine may send the response duration and high availability corresponding to transaction 3 to the main database. The main database then obtains the fifth response result corresponding to transaction 3 according to the response duration indicated by the first information and the high availability indicated by the second information, and feeds back the fifth response result to the client 102 through the main engine.

[0615] For example, the master database can output the fifth response result to the main engine based on the response time and high availability of transaction 3, and then the main engine can return the response result to the client 102. This can reduce the computational overhead of the main engine.

[0616] Referring to the above Figure 4c and Figure 4d According to the relevant description in the embodiment, the main engine or main library can set a timer according to the response duration T1 indicated by the first information, so as to output the fifth response result based on the execution progress information that has been received and the indicated transaction number is greater than or equal to 3 before the timer T reaches the response duration T1.

[0617] The following example illustrates how the main engine returns the fifth response result to the client based on the response time and high availability corresponding to transaction 3. The principle is similar when the execution subject is the main database.

[0618] Specific example 1, where high availability K is 2.

[0619] Starting from the moment the timer of the main engine begins counting, before the timeout T reaches the response duration T1, the main engine can receive the transaction execution progress information 0' (an example of write progress information), the transaction execution progress information 1' (another example of write progress information) of the slave engine 2, and the transaction execution progress information 2' (another example of write progress information) of the slave engine 3. The transaction number indicated by the transaction execution progress information 0' and the transaction execution progress information is 3, while the transaction number indicated by the transaction execution progress information 2' is 2. Therefore, based on the obtained transaction execution progress information from the three engines, the main engine can determine that the number of computing instances (also called computing engines) that have executed transaction 3 and written the first data has reached the high availability K (here, 2) corresponding to transaction 3. Then, before the timeout T reaches the response duration T1, the main engine can output a fifth response result to the client 102 based on the currently received transaction execution progress information 0' and transaction execution progress information 1'. The fifth response result includes information indicating that the first database system (e.g., the main engine and the master database) and a second database system (e.g., the slave engine 2 and the slave database 2) have supported access to the first data corresponding to the first data access request.

[0620] Specific example 2, where high availability K is 3.

[0621] The main engine can receive the transaction execution progress information 0' from the main engine, the execution progress information 1' from slave engine 2, and the transaction execution progress information 2' from slave engine 3. For example, when the timeout T reaches the response duration T1, the main engine can determine, based on the obtained transaction execution progress information from the three engines, that the number of computing instances (also called computing engines) that have executed transaction 3 and written the first data is 2, which is less than the high availability K (here, 3) corresponding to transaction 3. Then, when the timeout T reaches the response duration T1, the main engine can output the fifth response result to the client 102 based on the above three transaction execution progress information.

[0622] In one possible implementation, the fifth response output from the main engine may include information indicating that the first data access request "failed".

[0623] In another possible implementation, the fifth response result output by the main engine may include information indicating that the first database system (e.g., the main engine and the master database) has supported access to the first data corresponding to the first data access request, and information indicating that a second database system (e.g., slave engine 2 and slave database 2) has supported access to the first data corresponding to the first data access request. Optionally, it may also indicate that another second database system (e.g., slave engine 3 and slave database 3) has not yet supported access to write the first data corresponding to the first data access request.

[0624] The embodiments of this application can comprehensively meet the requirements of response time and high availability, and flexibly output the response result of the first data access request at different times, so as to meet the latency requirements of the business and the high availability backup requirements of the business.

[0625] The following is combined Figure 3 The methods of embodiments of this application are illustrated with specific examples.

[0626] Please refer to Figure 3 In Region 1, Region 2, and Region 3, each region includes a storage instance that can provide stored data. The stored data can be stored in any form, such as key-value pairs, documents, or tables, to support the method of this application embodiment, thereby enabling cross-region data access.

[0627] For example, data from social media applications (such as message data) can be stored in the form of documents; data from e-commerce applications (such as browsing history and order records) can be stored in the form of tables; and data from short video applications (such as browsing history) can be stored in the form of files and index metadata.

[0628] exist Figure 3In the embodiment, region 1 may be located at the first station (e.g., the master station), and the stations where regions 2 and 3 are located are both slave stations of the first station.

[0629] In other embodiments, the stations where the three regions are located can be master and slave stations for each other. For example, the station where region 2 is located can also be the master station, and the stations where region 1 and region 3 are located can both be slave stations of region 2 to achieve backup storage of the first data written to region 2; or, the station where region 3 is located can also be the master station, and the stations where region 1 and region 2 are located can both be slave stations of region 1 to achieve backup storage of the first data written to region 3.

[0630] The application sending the first data access request may include first information and / or second information in the first data access request based on business needs, so as to send it to the main site through the cloud management platform.

[0631] For example, social media applications have high requirements for data availability, so the first data access request can carry a second piece of information indicating high availability.

[0632] As an example, if a social media application requires message data to be backed up to at least two other regions besides the region located on the local site, the client can determine that the first data access request carries the second information, and the second information indicates that the high availability corresponding to the first data access request is 3.

[0633] For example, short video applications have high requirements for response time, so the first data access request can carry first information indicating the response time. Optionally, it can carry second information indicating high availability.

[0634] As an example, a short video application requires that the client's response latency not exceed 0.5 seconds and that the data be backed up to another region as much as possible, except for the region located on the local site. In this case, the client can determine that the first data access request carries first information and second information. The first information indicates that the response time corresponding to the first data access request is 0.5 seconds, and the second information indicates that the high availability corresponding to the first data access request is 2.

[0635] Subsequently, the cloud management platform of this application embodiment can receive a data access request from an application (an example of a client), which may include at least one of first information and second information, in accordance with the above. Figure 4c or Figure 4d or Figure 4e The implementation process of the method described in the embodiment is used to access data and output response results; the specific process will not be repeated here.

[0636] In some embodiments, when the method can obtain the first information and the second information, during the process of responding to the first data access request, in the scenario where the database system in any one of the multiple areas used to implement data access fails, the high availability protection can be downgraded. That is, even if the number of areas that already support access to the first data is less than the high availability, the response result is sent to the client first, so as to ensure the stability of the front-end business latency and the determination of the RPO status, so that the protection can be quickly restored after the database system failure is repaired.

[0637] Combined with Figures 3 to 4e ,as well as Figures 5a to 5b For any of the embodiments, please refer to Figure 4f , Figure 4f This is a flowchart illustrating another data access method provided in an embodiment of this application. The application scenarios for this data access method can be referred to... Figure 4a The following describes the application scenarios in the embodiments of this application. Taking the application of the method of this application to the above-mentioned cloud management platform as an example, we will introduce the methods of various embodiments of this application. This method can also be applied to the above-mentioned cloud service system.

[0638] like Figure 4f As shown, this data access method may include, but is not limited to, [other methods]. Figure 4f The steps S505 and S506 are shown. Furthermore, prior to step S505, the data access method may also include... Figure 4b Step S503 in the embodiment.

[0639] based on Figure 4a In step S4012 of the embodiment, the cloud management platform can receive the first write progress information of the first region, based on, for example... Figure 4b In steps S501 to S503 of the embodiment, the cloud management platform can receive the third write progress information of the second region. See the above for details. Figure 4a Examples and Figure 4b Examples are not described in detail here.

[0640] like Figure 4f As shown, after step S4012 and step 503, the method may further include the following steps S505 and S506.

[0641] In this embodiment, during or after the cloud management platform responds to a first data access request, at least one of the second database systems in the aforementioned multiple regions may malfunction, or the transmission link between the database system in the second region and the first database system may fail. This results in the first data (data written based on the data access request) already written to the first database system not being synchronously written from the first region to the second database system in the second region, meaning the second region does not store a data copy of the first data. After the database system in the second region recovers from the fault, or after the aforementioned transmission link failure is resolved, the method of this embodiment can use steps S505 and S506 to send a copy of the data that was not backed up in the second region (compared to the first region) from the first database system to the second database system, ensuring that the data stored in the database systems of the first and second regions is consistent, thus meeting high availability requirements.

[0642] Step S505: The cloud management platform determines the third data to be synchronized from the first region to the second region based on the first write progress information of the first region and the third write progress information of the second region.

[0643] For example, the second area is used to store a copy of the data from the first area.

[0644] In some embodiments, the first database system may also determine the third data to be synchronized from the first region to the second region based on the first write progress information of the first region and the third write progress information of the second region.

[0645] In some embodiments, after step S4012, the cloud management platform can obtain the first write progress information of the first region and the third write progress information of at least one second region from the write progress information of the different regions.

[0646] In other embodiments, after step S4012, the cloud management platform can obtain the first write progress information of the first region and the third write progress information of at least one second region from the write progress information of the different regions that are saved.

[0647] The cloud management platform can determine the missing data copies in each second region compared to the first region by comparing the third write progress information of each second region with the first write progress information of the first region.

[0648] For example, the write progress information for each region is used to indicate the write progress of the second data corresponding to the second data access request most recently responded to in that region.

[0649] For example, if a cloud management platform receives transactions 1 through 5, and during the response process based on a first data access request (e.g., corresponding to transaction 5), the database system in the second region experiences a failure. After the failure is resolved, the cloud management platform can obtain transaction execution progress information 1 (an example of first write progress information) for the first region, and transaction execution progress information 2 (an example of third write progress information) for the second region, which was saved before the database system failure occurred. Transaction execution progress information 1 indicates transaction 5, and transaction execution progress information 2 indicates transaction 2. Therefore, based on transaction execution progress information 1 and transaction execution progress information 2, the cloud management platform can determine that the missing data copies in the second region compared to the first region are the data copies of the data to be written corresponding to transactions 3 through 5, which is an example of third data.

[0650] Step S506: The cloud management platform notifies the first database system to send the third data to the second region.

[0651] This third data is a copy of the data that is missing from the first region relative to the second region.

[0652] In some embodiments, upon receiving the aforementioned notification from the cloud management platform, the first database system may send third data to the second database system. The second database system is the database system of the second region. This allows the data stored in the second region to be synchronized with the data stored in the first region.

[0653] Through the above steps S505 and S506, after the database system in the second region is recovered from a failure, the missing data copies in the second region compared to the first region can be incrementally recovered.

[0654] The following is the first database system with the execution subject as the first region (e.g., Figure 5c Taking the main engine and main library shown as an example, combined with Figure 5c To illustrate the above process, the database system of the second region is the second database system, for example, as shown below. Figure 5c The aforementioned are engine 2 and library 2. The first region is located at the first site, and the second region is located at the second site.

[0655] like Figure 5cAs shown, for example, client cluster 800 issues a batch of transactions with transaction numbers from 1 to 1000. The main engine (an example of a computing instance of the first database system) executes transactions 1 to 1000 successfully in sequence, so that the transaction number in the main engine's transaction execution progress information is 1000 as shown in the circle. The main engine, following the methods described in the above embodiments and based on the execution order of multiple transactions, synchronously writes the first data corresponding to each transaction to the slave database 2 and slave engine 2 in the second region. However, after the main engine synchronizes the first data corresponding to transaction 900 to the second region, it has not yet completed the synchronization of the first data corresponding to transaction 901. If the second database system (e.g., slave engine 2) fails, or the communication link between the first and second sites fails, the first data corresponding to transactions 901 to 1000 are not synchronized from the first site to the second site. Therefore, the transaction number in the transaction execution progress information received by the main engine from slave engine 2 (an example of a computing instance of the second database system) is 900 as shown in the circle within the dashed box, indicating that the transaction number of its most recently successfully executed transaction is 900.

[0656] For the process of writing the first data for each transaction from transaction 1 to transaction 900, please refer to... Figure 4a as well as Figure 5a The details of the embodiments will not be repeated here.

[0657] Once the second station recovers from the aforementioned failure and restarts operation, or once the communication link between the second and first stations is restored and normal communication is possible, the main engine can perform incremental recovery of the stored data on the second station. The process is as follows:

[0658] The main engine can obtain the transaction execution progress information of the main engine (represented by transaction execution progress information 0') and the transaction execution progress information of the slave engine 2 (represented by transaction execution progress information 1'), wherein the transaction execution progress information serves as an example of the write progress information in the above embodiment.

[0659] For example, the main engine can obtain the transaction execution progress information 0' and transaction execution progress information 1' from the transaction execution progress information of each engine that is saved.

[0660] The transaction execution progress information 0' includes the transaction number of the most recently successfully executed transaction on the main engine, which is 1000 in this case. The transaction execution progress information 1' includes the transaction number of the most recently successfully executed transaction on engine 2 (i.e., the transaction corresponding to the first data backup from the main database to the slave database 2), which is 900 in this case, indicating that the most recently successfully executed data backup before the failure of engine 2 was transaction 900.

[0661] Based on this, the main engine can determine that the missing data replicas in slave database 2 compared to the main database are the first data corresponding to transactions 901 to 1000 respectively.

[0662] Afterwards, the master engine can control the master database to synchronize the first data corresponding to transactions 901 to 1000 to the slave database 2, and synchronize the database operations corresponding to these first data to the slave engine 2, so as to realize the recovery of the data corresponding to transactions 901 to 1000.

[0663] Specifically, such as Figure 5c As shown in step 1, the main engine can send the transaction execution progress information 1' (indicating transaction 900) obtained above from the slave engine 2 and the transaction execution progress information 0' (indicating that the most recently successfully executed transaction is transaction 1000) to the master database. The master database can find the first data stored in the master database corresponding to transaction numbers 901 to 1000 respectively based on transaction number 900 and transaction number 1000.

[0664] Then, as shown in step 2, the master database can synchronize the first data corresponding to transactions 901 to 1000 to the slave database 2 sequentially or in batches (the specific synchronization method is not limited).

[0665] For example, the master database can send the first data corresponding to transactions 901 to 1000 to the slave database 2 in a single batch, or it can send the first data corresponding to each of the 100 transactions to the slave database 2 in ascending order of transaction number. This application embodiment does not limit this.

[0666] After that, as Figure 5c As shown in steps 3.1 and 3.2, the slave database 2 can generate a corresponding simulated database operation (e.g., a log) based on the first data corresponding to the written transaction 901, and send the simulated database operation to the slave engine 2. After receiving the simulated database operation, the slave engine 2 updates the transaction number in the transaction execution progress information 1' to 901 (indicating transaction 901).

[0667] in, Figure 5c Step 3.1 in the above Figure 5a Step 5.1 is based on the same principle, and step 3.2 is the same as described above. Figure 5a The principle is the same as in step 5.2.

[0668] After step 3.2, as shown in step 4, slave database 2 can send a response result about incrementally synchronized storage data to master database. The response result may include transaction execution progress information 1' of slave engine 2 (carrying transaction number 901), and information indicating that slave database 2 has successfully written the first data corresponding to transaction 901.

[0669] After step 4, as Figure 5c In step 5 shown, the master database can send the transaction execution progress information 1' of the slave engine 2 to the master engine, so that the master engine can update the transaction execution progress information of the slave engine 2 that it has saved. For example, the transaction number in the transaction execution progress information can be updated from 900 to 901, so as to indicate that the transaction number corresponding to the data backed up by the slave engine 2 in the most recent data backup from the master engine is 901.

[0670] In this embodiment of the application, each time the slave database 2 and the slave engine 2 synchronize the first data of a transaction from the first site, they send an updated transaction execution progress information to the first site, so that the transaction execution progress information of the slave engine 2 stored on the main engine side is continuously updated as the backup progress progresses.

[0671] In other embodiments, the slave engine 2 may also send updated transaction execution progress information to the first site once for each of the first data corresponding to multiple transactions synchronized from the first site, so that the transaction execution progress information of the slave engine 2 stored on the main engine side is continuously updated as the backup progress progresses.

[0672] For example, from engine 2, it can be seen that... Figure 5c In the incremental recovery scenario shown, after writing the first data of the five transactions synchronized from the first site, a transaction execution progress information is sent to the first site. For example, in the case of... Figure 5c Step 2, as shown, involves the slave database 2 writing the first data corresponding to transactions 901 to 905, and the slave engine 2 storing the database operations corresponding to transactions 901 to 905 through step 3.1. This indicates that the second server of the second site has synchronized the target descriptions corresponding to transactions 901 to 905. The slave engine 2 can then send the transaction execution progress information 1' (specifically carrying transaction number 905) to the master engine through steps 4 and 5, or via the dashed arrow. This allows the master engine to update the transaction number in the saved transaction execution progress information of the slave engine 2 from 900 to 905. Similarly, the first site continuously synchronizes the first data of subsequent transactions to the second site until the first data corresponding to transactions 900 to 1000 are synchronized from the master database to the slave database, and the corresponding database operations are synchronized to the slave engine 2, thus updating the transaction number in the transaction execution progress information saved by the slave engine 2 on the master engine side to 1000.

[0673] During the incremental recovery of the missing data copy in the second region compared to the first region through the above steps S505 and S506, when the cloud management platform receives a data access request from a client in the second region, such as a client in the second site (e.g., ... Figure 5cAs shown in client 103, the cloud management platform can decide whether to send the data access request to the database system of the second region based on the data access request.

[0674] For example, if the data access request is a write data request, the cloud management platform may not issue the data access request to the database system in the second region, but instead route it to the database system in other regions (such as the first region and other second regions) for data access.

[0675] For example, if the data access request is a request to read data, and the data to be read is data that the database system in the second region had stored before the fault was sent (e.g., any data in the first data corresponding to transactions 1 to 900 above), then the cloud management platform can send the data access request to the database system in the second region to enable access to the corresponding data in slave database 2.

[0676] In some embodiments, during the incremental recovery of the missing data copy in the second region compared to the first region through steps S505 and S506 described above, if a client in the second region needs to issue a data access request, the client can decide which region to route the data access request to based on the response result of the previous data access request (e.g., write progress information of different regions). For details, please refer to the above description. Figure 4b The relevant descriptions in the corresponding embodiments enable the client in the region to determine which region's database system to route the current data access request to during the fault recovery process of the database system in the client's region, based on the previous response results, so as to achieve reliable data access and ensure high data availability.

[0677] In the above Figure 5c In one embodiment, the example given is that when performing data recovery on the second region, the transaction corresponding to the database operation saved by engine 2 is the same as the transaction corresponding to the first data saved by slave database 2.

[0678] In other embodiments, in accordance with Figure 5a The process shown, or Figure 4aThe process illustrated involves the synchronous writing of data from the first site to the second site. A failure at the second site, or a link failure between the first and second sites, could interrupt data synchronization. For example, if the failure occurs after the first data corresponding to transaction 900 is written to slave database 2, slave database 2 may not have yet sent the database operation corresponding to transaction 900 to slave engine 2 via simulated database operations. Therefore, the latest database operation stored by slave engine 2 corresponds to transaction 899. After the failure is repaired, slave engine 2 and slave database 2 within the second site restart, as shown... Figure 5c After the slave database 2 restarts, it can obtain the corresponding database operation based on the first data corresponding to the saved transaction 900, and send the database operation corresponding to transaction 900 to slave engine 2. This ensures that slave engine 2 also saves the database operation for transaction 900, and sends the transaction execution progress information of slave engine 2 (specifically, the transaction number is 900) to the first site, updating the transaction number in the transaction execution progress information of slave engine 2 on the master engine side from 899 to 900. Ther...

Claims

1. A data access method, characterized in that, The method is applied to a cloud service system, which includes a cloud management platform and multiple database systems, including a first database system and a second database system. The cloud management platform manages the infrastructure providing cloud services. The infrastructure deploys one or more database instances of the first database system and one or more database instances of the second database system. The first database system is located in a first region, and the second database system is located in a second region. The first database system receives a first data write request, which indicates the first data to be written. The first database system writes the first data based on the first data write request and obtains the first write progress information of the first region. The first write progress information is used to indicate the writing progress of the first data in the first region. The first database system sends the first data to the second database system; The first database system obtains the second write progress information of the second region, which is used to indicate the write progress of the first data in the second region. The first database system outputs a first response result in response to the first data write request. The first response result includes first write progress information for the first region and second write progress information for the second region.

2. The method according to claim 1, characterized in that, The method further includes: The first database system obtains first information, which is used to indicate the response time of the first data write request; Starting from the moment the first database system receives the first data write request, it outputs a second response result to the first data write request within the response duration. The second response result includes the first write progress information, which includes information indicating that the first region has supported access to the first data.

3. The method according to claim 1 or 2, characterized in that, Before the first database system outputs a first response result to the first data write request, the method further includes: The first database system receives a second data write request. The second data write request and the first data write request are the same batch of data write requests processed by the first database system. The response order of the second data write request is before the response order of the first data write request. The second data write request is used to indicate the second data to be written. The first database system sends the second data to the second database system; The first database system obtains the third write progress information of the second region, which is used to indicate the write progress of the second region for the second data corresponding to the most recently responded second data write request. The first database system outputs a third response result in response to the first data write request, the third response result including the first write progress information and the third write progress information.

4. The method according to claim 3, characterized in that, The method further includes: The first database system obtains the synchronization delay information of the second region based on the first write progress information of the first region and the third write progress information of the second region. The synchronization delay information is used to indicate the time required for the data stored in the second region to be synchronized with the data stored in the first region. The first database system outputs a fourth response result in response to the first data write request, the fourth response result including the synchronization delay information of the second region.

5. The method according to claim 4, characterized in that, The method further includes: The first database system determines the third data to be synchronized from the first region to the second region based on the first write progress information of the first region and the third write progress information of the second region; The first database system sends the third data to the second database system.

6. The method according to any one of claims 1 to 5, characterized in that, The first database system includes a first storage device located in the first region where the first database system is situated, and the second database system includes a second storage device located in the second region where the second database system is situated. The first database system writes the first data based on the first data write request, including: The first database system writes the first data to the first storage device based on the first data write request; The first database system sends the first data to the second database system, including: The first storage device sends the first data to the second storage device.

7. The method according to any one of claims 1 to 6, characterized in that, The method further includes: The cloud management platform receives the first data write request; The cloud management platform sends the first data write request to the first database system; The cloud management platform receives the first response result output by the first database system; The cloud management platform outputs the first response result.

8. A cloud service system, the cloud service system comprising a cloud management platform and multiple database systems, the multiple database systems including a first database system and a second database system, the cloud management platform being used to manage infrastructure providing cloud services, the infrastructure being deployed with one or more database instances including the first database system and one or more database instances including the second database system, the first database system being located in a first region, and the second database system being located in a second region; The first database system is used to receive a first data write request, the first data write request being used to indicate the first data to be written; The first database system is further configured to write the first data based on the first data write request, and obtain first write progress information of the first region, wherein the first write progress information is used to indicate the write progress of the first data in the first region. The first database system is also used to send the first data to the second database system; The first database system is also used to obtain second write progress information of the second region, the second write progress information being used to indicate the write progress of the first data in the second region; The first database system is also configured to output a first response result in response to the first data write request, the first response result including first write progress information of the first region and second write progress information of the second region.

9. The cloud service system according to claim 8, characterized in that, The first database system is also used to obtain first information, which is used to indicate the response time of the first data write request; The first database system is further configured to output a second response result to the first data write request within the response duration, starting from the moment the first data write request is received, the second response result including the first write progress information, the first write progress information including information indicating that the first area has supported access to the first data.

10. The cloud service system according to claim 8 or 9, characterized in that, The first database system is also used to receive a second data write request, wherein the second data write request and the first data write request are the same batch of data write requests processed by the first database system in batches, the response order of the second data write request is before the response order of the first data write request, and the second data write request is used to indicate the second data to be written; The first database system is also used to send the second data to the second database system; The first database system is also used to obtain third write progress information of the second region, the third write progress information being used to indicate the write progress of the second data corresponding to the most recently responded second data write request in the second region; The first database system is also used to output a third response result to the first data write request, the third response result including the first write progress information and the third write progress information.

11. The cloud service system according to claim 10, characterized in that, The first database system is also used to obtain synchronization delay information of the second region based on the first write progress information of the first region and the third write progress information of the second region. The synchronization delay information is used to indicate the time required for the data stored in the second region to be synchronized with the data stored in the first region. The first database system is also used to output a fourth response result to the first data write request, the fourth response result including the synchronization delay information of the second region.

12. The cloud service system according to claim 11, characterized in that, The first database system is also used to determine the third data to be synchronized from the first region to the second region based on the first write progress information of the first region and the third write progress information of the second region; The first database system is also used to send the third data to the second database system.

13. The cloud service system according to any one of claims 8 to 12, characterized in that, The first database system includes a first storage device located in the first region where the first database system is situated, and the second database system includes a second storage device located in the second region where the second database system is situated. The first database system is specifically used to write the first data to the first storage device based on the first data write request; The first storage device is used to send the first data to the second storage device.

14. The cloud service system according to any one of claims 8 to 13, characterized in that, The cloud management platform is also used to receive the first data write request; The cloud management platform is also used to send the first data write request to the first database system; The cloud management platform is also used to receive the first response result output by the first database system; The cloud management platform is also used to output the first response result.

15. A computing device cluster, characterized in that, It includes at least one computing device, each computing device including a processor and memory; The processor of the at least one computing device is configured to execute instructions stored in the memory of the at least one computing device to cause the cluster of computing devices to perform the method as described in any one of claims 1 to 7.

16. A computer program product containing instructions, characterized in that, When the instruction is executed by the computing device cluster, the computing device cluster causes the computing device cluster to perform the method as described in any one of claims 1 to 7.

17. A computer-readable storage medium, characterized in that, Includes computer program instructions, which, when executed by a cluster of computing devices, perform the method as described in any one of claims 1 to 7.