Method, device and medium for data synchronization between cloud database nodes

Abstract

Methods, processing units, and computer readable media in a cloud database are described. Redo log records are applied to pages on a database replica only when an updated version of the page is requested from the database replica. A database replica node can track the most recent redo log record applicable to a given page through a log cache. When an updated version of the page is requested, the most recent redo log record stored in the log cache can be applied to update the page on demand. By applying only redo log records applicable to the page of the current request, processing resources are only available to generate the page currently needed. Methods of registering redo log records to a log cache by a primary or replica server are also described.

Description

[0001] Related applications cross-application

[0002] This invention claims priority to U.S. Non-Provisional Application No. 17 / 107,588, filed November 30, 2020, entitled “METHOD, APPARATUS AND MEDIUM FOR DATA SYNCHRONIZATION BETWEEN CLOUDDATABASE NODES”, the contents of which are incorporated herein by reference. Technical Field

[0003] This invention relates to distributed database management, and more particularly to a method, apparatus, and processor-readable medium for data synchronization between cloud database nodes. Background Technology

[0004] Cloud computing is a network-based form of computing (e.g., internet-based computing) that allows access to a shared pool of configurable computing resources and higher-level services that can be rapidly provisioned over the internet with minimal management effort. Cloud computing represents another shift in behavior following the move from mainframe-based computing to client-server-based computing, and is implemented as a service. Cloud service providers typically offer three main types of services (hereinafter referred to as cloud computing services) by creating virtual machines on demand for customer use: Infrastructure as a Service (IaaS), Platform as a Service (PaaS), and Software as a Service (SaaS). IaaS provides computing infrastructure that customers can rent and use. Computing infrastructure includes virtualized physical computing resources (e.g., processors, memory, storage, servers, network components, etc.) shared among customers. PaaS provides a platform that allows customers to develop, run, and manage software applications without building and maintaining computing infrastructure. SaaS provides software applications running on computing infrastructure on demand via the internet on a subscription basis.

[0005] Typically, one type of cloud service offered by a cloud computing service provider is a database service. A database service is a PaaS (Platform as a Service) that enables cloud service providers to offer secure and cost-effective enterprise-grade databases to their customers. In a database service, the database can be modified (e.g., by writing data) by multiple different entities (e.g., different master servers). To track changes made to the database, information describing these changes is typically stored in a redo log. Therefore, the redo log contains information describing the history of all changes made to the database content and can be used (e.g., in the event of a failure) to reconstruct the database content. Redo log entries are also used to ensure that copies of the database correctly reflect the data contained in the original (or master) database.

[0006] Cloud databases have limitations when using redo logging to update data on database replicas. Each replica needs to support read-only transactions to access database data retrieved from cloud storage. However, each replica typically has a local data cache (also known as a buffer pool) to store data locally to satisfy read requests received from clients. When the database master updates database data, the locally stored data in the replica buffer pool is considered expired or outdated. To enable database replicas to read updated data, data must be coordinated or synchronized between the database master and the database replicas. This data synchronization method should achieve three distinct functions: first, updating the list of transactions executed by the master in the replicas; second, invalidating or discarding data in the replica buffer pool that has expired due to active transactions, so that read requests received by the replicas do not result in access to outdated local versions of the data; and finally, updating index values ​​stored on the replicas that indicate which transactions executed by the database master have been processed or registered by the replicas (e.g., log sequence numbers or LSNs, as described below). Typically, the data synchronization method performed by a replica includes: receiving redo log records from the master server; discarding locally stored data based on the contents of the redo log records; applying the redo log records to the locally stored data to update the locally stored data; and updating the local storage index value, which indicates which redo log records in the transaction sequence have been applied. Read requests received by the replica after local data (e.g., data pages) has been discarded but before it has been updated may cause delays, as the replica is waiting for the local data to be updated or must retrieve the updated data from remote storage.

[0007] When implementing the data synchronization method described above, two performance metrics should be considered. First, data visibility lag between the master server and replicas should be minimized (ideally). Data visibility lag represents the time lag between the master server making changes to database data and committing those changes, and the replica registering those changes to discard the data stored locally. Second, the query throughput of the replicas should be maximized. Replica query throughput reflects the number of read requests that the replica can satisfy within a given time period (e.g., per second). In existing master-replica data synchronization methods, both metrics can be affected when the database master server has a heavy write update workload (i.e., processing and committing a large number of database data updates within a given time period, such as per second): data visibility lag may increase, and query throughput may decrease.

[0008] Data synchronization between the database master server and database replicas generally employs two methods: sequential application of redo log records and proactive parallel application of redo log records. In the sequential application of redo log records method, the replica maintains only a single version of each data page in its buffer pool. Upon receiving a set of redo log records, the replica parses the redo log records to identify all data pages updated within a single mini-transaction (MTR, detailed below). The replica then acquires exclusive locks on all these data pages present in its replica buffer pool. The redo log records in the mini-transaction are applied in parallel to the corresponding locally stored (locked) data pages to generate updated local copies of these data pages. After the local data pages are updated, the replica releases the exclusive locks on these pages. Then, the replica's list of active transactions is updated to indicate which transactions have been processed (i.e., applied to the pages in local storage).

[0009] Applying redo logs sequentially has limitations. Redo logs may contain many MTRs (Mean Transmissions), and these MTRs may have dependencies. Since each page in the replica pool has only one version, replicas must process each MTR sequentially to ensure consistency. This can increase data visibility lag and reduce query throughput due to contention for page locks.

[0010] In the proactive parallel application of redo log records, a replica pool can store multiple versions of a given data page. Each data page in the pool is read-only, meaning that once created, it is never modified. This allows lock-free read access to the data pages. Upon receiving a set of redo log records, the replica parses the redo log records to identify all data pages whose redo log records were updated within any MTR prior to a point in the transaction sequence (e.g., a target index value, such as a target LSN). The replica then identifies all data pages within this set of MTRs. Each such data page in the replica pool is tagged with an updated index value indicating the point in the transaction sequence where the page expires (e.g., an expired LSN). No locking of the data page is required. The redo log records to be applied to a given data page are then applied to the local replica of that data page in the pool to generate an updated version of the page. Note that a local copy of a data page can only be updated via a redo log record if its expired LSN is greater than (e.g., later in the sequence) or equal to the starting LSN of the redo log record. (For example, a local copy of a data page can only be updated via a set of redo log records between LSN=1000 and LSN=2000 if its expired LSN is 1000 or greater.) Typically, a replica only receives records whose LSN range begins with the replica's visible LSN; therefore, a local copy of a data page can only be updated if its expired LSN equals the replica's visible LSN (sometimes denoted as expired LSN=MAX). Redo log records can be applied in parallel across multiple data pages within this set of MTRs. After applying the redo log record, the list of active transactions stored in the replica is updated to indicate which transactions have been processed (i.e., applied to pages in local storage), and the visible index value (e.g., the visible LSN) is updated to the target index value (e.g., the target LSN). When a replica receives a read request that requires reading a data page from the buffer pool, it uses the visible index value to access the correct version of the data page to ensure consistency.

[0011] Unlike sequential redo logging, this proactive parallel approach supports lock-free data page access for both log application (i.e., data page updates) and data page read requests. By implementing parallel redo logging to a certain extent, redo logging application performance can be accelerated. However, this approach still has limitations. First, this approach creates multiple new versions for each data page, resulting in the generation and storage of many unused data pages in the replica buffer pool and in memory. These locally stored replicas consume space in the buffer pool, increasing buffer pressure and thus reducing throughput. Second, applying redo logging consumes processor resources (e.g., CPU cycles) on the database replica server. Processor resources on replicas are limited; when processor resource usage reaches its maximum, such as during periods of high transaction volume on the database master server, the redo logging application process cannot keep up with the rate of updates received from the database master server. Data visibility lag increases over time, and the increasing lag also reduces the query throughput of the replica. Third, in this approach, the input and output load on cloud storage can be very high. Local copies of data pages on the replica can only be updated if the data page exists in the replica buffer pool when redo logging is applied. If a data page is not in the buffer pool and redo logging needs to be applied to the last version of that data page, it must be retrieved from remote cloud storage. This forces the cloud storage system to perform a large number of small data page reads, increasing the input / output pressure on the cloud storage. This can further reduce the query throughput of the replica. Fourth, this approach can lead to high data visibility lag. Updated data pages are only visible to new read requests after all redo logging in that MTR group has been applied, which can increase the data visibility lag for any read requests of data pages affected by redo logging in that MTR group.

[0012] Therefore, there is a need to provide a method for synchronizing data on database replicas by applying redo logging, in order to overcome one or more limitations of the existing methods described above. Summary of the Invention

[0013] This invention describes an example where redo logging is applied to a page on a database replica only when the current version of the page is requested from the database replica. This feature can help reduce the consumption of memory and processing resources.

[0014] In some examples, database replica nodes can use a log cache to keep track of the most recent redo log entries applicable to a given page. When the current version of that page is requested, the most recent redo log entry stored in the log cache can be applied to update the page on demand. By applying only the redo log entry applicable to the currently requested page, processing resources are only used to generate the currently needed page. Processing resources can be primarily used to keep frequently requested pages up-to-date, thereby reducing the latency that could occur if all pages were updated (even if the page was never requested).

[0015] As used in the context of redo logging in this article, the term "application" can refer to the process of modifying or updating a data page in a database using the content of a redo log record. One or more redo log records can be applied to an expired version of a data page to update the content of the data page, thereby reflecting the changes to the database content recorded in the redo log record.

[0016] As used in this article, the term "page" refers to a data page in a database.

[0017] As used herein, the term "database master server" refers to a server or other node in a cloud database that handles modifications to the database, including requests to insert, update, or delete database records. The term "database replica server" refers to a server or other node in a cloud database that handles only read requests, such as requests to select database records. A database replica server may maintain copies of some or all of the database's data pages based on redo log records received from the database master server, as described in the example embodiments herein. In some configurations, the cloud database may be a multi-master database with multiple database master servers; in this case, each additional database master server may implement some of the redo log on-demand application technologies described herein with reference to the database replica server, and therefore may be considered to fall within the definition of "database replica server" of the described embodiments. Database master servers and database replica servers may be collectively referred to as "database servers."

[0018] In some aspects, the present invention describes a method for synchronizing data on a database replica server for a cloud database, the cloud database including data stored in pages. The method includes: the database replica server receiving a request from a client for a desired page of database data; in response to receiving the request for the desired page, retrieving a stored version of the desired page, retrieving one or more redo log records associated with the desired page from a log cache, applying the one or more redo log records to the stored version of the desired page to generate an updated desired page, and sending the updated desired page to the client.

[0019] In some aspects, the present invention describes a processing unit. The processing unit includes a processing device and a memory. The memory stores instructions that, when executed by the processing device, cause the processing unit to perform the functions of a database replica server for a cloud database, the cloud database including data stored in pages. The database replica server is configured to receive a request from a client for a desired page of database data; in response to receiving the request for the desired page, retrieve a stored version of the desired page, retrieve one or more redo log records associated with the desired page from a log cache, apply the one or more redo log records to the stored version of the desired page to generate an updated desired page, and send the updated desired page to the client.

[0020] In some aspects, the present invention describes a computer-readable medium storing instructions executable by a processing device in a cloud database, the cloud database including data stored in pages. When the instructions are executed, a database replica server of the cloud database causes it to perform the following operations: receive a request from a client for a desired page of database data; in response to receiving the request for the desired page, retrieve a stored version of the desired page, retrieve one or more redo log records associated with the desired page, apply the one or more redo log records to the stored version of the desired page to generate an updated desired page, and send the updated desired page to the client.

[0021] In some examples, the cloud database is a multi-master cloud database; the database replica server is the database master server.

[0022] In some examples, the log cache is part of the database replica server.

[0023] In some examples, the log cache is part of the cloud database and is separate from the database replica server.

[0024] In some examples, the database replica server retrieves a stored version of the desired page from its buffer pool.

[0025] In some examples, the database replica server retrieves a stored version of the desired page from the page storage of the cloud database.

[0026] In some examples, before retrieving the one or more redo log records associated with the desired page, the method further includes storing a plurality of redo log records to the log cache. The plurality of redo log records includes at least one of the one or more redo log records associated with the desired page.

[0027] In some examples, the database master server stores the multiple redo log records in the log cache.

[0028] In some examples, the database replica server stores the multiple redo log records to the log cache.

[0029] In some examples, before storing the plurality of redo log records to the log cache, the method further includes: determining that the available memory of the log cache is insufficient to store the plurality of redo log records, and removing one or more redo log records stored in the log cache. In some examples, each of the plurality of redo log records is associated with a page; storing the plurality of redo log records to the log cache includes: associating each of the plurality of redo log records with a lookup table entry corresponding to the page associated with each redo log record and storing it in a lookup table of the log cache; retrieving the one or more redo log records from the log cache includes: retrieving one or more redo log records associated with a lookup table entry corresponding to the desired page.

[0030] In some examples, the storage version of the desired page is associated with a log sequence number; retrieving the one or more redo log records includes retrieving one or more redo log records stored with a log sequence number greater than the storage version of the desired page.

[0031] In some examples, before retrieving the one or more redo log records associated with the desired page, the method further includes: determining that the available memory in the log cache is insufficient to store the plurality of redo log records; removing one or more redo log records stored in the log cache; storing the plurality of redo log records (the plurality of redo log records includes at least one of the one or more redo log records associated with the desired page); and updating the visible log sequence number of the database replica server to the end log sequence number associated with the plurality of redo log records.

[0032] In some examples, the processing unit includes the log cache, and when the instruction is executed by the processing device, the processing unit also causes the processing unit to perform the functions of the log cache.

[0033] In some examples, the log cache includes multiple stored redo log records (each of the multiple stored redo log records is associated with a lookup table entry corresponding to the page and stored in the lookup table of the log cache); retrieving the one or more redo log records from the log cache includes: retrieving one or more stored redo log records associated with the lookup table entry corresponding to the desired page.

[0034] In some examples, when the instruction is executed by the processing device, it also causes the processing unit to perform the function of a buffer pool; the stored version of the desired page is retrieved from the buffer pool.

[0035] In some examples, the storage version of the desired page is associated with a log sequence number; retrieving the one or more redo log records includes retrieving one or more redo log records stored with a log sequence number greater than the storage version of the desired page.

[0036] In some examples, the database replica server is further configured to, before retrieving the one or more redo log records associated with the desired page: determine that the available memory in the log cache is insufficient to store the received redo log records; remove one or more stored redo log records stored in the log cache; store the received redo log records into the log cache, the redo log records including at least one of the one or more redo log records associated with the desired page; and update the visible log sequence number of the database replica server to the end log sequence number associated with the received redo log records. Attached Figure Description

[0037] The following will be illustrated by way of example with reference to the accompanying drawings, which show exemplary embodiments of this application.

[0038] Figure 1 This is a block diagram of a cloud computing architecture for providing cloud computing services according to the example embodiments described herein;

[0039] Figure 2 This is a simplified logical diagram of an example architecture of a cloud database based on the example embodiments described herein;

[0040] Figure 3 This is a block diagram of a simplified example of a processing unit according to the exemplary embodiments described herein;

[0041] Figure 4 This is a flowchart of an example method for processing redo log recording according to the example embodiments described herein, wherein the execution subjects of the method are multiple software entities in a cloud database;

[0042] Figure 5 This is a block diagram illustrating an example of synchronizing data pages stored in a buffer pool of a database replica server with the most recently committed transaction of the database master server via log caching, according to the example embodiments described herein.

[0043] Figure 6A This is a flowchart of a first example method for registering redo log records to a log cache via a database master server, according to an example embodiment described herein;

[0044] Figure 6B This is a flowchart of a second example method for registering redo log records to a log cache via a database replica server associated with the log cache, according to an example embodiment described herein;

[0045] Figure 7 This is a flowchart of an example method for a database replica server to synchronize data by applying redo logging on demand, according to the example embodiments described herein.

[0046] Similar figure numbers can be used in different figures to represent similar components. Detailed Implementation

[0047] This invention describes an example of using an active-active architecture in a cloud computing context. Although some system diagrams and flowcharts are shown and discussed, these are merely examples and are not intended to be limiting.

[0048] Example cloud computing architecture

[0049] Figure 1This is a logical block diagram of a cloud computing architecture that provides cloud computing services. The logical diagram of cloud computing architecture 100 (hereinafter referred to as Cloud 100) typically includes an infrastructure platform 102 (e.g., an infrastructure as a service (IaaS) layer), an application platform 104 (e.g., a platform as a service (PaaS) layer), and an application 106 (e.g., a software as a service (SaaS) layer). The infrastructure platform 102 includes physical hardware resources 108 and a virtualization layer 110 that presents an abstraction of the physical hardware resources 108 to the application platform 104. The abstraction presented by the virtualization layer 110 depends on the requirements of the application 112 hosted on the application platform 104. The physical hardware resources 108 include physical machines or servers 114 and physical storage servers 116. The physical machines or servers 114 include physical processing resources 114 (e.g., central processing units (CPUs), graphics processing units (GPUs), accelerators, and tensor processing units (TPUs)). Physical storage server 116 includes storage resources such as memory (e.g., static random access memory (SRAM), dynamic random access memory (DRAM), synchronous DRAM (SDRAM), read-only memory (ROM), persistent storage devices (e.g., hard disk drives, optical drives, or combinations thereof), and network resources (not shown) typically residing within a data center. As understood in the art, a data center comprises a collection of physical hardware resources 108 (typically in the form of servers) that can be used as a collective computing resource including processing, storage, and networking resources. Within a data center, multiple servers can be connected together to provide a pool of computing resources on which virtualized entities can be instantiated. Data centers can interconnect to form computing resource pools, and computing resources within these pools are interconnected via connectivity resources. Connectivity resources can take the form of physical connections, such as Ethernet or optical communication links.

[0050] Virtualization layer 110 provides a flexible and efficient multi-tenant runtime and hosting environment for application 112 by offering IaaS facilities. Virtualization layer 110 includes a virtualization manager or virtual machine monitor (not shown), which can provide a security and resource "sandbox" for each application 112 hosted by application platform 104. Each "sandbox" can be implemented as a virtual machine (VM) 118, which can include an appropriate operating system and controlled access to virtualized storage resources 120.

[0051] The virtualization of physical hardware resources 108 by the virtualization layer 110 is considered the foundational technology of the cloud 100. Virtualization is a technology that allows the creation of virtual computing resource pools, where computing resources (e.g., processing, storage, and network resources) are interconnected through connectivity resources. Virtualization can take the form of instantiating VMs 118, which are identical to physical computing devices to another entity on the network and the software running on them. VMs 118 have their own set of computing resources (e.g., processing, storage, and connectivity resources) on which an operating system can run. VMs 118 may have virtual network interfaces that can be assigned network addresses. Between the underlying resources and VMs 118, there is typically a virtual machine monitor (not shown) to manage resource isolation and network interaction. One of the roles of VMs 118 is to provide isolation from other processes running on the cloud 100. Initially, the VM 118 mechanism allowed different processes to run without the concern that a single faulty process would cause the entire system to crash. Instead, faulty processes were contained within their own VMs 118. This isolation allows each VM to have its own set of network interfaces. Typically, a single underlying compute resource can support multiple virtualization entities.

[0052] Those skilled in the art will understand that a recent development is the use of containers to replace VMs 118. As mentioned above, each VM 118 typically includes its own operating system, which often increases the use of redundant compute, storage, and connectivity resources. Containers allow a single operating system (OS) kernel to support multiple isolated applications. A single OS replaces the virtual machine monitor-hosted containers that allow each VM 118 to run its own operating system, and these containers are responsible for implementing the resource isolation provided by the VM 118.

[0053] Application platform 104 provides the capability to host application 112, including application platform service 122. Application platform service 122 provides a set of middleware application services and infrastructure services to application 112 hosted on application platform 104. Application 112 hosted on application platform 104 can run on a VM or a physical machine. Figure 1As shown, application platform service 122 includes a caching service 124 for in-memory data storage, a database service 126 for applications, a messaging service 128 for publishing messages to subscribing clients, and an API gateway service 130 that enables clients to create, publish, and maintain application programming interfaces (APIs) to access other cloud services. Those skilled in the art will understand that application platform service 112 can provide clients with other middleware application services, such as notification services, runtime services, etc. Client applications 112 can be deployed and executed within the corresponding VM 118 or physical machine 114.

[0054] Database service 126 can be implemented through a cloud (or cloud-native) database architecture, which will be discussed further below. Some terms used in this invention are introduced below.

[0055] In this invention, a database refers to an organized collection of data, typically stored and accessed electronically via a computer system.

[0056] A Database Management System (DBMS) is a "software system" that enables users (such as database administrators) to define, create, and maintain databases and control access to them. A DBMS is the "software" that interacts with end users (such as client users), applications, and the database to capture and analyze data. The abbreviation DBMS is sometimes extended to indicate the underlying database model, such as RDBMS for relational database model, OODBMS or ORDBMS for object-oriented database model, and ORDBMS for object-relational database model. Other extensions can indicate other features, such as DDBMS for distributed database management system. The core functions provided by a DBMS are data storage, retrieval, and updating. Mature, general-purpose DBMSs typically provide the following functions:

[0057] Data storage, retrieval, and updating

[0058] • A user-accessible directory or data dictionary describing metadata

[0059] • Supports transactions and concurrency

[0060] Facilities for recovering the database when it is corrupted

[0061] • Authorization to support data access and updates

[0062] Supports remote access

[0063] • Enforce constraints to ensure that data in the database conforms to certain rules

[0064] A database engine (or storage engine) is the underlying software component of a DBMS used to create, read, update, and delete (CRUD) data from a database. External interaction with the database is achieved through applications that connect to the DBMS.

[0065] A database transaction (also simply called a transaction) is a unit of work executed in a DBMS.

[0066] A database page (or simply page) is the basic internal structure that organizes data within a database file. A database page is a unit of storage whose size can be configured on a system-wide, database-wide, or group-specific basis. Pages can be identified by identifiers, such as page identifiers and space identifiers.

[0067] A redo log is a file that records the history of all changes made to a database. Redo logs (or more generally, database logs) can be stored as files. Each redo log contains one or more redo log records (or more generally, database log records). A redo log record, also called a redo entry or log entry, stores a set of change vectors, each describing or representing a change made to a single block or page in the database. The term "redo log" can originate from a specific DBMS model, but it can also be used in a more general way to refer to the database log. MySQL TM This is an example database model that uses the term "redo log"; MySQL TM This is an example database model that can be used to implement the examples described herein. It should be understood that the invention can be equally applied to other database models. A database model is a data model that defines the logical structure of a database and determines how data can be stored, organized, and manipulated. An example of a database model is the relational model, which uses a table-based format to store, organize, and manipulate data.

[0068] Redo log entries may include more information, such as a page identifier that identifies the page to which the redo log entry applies. In some embodiments, the page identifier may include a page identifier (ID) and a space ID. Redo log entries may also include a sequence number, such as a log sequence number (LSN), indicating the position of the redo log entry in the redo log. Typically, LSNs are assigned to redo log entries in the order they are entered in the GFB. Redo log entries in the GFB are typically sorted in ascending LSN order. Log entries may be parsed or processed to determine which log entries will apply to which page (e.g., based on page ID). In some embodiments, log entries may be parsed until the end of a predefined boundary (e.g., the GFB boundary described below) is reached.

[0069] Cloud-native databases (referred to as cloud databases in this article) are database services that can be built, deployed, and delivered in the cloud. As a PaaS, cloud databases provide a database that allows organizations, end users, and their respective applications to store, manage, and retrieve data in the cloud.

[0070] Example cloud database architecture

[0071] Figure 2 This is a simplified logical block diagram of the architecture of Cloud Database 200, in which the computing layer 210 and the storage layer 230 are separated. Figure 2 The cloud database 200 introduces an additional layer (i.e., a storage abstraction layer (SAL) 220) to separate the compute layer 210 and the storage layer 230. SAL 220 provides an abstraction layer where physical resources (e.g., physical storage resources and physical processing resources) provided by the IaaS layer 102 can be pooled to serve the compute layer 210 and the storage layer 230. Separating the compute layer 210 and the storage layer 230 from the abstracted physical resources (and pooling physical resources) enables better scalability and load balancing. For example, the compute layer includes a cluster of servers (e.g., primary servers and replica servers), and the storage layer includes a cluster of storage servers.

[0072] The compute layer 210 includes a database master server 212 (also referred to as master server 212) and one or more database replica servers 214 (also referred to as replicas 214). Database master server 212 and database replica servers 214 can be collectively referred to as database servers 212 and 214. In some examples, database servers 212 and 214 may also be referred to as nodes in the cloud database 200. For example, there may be a single database master server 212 and one or more database replica servers 214. Typically, database master server 212 handles all modifications to the database (including requests to insert, update, or delete database records), while database replica servers 214 only handle read requests (i.e., requests to select database records). Database transactions are handled by database servers 212 and 214 in the compute layer 210, including multiple statements such as insert, update, delete, and select (i.e., read requests). It should be noted that database servers 212 and 214 may not be physical hardware servers, but rather software running on physical processing resources in the cloud (i.e., in the IaaS layer 102). Database servers 212 or 214 can be software running on virtual machines 118 or containers provided in the IaaS layer 102 of the cloud (also referred to as instances of database servers 212 or 214). Typically, since any instance is implemented on a physical machine, instances of database servers 212 and 214 can be considered to have physicality. For simplicity, instances of database servers 212 and 214 are simply referred to as database servers 212 and 214 in this invention.

[0073] Each database server 212 or 214 communicates with SAL 220 through its respective primary storage abstraction layer (SAL) module 222 or replica SAL module 223. (See reference...) Figure 1SAL 220 can be considered as an abstraction layer that spans database service 126 and virtualized storage resource 120, pooling physical resources to serve database service 126 and virtualized storage resource 120. It should be noted that SAL 220 is not a typical layer of traditional database services (e.g., database services provided by traditional cloud service providers). The cloud database 200 described herein includes SAL 220, which can be used to implement functionality superior to traditional database services (discussed further below). Each SAL module 222 or 223 can be a software instance implemented in SAL 220. For simplicity, instances of SAL modules 222 or 223 may be simply referred to as SAL modules 222 or 223 herein. SAL modules 222 or 223 provide the functionality of logical SAL 220. In some examples, one or more functions of SAL modules 222 or 223 may be implemented in storage layer 230. SAL 220 is used to isolate the client-facing front end (provided by the computing layer 210) from the way the database is organized and managed.

[0074] Data (including redo logs and pages of the database, as described below) is stored in storage tier 230. In this example, storage tier 230 is accessible via a network, such as a remote direct memory access (RDMA) network. For example, storage tier 230 could be a distributed storage system provided by virtualization tier 120 in IaaS 102, offering fast, reliable, and scalable storage. Storage tier 230 includes one or more page stores 232 storing pages containing data and one or more log stores 234 storing one or more redo logs. Page stores 232 serve read requests (i.e., requests to read data from one or more pages) received from database servers 212 or 214. Page stores 232 can recreate any version of the pages that database servers 212 or 214 may request. In cloud database 200, page stores 232 are operated by a storage resource cluster (not shown). Each page store 232 receives all redo log records generated for the pages it is responsible for and merges (or applies via conflict resolution, if applicable) the redo log records into the database pages.

[0075] While the above description is in the context of a single database, it should be understood that in some examples, a cloud database 200 can be used to manage two or more databases (e.g., logically separating the databases). Each database is divided into small, fixed-size subsets of pages, which can be called slices. Each page store 232 manages multiple corresponding slices. A slice managed by a single page store 232 can include slices of pages from different databases. The page store server only receives redo log records for pages belonging to the slices managed by that page store server. Typically, a database can have multiple slices, and each slice can be replicated to multiple page stores 232 to ensure durability and availability (e.g., if a page store 232 becomes unavailable, another page store 232 to which the slice is replicated can be used to continue serving requests to access (i.e., read) or modify (i.e., write) data stored in that slice).

[0076] The operations performed by the primary SAL module 222 include sending redo log record updates from the primary database server 212 to the replica database server 214 (arrow 202); sending information about the physical location of the redo logs (i.e., identifying the log store 234) so ​​that the replica database server 214 knows where to access (i.e. read) the latest redo log record (also arrow 202); accessing (i.e. reading) pages from the page store 232 (arrow 204); and writing redo log records to the log store 234 (arrow 205) and the page store 232 (arrow 206). The operations performed by the replica SAL module 223 include receiving redo log record updates from the primary database server 212 (arrow 202); and receiving redo log record updates from the log store 234 (arrow 208). SAL 220 is also responsible for creating, managing, and destroying slices in the page store 232 and allocating pages to slices. In some examples, each SAL module 222 or 223 may be linked to database server 212 or 214; in other examples, each SAL module 222 or 223 may be implemented by another component in cloud database 200 (e.g., by another server not linked to database server 212 or 214, such as a storage server). Each database server 212 or 214 may be served by its respective SAL module 222 or 223 (as shown in the figure). In some examples, a single instance of a SAL module serving the functionality of both the primary SAL module 22 and the replica SAL module 223 may serve two or more database servers 212 and 214. In some examples, a single instance of such a SAL module may serve all database servers 212 and 214 in cloud database 200. In some examples, SAL 220 may be implemented using separate SAL modules 222 and 223 that may run on VM 118, in a container, or on physical server 114.

[0077] Example processing unit

[0078] Figure 3 This is a simplified example block diagram of processing unit 300, which can be used to implement physical machine or server 114 or physical storage server 116. Alternatively, processing unit 300 may be an example of virtual machine 118 provided by virtualization layer 110 of IaaS 102. Other examples suitable for implementing the embodiments described herein may be used, which may include components different from those described below. Although Figure 3 A single instance of each component is shown, but each component in the processing unit 300 can have multiple instances.

[0079] The processing unit 300 may include one or more processing devices 302, such as a processor, microprocessor, digital signal processor, application-specific integrated circuit (ASIC), field-programmable gate array (FPGA), dedicated logic circuit, dedicated artificial intelligence processing unit, or a combination thereof. The processing unit 300 may also include one or more optional input / output (I / O) interfaces 304, which may support connection to one or more optional input devices 306 and / or optional output devices 308.

[0080] In the example shown, input device 306 (e.g., keyboard, mouse, microphone, touchscreen, and / or keypad) and output device 308 (e.g., display, speaker, and / or printer) are shown as optional and external to processing unit 300. In other examples, no input device 306 and output device 308 may be present, in which case I / O interface 304 may not be required.

[0081] The processing unit 300 may include one or more network interfaces 310 for wired or wireless communication with entities in the cloud database architecture. The network interface 310 may include wired links (e.g., Ethernet cables) and / or wireless links (e.g., one or more antennas) for communication between different layers 210, 220, and 230 in the cloud database architecture 200.

[0082] The processing unit 300 may also include one or more storage units 312, which may include mass storage units such as solid-state drives, hard disk drives, disk drives and / or optical disk drives.

[0083] Processing unit 300 may include one or more memories 314, which may include volatile or non-volatile memories (e.g., flash memory, random access memory (RAM), and / or read-only memory (ROM). One or more non-transient memories 314 may store instructions executed by one or more processing devices 302, for example, to perform the examples described in this invention. For example, when processing unit 300 is used to implement SAL module 222 or 223, one or more memories 314 may store instructions for performing the functions of SAL module 222 or 223 and managing redo log recording, as discussed further below.

[0084] One or more memories 314 may include other software instructions, such as software instructions for implementing an operating system and other applications / functions. In some examples, the processing unit 300 may additionally or alternatively execute instructions from external memory (e.g., an external driver connected to the processing unit 300 via wired or wireless communication), or the executable instructions may be provided by transient or non-transient computer-readable media. Examples of non-transient computer-readable media include RAM, ROM, erasable programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), flash memory, CD-ROM, or other portable storage devices.

[0085] The processing unit 300 may also include a bus 316 that provides communication between components of the processing unit 300, including the components described above. The bus 316 may be any suitable bus architecture, such as a memory bus, peripheral bus, or video bus.

[0086] Continue to refer to Figure 2Whenever a cloud service provider creates or expands a database, the primary SAL module 222 selects the page store 232 associated with that database (or, if the database is newly created, selects any suitable page store 232) and creates slices on the selected page store 232. The database master server 212 maintains redo log records in the group flush buffer (GFB). Redo log records of any database transactions submitted by cloud database clients to the compute layer 210 can be stored in the GFB. Redo log records stored in the GFB can be flushed to the primary SAL module 222 for updating in the log store 234. The process of transferring redo log records from the buffer and clearing the buffer can be called "flushing" the buffer. The primary SAL module 222 adds log records to the currently active log store 234 to help ensure the persistence of the redo log records. After the primary SAL module 222 successfully adds all transferred redo log records to all log stores 234, the successful storage of the redo log records can be confirmed by the primary SAL module 222 to the database master server 212. In some embodiments, redo log records can be parsed and then distributed to the slice log buffer (SLB) in the main SAL module 222 before, during, or after the main SAL module 222 adds redo log records to the log store 234. Each SLB corresponds to a set of one or more slices (e.g., an SLB may correspond to a slice stored in a single log store 234) and only stores log records (or a portion of log records) related to the pages stored in its corresponding slice set. Each SLB can be refreshed when it is full and / or at predefined time intervals (e.g., when a timeout counter expires).

[0087] Example methods for handling redo logging

[0088] Figure 4 An example method 400 for processing redo log records is shown, in which the execution body is multiple software entities in cloud database 200 (e.g., instances of database master server 212, master SAL module 222, and page store 232, as described below). It should be understood that method 400 provides a simplified overview and is merely an example.

[0089] Step 402: Database master server 212 generates redo log records and adds (i.e., writes) them to the GFB. Database master server 212 (via master SAL module 222) refreshes (or transfers) the redo log records stored in the GFB to SAL 220. For example, the GFB can be refreshed when a certain buffer size is reached (e.g., the GFB is full) and / or at certain time intervals. The GFB contains a set of committed redo log records from database master server 212 (i.e., redo log records that record database transactions committed by the cloud database 200's clients).

[0090] Step 404: The primary SAL module 222 receives redo log records from the GFB, parses the redo log records, and copies them to the SLB corresponding to the appropriate slice. For example, the primary SAL module 222 parses the redo log records to identify which database page is affected by a given redo log record, thereby determining which slice is the appropriate slice to which the given redo log record should be applied. Then, the primary SAL module 222 copies the given redo log record to the SLB corresponding to the appropriate slice.

[0091] Step 406: Page store 232 receives redo log records from the appropriate SLB, parses the redo log records, and updates the data stored in the corresponding database page using the redo log records. For example, the page store parses the redo log records applicable to a given page. All data updates indicated by the redo log records applied to the given page are applied so that the given page correctly reflects the modifications indicated by the redo log records.

[0092] Redo log entries can take the form of multiple mini-transactions (MTRs). MTR is a database term used to describe the smallest, indivisible group of redo log entries that should not be separated to maintain database consistency. Database consistency refers to the fact that replicated data (including replicated data in replica page storage 232 and replicated redo log entries in replica log storage 234) correctly reflects committed database transactions in compute layer 210. The term MTR is commonly used in MySQL. TMIn the context of [previous context], however, in this invention, the term MTR is generally used to refer to the smallest, indivisible atomic unit of redo log records, and is not limited to any particular database implementation. In this invention, "atomic unit" refers to a group of redo log records that should be applied together to correctly reflect the data stored in the database (e.g., database operations performed by replica page store 232 and replica log store 234 to correctly replicate database master server 212). MTR is an example of an "atomic unit." Thus, for example, a B+ tree includes a root page node and its leaf page nodes. When performing a tree split or merge, the B+ tree data structure may need to update several B+ tree page nodes simultaneously. All these page updates are included in multiple redo log records, which, because the redo log records need to be applied atomically (i.e., as an indivisible group), should be grouped into an MTR. A group of redo log records within a single MTR can be defined by MTR boundaries. Therefore, MTR boundaries can be implicit information defining which log records should be processed together. Database engines can implement algorithms to determine the start and end of an MTR. For example, MySQL TM InnoDB TM The engine generates an MTR end redo record to identify the MTR boundary; the MTR end redo record indicates that the next record is the first record of the new MTR. The main SAL module 222 can determine the start and end of the MTR by using this implicit or explicit indicator of the MT boundary when parsing redo log records.

[0093] In traditional database services, redo log records in a GFB (Server-Side Buffer) can be directly flushed to storage. However, in cloud databases (i.e., cloud-native databases), redo log records can be sent to different page storage units (SLBs) based on their slice partitions. A database typically has dozens or even hundreds of slices. Each slice has a corresponding SLB. The content of a given slice's SLB (e.g., redo log records) is flushed to the page storage unit (SLB) corresponding to that slice. For example, the SLB can be flushed when a certain buffer size is reached (e.g., the SLB is full) and / or at certain time intervals.

[0094] Database servers (primary server 212 and replica 214) typically need to access page versions within MTR boundaries to help ensure database consistency during page processing. A GFB can contain multiple MTRs, and redo log records within a single GFB can be defined by GFB boundaries. Therefore, access to redo log records within GFB boundaries should ensure adherence to each MTR boundary. Database primary server 212 always accesses (i.e., reads) the latest version of the page, which is within the GFB boundary. Database replica server 214 lags behind database primary server 212. Page versions accessible to database replica server 214 are made available only when updates to database pages are completed at least based on MTR boundaries. That is, database replica server 214 can only access (i.e., read) the updated page version (i.e., the version of the updated page) after all redo log records within the same MTR boundary have been processed. Adhering to MTR boundaries in this way helps ensure database consistency. However, record processing boundaries can be larger, such as the GFB boundaries of a single GFB or even a group of GFBs.

[0095] Example database replica synchronization method

[0096] As described above, the state of pages stored in the buffer pool of database replica server 214 lags behind the latest transaction committed by database master server 212. The version of a page accessible to database replica server 214 becomes visible (i.e., visible to read requests) only when an update to a database page is completed at least based on the MTR boundary. In existing redo logging methods, as described in the "Background Art" section above, database replica server 214 can only access (i.e. read) the updated version of a page (i.e., the version of the updated page) after all redo log entries within the same MTR boundary have been processed. In some cases, as described above, this can lead to increased data visibility lag and / or reduced query throughput at database replica server 214.

[0097] To address these limitations, the exemplary embodiments described herein can provide redo logging on demand only when a client of database replica server 214 requests a page stored in a buffer pool on database replica server 214. Therefore, a specific page stored on database replica server 214 can be synchronized with the latest transactions committed by database master server 212, while removing the redo logging application step (e.g., sequential or proactively parallel redo logging application as described in the "Background" section above) from the critical path of the ongoing synchronization process, potentially avoiding the problem of data visibility lag increasing over time. Instead of requiring all local pages to be updated upon receiving redo logging, an embodiment is described that updates only the requested page.

[0098] In some embodiments, the log cache in the database replica server 214 can be used to reduce the input / output pressure on cloud storage (e.g., log storage 234 and / or page storage 232). In some embodiments, the log cache can be used to track the latest page updates (e.g., the current LSN) from the database master server 212 and provide a lookup interface to allow the database replica server 214 to obtain redo log records applicable to a specific page key (e.g., applicable to the requested page) and version range.

[0099] Similar to the proactive parallel redo logging application approach described in the "Background Art" section above, the various embodiments described herein may require storing multiple versions of a page in a buffer pool of the database replica server 214. As with existing methods, each page in the buffer pool can be specified as read-only, meaning that once a page is created, it will not be modified. This may enable lock-free read access to the page in response to read requests.

[0100] Figure 5 This is a block diagram illustrating an example of synchronizing data pages stored in the replica buffer pool 1214 of the database replica server 214 with the most recently committed transactions of the database master server 212 via the log cache 1240.

[0101] Database master server 212 includes a main buffer pool 1212 for storing the latest database pages. The database pages in main buffer pool 1212 are represented as a B+ tree structure containing four database pages: page A 1222 (LSN=200), page B 1224 (LSN=120), page C 1226 (LSN=200), and page D 1228 (LSN=200). Page D is newly added to the B+ tree. Pages A, C, and D need to be updated atomically to ensure consistency. Therefore, page A is moved up from LSN 100 to LSN 200, page C is moved up from LSN 120 to LSN 200, and page D is added to LSN 200. Database master server 212 generates redo log records for pages A, C, and D in a single MTR.

[0102] Database replica server 214 includes a replica buffer pool 1214 for storing local versions of data pages. The locally stored pages in replica buffer pool 1214 are represented as a B+ tree structure containing three pages: a local version of page A1232 corresponding to LSN=100, a local version of page B1234 corresponding to LSN=120, and a local version of page C1236 corresponding to LSN=150. It should be understood that the local stored versions of pages A1232 and C1236 are obsolete relative to the latest versions of pages A1222 and C1226 corresponding to LSN=200 in database master server 214.

[0103] Log cache 1240 is used to store redo log records refreshed from primary buffer pool 1212. In some embodiments, log cache 1240 is part of database replica server 214. In other embodiments, it may be implemented elsewhere in cloud database 200, such as within replica SAL 223 or as a separate node. Log cache 1240 is implemented as a logical process separate from database replica server 214 running on a separate physical device, and may be referred to as "detached" from database replica server 214. Log cache 1240 is used to store redo log records, for example via... Figure 2 Arrow 202 in the image is received directly from the database master server 212, or, for example, via... Figure 2 Arrow 208 in the image receives data from log store 234. On database master server 212, the redo log records corresponding to the latest versions of pages A 1222, C 1226, and D 1228 (all at LSN 200) are written to log store 234 (i.e., ...). Figure 2 Following arrow 205, before moving the read view on database replica server 214 and making the modifications visible to client read requests (i.e., increasing the visible LSN of database replica server to 200), database master server 212 or database replica server 214 writes (i.e. registers) the redo log records corresponding to pages A 1222, C 1226, and D 1228 at LSN=200 to log cache 1240. The following is in conjunction with... Figure 6A and Figure 6B A more detailed description of the example method for registering redo logging to log cache 1240.

[0104] Log cache 1240 organizes the contents of received redo log records according to the pages to be updated via redo log records. In some embodiments, lookup table 1242, such as a hash table with page identifiers as keys, is used to organize redo log records by predetermined pages. Thus, lookup table 1242 may contain page A lookup table entry 1244, page B lookup table entry 1246, page C lookup table entry 1248, and page D lookup table entry 1250, as well as lookup table entries for other pages appearing in the redo log records from database master server 212. Log cache 1240 provides an interface that enables database replica server 214 to retrieve a list of redo log records for a single page between a start page version (e.g., start LSN) and an end page version (e.g., end LSN). Each lookup table entry 1244, 1246, 1248, and 1250 has one or more associated redo log records, each associated with a page version (e.g., LSN). Therefore, page A lookup table entry 1244 has a first redo log record at LSN = 200 1252 and a second redo log record at LSN = 100 1254, page B lookup table entry 1246 has a single redo log record at LSN = 120 1256, page C lookup table entry 1248 has a first redo log record at LSN = 200 1258 and a second redo log record at LSN = 150 1260, and page D lookup table entry 1250 has a single redo log record at LSN = 200 1262. Thus, for example, the key of an entry in lookup table 1242 could be a page identifier, but the value corresponding to that entry could be a linked list of the most recent redo log records associated with the page.

[0105] Log cache 1240 provides an efficient lookup interface for use by database replica server 214. For a given page identifier (e.g., "page A", or the page ID corresponding to page A) and page version range (e.g., start LSN and end LSN), log cache 1240 can return all redo log entries within that page version range from the corresponding lookup table 1242 entry. For example, if the log cache 1240 receives a lookup request from database replica server 214 for all versions of page A between LSN=130 and LSN=230, it returns the first redo log record 1252 at LSN=200 from page A lookup table entry 1244.

[0106] In some embodiments, the database replica server 214 may apply redo log records (e.g., redo log records 1252 and 1258) to local storage pages (e.g., pages A1232 and C1236) in the replica buffer pool 1214 as needed via log cache 1240. The following is in conjunction with... Figure 7Describe in more detail the process of applying redo logging on demand.

[0107] In some embodiments, when the available memory for log cache 1240 is insufficient, log cache 1240 can be refreshed or cleaned by cleaning or eviction of logs to remove historical redo log record versions. In some embodiments, when there is no available memory to register new redo log records, redo log records (e.g., the oldest unused redo log records) can be proactively evicted by cleaning. It should be understood that other reactive and / or proactive methods can be used in various embodiments to discard, overwrite, or refresh the contents of log cache 1240.

[0108] Log cache 1240 can be logically independent of Figure 2 The various components are shown. Log cache 1240 can run within a logical process with the same functionality as database replica server 214, as a separate process on database replica server 214, or even... Figure 2 or Figure 1 It runs on different nodes in the system, as long as the database replica server 214 is configured to communicate with the log cache 1240. In a cloud database 200 with multiple database replica servers 214, each database replica server 214 can have its own log cache 1240, or a single log cache 1240 can be shared by multiple database replica servers 214. In a multi-master database configuration, a single log cache 1240 can also be shared by multiple database master servers 212 to support data page synchronization when these database master servers 212 act as database replica servers 214.

[0109] In some embodiments, the log cache 1240 is stored entirely in memory. In other embodiments, the log cache 1240 may be partially stored in memory and partially stored in fast-accessible external storage; or it may be stored entirely in fast-accessible external storage with a memory-based cache.

[0110] Example method for registering redo logging to a log cache

[0111] When the database master server 212 commits a new transaction, the corresponding redo log record is refreshed from the primary buffer pool 1212 and needs to be registered to the log cache 1240. The new redo log record can be registered to the log cache 1240 after the database master server 212 has written the new redo log record to cloud storage (e.g., log storage 234 and page storage 232) and before the database replica server 214 makes the corresponding modifications visible to transactions (i.e., read requests received from clients). In some embodiments, the database master server 212 can register the redo log record to the log cache 1240 simultaneously with writing the redo log record to cloud storage. However, if the commit fails, resulting in the modifications not being written to cloud storage, the uncommitted redo log record must be deleted from the log cache 1240 via a rollback mechanism.

[0112] Below are two alternative example methods for registering redo logging records to log cache 1240. Figure 6A The first example method shown registers redo log records to log cache 1240 via database master server 212. Figure 6B The second example method shown registers redo log records to log cache 1240 via database replica server 214 associated with log cache 1240.

[0113] Figure 6A This is a flowchart of a first example method 1300 for registering redo log records to the log cache 1240 via the database master server 212. It should be understood that in some embodiments, steps involving communication with the database master server 212 may be performed by the master SAL 222; in some embodiments, steps involving communication with the database replica server 214 may be performed by the replica SAL 223.

[0114] Step 1302: Database master server 212 processes the GFB being refreshed to extract metadata. The metadata may include an updated list of transactions, which includes sequential transactions up to the end LSN of the GFB. The updated list of transactions may include transactions that were committed or rolled back during the GFB window (i.e., up to the end LSN of the GFB). For each page modified via the GFB's redo log, the metadata may also include a page identifier (e.g., page ID), the previous page LSN, and the new page LSN.

[0115] Step 1304: The database master server 212 registers the redo log records refreshed from GFB to (i.e., stores them in) the log cache 1240, and waits for confirmation from the log cache 1240. In some embodiments, this step can be performed in parallel with step 1302.

[0116] Step 1306: In response to receiving an acknowledgment from the log cache 1240, the database master server 212 sends metadata to the database replica server 214 (e.g., via...). Figure 2 (Arrow 202 in the image).

[0117] Step 1308: Database replica server 214 invalidates pages in replica buffer pool 1214 that are identified as being updated in the metadata (e.g., pages whose page IDs appear in the metadata).

[0118] Step 1310: Database replica server 214 sets the page expiration LSN of each page invalidated in step 1306 to the new page LSN of the corresponding page identified in the metadata. In some embodiments, steps 1308 and 1310 are a single step, and invalidating a page is achieved by setting the page expiration LSN to the new page LSN. A page is invalidated by updating the page's expiration LSN in replica buffer pool 1214 from the page's initial value (e.g., the MAX value, which indicates that the page is up-to-date, and the expiration LSN equals the last set of redo log records received by database replica server 214) to a new page LSN (e.g., the end LSN of the GFB of the current redo log record set). If the page's expiration LSN in replica buffer pool 1214 is less than MAX, then the page is no longer the latest version; a newer version of the page exists, and the LSN used to update the page's redo log record is equal to the page's expiration LSN.

[0119] Step 1312: Database replica server 214 updates its locally stored transaction list to include the updated transaction list in the metadata.

[0120] Step 1314: Database replica server 214 adds its visible LSN to the ending LSN of the GFB included in the metadata. The new value of the visible LSN allows read requests received by database replica server 214 to access the new version of the page updated by the received metadata.

[0121] In some embodiments, several consecutive GFBs can be processed together to optimize the processing of metadata by the database replica server 214. If two GFBs are consecutive, the last redo log record of the first GFB and the first redo log record of the second GFB must be consecutive in the global redo log record sequence, meaning there are no other redo log records between them. In some embodiments, this can be represented by a global LSN index, such that if the LSN of the last redo log record of the first GFB immediately precedes the LSN of the first redo log record of the second GFB, the two GFBs are considered consecutive.

[0122] Figure 6BThis is a flowchart of a second example method 1350 for registering (i.e., storing) redo log records to (associated with) the database replica server 214 of the log cache 1240. As in method 1300, it should be understood that in some embodiments, steps involving communication with the database master server 212 may be performed by the master SAL 222; in some embodiments, steps involving communication with the database replica server 214 may be performed by the replica SAL 223.

[0123] Step 1352: Database master server 212 refreshes the redo log records in GFB to cloud storage, such as page storage 232 and log storage 234.

[0124] Step 1354: Database master server 212 sends a synchronization instruction to database replica server 214. The synchronization instruction may include the location of the refreshed redo log records in cloud storage, and the end LSN of the refreshed GFB content. In alternative embodiments, the synchronization method may include refreshed GFB content (i.e., redo log records refreshed from GFB).

[0125] Step 1356: Database replica server 214 receives synchronization instructions.

[0126] Step 1358: In embodiments where the synchronization command does not include refreshed GFB content, the database replica server 214 reads the refreshed GFB content from cloud storage. In embodiments where the synchronization command includes refreshed GFB content, this step can be omitted.

[0127] Step 1360: Database replica server 214 processes the GFB content to extract metadata from it, as in step 1302 of method 1300. The metadata may include an updated list of transactions, which includes sequential transactions up to the end LSN of the GFB. For each page updated via redo logging, the metadata may also include an updated page identifier (e.g., page ID), the previous page LSN, and the new page LSN.

[0128] Step 1362: Database replica server 214 invalidates pages in replica buffer pool 1214 that are identified as being updated in the metadata (e.g., pages whose page IDs appear in the updated transaction list). In some embodiments, step 1362 may be the same as or equivalent to step 1308 of method 1300.

[0129] Step 1364: Database replica server 214 sets the page expiration LSN of each page invalidated in step 1306 to the new page LSN of the corresponding transaction list item in the metadata. In some embodiments, step 1364 may be the same as or equivalent to step 1310 of method 1300. Similar to steps 1308 and 1310 of method 1300, in some embodiments, steps 1362 and 1364 may be a single step and can invalidate a page by updating the page expiration LSN.

[0130] Step 1366: Database replica server 214 updates its locally stored transaction list to include the updated transaction list in the metadata. In some embodiments, step 1362 may be the same as or equivalent to step 1312 of method 1300.

[0131] Step 1368: Database replica server 214 registers the redo log records refreshed from GFB to (i.e., stores them in) log cache 1240 and waits for confirmation from log cache 1240. In some embodiments, this step can be performed in parallel with steps 1360 to 1366.

[0132] Step 1370: Database replica server 214 adds its visible LSN to the ending LSN of the GFB included in the metadata. The new value of the visible LSN allows read requests received by database replica server 214 to access the new version of the page updated by the received metadata. In some embodiments, step 1362 may be the same as or equivalent to step 1314 of method 1300.

[0133] In some embodiments, such as in method 1300, several consecutive GFBs can be processed together to optimize the processing of metadata by the database replica server 214.

[0134] Example methods for applying redo logging on demand

[0135] In some embodiments, in response to receiving a read request, database replica server 214 applies redo log entries to pages in local storage (e.g., in a buffer pool) on demand. When a read request for a specific page is received from a client, database replica server 214 retrieves a copy of that page stored in replica buffer pool 1214, looks up the page in lookup table 1242 of log cache 1240, and applies any redo log entries associated with the lookup table entry for that page, bringing the latest version of the page into replica buffer pool 1214. If the requested page does not exist in replica buffer pool 1214, database replica server 214 may retrieve the latest version of the page stored in page store 232. The page requested in the read request may be referred to as the "expected page". In some embodiments, the read request may specify a version of the expected page (e.g., LSN); the specified version of the page may be referred to as the "expected version".

[0136] In some embodiments, the replica buffer pool 1214 may store multiple versions of a page. For example, in combination with Figure 5 Since redo log records 1252 and 1254 for page A in lookup table 1242 of log cache 1240 are applied to an existing version of page A stored in replica buffer pool 1214, multiple versions of page A can be generated and stored in replica buffer pool 1214. For example, Figure 5 The version of page A 1232 shown corresponds to LSN = 100, or more precisely, to the LSN range [100, 200] (i.e., from LSN 100 (inclusive) to LSN 200 (exclusive)). Once the first page A redo log record 1252 in the log cache 1240 is applied to the existing version of page A 1232, a second version of page A (not shown) corresponding to the LSN range [200, MAX) can be generated. For each page version, the LSN range is shown as a left-closed, right-open interval [start LSN, expired LSN].

[0137] In an embodiment of the data synchronization method for the described database replica server 214, the database replica server generates an updated version of a page only when a client requests it. If a transaction being processed by the database replica server 214 (i.e., a read request from a client) does not require access to an updated version of a given page, then an updated version of the given page is not generated. Generating updated versions of pages on demand reduces unnecessary buffer pool usage (i.e., memory usage and / or memory I / O) and also reduces processor resource (e.g., CPU cycles) usage of the database replica server 214. When a set of transactions (i.e., read requests) being processed by the database replica server 214 requires access to updated versions of individual pages, multiple transaction threads can concurrently generate an updated version of each desired page without constraining a predefined number of threads for the redo logging application. Not constraining the number of threads for concurrent redo logging applications distributes the overall redo logging application overhead across the transactions. Since generating an updated version of a single page by applying redo logging takes only a small amount of time (e.g., at most tens of microseconds in some embodiments), the additional overhead attributable to each transaction is negligible, and therefore transaction response time is unaffected. Furthermore, since the application of redo log records is not part of the critical path for advancing the visible LSN of database replica server 214, data visibility lag is reduced. Additionally, through log caching 1240, since page storage 232 does not need to apply all currently received redo log records to generate older versions of pages, the load on cloud storage can be reduced when retrieving older versions of pages. For the same reason, query throughput can also be improved by reducing the latency of retrieving older versions of pages. Therefore, compared to existing database replica server data synchronization methods, the example embodiments described herein can provide consistently high query throughput and / or lower data visibility lag.

[0138] Figure 7 This is a flowchart of example method 1400 for a database replica server to synchronize data by applying redo logs on demand.

[0139] Step 1402: Database replica server 214 receives a read request from the client. The read request includes an identifier associated with the desired page (e.g., page ID), denoted here as...<page id> In some embodiments, the read request includes a version identifier (e.g., LSN) of the desired page (e.g., log sequence number), denoted here as v(target), which identifies the version of the requested desired page.

[0140] Step 1404: Database replica server 214 determines whether the expected page exists in replica buffer pool 1214. <pageid>The requested version v(target). If the expected page exists in replica buffer pool 1214.<page id> If the version is v(target), then step 1424 of method 1400 is executed; otherwise, step 1406 of method 1400 is executed.

[0141] Step 1406: Database replica server 214 determines whether the expected page exists in replica buffer pool 1214. <pageid>If it is an older version, then execute step 1408 of method 1400; otherwise, execute step 1416 of method 1400.

[0142] Step 1408: Database replica server 214 retrieves the desired page from replica buffer pool 1214. <pageid>The latest version (e.g., LSN) v(base), where v(base) is lower than v(target).

[0143] Step 1410: Database replica server 214 retrieves the desired page from the log cache.<page id> One or more associated redo log records. In some embodiments, the log cache may provide a log cache software interface that receives a page identifier, a start version identifier, and an end version identifier, and returns all redo log records associated with the page identified by the page identifier having a version identifier between the start and end version identifiers. Thus, for example, the database replica server 214 can use the parameters (<page id> The `v(base), v(target)` parameter is passed to the log caching software interface. In response, the log caching software interface can return all redo log records stored in lookup table 1242, where the key of the lookup table entry is...<page id> The LSN value is between v(base) and v(target).

[0144] Step 1412: Database replica server 214 determines whether the log cache includes all redo log records within a specified version range. In some embodiments, this condition may be evaluated by referring to the visible LSN of database replica server 214 (or another indicator of the latest page version registered in log cache 1240); in these embodiments, step 1412 may be performed before step 1410. However, in other embodiments, this evaluation can only be performed after step 1410 has retrieved redo log records from log cache 1240. If log cache 1240 does not contain enough redo log records to display the desired page...<page id> If the redo log record is updated from version v (base) to the requested version v (target), then step 1416 of method 1400 is executed; otherwise, step 1414 of method 1400 is executed.

[0145] Step 1414: Database replica server 214 applies the redo log records retrieved from log cache 1240 to the desired page.<page id> The retrieved storage version v(base) is used to generate the updated expected page, i.e., the expected page.<page id> The requested version v(target). The updated expected page is stored in replica buffer pool 1214.

[0146] Step 1416: In response to determining (step 1406) that the replica buffer pool 1214 does not contain any version of the expected page, or determining (step 1412) that the log cache 1240 does not contain enough to store the expected page.<page id> The local storage version v (base) is updated to the redo log record of the requested version v (target), and the database replica server 214 retrieves a copy of the desired page from cloud storage (e.g., page storage 232). In some embodiments, the desired page is retrieved from storage by sending a page read request to page storage 232 storing the desired page. The page read request includes parameters (<page id> v(cached), and v(target)). In some embodiments, v(cached) is the lowest (i.e., earliest) version (e.g., LSN) of the redo log record stored in lookup table 1242, which is associated with the desired page.<page id> The lookup table entry is associated with it. In some embodiments, for a more conservative approach, v(cached) can be a newer (i.e., higher) version (e.g., LSN), but in any case, v(cached) needs to be less than or equal to v(target).

[0147] In response to a read request from database replica server 214, page storage 232 returns the expected page that is higher than version v (cached) and lower than or equal to version v (target).<page id> Version 232. Page storage 232 returns the expected page.<page id> The version is denoted as v(retrieved), where v(cached) < v(retrieved) ≤ v(target).

[0148] Step 1418: As in step 1410, database replica server 214 retrieves the expected page from the log cache again.<page id> Associated redo log records. Unlike step 1410, database replica server 214 seeks to retrieve all redo log records between versions v(retrieved) and v(target); therefore, it can include the parameter (<page id> The `v(retrieved), v(target)` values ​​are passed to the log caching software interface. In response, the log caching software interface can return all redo log records stored in lookup table 1242, where the key of that lookup table entry is...<page id> The LSN value is between v(retrieved) and v(target).

[0149] Step 1420: As in step 1412, database replica server 214 determines whether the log cache includes all redo log records within the specified version range. If the log cache 1240 does not contain enough to satisfy the expected page...<page id> If the redo log record is updated from version v (retrieved) to the requested version v (target), then step 1422 of method 1400 is executed; otherwise, step 1414 of method 1400 is executed.

[0150] Step 1422: As in step 1416, database replica server 214 retrieves a copy of the desired page from cloud storage (e.g., page storage 232). Unlike step 1416, the page version requested from cloud storage is version v (target), therefore, the read request can pass parameters (<page id> This means that log caching 1240 is not used; database replica server 214 waits for cloud storage to update to the requested version v(target) of the expected page. Cloud storage (e.g., page storage 232) will then store the expected page.<page id> After version v(target) is returned to database replica server 214, step 1424 of method 1400 is executed.

[0151] Step 1424: Database replica server 214 reads the updated expected page (i.e., the expected page) from replica buffer pool 1214.<page id> Version v(target) is updated and the expected page is sent to the client.

[0152] In addition to the advantages mentioned above, the on-demand application of redo logging method 1400 can also offer other advantages. By applying redo logging on demand, the described embodiments can remove the process of applying redo log records to update pages from the critical path of the data synchronization process of the database replica server. Therefore, the lag introduced by data synchronization can be significantly reduced, thereby shortening data visibility lag. Thus, the database replica server only needs to complete a few small steps to move its visible LSN up: extracting metadata from the redo log records refreshed in the database master server buffer, registering the refreshed redo log records to the log cache, invalidating discarded or obsolete pages in the buffer pool, setting the expiration LSN of invalid pages, and updating the locally stored transaction list. All of these steps can be completed quickly (e.g., within milliseconds in some embodiments).

[0153] In some embodiments, zero visibility lag in cloud databases can be achieved by applying redo logging on demand. The database master server can be configured to delay sending transaction commit notifications to its clients until the database replica server has completed data synchronization. This may slow down the transaction commit process on the database master server, but it offers the advantage that transactions on the database replica server may not experience any delay in viewing the latest updates from the database master server. Furthermore, this feature can be enabled or disabled on a per-transaction basis, allowing only clients that do not require lag to use it.

[0154] A similar function can be implemented using a database replica server to achieve the same goal: no data visibility lag. When the database replica server 214 receives a read request from a client, if the client requires or requests zero data visibility lag, the database replica server 214 can delay executing the transaction (i.e., satisfy the read request) and trigger data synchronization method 1300 or 1350 to obtain the latest redo log record committed by the database master server 212. The database replica server 214 can wait until the visible LSN is updated to the latest LSN of the redo log record committed by the database master server 212 before allowing the transaction to execute.

[0155] Overview

[0156] While this invention describes functions performed by certain components and physical entities, it should be understood that in a distributed system, some or all of the processes can be distributed across multiple components and entities, and multiple instances of the process can be executed on the distributed system.

[0157] Although the present invention describes methods and processes by steps performed in a certain order, one or more steps in the methods and processes may be omitted or modified as appropriate. Where appropriate, one or more steps may be performed in an order other than that described.

[0158] Although the invention has been described at least partially in terms of method, those skilled in the art will understand that the invention is also directed to various components for performing at least some aspects and features of the method, whether by hardware components, software, or any combination thereof. Accordingly, the technical solutions of the invention can be embodied in the form of a software product. Suitable software products can be stored in pre-recorded storage devices or other similar non-volatile or non-transitory computer-readable media, including DVDs, CD-ROMs, USB flash drives, removable hard drives, or other storage media. The software product includes instructions tangibly stored thereon that enable a processing device (e.g., a personal computer, server, or network device) to perform examples of the methods disclosed herein. Generally, software improves the operation of hardware in one or more ways.

[0159] The invention may be embodied in other specific forms without departing from the subject matter of the claims. The exemplary embodiments described are merely illustrative in all respects and not restrictive. Features selected from one or more of the foregoing embodiments may be combined to create alternative embodiments not explicitly described, and features suitable for such combinations will be understood within the scope of the invention.

[0160] All values ​​and sub-ranges within the scope of the disclosure are also disclosed. Furthermore, although the systems, devices, and processes disclosed and illustrated herein may include a specific number of elements / components, modifications may be made to say the systems, devices, and components to include more or fewer of such elements / components. For example, although any element / component disclosed may be referred to as a single quantity, embodiments disclosed herein may be modified to include multiple such elements / components. The subject matter described herein is intended to cover and encompass all appropriate technical changes.< / pageid> < / pageid> < / pageid>

Claims

1. A method for synchronizing data on a database replica server for a cloud database, characterized in that, The cloud database includes a computing layer and a storage layer, wherein the computing layer and the storage layer are separate; the computing layer includes a database master server configured to generate redo log records and a database replica server configured to respond to client read requests; the storage layer includes a log storage configured to store redo log records and a page storage configured to store data pages in the database, update the data pages based on the redo log records, and provide the updated data pages to the database replica server, wherein the method includes: The database replica server receives a request from the client to read the desired page of the database data; In response to receiving a request to read the desired page: After determining that the requested version of the desired page is not stored in the buffer pool of the database replica server, The retrieved expected page is an older storage version; Retrieve one or more redo log records associated with the desired page from the log cache; The one or more redo log records are applied to the old storage version of the desired page to generate the updated desired page; The database replica server sends the updated expected page to the client.

2. The method according to claim 1, characterized in that, The cloud database is a multi-master cloud database; The database replica server is the database master server.

3. The method according to claim 1 or 2, characterized in that, The log cache is part of the database replica server.

4. The method according to claim 1 or 2, characterized in that, The log cache is part of the cloud database and is separate from the database replica server.

5. The method according to any one of claims 1 to 4, characterized in that, The database replica server retrieves the stored version of the desired page from its buffer pool.

6. The method according to any one of claims 1 to 4, characterized in that, The database replica server retrieves the stored version of the desired page from the page storage of the cloud database.

7. The method according to any one of claims 1 to 6, characterized in that, Before retrieving the one or more redo log records associated with the desired page, the method further includes: Multiple redo log records are stored in the log cache, the multiple redo log records including at least one of the one or more redo log records associated with the desired page.

8. The method according to claim 7, characterized in that, The database master server stores the multiple redo log records in the log cache.

9. The method according to claim 7, characterized in that, The database replica server stores the multiple redo log records into the log cache.

10. The method according to claim 7, characterized in that, Before storing the plurality of redo log records to the log cache, the method further includes: It was determined that the available memory in the log cache was insufficient to store the multiple redo log records; Remove one or more redo log records stored in the log cache.

11. The method according to claim 7, characterized in that, Each of the multiple redo log records is associated with a page; Storing the plurality of redo log records to the log cache includes: associating each redo log record in the plurality of redo log records with a lookup table entry corresponding to the page associated with each redo log record and storing it in the lookup table of the log cache; Retrieving the one or more redo log records from the log cache includes: retrieving one or more redo log records stored in association with the lookup table entry corresponding to the desired page.

12. The method according to claim 11, characterized in that, The storage version of the desired page is associated with the log sequence number; Retrieving the one or more redo log records includes: retrieving one or more redo log records stored with a log sequence number greater than the log sequence number of the storage version of the desired page.

13. The method according to claim 12, characterized in that, Before retrieving the one or more redo log records associated with the desired page, the method further includes: It was determined that the available memory in the log cache was insufficient to store the multiple redo log records; Remove one or more redo log records stored in the log cache; The plurality of redo log records are stored in the log cache, the plurality of redo log records including at least one of the one or more redo log records associated with the desired page; Update the visible log sequence number of the database replica server to the end log sequence number associated with the plurality of redo log records.

14. A processing unit, characterized in that, include: Processing equipment; as well as A memory for storing instructions, which, when executed by the processing device, cause the processing unit to perform the functions of a database replica server for a cloud database. The database replica server is configured to respond to read requests from clients. The cloud database includes a compute layer and a storage layer, which are separate. The compute layer includes a database master server configured to generate redo log records and the database replica server. The storage layer includes a log store configured to store redo log records and a page store configured to store data pages in the database, update the data pages based on the redo log records, and provide the updated data pages to the database replica server. The database replica server is used for: Receive a request from the client to read the desired page of the database. In response to receiving a request to read the desired page: After determining that the requested version of the desired page is not stored in the buffer pool of the database replica server, The retrieved expected page is an older storage version; Retrieve one or more redo log records associated with the desired page from the log cache; The one or more redo log records are applied to the old storage version of the desired page to generate the updated desired page; The updated desired page is sent to the client.

15. The processing unit according to claim 14, characterized in that, The processing unit includes the log cache; When the instruction is executed by the processing device, it also causes the processing unit to perform the log caching function.

16. The processing unit according to claim 14 or 15, characterized in that, The log cache includes multiple stored redo log records, and each of the multiple stored redo log records is associated with a lookup table entry corresponding to the page and stored in the lookup table of the log cache; Retrieving the one or more redo log records from the log cache includes: retrieving one or more stored redo log records associated with the lookup table entry corresponding to the desired page.

17. The processing unit according to claim 16, characterized in that, When the instruction is executed by the processing device, it also causes the processing unit to perform the function of the buffer pool; The stored version of the desired page is retrieved from the buffer pool.

18. The processing unit according to claim 17, characterized in that, The storage version of the desired page is associated with the log sequence number; Retrieving the one or more redo log records includes: retrieving one or more redo log records stored with a log sequence number greater than the log sequence number of the storage version of the desired page.

19. The processing unit according to claim 18, characterized in that, The database replica server is also configured to: retrieve the one or more redo log records associated with the desired page: It was determined that the available memory in the log cache was insufficient to store the multiple redo log records received; Remove one or more redo log records stored in the log cache; The received multiple redo log records are stored in the log cache, and the multiple redo log records include at least one of the one or more redo log records associated with the desired page; Update the visible log sequence number of the database replica server to the end log sequence number associated with the received plurality of redo log records.

20. A computer-readable medium storing instructions to be executed by a processing device in a cloud database, characterized in that, The cloud database includes a computing layer and a storage layer, wherein the computing layer and the storage layer are separate. The computing layer includes a database master server configured to generate redo log records and a database replica server configured to respond to client read requests. The storage layer includes a log storage configured to store redo log records and a page storage configured to store data pages in the database, update the data pages based on the redo log records, and provide the updated data pages to the database replica server. When the instruction is executed, the database replica server performs the following operations: Receive a request from the client to read the desired page of the database. In response to receiving a request to read the desired page: After determining that the requested version of the desired page is not stored in the buffer pool of the database replica server, The retrieved expected page is an older storage version; Retrieve one or more redo log records associated with the desired page; The one or more redo log records are applied to the old storage version of the desired page to generate the updated desired page; The updated desired page is sent to the client.

Images