Data access method, cloud service system, and device

Abstract

Provided in the present application are a data access method, a cloud service system, and a device. The method comprises: a first database system receiving a first data write request; the first database system writing first data on the basis of the first data write request, and acquiring first write progress information of a first region; the first database system sending the first data to a second database system; the first database system acquiring second write progress information of a second region; and the first database system outputting a first response result for the first data write request, wherein the first response result comprises the first write progress information of the first region and the second write progress information of the second region. For example, the first database system can output the first response result to a client that sends the data write request. In this way, it is convenient for the client to obtain, on the basis of the response result, write progresses of the first data in different regions, and thus the implementation of cross-regional data access is facilitated, which is conducive to deploying global services.

Description

Data access methods, cloud service systems and devices

[0001] This application claims priority to Chinese Patent Application No. 202411988243.0, filed on December 28, 2024, entitled “Data Access Method, Cloud Service System and Other Devices”, the entire contents of which are incorporated herein by reference. Technical Field

[0002] 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

[0003] 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.

[0004] 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

[0005] 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.

[0006] 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.

[0007] 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.

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

[0009] 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.

[0010] 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.

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

[0012] 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.

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

[0014] 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.

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

[0016] 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.

[0017] 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.

[0018] 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.

[0019] 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.

[0020] 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.

[0021] 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.

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

[0023] 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.

[0024] 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.

[0025] 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.

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

[0027] 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.

[0028] 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.

[0029] 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.

[0030] 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.

[0031] 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.

[0032] 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.

[0033] 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.

[0034] 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.

[0035] 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.

[0036] 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.

[0037] 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.

[0038] 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.

[0039] 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.

[0040] 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.

[0041] 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.

[0042] 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.

[0043] 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.

[0044] 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.

[0045] 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.

[0046] 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.

[0047] 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.

[0048] 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.

[0049] 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.

[0050] 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.

[0051] 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.

[0052] 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.

[0053] 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.

[0054] 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.

[0055] 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.

[0056] 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.

[0057] 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.

[0058] 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.

[0059] 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.

[0060] 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.

[0061] 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.

[0062] 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.

[0063] 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.

[0064] 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.

[0065] 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.

[0066] 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.

[0067] 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.

[0068] 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.

[0069] 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.

[0070] 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.

[0071] 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

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

[0073] Figure 1b is a flowchart of a data access method in a fault scenario in a related technology.

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

[0075] Figure 2a is a schematic diagram of an implementation scenario involving a data access method provided in an embodiment of this application;

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

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

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

[0079] Figure 4b is a flowchart illustrating another data access method provided in an embodiment of this application;

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

[0081] Figure 4d is a flowchart illustrating another data access method provided in an embodiment of this application;

[0082] Figure 4e is a flowchart illustrating another data access method provided in an embodiment of this application;

[0083] Figure 4f is a flowchart illustrating another data access method provided in an embodiment of this application;

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

[0085] Figure 5b is a schematic diagram of another data access method provided in an embodiment of this application;

[0086] Figure 5c is a schematic diagram of another data access method provided in an embodiment of this application;

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

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

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

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

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

[0092] 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.

[0093] 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.

[0094] 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.

[0095] 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.

[0096] 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:

[0097] 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.

[0098] 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.

[0099] 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.

[0100] 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.

[0101] 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.

[0102] 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.

[0103] 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.

[0104] 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.).

[0105] 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.

[0106] 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.

[0107] 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.

[0108] 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.

[0109] 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".

[0110] 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".

[0111] 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.

[0112] 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 state of the database.

[0113] 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.

[0114] 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.

[0115] 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.

[0116] 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).

[0117] Referring to Figures 1a to 1c, a data access method is provided in the related technology. As shown in Figure 1a, the data is stored in a database. The system may include two physically distant sites, namely a first site (also called the master site) and a second site (also called the slave site). The first site includes multiple clients 1, a MySQL database engine 1 (also called the master engine), and a master database (also called the master database). The second site includes a client 2, a MySQL database engine 2 (also called the slave engine), and a slave database (also called 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.

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

[0119] Implementation Method 1

[0120] Referring to steps 1 to 6 (solid lines) in Figure 1a, 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.

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

[0122] 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.

[0123] 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.

[0124] 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.

[0125] 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.

[0126] The data access method described above in the related technology can also be implemented through implementation method 2, which can be implemented through solid line steps 1 to 3, dashed line steps 4 to 5, and solid line step 6 as shown in Figure 1a.

[0127] 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.

[0128] 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.

[0129] 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.

[0130] 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.

[0131] Furthermore, in the data backup process described in Method 1, after a transaction is completed in the master database, it must wait for the transaction to also be completed in the slave database (e.g., steps 3, 4, and 5 as shown in Figure 1a) before a response result can be returned to client 1 via step 6. This results in a longer response delay for client 1, thus affecting client 1's ability to issue other business (e.g., submit another order). Moreover, during the synchronization of data from the master database to the slave database, data transmission between MySQL database engine 1 and MySQL database engine 2, as well as between MySQL database engine 2 and the slave database, takes a long time, especially when the physical distance between the master and slave sites is large (e.g., the two sites are in different regions). This further increases the response delay for client 1.

[0132] 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.

[0133] Furthermore, in some cases, referring to Figure 1a and referring to Figure 1b, during 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 will be described below:

[0134] As shown in Figures 1b and 1c, at time t0, client 1 at the first site (also called the master 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 master database according to the database operations involved in transaction 1, thereby achieving 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 synchronizing data to MySQL database engine 2.

[0135] 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.

[0136] During the data synchronization process from MySQL database engine 1 to MySQL database engine 2, a failure occurs at the second site at time t2, 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. Therefore, MySQL database engine 1 only detects the failure of the second site and / or the break in the communication link between the two sites at time t4, as shown in Figure 1c. Only after time t4, for example, at time t5, will MySQL database engine 1 return a response result to client 1 for data access request 1 (e.g., order submission successful).

[0137] During the execution of data access request 1 as shown in Figure 1c, a failure at the second site and / or a break in the communication link between the two sites will cause a period of lag 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 lag in the client's current business operations.

[0138] 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.

[0139] 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.

[0140] 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.

[0141] 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.

[0142] 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.

[0143] 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.

[0144] 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.

[0145] 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.

[0146] 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.

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

[0148] 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.

[0149] Figure 2a is a schematic diagram of an implementation scenario involving a data access method provided in this application. As shown in Figure 2a, the implementation scenario includes: a data center 1 and a client 1. A communication connection can be established between the data center 1 and the client 1 via a network. Optionally, the network can be the Internet, or other networks; this application embodiment does not limit the specific network. Tenants can interact with the data center 1 through the client 1. For example, a tenant can send data access requests (e.g., data write requests) to the data center 1 through the client 1. The data center 1 responds based on the information sent by the client 1.

[0150] Data center 1 is equipped with a large amount of infrastructure owned by a 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. As shown in Figure 2a, data center 1 includes a cloud management platform and infrastructure (not shown in Figure 2a). The cloud management platform and infrastructure are connected via an internal network within the data center. 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 computing 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 computing nodes of the computing node cluster. Tenants can send data access requests (e.g., data write requests) and related information to the computing nodes through their client 1. The computing 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.

[0151] 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.

[0152] In the implementation scenario shown in Figure 2a, 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 hardware devices such as 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 for the virtual machines, and to manage the virtual machines.

[0153] 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.

[0154] In one implementation, as shown in Figure 2b, the location of infrastructure in a data center can be described by cloud resource deployment regions (regions) and availability zones (AZs). Tenants can choose to deploy cloud services based on resources in specific regions and AZs. Regions are defined based on geographical location and network latency. Using the same resource pool within the same region can be understood as sharing public 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 regions and dedicated regions. General regions provide general cloud services to public tenants. Dedicated regions are dedicated regions that host the same type of business or provide 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 a collection of one or more data centers as shown in Figure 2a. Computing, network, and storage resources within an AZ are logically divided into multiple clusters.

[0155] Tenants can send instructions to the cloud management platform through their client 1 (as shown in Figure 2a) to create, manage, log in to, and operate virtual instances on the server, and use the cloud services provided by these virtual instances. For example, the cloud management platform can provide an access interface. This 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 these accounts and passwords. 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 with specific specifications (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.

[0156] 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.

[0157] 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.

[0158] 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.

[0159] Referring to Figures 2a and 2b, and further to Figure 3, Figure 3 illustrates a cross-regional cloud service system provided by an embodiment of this application. Based on the system described in Figure 3, cross-regional data access services provided by this embodiment of the application can be realized.

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

[0161] 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.

[0162] 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.

[0163] 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.

[0164] 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.

[0165] 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).

[0166] 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.

[0167] 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.

[0168] 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.).

[0169] Referring again to Figure 3, the system may include a data center cluster 1001 deployed in region 2 and a client cluster 801 communicating with it. Referring to Figure 2a, as shown in Figure 3, the client cluster 801 and the data center cluster 1001 interact through a cloud management platform to access cloud services.

[0170] 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.

[0171] 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.

[0172] 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.

[0173] Referring again to Figure 3, the system may further include a data center cluster 1002 deployed in region 3 and a client cluster 802 communicating with it. Referring to Figure 2a, as shown in Figure 3, the client cluster 802 and the data center cluster 1002 interact via a cloud management platform to access cloud services.

[0174] 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.

[0175] 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.

[0176] 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.

[0177] In the system shown in Figure 3, taking the example of a computing instance running on a single computing node, 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.

[0178] Similarly, as shown in Figure 3, the system is illustrated by taking a single storage instance running on a single storage node as an example. 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.

[0179] In the embodiments described below, for ease of explanation, computing instance 1 shown in Figure 3 is also referred to as "main engine", storage instance 1 is also referred to as "main library", computing instance 2 is also referred to as "slave engine 2", storage instance 2 is also referred to as "slave library 2", computing instance 3 is also referred to as "slave engine 3", and storage instance 3 is also referred to as "slave library 3".

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

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

[0182] In some embodiments, the data access method can be applied to the cloud service system described in any of the embodiments of Figures 2a to 2b and Figure 3. For example, it 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. This application does not limit this.

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

[0184] 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.

[0185] 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.

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

[0187] 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).

[0188] 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.

[0189] 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.

[0190] 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.

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

[0192] 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.

[0193] 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 some embodiments, the number of second regions may be N, where N is a positive integer.

[0194] 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.

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

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

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

[0198] 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.

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

[0200] 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.

[0201] 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.

[0202] 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.

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

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

[0205] 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.

[0206] 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.

[0207] 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.

[0208] 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.

[0209] 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.

[0210] For example, as shown in Figure 3, client 102 sends a first data access request to a server in region 1, such as computing instance 1, through a cloud management platform (not shown). Region 1 can then be called the primary site. The primary site can be used to write first data based on the first data access request, while the secondary sites communicating with the primary site (such as at least one of region 2 and region 3 as shown in Figure 3) are used to back up the first data.

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

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

[0213] 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.

[0214] Taking the architecture in Figure 3 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.

[0215] Taking the architecture shown in Figure 3 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.

[0216] 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).

[0217] 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.

[0218] 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.

[0219] 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.

[0220] 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.

[0221] 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.

[0222] 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.

[0223] 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).

[0224] 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").

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

[0226] 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).

[0227] 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).

[0228] 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").

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

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

[0231] 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).

[0232] 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").

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

[0234] 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).

[0235] In the scenario shown in Figure 3, 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.

[0236] 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).

[0237] 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 the scenario of FIG3, 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.

[0238] 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.

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

[0240] 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.

[0241] 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.

[0242] 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.

[0243] 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.

[0244] 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.

[0245] 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.

[0246] 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.

[0247] 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.

[0248] 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.

[0249] 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.

[0250] 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.

[0251] 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.

[0252] 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.

[0253] 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.

[0254] 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.

[0255] 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.

[0256] 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.

[0257] 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.

[0258] For example, taking Figure 3 as an 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.

[0259] 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.

[0260] 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.

[0261] 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.

[0262] 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.

[0263] 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.

[0264] 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.

[0265] Taking Figure 3 as an example, when the computing node 11 in region 1 generates a corresponding transaction based on the first data access request sent by the client 102 and stores the database operation in the transaction in the 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 storage node 21 in region 1 also stores the first data, it means that region 1 supports access to the first data.

[0266] 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.

[0267] 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.

[0268] 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.

[0269] 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.

[0270] 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.

[0271] 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.

[0272] Taking Figure 3 as an example, if the first database system in region 1 receives the 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.

[0273] 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.

[0274] 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.

[0275] 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.

[0276] 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.

[0277] 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.

[0278] 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.

[0279] For example, in the scenario shown in Figure 3, 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 writes the target operation, and a storage instance (e.g., storage instance 1) communicating with the compute instance (e.g., compute instance 1) writes the first data, then region 1 has supported access to the first data.

[0280] 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.

[0281] Accordingly, if storage instance 1, as shown in Figure 3, 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 has supported access to the first data.

[0282] Conversely, if storage instance 1, as shown in Figure 3, does not synchronize the first data to at least one storage instance in region 2, and / or the computing 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.

[0283] Accordingly, if storage instance 1, as shown in Figure 3, 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.

[0284] Conversely, if storage instance 1, as shown in Figure 3, 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.

[0285] Referring again to Figure 3, in the cloud scenario shown in Figure 3, the first database system located in region 1 can obtain the second write progress information of region 2 and the second write progress information of 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.

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

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

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

[0289] In some embodiments, taking FIG3 as an example, the first database system located in region 1 can output a first response result to the first data access request. For example, the first response result can be output to a cloud management platform so that the cloud management platform can output the first response result. For example, it can be output to the client that sent the first data write request, such as client 102 shown in FIG3.

[0290] 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.

[0291] In other embodiments, the write progress information of each region included in the first response result can be used to indicate the write progress of the specific physical server or specific virtual instance in the corresponding region regarding 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 these scenarios fall within the scope of the embodiment in Figure 4a.

[0292] 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.

[0293] 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.

[0294] 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.

[0295] 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.

[0296] 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).

[0297] Referring 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.

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

[0299] 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.

[0300] 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.

[0301] 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.

[0302] The following describes several possible representations of the target information included in the response results shown in Figure 4a above. In specific applications, the target information may have more or fewer representations to indicate the writing progress information of the first data in each of the multiple areas used to implement data access.

[0303] In some embodiments, the multiple servers in different regions of the embodiment in FIG4a 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 limit them.

[0304] 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.

[0305] 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.

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

[0307] For example, in the scenario shown in Figure 3, 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.

[0308] 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.

[0309] 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.

[0310] 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.

[0311] 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.

[0312] Taking Figure 3 as an 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.

[0313] For example, in the scenario shown in Figure 3, 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.

[0314] 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.

[0315] Taking Figure 3 as an example, the transaction numbers of the 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".

[0316] 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.

[0317] 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.

[0318] 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.

[0319] 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.

[0320] 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.

[0321] 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.

[0322] 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.

[0323] 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.

[0324] 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).

[0325] 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.

[0326] 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.

[0327] 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.

[0328] 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.

[0329] 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.

[0330] 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.

[0331] 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.

[0332] 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).

[0333] The methods of the above embodiments will be described below with reference to Figure 5a. The architecture shown in Figure 5a can be implemented in conjunction with the architecture shown in Figure 3, and there is no limitation here.

[0334] Please refer to Figure 5a. Taking data stored in a relational database as an example, the first data access request received by the 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.

[0335] 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 take one master database corresponding to one slave database as an example. As shown in Figure 3 above, a system with one master database corresponding to two slave databases is a preferred cross-regional system.

[0336] For example, the main engine can process a batch (multiple) of transactions at a time, and the processing method of each transaction is the same. The following uses a single transaction as an example, and takes the calculation instance 1 (i.e. the main engine) shown in Figure 5a to execute the method shown in Figure 4a as an example. When the execution subject is another object, the method is the same.

[0337] Please refer to steps 1 and 2 in Figure 5a:

[0338] 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.

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

[0340] In the first implementation, after step 2, please refer to step 3 in Figure 5a. After the primary database writes the first data, it sends a response indicating that transaction 1 was successfully written in the primary database to the primary engine.

[0341] 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.

[0342] 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.

[0343] 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.

[0344] 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.

[0345] 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.

[0346] 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.

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

[0348] 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.

[0349] 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.

[0350] In the embodiment shown in Figure 5a above, after the master database writes the first data, it can execute step 3 to send a response to the master 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 master engine. This scheme is an asynchronous access scheme for the master database.

[0351] 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.

[0352] Referring to the above description of the relevant technologies in conjunction with Figure 1a, in these technologies, when synchronizing data from the master site to the slave site, the master engine of the server (i.e., the server-side) transmits log data related to database operations and other data involved in transactions to the slave engine to achieve data synchronization between the master and slave sites. The amount of this log data is large, resulting in a long data synchronization time. Furthermore, only after data synchronization can the master engine respond to the client's data access request, leading to a long response time for the client's data access request.

[0353] 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.

[0354] Furthermore, the data synchronization process in related technologies involves data transmission from the main engine to the slave engine, from the slave engine to the slave database, and from the engine to the main engine (e.g., the data transmission process in solid lines 3 to 5 of Figure 1a). In contrast, the data synchronization process in this embodiment only requires one round trip data transmission between the main database and the slave database (e.g., the data transmission process in steps 4 to 6 of Figure 5a). Since the communication speed within the region is very fast, the data transmission speed within the second region (e.g., steps 5.1 and 5.2 of Figure 5a) is also very fast, having almost no impact on latency. Compared to related technologies, the path between different sites traversed in the data synchronization process in this embodiment is shorter, thereby further reducing the time used for data synchronization and consequently further reducing client response latency.

[0355] 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 the 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 steps 5.1 and 5.2, as shown in Figure 5a, have not yet been completed when the main engine returns the response result to the client, meaning that the simulated database operations related to the first data have not yet been stored on the slave server (e.g., slave engine 2), after the second database system restarts, slave database 2 can send the simulated database operations related to the first data to slave engine 2 to achieve storage of the database operations, thereby not affecting access to the first data in the second area and ensuring high availability of data.

[0356] 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.

[0357] 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.

[0358] 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.

[0359] 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.

[0360] 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.

[0361] 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.

[0362] The third implementation differs from the second in that, instead of sending the transaction execution progress information 1 to the first site through the slave database 2, as shown by the dashed arrow in Figure 5a, the slave engine 2 directly sends the transaction execution progress information 1 to the master 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 the transaction progress information 1 can be achieved through the third implementation.

[0363] 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.

[0364] 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).

[0365] Furthermore, regardless of which of the above-mentioned first to fourth implementation methods is used, after the slave engine 2 saves the simulated database operations for transaction 1 in step 5.1, the master engine can obtain the transaction execution progress information 1 of the slave engine 2. Here, as shown in Figure 5a, the ① near the slave engine 2 indicates that the slave engine 2 has synchronized the stored data of transaction 1 and the corresponding first data written to the slave database 2 for transaction 1.

[0366] 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.

[0367] Similarly, as shown in 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 has been written to the main database 1.

[0368] 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.

[0369] 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.

[0370] 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.

[0371] 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.

[0372] In some embodiments, the number of virtual instances in each site is not limited to the set shown in Figure 5a (one compute instance and one storage instance). In this case, the main engine can return the response result to the client only if more than half of the compute instances in the two sites have successfully executed transaction 1.

[0373] 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.

[0374] 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.

[0375] 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.

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

[0377] 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.

[0378] 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.

[0379] 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.

[0380] 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 area not only needs to write the target operation and the first data in the first area based on the request, but also needs to synchronize the first data to the second area for storage.

[0381] 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.

[0382] 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.

[0383] 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.

[0384] 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.

[0385] Referring 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.

[0386] 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).

[0387] Then, client 102 can send data access request 2 to compute instance 1 through the cloud management platform (such as the cloud management platform shown in Figure 2a). After receiving data access request 2, compute instance 1 can read data from storage instance 1. After compute instance 1 successfully reads the data, it can return the read data to client 102.

[0388] 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).

[0389] Then, client 102 can proceed as described in scenario 1 above, or it can route data access request 2 to client 103 in region 2. Client 103 can then distribute data access request 2 to compute instance 2 via a cloud management platform (e.g., the cloud management platform shown in Figure 2a), 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 in turn sends the read data to client 102.

[0390] 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).

[0391] 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.

[0392] 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.

[0393] Referring to any of the embodiments in Figures 3 to 5a, please refer to Figure 4b, which is a flowchart illustrating another data access method provided by an embodiment of this application. The application scenarios of this data access method can be found in the description of the application scenarios in the embodiment of Figure 4a. The following describes the methods of various embodiments of this application using the method of this application applied to the aforementioned cloud management platform as an example. This method can also be applied to the aforementioned cloud service system.

[0394] Referring to Figure 4a, before step S403, the method may further include: steps S501, S502, S503, and S504.

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

[0396] 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.

[0397] 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.

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

[0399] 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.

[0400] 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.

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

[0402] 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 the principle of the first database system obtaining the first write progress information of the first region as described in the embodiment of FIG4a, except that the second data is data written by the first database system before the first data.

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

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

[0405] 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.

[0406] 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.

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

[0408] 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.

[0409] The third write progress information is similar to the second write progress information of the second region mentioned in the embodiment of Figure 4a 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. This will not be elaborated here.

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

[0411] In some embodiments, the third response result includes first write progress information (e.g., the first write progress information obtained in S4012 in FIG4a above) and third write progress information.

[0412] 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.

[0413] Thus, prior to S403 as shown in FIG4a, in some embodiments, the first database system may output a third response result in response 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.

[0414] 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.

[0415] Take the cloud scenario shown in Figure 3 as an example:

[0416] For example, the first region is region 1 as shown in Figure 3, and the second region consists of two regions, namely region 2 and region 3.

[0417] 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.

[0418] 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.

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

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

[0421] Taking Figure 5b as an example, multiple clients within the client cluster 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 and process 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 (e.g., transactions) at a time, such as transactions 1 to 100. These transactions are ordered in sequence, and different sites (e.g., the first site to the third site shown in Figure 5b) perform data writing (the first site performs the writing) and backup (the second and third sites back up the data written by the first site) according to the same transaction order.

[0422] 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 copy of the data written by the first database system to achieve a backup effect.

[0423] 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.

[0424] 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.

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

[0426] For example, the write progress information mentioned in any of the above embodiments can be the transaction execution progress information described in the embodiment of FIG4a.

[0427] 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.

[0428] The above process will be explained in detail below with reference to Figure 5b. The architecture shown in Figure 5b can be implemented in conjunction with the architecture shown in Figure 3, and there are no restrictions here.

[0429] 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 the site located in region 1 as shown in Figure 3, the second site can be the site located in region 2, and the third site can be the site located in region 3.

[0430] 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.

[0431] For a description of the first and second stations during the synchronization process, please refer to the relevant description in Figure 5a.

[0432] The interaction process between the first database system of the first site and the second database system of the third site in Figure 5b is the same as the interaction process between the first database system of the first site and the second database system of the second site in Figure 5a. The process of the second database system of the third site backing up and storing data is the same as the process of the second database system of the second site backing up and storing data shown in Figure 5a. The differences will be explained below, and the similarities will be described with reference to the relevant description in Figure 5a.

[0433] As shown in Figure 5b, 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 in region 3 as shown in Figure 3.

[0434] For example, as shown in Figure 5b, a batch of data access requests received by the main engine from client cluster 800 correspond to a batch of transactions, namely transactions 1 to 100. For example, the first data access request currently being processed by the main engine is transaction 3 among transactions 1 to 100.

[0435] As shown in Figure 5b, 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'.

[0436] 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.

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

[0438] According to this data synchronization process, slave database 2 synchronizes the data to be written corresponding to transactions 1 to 3 from the master database, and slave engine 2 also stores 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 (which is one of the 100 transactions synchronizing data from the first site to the second site) is transaction 3. In Figure 5b, transaction 3 in the transaction execution progress information 1' is represented by ③ next to slave engine 2. This transaction execution progress information 1' indicates that the second area located at the second site supports access to the first data corresponding to transaction 3.

[0439] 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.

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

[0441] 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 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 transaction execution progress information on the storage instance 2 side. Thus, before step 5.2 as shown in FIG5b, the writing progress of the first data corresponding to transaction 3 in the second area located at the second site is information indicating that the first data has been written to the second area.

[0442] 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. In Figure 5b, transaction 2 in the transaction execution progress information 2' is represented by ② next to engine 3. The most recently successfully executed transaction indicated in the transaction execution progress 2' of engine 3 (which is the transaction among the aforementioned 100 transactions where the first station synchronizes data with the second station) is transaction 2.

[0443] 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.

[0444] 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.

[0445] 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.

[0446] For example, in the scenario of the embodiment in Figure 4b, 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.

[0447] The first write progress information can be the write progress information (e.g., information that has been supported for access) of the first data (specifically, the data written to the main database corresponding to transaction 3) in region 1 where the first site is located, as shown in Figure 5b.

[0448] In the scenario shown in Figure 5b, the second region consists of two areas: region 2, where the second station is located, and region 3, where the third station is located.

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

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

[0451] The third write progress information of region 3 can be the write progress information (e.g., information that access is supported) of the second data (specifically, the data written to the primary database corresponding to the second data access request in the most recent response) of region 3 where the third site is located, as shown in Figure 5b.

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

[0453] 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.

[0454] 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.

[0455] Alternatively, for example, a batch of data access requests issued by client cluster 800 can be considered as transactions, ordered as transactions 1 to 5, corresponding to business 1 to business 5 respectively, and each business from business 2 to business 5 depends on the adjacent previous business. Taking Figure 5b as an example, ③ next to the main engine represents transaction 3 in transaction execution progress information 0', that is, the most recently successfully executed transaction of the current main engine (a transaction among transactions 1 to 5) is transaction 3. ③ next to the slave engine 2 represents transaction 3 in transaction execution progress information 1', that is, the most recently successfully executed transaction of the slave engine 2 (the transaction corresponding to the most recently synchronized data from the first site to the second site) is transaction 3. ② next to the slave engine 3 represents transaction 2 in transaction execution progress information 2', that is, the most recently successfully executed transaction of the slave engine 3 (the transaction corresponding to the most recently synchronized data from the first site to the second site) is transaction 2.

[0456] 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.

[0457] In the embodiment shown in Figure 5b above, 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.

[0458] 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 the first data in response to data access requests received by the second site (where the slave engine 2 writes the database operation corresponding to the first data, and the slave database 2 writes the data to be stored). For example, the data access request received by the database system of the second site indicates a request to write the first data. The second site can also synchronously back up the first data to the first and third sites, a process similar to that in Figure 5b where the first site is the master site and the second and third sites are slave sites, the only difference being that the second site is the master site and the first and third sites are slave sites.

[0459] Similarly, in some embodiments, the third station shown in FIG5b can be the master station, and the first station and the second station can be the slave stations of the third station to implement the method of the embodiments of this application. The specific implementation principle is similar to the process in FIG5b in which the first station is the master station and the second station and the third station are the slave stations.

[0460] For example, as shown in Figure 5b, computing instance 1 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.

[0461] 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).

[0462] 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).

[0463] 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 β).

[0464] 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 β.

[0465] 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.

[0466] 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.

[0467] 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.

[0468] 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.

[0469] 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.

[0470] 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.

[0471] 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.

[0472] 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.

[0473] 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.

[0474] 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.

[0475] 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.

[0476] 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.

[0477] 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.

[0478] 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.

[0479] 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.

[0480] As shown in Figure 4b, 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.

[0481] 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.

[0482] 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.

[0483] 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.

[0484] 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.

[0485] 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 S4012 as shown in Figure 4a. Correspondingly, the first write progress information of the first region used by the first database system to obtain the synchronization latency information of the second region can also be referred to the specific description of the first database system obtaining the first write progress information of the first region in the process of Figure 4a, which will not be repeated here.

[0486] In some embodiments, for example, the first database system can obtain the synchronization latency information of the second 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, this step can be performed by the main engine in Figure 5a, and the process is similar to that performed by the cloud management platform.

[0487] 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.

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

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

[0490] 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.

[0491] 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.

[0492] 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.

[0493] Referring to 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 engine 1 (in the second database system) is 30, it means that the most recently successfully executed transaction by engine 1 is Transaction 30 (the transaction corresponding to the most recently responded second data access request in region 2 where the second site is located is Transaction 30). If the transaction number in the current transaction execution progress information of engine 2 (in another second database system) is 50 (the transaction corresponding to the most recently responded second data access request in region 3 where the third site is located is Transaction 50), it means that the most recently successfully executed transaction by engine 2 is Transaction 50.

[0494] 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.

[0495] In this way, the client can output a fourth response result based on the synchronization delay information of region 2 where the second station is located and region 3 where the third station is located. This fourth response result can be output simultaneously with the first response result in Figure 4a above, or output sequentially, without any restriction on the order.

[0496] 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.

[0497] 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.

[0498] Referring to any one of the embodiments in Figures 3 to 4b and Figures 5a to 5b, and specifically to Figure 4c, which is a flowchart illustrating another data access method provided by an embodiment of this application, the application scenarios of this data access method can be found in the description of the application scenarios in the embodiment of Figure 4a. The following describes the methods of various embodiments of this application using the method of this application applied to the aforementioned cloud management platform as an example. This method can also be applied to the aforementioned cloud service system.

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

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

[0501] For a description of step S401, please refer to the relevant introduction of this step in the embodiment of Figure 4a above, and it will not be repeated here.

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

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

[0504] 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.

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

[0506] 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).

[0507] 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.

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

[0509] 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.

[0510] 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.

[0511] As an example, as shown in Figure 3, 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.

[0512] 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.

[0513] 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.

[0514] 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.

[0515] Taking Figure 3 as an example, the first information can be pre-configured in a computing node (e.g., computing node 11) or a storage node (e.g., storage node 12) within region 1, or a computing instance (e.g., computing instance 1) within a computing 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.

[0516] 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.

[0517] 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.

[0518] In the embodiment shown in Figure 4c, step S701 is executed after step S401. In other embodiments, S401 may be executed in parallel 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.

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

[0520] 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.

[0521] 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.

[0522] 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.

[0523] 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.

[0524] 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.

[0525] 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.

[0526] In conjunction with the embodiment of Figure 4a above, 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.

[0527] 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.

[0528] 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.

[0529] 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.

[0530] 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.

[0531] 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.

[0532] Taking Figure 3 as an example, 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 (for example, 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 example, 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.

[0533] 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.

[0534] Continuing with Figure 3 as an example, if the cloud management platform (not shown) determines, based on the first information, that the response duration indicated by the first information is greater than a preset threshold, it indicates that the response duration is relatively long. Then, 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 (e.g., compute instance 3 and storage instance 3 in region 3) that responded to the first data access request, so that the cloud management platform can output the write progress of the first data corresponding to the first data access request from the aforementioned database system to client 102. This allows the client to determine the synchronization progress of the first data from different regions' database systems based on the response information.

[0535] The specific implementation of the above process will be explained below with reference to Figure 5b.

[0536] For example, as shown in Figure 5b, the main engine (an example of a computing instance in the first database system) processes a batch of transactions, numbered 1 through 100. For instance, the first data access request currently being processed by the main engine is transaction 3 within 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.

[0537] 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).

[0538] 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.

[0539] 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 (refer to the embodiment in Figure 4b). Based on the response time of transaction 3, within that response time, it outputs a second response result to the master engine based on the obtained write progress information. The master engine then returns the second response result to the client 102. This reduces the computational overhead of the master engine. Among the write progress information of the three regions obtained by the master database, at least one region's engine sends write progress information indicating that the region where that engine is located supports access to the first data.

[0540] 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.

[0541] 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.

[0542] For example, before the timeout T reaches the response duration T1, the main engine can obtain the transaction execution progress information 0' (an example of writing progress information) as shown in Figure 5b. This transaction execution progress information 0' includes information about the most recently successfully executed transaction by the main engine (here, transaction 3). Then, 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.

[0543] 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.

[0544] 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.

[0545] As described above, in the related technologies, referring to Figures 1b and 1c, during the process of synchronizing data from the master site to the slave site, in the scenario where the slave site fails, there is a certain time delay between the failure of the slave site and the master engine detecting the failure. The master engine can only return the response result of the data access request to the client after detecting the failure. Therefore, when a 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.

[0546] 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 allows 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, such as a database system located in the same region as the client (e.g., region 1 as shown in Figure 3). Thus, even if the database system in other regions (e.g., any one of region 2 or region 3 as shown in Figure 3) that processes the first data access request 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. This reduces the response latency to the first data access request in fault scenarios, enabling the client to receive the response result promptly and reducing client 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.

[0547] For example, referring to Figure 5b, if client cluster 800 issues 1000 transactions, the main engine processes a batch of transactions (e.g., 100 transactions) at a time. During the processing of each batch of transactions, the main engine first returns a response indicating that its write was successful to client cluster 800, without waiting for slave engines 2 and 3 to complete data backup before returning a response. 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 sites) will not cause service interruptions in client cluster 800.

[0548] Referring to any one of Figures 3 to 4c and Figures 5a to 5b, and specifically to Figure 4d, which is a flowchart illustrating another data access method provided by an embodiment of this application, the application scenarios of this data access method can be found in the description of the application scenarios in the embodiment of Figure 4a. The following describes the methods of various embodiments of this application using the method of this application applied to the aforementioned cloud management platform as an example. This method can also be applied to the aforementioned cloud service system.

[0549] As shown in Figure 4d, the data access method may include, but is not limited to, steps S401, S801 and S403 as shown in Figure 4d.

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

[0551] For a description of step S401, please refer to the relevant introduction of this step in the embodiment of Figure 4a above, and it will not be repeated here.

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

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

[0554] 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.

[0555] 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.

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

[0557] 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.

[0558] 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.

[0559] 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.

[0560] 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.

[0561] 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.

[0562] 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).

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

[0564] 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.

[0565] 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.

[0566] 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.

[0567] 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.

[0568] As an example, as shown in Figure 3, 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.

[0569] 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.

[0570] 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.

[0571] 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.

[0572] Continuing with Figure 3 as an example, this second information can be pre-configured in a computing node (e.g., computing node 11) or a storage node (e.g., storage node 12) within region 1, or a computing instance (e.g., computing instance 1) within a computing 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.

[0573] 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.

[0574] 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.

[0575] In the embodiment shown in Figure 4c, step S801 is executed after step S401. In other embodiments, S401 may be executed in parallel 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.

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

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

[0578] The similarities between step S403 and step S403 in the embodiment shown in Figure 4a will not be repeated here; only the differences will be explained below:

[0579] 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).

[0580] 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.

[0581] Referring to the embodiment in Figure 4a above, for example, if the second information indicates that the minimum number of regions for writing 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.

[0582] 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.

[0583] 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.

[0584] 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.

[0585] Continuing with Figure 3 as an example, let's say the client issuing the first data access request is client 102 in region 1, and the responding node 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. Compute node 11 can then send the aforementioned 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, based on these three write progress information (specifically, for example, the first write progress and N second write progresses), outputs a first response result to client 102.

[0586] 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.

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

[0588] The specific implementation of the above process will be explained below with reference to Figure 5b.

[0589] For example, as shown in Figure 5b, the main engine (an example of a computing instance in the first database system) processes a batch of transactions, numbered 1 through 100. For instance, the first data access request currently being processed by the main engine is transaction 3 out of transactions 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.

[0590] 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).

[0591] 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.

[0592] 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.

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

[0594] 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.

[0595] 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.

[0596] Referring to any one of Figures 3 to 4d and Figures 5a to 5b, and specifically to Figure 4e, which is a flowchart illustrating another data access method provided by an embodiment of this application, the application scenarios of this data access method can be found in the description of the application scenarios in the embodiment of Figure 4a. The following describes the methods of various embodiments of this application using the method of this application applied to the aforementioned cloud management platform as an example. This method can also be applied to the aforementioned cloud service system.

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

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

[0599] For a description of step S401, please refer to the relevant introduction of this step in the embodiment of Figure 4a above, and it will not be repeated here.

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

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

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

[0603] In the embodiment shown in Figure 4e, step S901 is executed after step S401. In other embodiments, S401 may be executed in parallel 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.

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

[0605] 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.

[0606] The similarities between step S403 and step S403 in the embodiment of Figure 4a and step S504 in the embodiment of Figure 4b will not be repeated here. Only the differences will be explained below:

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

[0608] 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.

[0609] 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.

[0610] 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.

[0611] 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.

[0612] The following section, using Figure 5b, illustrates the process by which the cloud management platform outputs the fifth response result based on this response time and high availability:

[0613] For example, as shown in Figure 5b, the main engine (an example of a computing instance in the first database system) processes a batch of transactions, numbered 1 through 100. For instance, the first data access request currently being processed by the main engine is transaction 3 out of transactions 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.

[0614] 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.

[0615] 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.

[0616] 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.

[0617] Referring to the relevant descriptions in the embodiments of Figures 4c and 4d above, 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.

[0618] 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.

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

[0620] 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.

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

[0622] 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.

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

[0624] 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.

[0625] 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.

[0626] The method of this application embodiment will be illustrated below with reference to Figure 3 and specific examples.

[0627] Referring to Figure 3, in Region 1, Region 2, and Region 3, each region includes a storage instance capable of providing 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-regional data access.

[0628] 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.

[0629] In the embodiment shown in Figure 3, 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.

[0630] 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.

[0631] 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.

[0632] 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.

[0633] 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.

[0634] 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.

[0635] 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.

[0636] Subsequently, the cloud management platform of this application embodiment can receive a data access request from an application (an example of a client). The data access request may include at least one of the first information and the second information to perform data access and output a response result in accordance with the implementation process of the method described in the embodiments of FIG4c, FIG4d, or FIG4e. The specific process will not be described in detail here.

[0637] 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.

[0638] Referring to any one of Figures 3 to 4e and Figures 5a to 5b, and specifically to Figure 4f, which is a flowchart illustrating another data access method provided by an embodiment of this application, the application scenarios of this data access method can be found in the description of the application scenarios in the embodiment of Figure 4a. The following describes the methods of various embodiments of this application using the method of this application applied to the aforementioned cloud management platform as an example. This method can also be applied to the aforementioned cloud service system.

[0639] As shown in Figure 4f, the data access method may include, but is not limited to, steps S505 and S506 shown in Figure 4f. Furthermore, before step S505, the data access method may also include step S503 in the embodiment of Figure 4b.

[0640] Based on step S4012 in the embodiment of Figure 4a, the cloud management platform can receive the first write progress information of the first region. Based on steps S501 to S503 in the embodiment of Figure 4b, the cloud management platform can receive the third write progress information of the second region. For details, please refer to the embodiments of Figure 4a and Figure 4b above, and will not be repeated here.

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

[0642] In this embodiment, during or after the cloud management platform responds to a first data access request, at least one second database system in a second region among the multiple regions may fail, 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 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.

[0643] 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.

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

[0645] 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.

[0646] 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.

[0647] 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.

[0648] 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.

[0649] 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.

[0650] 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.

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

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

[0653] 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.

[0654] 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.

[0655] The following explanation uses the first database system (e.g., the main engine and main database shown in Figure 5c) as the execution entity in the first region as an example, and refers to Figure 5c to illustrate the above process. The database system in the second region is the second database system, such as the slave engine 2 and slave database 2 as shown in Figure 5c. The first region is located at the first site, and the second region is located at the second site.

[0656] As shown in Figure 5c, 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) successfully executes transactions 1 to 1000 sequentially, resulting in the transaction number 1000 in the main engine's transaction execution progress information, as indicated by the circle. Following the methods described in the above embodiments and based on the execution order of multiple transactions, the main engine 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 indicated by the circle within the dashed box, representing the transaction number of its most recently successfully executed transaction.

[0657] The writing process of the first data corresponding to each transaction in transactions 1 to 900 can be referred to the relevant descriptions of the embodiments in Figures 4a and 5a, which will not be repeated here.

[0658] 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:

[0659] 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.

[0660] 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.

[0661] 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.

[0662] 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.

[0663] 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.

[0664] Specifically, as shown in Figure 5c, as 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) from the main engine to the master database. The master database can find the first data stored in the master database that corresponds to transaction numbers 901 to 1000 respectively, based on transaction number 900 and transaction number 1000.

[0665] 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).

[0666] 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.

[0667] Then, as shown in steps 3.1 and 3.2 of Figure 5c, 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).

[0668] In particular, step 3.1 in Figure 5c is the same as step 5.1 in Figure 5a above, and step 3.2 is the same as step 5.2 in Figure 5a above.

[0669] 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.

[0670] After step 4, as shown in step 5 of Figure 5c, 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.

[0671] 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.

[0672] 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.

[0673] For example, in the incremental recovery scenario shown in Figure 5c, engine 2 can send transaction execution progress information to the first site every time it writes the first data of the five transactions synchronized from the first site. For instance, after slave database 2 writes the first data corresponding to transactions 901 to 905 through step 2 as shown in Figure 5c, and after slave engine 2 stores the database operations corresponding to transactions 901 to 905 through step 3.1, it indicates that the second server of the second site has synchronized the target descriptions corresponding to transactions 901 to 905. Then, slave engine 2 can send the transaction execution progress information 1' (specifically carrying the transaction number 905) to the main engine through steps 4 and 5, or through the dashed arrow. In this way, the main engine can update the transaction number in the saved transaction execution progress information of slave engine 2 from 900 to 905. In this manner, the first station continuously synchronizes the first data of subsequent transactions to the second station 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 slave engine 2, so that the transaction number in the transaction execution progress information stored by slave engine 2 on the master engine side is updated to 1000.

[0674] 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 of the second site (e.g., client 103 as shown in Figure 5c), 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.

[0675] 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.

[0676] 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.

[0677] 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, the client in the second region needs to issue a data access request. The client can then 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 relevant descriptions in the embodiments corresponding to Figure 4b above. Thus, during the fault recovery process of the database system in the client's region, the client in that region can also determine which region's database system the current data access request should be routed to based on the previous response results to achieve reliable data access and ensure high data availability.

[0678] In the embodiment of Figure 5c above, the example is taken as follows: 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.

[0679] In other embodiments, during the synchronous data writing process from the first station to the second station according to the process shown in Figure 5a or Figure 4a, a failure occurs at the second station or a link failure occurs between the first and second stations, resulting in data synchronization interruption. For example, the above-mentioned failure occurs after the slave database 2 writes the first data corresponding to transaction 900, causing the slave database 2 to not yet send the database operation corresponding to transaction 900 to the slave engine 2 through simulated database operation. Thus, the latest database operation corresponding to the transaction saved by the slave engine 2 is the database operation corresponding to transaction 899. After the above-mentioned failure is repaired, the slave engine 2 and the slave database 2 in the second station restart. As shown in Figure 5c, after the slave database 2 restarts, it can obtain the corresponding database operation based on the saved first data corresponding to transaction 900 and send the database operation corresponding to transaction 900 to the slave engine 2, so that the slave engine 2 also saves the database operation of transaction 900 and sends the transaction execution progress information of the slave engine 2 (specifically, the transaction number is 900) to the first station to update the transaction number in the transaction execution progress information of the slave engine 2 on the main engine side from 899 to 900. During the incremental recovery process from the first site to the second site, the master database does not need to synchronize the first data of transaction 900 already stored in the slave database 2, so as to reduce the duplicate writing of data. Other processes are the same as the description of Figure 5c in the above embodiment, and will not be repeated here.

[0680] In related technologies, a failure occurs because the master database cannot know which request the slave database has executed, resulting in the incomplete synchronization of subsequent persistent data. In order to ensure high availability of data, it is necessary to keep the data stored in the database system between the master site and the slave site consistent. When the master site restores the data of the slave site, it can clear the data in the slave database of the slave site and synchronize all the data stored in the master database of the master site to the slave database of the slave site. This results in a huge amount of data to be synchronized, which makes the data recovery time after the slave site failure long and the data recovery efficiency low.

[0681] In the data access method provided in this application embodiment, after the database system in the second region recovers from the failure, the first database system can determine the missing data copy (third data) in the second region compared t...

Claims

A data access method, characterized in that, The method is applied to a cloud service system, the cloud service system comprises a cloud management platform and a plurality of database systems, the plurality of database systems comprise a first database system and a second database system, the cloud management platform is used for managing infrastructure providing cloud services, the infrastructure is deployed with 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, and the method comprises the following steps: The first database system receives a first data write request, the first data write request is used for indicating first data to be written; The first database system writes the first data based on the first data write request, and obtains first write progress information of the first region, the first write progress information is used for indicating the write 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 second write progress information of the second region, the second write progress information is used for indicating the write progress of the first data in the second region; The first database system outputs a first response result for the first data write request, the first response result comprises the first write progress information of the first region and the second write progress information of the second region. The method of claim 1, wherein The method further comprises: The first database system obtains first information, the first information is used for indicating the response time length of the first data write request; The first database system outputs a second response result for the first data write request within the response time length from the time of receiving the first data write request, the second response result comprises the first write progress information, and the first write progress information comprises information indicating that the first region has supported access to the first data. The method according to claim 1 or 2, characterized in that Before the first database system outputs the first response result for the first data write request, the method further comprises: 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 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 for indicating second data to be written; The first database system sends the second data to the second database system; The first database system obtains third write progress information of the second region, the third write progress information is used for indicating the write progress of the second data corresponding to the second data write request of the last response in the second region; The first database system outputs a third response result for the first data write request, the third response result comprises the first write progress information and the third write progress information. The method according to claim 3, characterized in that The method further comprises: The first database system obtains 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 being used to indicate a time required for data stored in the second region to be synchronized to data stored in the first region. The first database system outputs a fourth response result for the first data write request, the fourth response result including the synchronization delay information of the second region. The method according to claim 4, characterized in that The method further includes: The first database system determines third data of the first region to be synchronized 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. The method according to any one of claims 1 to 5, characterized in that The first database system includes a first storage device on the first region where the first database system is located, and the second database system includes a second storage device on the second region where the second database system is located, 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. 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. A cloud service system, the cloud service system including a cloud management platform and a plurality of database systems, the plurality of 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 included in the first database system and one or more database instances included in 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 first data to be written; The first database system is further used to write the first data based on the first data write request and to obtain first write progress information of the first region, the first write progress information being used to indicate a write progress of the first data by the first region; The first database system is further used to send the first data to the second database system; The first database system is further used to obtain second write progress information of a second region, the second write progress information being used to indicate a write progress of the first data by the second region; The first database system is further used to send the first data to the second database system; The first database system is further configured to output a first response result for the first data write request, the first response result comprising first write progress information of the first region and second write progress information of the second region. The cloud service system of claim 8, wherein The first database system is further configured to obtain first information, the first information being used to indicate a response time length of the first data write request; The first database system is further configured to output a second response result for the first data write request within the response time length, starting from a time when the first data write request is received, the second response result comprising the first write progress information, the first write progress information comprising information indicating that the first region has supported access to the first data. The cloud service system of claim 8 or 9, wherein The first database system is further configured to receive a second data write request, the second data write request and the first data write request being same batch data write requests processed by the first database system, a response order of the second data write request being before a response order of the first data write request, the second data write request being used to indicate 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, the third write progress information being used to indicate a write progress of the second data corresponding to the second data write request of the latest response by the second region; The first database system is further configured to output a third response result for the first data write request, the third response result comprising the first write progress information and the third write progress information. The cloud service system of claim 10, wherein The first database system is further configured to obtain synchronization time 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 time delay information being used to indicate a time required for data stored by the second region to synchronize with data stored by the first region; The first database system is further configured to output a fourth response result for the first data write request, the fourth response result comprising the synchronization time delay information of the second region. The cloud service system of claim 11, wherein The first database system is further configured to determine 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. The cloud service system according to any one of claims 8 to 12, characterized in that The first database system comprises a first storage device on the first region where the first database system is located, and the second database system comprises a second storage device on the second region where the second database system is located, The first database system is specifically configured to write the first data to the first storage device based on the first data write request; The first storage device is configured to send the first data to the second storage device. The cloud service system according to any one of claims 8-13, characterized in that, The cloud management platform is further configured to receive the first data write request; The cloud management platform is further configured to send the first data write request to the first database system; The cloud management platform is further configured to receive the first response result output by the first database system; The cloud management platform is further configured to output the first response result. A cluster of computing devices, characterized in that, at least one computing device, each computing device comprising a processor and a 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, so that the computing device cluster executes the method according to any one of claims 1-7. A computer program product comprising instructions, characterized in that The instructions, when executed by the computing device cluster, cause the computing device cluster to execute the method according to any one of claims 1-7. A computer-readable storage medium, characterized by computer program instructions, which, when executed by a computing device cluster, cause the computing device cluster to execute the method according to any one of claims 1-7.

Images