Replication for hot-standby online database

Abstract

Computer system (10) used to replicate a database image from a functioning primary node (12) in a distributed database environment, wherein the computer system comprises: one or more computer processors (22); and one or more computer-readable storage media (30); wherein program instructions (200A) are stored on the computer-readable storage media (34) for execution by at least one of the one or more computer processors, wherein the program instructions include instructions that cause the at least one of the one or more computer processors to: to provide a checkpoint image of the primary node including a database structure and a plurality of database pages (301); to create a replica database (100B) on a backup node by initializing a backup node (12') and storing the specified database structure on the initialized backup node; to send each database page of the checkpoint image to the backup node for storage; After the creation of a checkpoint image has started, each subsequent transaction is stored on the primary node, thereby generating a corresponding REDO transaction to send to the backup node; to identify each data page on which each subsequent transaction performs operations; In parallel with sending the database pages, send each generated REDO transaction to the backup node in the order in which the corresponding transaction took place, so that the backup node can replicate the transactions in the correct order; and to prioritize each flagged database page so that it arrives at the backup node before or at roughly the same time as a corresponding REDO transaction, allowing the corresponding REDO transaction to perform operations on the flagged database page without having to wait until each database page is saved to the backup node.

Description

AREA OF INVENTION

[0001] This invention relates to a method and a device for a replicator for a hot-standby online database. BACKGROUND

[0002] In a hot-standby (HSB) database, a transaction is committed in two phases, where both a primary node and a backup node must successfully acknowledge changes before the transaction is considered properly committed. This is a two-phase commitment (2PC) protocol that ensures a database always has the same state on both nodes. 2PC is an atomic commitment protocol (ACP) and a special type of consensus protocol used to coordinate all processes involved in a distributed atomic transaction regarding whether to commit or abort (undo) the transaction. Some HSB databases allow users to sacrifice consistency for performance by enabling more relaxed transactions.Such a transaction is defined in a Two-Safe-Received (2SR) protocol, where the primary node commits the transaction once a backup node confirms that it has received all the protocol records of the committing transaction.

[0003] A primary node is sometimes called a main node, and a backup node is sometimes called a secondary node, standby node, or child node. Typically, a primary node accepts all transactions, while a backup node accepts only read-only transactions.

[0004] There are several ways to keep a backup node synchronized with a primary node, but this publication focuses on protocol replication (also known as protocol dispatch replication). With protocol replication, a primary node stores each write transaction in its database and in a log record, which is then copied to a backup node. When a backup node receives log records, it performs a redo transaction for each received record. A redo transaction repeats the referenced transaction.

[0005] In these implementations, an HSB database is stored in main memory for faster data access, since main memory, unlike persistent memory with its indirect access and slower access speed, is directly addressed by a processing unit (CPU). Fast main memory access is not a property specific to HSB databases, but it applies to in-memory databases that can support hot standby functionality. Log records are typically stored in persistent memory. An in-memory database ensures persistent data changes by writing checkpoint images (also called snapshots) of the database to persistent memory at regular intervals (or on demand). Writing checkpoint images is a checkpoint process.A checkpoint image aggregates data into database pages, which are contiguous data ranges in mass storage and are typically the same size as single or multiple logical memory blocks. For simplicity, it is assumed that a database page is the same size as a disk block.

[0006] An in-memory database manages its active data in volatile main memory. Typically, an in-memory database includes a built-in main memory manager that allocates large portions of main memory from the operating system and then organizes it in the most suitable way for use by the in-memory database. It is assumed that the data is stored in main memory segments of varying sizes, but that each main memory segment contains information that allows the data to be grouped into main memory page sizes to create a checkpoint image. Alternatively, the database could be structured into main memory page sizes.

[0007] An HSB database has a primary node and usually a backup node, though some variants have multiple backup nodes. In more complex systems, it's possible to duplicate a database across partitions (or "shards"), with one partition considered the primary and others as backup partitions. The same principles apply to this partitioned model. A node can be a physically separate computer unit, a card in a card tray, or a process within a virtual machine on the single host computer. Occasionally, an HSB database, or a computer node running an HSB database, may crash.Such a crash corrupts the checkpoint image of one of the nodes to such an extent that the database stored on the affected node cannot be recovered. If another node remains functional during a crash, it can assume the role of the primary node (if it wasn't already the primary node) and continue executing transactions.

[0008] Some time after a primary node fails, another node is initialized as a backup node. The initialized node can be the failed (and recovered) node or a replacement node capable of fulfilling the backup node function in an HSB database. If the primary node has failed, there is no way to initialize a backup node using a non-existent checkpoint image. A database copy is only possible if the primary node is operational. If the database is not stored on the disk of the initialized backup node, it cannot restore or process transactions stored in REDO transactions.Therefore, a copy of the data must be provided for the initialized backup node, followed by log records containing all changes made to the database on the primary node after the time the checkpoint image was created.

[0009] If a backup node has been restarted after a failure, its checkpoint image may be corrupted or it may not have one at all. Therefore, a complete checkpoint image must be copied from the primary node to the backup node without taking the primary node offline. The backup node requires: metadata; system tables; the most recent checkpoint image; and REDO transactions of write operations performed from the point at which checkpoint image creation began until the primary and backup databases are consistent.

[0010] Synchronizing a database on a backup node with data from a primary node involves two phases: a copy phase and a reconciliation phase. The copy phase involves copying the database located on the primary node to the backup node. The reconciliation phase involves creating log records on the backup node about transactions that have already been executed and committed on the primary node. If one of the nodes has failed or is currently being restored, the system is in a vulnerable phase because the fault tolerance of the HSB database has decreased due to the failure.

[0011] Known solutions for HSB synchronization create complete copies of one or more checkpoint images, including iterative versions of the checkpoint images, followed by the log sets generated by the most recently performed transactions.

[0012] A common HSB synchronization process can be divided into, for example, a primary synchronization process at the primary node: sending a checkpoint image (including metadata and actual data) from the primary node to the backup node; sending REDO transactions that were active during the creation of the checkpoint image; and sending REDO transactions that were executed during synchronization at the primary node. The corresponding backup synchronization process can be divided into the following steps: receiving a checkpoint image (including metadata and actual data); receiving REDO transactions that were active during the creation of the checkpoint image; and receiving REDO transactions that were executed during synchronization at the primary node.

[0013] An in-memory database running on standard hardware can execute hundreds of thousands of individual write transactions per second. Under normal circumstances, read-only transactions can be performed on both a primary node and a backup node, thus partially offloading the load from the primary node. If other nodes fail, the remaining node may have to assume the role of the primary node (if it wasn't already). The primary node immediately becomes responsible for all write and read-only transactions, potentially doubling the number of its active client connections in practice. Consequently, the primary node's memory footprint increases significantly, and depending on the utilization and implementation details, performance may decrease due to the higher number of concurrent transactions.

[0014] When the backup node restoration process begins, the primary node is responsible for creating a fresh checkpoint image of the current database state, which is copied to create a backup in a database template. Any transactions that were not committed during the checkpoint image creation must be recorded as REDO transactions on the primary node, sent to a backup node, and executed. This constitutes the reconciliation phase.

[0015] Copying a checkpoint image from a primary node to a backup node and instructing the backup node to synchronize with the primary node must occur before the primary node's main memory is exhausted. If the primary node's main memory is exhausted, the HSB synchronization process will fail, or the primary node's REDO transactions must alternatively be stored in persistent storage to reduce memory requirements. REDO transactions in persistent storage must be read from the persistent storage disk, which is significantly slower than reading data from fast storage.

[0016] Accessing REDO transactions from persistent storage slows down the reconciliation phase. Slow reconciliation increases the risk of subsequent failures and reduces the overall ability of a backup node to reconcile with the primary node in a timely manner. Additional failures during the vulnerable period can be disastrous for the HSB database. If a backup node cannot reconcile with a primary node after the initial failure, the risk of a critical failure in the future increases.

[0017] Therefore, the reconciliation phase becomes a serious threat to the availability of HSB databases in cases where the update frequency is high, and it is important to make the HSB synchronization process as quick as possible to keep this risk as small as possible.

[0018] The publication "Incremental Recovery in Main Memory Database Systems" addresses data recovery in main memory database systems. It proposes an incremental recovery scheme that includes page-by-page incremental recovery after failures and the technique of log-driven backups, which can be performed in parallel with normal transaction execution. The core idea is to separate the recovery-related I / O operations from the actual transaction execution. This is achieved by using non-volatile RAM to store critical state information, such as marking pages as "outdated" or "current." BRIEF SUMMARY OF THE INVENTION

[0019] The invention is based on the objective of creating a computer system, a method, a computer program product, and a computer program that enable improved replication of a database image. This objective has been achieved by the features of the corresponding independent claims. The embodiments of the invention are specified in the dependent claims.

[0020] A replicator is provided to replicate a database image from a functioning primary node in a distributed database environment, wherein the replicator includes: an image engine to specify a checkpoint image of the primary node, including a database structure and a variety of database pages; a controller to create a replica database on a backup node by initializing a backup node and storing the specified database structure on the initialized backup node; a transfer mechanism to send each database page of the checkpoint image to the backup node for storage; and a logger to record each subsequent transaction on the primary node after the creation of a checkpoint image has started, thereby generating a corresponding REDO transaction to send to the backup node.a page identifier to mark each data page on which each subsequent transaction performs operations; a parallel transfer mechanism to send each generated REDO transaction to the backup node in the order in which the corresponding transaction occurred, in parallel with the sending of the database pages, so that the backup node can replicate the transactions in the correct order; and a page controller to prioritize each marked database page so that it arrives at the backup node before or largely at the same time as a corresponding REDO transaction, allowing the corresponding REDO transaction to perform operations on the marked database page without having to wait for the remaining database page to be stored on the backup node.

[0021] Furthermore, a method is provided to replicate a database image from a functioning primary node to a backup node in a distributed database environment, wherein the method comprises: specifying a checkpoint image of the primary node including a database structure and a plurality of database pages; initiating the creation of a replica database on a backup node by initializing a backup node and storing the specified database structure on the initialized backup node; sending each database page of the checkpoint image to the backup node for storage; after the creation of a checkpoint image has started, storing each transaction on the primary node and generating a corresponding REDO transaction to send it to the backup node; and identifying each data page on which each REDO transaction performs operations.In parallel with sending the database pages, sending each generated REDO transaction to the backup node in the order in which the corresponding transaction took place, so that the backup node can replicate the transactions in the correct order; and prioritizing each tagged database page so that it arrives at the backup node before or largely at the same time as a corresponding REDO transaction, with the corresponding REDO transaction performing operations on the tagged database page without having to wait until each database page is stored on the backup node.

[0022] It is proposed that the database structure be specified, extracted from the primary node, and sent to a newly created backup node, with the REDO transaction being sent in parallel to perform operations on the backup node. The newly created backup node replicates the database structure upon arrival. This replication (also known as synchronization) involves creating an empty database structure (metadata, tables, and indexes). Immediately after the structural replication of the metadata, the backup node can begin connecting to and serving database clients. The remaining data pages are sent in parallel with the execution of REDO transactions. Interleaving database pages and REDO transactions is advantageous because the backup node receives the most needed data first.

[0023] Among the most notable advantages is the ability for primary nodes to execute transactions without interruption; furthermore, primary nodes can begin sending REDO transactions to the backup node as soon as the backup node has received and processed the metadata. In addition, these implementations allow data pages to be sent from main memory to the backup node in parallel with the sending of REDO transactions.

[0024] The implementations recognize the possibility of replicating REDO transactions from a primary node to a backup node at the same time that a template database (seed database) is copied from the primary node to a backup node. In other words, a conventional HSB synchronization process involves transferring a fresh checkpoint image from the mass storage of a primary node to a backup node, followed by a reconciliation phase. Only after the reconciliation phase is it possible to initiate protocol transactions from a primary node to a backup node.

[0025] These embodiments allow a checkpoint image to be copied directly from the main memory of a primary node to a backup node without any input / output access to the slow persistent disk storage. They also allow the replication of active REDO transactions from a primary node to a backup node to begin during an HSB synchronization process. Consequently, the transfer of checkpoint images is faster because there are no operations in persistent storage. Furthermore, the storage requirement in a primary node is significantly lower than in the case where all active transactions must be cached in the primary node to transfer an entire checkpoint image (i.e., each data page).

[0026] Therefore, the duration of a database synchronization process is not dependent on the performance of a disk or system, but rather on the network's transmission capacity. Since network transmission capacity can be increased, for example by using proprietary network protocols instead of TCP / IP, the input / output bottleneck to and from the storage device is eliminated, thereby shortening the HSB synchronization process and increasing the overall availability of an HSB database.

[0027] The preferred embodiment is described in relation to Two-Safe-Received (2SR) protocol transactions, but other embodiments could use other types of transactions, including One-Safe-Received (1SR) protocol transactions, where transactions perform a commit once a commit request has been sent from a commit operation in the primary node to the backup node.

[0028] Advantageously, a modified database page is given a higher priority than an unchanged one. It is beneficial to send the most frequently used data (i.e., modified or used pages) as soon as possible so that less frequently used pages do not compete for shared resources.

[0029] Even more advantageous is that a database page in main memory is given a higher priority than data pages in persistent storage. Main memory is prioritized because data access is faster and transfer times are shorter than with persistent storage. Main memory is typically volatile storage with a smaller capacity but faster access times. Persistent storage is typically a persistent disk drive with a larger capacity but slower access times.

[0030] An even greater advantage is that the procedure further features: identifying two or more data pages on which a REDO transaction performs operations; and sending the two or more data pages in parallel with sending the generated REDO transaction.

[0031] Furthermore, it is advantageous that the primary node notifies the backup node that all database pages have been sent.

[0032] Preferably, the backup node notifies the primary node that all database pages have been received.

[0033] Preferably, REDO transactions and database pages are intertwined in a send buffer before being sent to a backup node.

[0034] Transactions are even more preferentially placed on the primary node, continuously burdening it.

[0035] The embodiments affect transaction processes that continue outside the cluster database environment, so that the database performance appears largely consistent and not significantly degraded during the failure of a node. This effect occurs at the machine and system level of an executing computer and below each higher application level. The embodiments demonstrate that the computer becomes faster during the failure of a node.

[0036] Furthermore, a computer program product is provided to replicate a functional primary database in a cluster database environment, wherein the computer program product includes a computer-readable storage medium containing computer-readable program code implemented thereon, and wherein the computer-readable program code is configured to perform all steps of the procedures.

[0037] The computer program product comprises a set of instructions that can be read by a computer. These instructions are either permanently stored on a physical medium, such as a computer-readable medium (e.g., an optical disk, magnetic disk, or solid-state drive), or can be transmitted to a computer system using a modem or other interface device over a physical medium, including, but not limited to, optical or analog transmission lines, or in a non-physical medium using wireless techniques, including, but not limited to, microwave, infrared, or other transmission techniques. The set of computer-readable instructions contains all or part of the functionality described above.

[0038] A person skilled in the art understands that such computer-readable instructions can be written in several programming languages ​​for use with many computer architectures or operating systems. Furthermore, such instructions can be stored using any current or future storage technology, including, but not limited to, semiconductor, magnetic, or optical technology, or transmitted using any current or future transmission technology, including, but not limited to, optical, infrared, or microwave technology.It is intended that such a computer program product will be distributed as an interchangeable data carrier with accompanying documentation in printed or electronic form, for example shrink-wrapped, pre-loaded with a computer system, for example on a ROM or hard drive of a system, or from a server or an electronic bulletin board via a network, for example via the Internet or the World Wide Web.

[0039] Furthermore, a computer program is provided which is stored on a computer-readable data carrier and can be loaded into the internal main memory of a digital computer, which includes parts of software code when the program is executed on a computer to perform all the steps of the method claims.

[0040] Furthermore, a data carrier aspect of the preferred embodiment is provided, which comprises functional computer data structures so that, when loaded into and operated on a computer system, it enables the computer system to perform all steps of the method claims. A suitable data carrier could be a semiconductor memory, a magnetic disk drive, or an optical disk. Channels for data transmission can also comprise storage media of any kind as well as signal transmission media such as, for example, wired or wireless signal transmission media. BRIEF DESCRIPTION OF THE DRAWINGS

[0041] Preferred embodiments of the present invention will now be described by way of example and with reference to the following drawings, wherein: Fig. 1 is an implementation overview of the preferred embodiment; Fig. 2 is a component overview of the preferred embodiment; Fig. 3 is a flowchart of a process of the preferred embodiment; the Fig. 4A to 4D are flowcharts of subprocesses of the preferred embodiment; Fig. 5 a flowchart of a corresponding process of a safety node of the preferred embodiment; and Fig. 6 is an implementation overview of a parallel data processing execution form. DETAILED DESCRIPTION OF THE EXECUTION FORMS

[0042] Referring to Fig. In this document, the implementation of a preferred embodiment in a hot-standby database system 10 is described. The hot-standby database system 10 can operate with numerous other environments or configurations of general-purpose or specialized data processing systems. Examples of known data processing systems, data processing environments, and / or configurations that may be suitable for use with the hot-standby database system 10 include, but are not limited to, personal computer systems, server computer systems, thin clients, thick clients, portable or laptop devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics, network PCs, minicomputer systems, mainframe computer systems, and distributed cloud computing environments, which may include any of the aforementioned systems or devices.

[0043] Hot-standby database system 10 can be described in the general context of instructions that can be executed by a computer system, such as program modules executed by a computer processor. In general, program modules can contain routines, programs, objects, components, logic, and data structures that perform specific tasks or implement certain abstract data types. Hot-standby database system 10 can be implemented in distributed cloud computing environments where tasks are performed by remote processing units connected via a transmission network. In a distributed cloud computing environment, program modules can reside in both local and remote storage media of a computer system, including main memory units.

[0044] The hot-standby database system 10 comprises: the primary node 12 in the form of a general-purpose computer server; one or more input units 14 and output units 16 directly connected to the primary node 12; a backup node 12' in the form of a computer server and at least one spare node 13.

[0045] The hot-standby database system 10 is connected to a network 20. The hot-standby database system 10 exchanges data with a user 18 using input devices 14 and output devices 16. Input devices 14 include one or more of the following: a keyboard, a scanner, a mouse, a trackball, or another pointing device. Output devices 16 include a monitor or a printer, or multiple monitors or multiple printers. The hot-standby database system 10 exchanges data with network devices (not shown) over the network 20. The network 20 can be a local area network (LAN), a wide area network (WAN), or the internet.

[0046] The computer server primary node 12 includes: a central processing unit (CPU) 22; a network adapter 24; a unit adapter 26; a bus 28 and a main memory 30.

[0047] The CPU 22 loads machine instructions from main memory 30 and performs machine operations in response to these instructions. These machine operations include: incrementing or decrementing a value in a register (not shown); transferring a value from main memory 30 to a register or vice versa; branching to another location in main memory if a condition is true or false (also known as a conditional branch instruction); and adding or subtracting the values ​​in two different registers and loading the result into another register. A typical CPU can perform many different machine operations. A set of machine instructions is called a machine code program, and the machine instructions are written in a machine code language, which is the lowest level of abstraction possible in the system.A computer program written in a high-level programming language must first be compiled into machine code before it can be executed. Alternatively, a machine code program, such as a virtual machine or an interpreter, can evaluate a high-level programming language with respect to machine operations.

[0048] The network adapter 24 is connected to the bus 28 and the network 20 to enable data exchange between the primary node 12 and network units including backup nodes.

[0049] The unit adapter 26 is connected to the bus 28 as well as input units 14 and output units 16 to enable data exchange between the computer server 12 and input units 14 and output units 16.

[0050] Bus 28 connects the main system components, including main memory 30 and CPU 22. Bus 28 represents one or more of various arbitrary bus structures, including a main memory bus or main memory control unit, a peripheral bus, an Accelerated Graphics Port, and a processor or local bus that utilizes any of a variety of bus architectures. Examples, but not limited to, such architectures include the Industry Standard Architecture (ISA), the Micro Channel Architecture (MCA), the Enhanced ISA (EISA), the Video Electronics Standards Association (VESA) local bus, and the Peripheral Component Interconnects (PCI).

[0051] The main memory 30 contains data storage media readable by a computer system in the form of volatile main memory 32 and non-volatile or persistent main memory 34. Examples of volatile main memory 32 include random access memory (RAM) 36 and cache memory 38. Volatile main memory is generally used because it is faster, and non-volatile memory is generally used because it retains data for longer periods. The hot-standby database system 10 may also contain other removable and / or non-removable, volatile and / or non-volatile storage media of a computer system. By way of example only, persistent memory 34 may be provided for read operations from and write operations to a non-removable, non-volatile magnetic storage medium (not shown, and typically a magnetic hard disk or a solid-state drive).Although not shown, additional storage media can be provided, including: an external connector for a removable, non-volatile semiconductor memory; and an optical disk drive for performing read operations from or write operations to a removable, non-volatile optical disk such as a compact disc (CD), a digital video disc (DVD), or Blu-ray disc. In these cases, each storage medium can be connected to bus 28 via one or more data disk interfaces. As further shown and described below, the system memory 30 can contain at least one program product having a set (for example, at least one set) of program modules configured to perform the functions of embodiments of the invention.

[0052] The set of program modules configured to perform the functions of the preferred embodiment includes database 100A and replicator 200A. Backup node 12' includes database 100B and replicator 200B. Other program modules supporting the preferred embodiment, but not shown, include firmware, a bootstrap program, an operating system, and support applications. The operating system, support applications, other program modules, and program data, or any specific combination thereof, may each include an implementation of a network environment.

[0053] The hot-standby database system 10 exchanges data with at least one network 20 (such as a local area network (LAN), a wide area network (WAN), and / or a public network like the Internet) via network adapter 24. As shown, network adapter 24 exchanges data with the other components of the computer server 12 via bus 28. It should be understood that other hardware and / or software components could also be used in conjunction with the hot-standby database system 10, although these are not shown. Examples include, but are not limited to: microcode, unit drivers, redundant processing units, external arrays of hard disk drives, a redundant array of independent disks (RAID), tape drives, and storage systems for data archiving.

[0054] Referring to Fig. 2. The replicator 200 (a general class of replicators 200A and 200B) has the following components: the copyid index 202; the dirtyid index 204, the send queue 206; the primary procedure 300 and the backup node procedure 500.

[0055] The copyid index 202 is a data structure used to store references to database pages that have already been sent to a backup node for a specific checkpoint image.

[0056] The `dirtyid` index 204 is a data structure used to store references to database pages that have been modified since the checkpoint image was created. If all database pages for a checkpoint image are to be read from main memory instead of reading unmodified database pages from disk, the `dirtyid` index 204 alternatively contains identifiers for all database pages. In the first case, whenever an unmodified database page is changed, its identifier is added to the `dirtyid` index 204. The contents of the `dirtyid` index 204 are deleted when the checkpoint image creation is complete. In the second case, the `dirtyid` index 204 contains all identifiers of database pages in the database.

[0057] Send queue 206 is a queue used to store database pages and REDO transactions before sending them to a backup node.

[0058] The primary method 300 is used to replicate a primary node and is described below with reference to Fig. 3 and the Fig. Sections 4A to 4D are described in detail.

[0059] The backup node procedure 500 is a corresponding backup node process for replicating the primary node and is described below with reference to Fig. 5 described in detail.

[0060] Referring to Fig. The primary procedure 300 has the logical process steps 301 to 307.

[0061] In an initial state, the primary node 300 executes transactions when another node, intended to become a new backup node, is started. A new backup node does not have its own database image, either because it has been corrupted or because it is entirely missing. It must share a common database with the primary node. The primary node 300 creates a self-contained, consistent version of its database, called a checkpoint image or snapshot. In an in-memory database, the checkpoint is created in main memory, from where it is copied for transfer to a backup node. Pages can be read from disk and main memory in parallel. Used pages reside in main memory because they have been modified recently. Consequently, they are more likely to be modified again at an earlier time than the pages on disk.

[0062] A database page encountered in the copyid index 202 of a primary node has one of the following states: BUFFERED (if it has already been added to the send buffer, i.e., it has already been found and a decision has been made to send it to a backup node); and SENT (if the actual sending of a page has taken place).

[0063] Step 301 creates a new checkpoint image and a new checkpoint identifier. A checkpoint counter is incremented. Updates caused by transactions do not lose data during checkpoint image creation. Update transactions can perform commit operations during checkpoint image creation. Older versions of checkpoint images are maintained until they are moved to persistent storage.

[0064] Step 302 serves to extract the necessary database structure, including metadata and system tables, from the database and send it to backup node 12'.

[0065] Step 303 is used to wait for a response. An acknowledgment arrives from backup node 12, informing that metadata has been successfully processed and backup node 12 is ready to receive data and REDO transactions.

[0066] Step 304 is used for the parallel processing of REDO transactions and database pages and is described below with reference to the parallel processing procedure '304' of the Fig. Sections 4A to 4D are described in more detail.

[0067] Step 305 is used to detect when all database pages have been sent to the backup node and to notify the backup node that no further pages will be sent.

[0068] Step 306 serves to confirm that all database pages have been received from the backup node and restored.

[0069] Step 307 is used to return to the normal procedure and switch from a local to a distributed commit protocol.

[0070] Referring to Fig. 4A has the parallel process procedure 304' the logical process steps 304A1, 304A2, 304A3, 304A4, 304F and the procedure 304B.

[0071] Step 304A1 serves to split the process into two separate processes that are executed in parallel: a first process to send database pages to the backup node, which starts at step 304A2, and a second process at procedure 304B to process REDO transactions.

[0072] Step 304A2 determines whether a database page has been unused or used (not modified or changed) since the checkpoint image was created. The dirtyid index 204 is used. If the database page is not listed in dirtyid index 204, the page is unused, and the process continues to step 304A3. Otherwise, the page is used, and the process continues to step 304A4. The database page is used if it is listed in dirtyid index 204 because changes have been made to it.

[0073] Step 304A3 serves to read the database page from main memory or from mass storage. With regard to consistency, this is irrelevant, since both pages are equivalent. In the preferred embodiment, however, the database page is read from functional main memory because access times are faster. The accessed database page is sent to the send queue 206 for transmission to the backup node. Next step 304F.

[0074] Step 304A4 reads the database pages from main memory only because it contains the most recent copy of the page. Next step 304F.

[0075] Procedure 304B is used to send REDO transactions to the backup node and is described below with reference to Fig. 4B described in more detail. Next step 304F.

[0076] Step 304F is used to determine whether there are any further database pages or REDO transactions to process, and if so, to return to step 304A1. Otherwise, it proceeds to step 305.

[0077] Referring to Fig. 4B includes the procedure 304B (send REDO transactions to the backup node) with the logical process steps 304B1 to 304B9, the procedure 304C and the procedure 304D.

[0078] Step 304B1 is used to specify a loop for each REDO transaction and to extract an identifier of a database page from a corresponding REDO transaction.

[0079] Step 304B2 is used to handle a REDO transaction with two or more database pages by performing all checks on all pages.

[0080] Step 304B3 is used to search the copyid index 202 for extracted page identifiers or for page identifiers to determine whether the database page has already been sent to the backup node.

[0081] Step 304B4 branches to step 304B5 if the extracted page identifier (page ID) is not listed in the copyid index 202 and therefore has not yet been sent to the backup node. Otherwise, if the extracted page ID is in the copyid index 202, the process continues with step 304B9.

[0082] Step 304B5 is used to search the extracted page ID in the dirtyid index 204 to determine if it has been changed after the checkpoint.

[0083] Step 304B6 is used to branch to step 304B7 if the dirtyid index 204 contains the extracted page ID. Otherwise, the process branches to procedure 304C.

[0084] Procedure 304C is used to handle page IDs that are not found in the copyid index 202 or the dirtyid index 204, and to proceed to step 304F when the procedure is complete. Procedure 304C is described below with reference to Fig. 4C is described in more detail.

[0085] Step 304B7 is used to read the page from main memory.

[0086] Step 304B8 is used to add the read page to the send queue 206 in order to send it to the backup node.

[0087] 304F was previously described as a return to step 304A1 in a loop if there are further pages or REDO transactions.

[0088] Step 304B9 is used to read the status of the entry and to proceed to procedure 304D.

[0089] Procedure 304D is used to handle database page IDs found in the copyid index 202 and to proceed to step 304F when the procedure is complete. Procedure 304D is described below with reference to Fig. 4D described in more detail.

[0090] Referring to Fig. Procedure 304C has the following logical process steps: 304C1 to 304C3, 304E1 and 304E2.

[0091] Step 304C1 is used to branch to step 304C2 if the extracted database page is unused and was created before the latest checkpoint image. Otherwise, step 304C3 is used.

[0092] Step 304C2 is used to read a database page from functional main memory or from mass storage. Next step 304E1.

[0093] Step 304E1 adds a REDO transaction to send queue 206. Next step 304E2.

[0094] Step 304E2 is used to add the identifier of the database page to the copyid index 202, and then to proceed to step 304F.

[0095] Step 304C3 is used only to add the REDO transaction to the send queue 206 before proceeding to step 304F.

[0096] Referring to Fig. In 4D, the 304D procedure has the logical process steps 304D1 to 304D3.

[0097] Step 304D1 is used to branch to step 304D2 if the page status is "queued". Otherwise, if the page status is "sent", it branches to step 304D3.

[0098] Step 304D2 is used to search for the page's storage location in the send queue 206 and insert the REDO transaction into the send queue 206 after the page's storage location. The process then proceeds to step 304F.

[0099] Step 304D3 is used to send the REDO transaction to the backup node as soon as possible, generally without adding it to the queue. It then proceeds to step 304F.

[0100] Referring to Fig. Section 5 of the safeguard node procedure 500 comprises the logical process steps 501 to 506 (including substeps 503.1, 503.2, 503.3, 504A1, 504A2, 504B1 and 504B2). The safeguard node procedure 500 is a supplement to the primary procedure 300.

[0101] Step 501 is used to receive metadata from the primary node. Metadata contains the database structure and necessary information to, for example, generate a database schema, and allows the backup node to open the database.

[0102] Step 502 is used to process the metadata and send confirmation back to the primary node that it is ready to receive the checkpoint image of the primary node and REDO transactions that correspond to transactions being executed on the primary node.

[0103] Step 503 branches to step 503.1 if the page type is a checkpoint image. Otherwise, if the document type is a REDO transaction, the step proceeds to step 503.2. When the backup node receives a page, it restores it by extracting rows and necessary information, such as the table ID and transaction ID, and inserting the rows into its local database. The backup node monitors each restored page by adding it to its index.

[0104] Step 503.1 is used to extract the table ID and transaction ID and insert rows and indexes to create the backup database. Step 505 then follows.

[0105] Step 503.2 is used to retrieve the table ID and the transaction ID, followed by step 503.3.

[0106] Step 503.3 is used to branch to 504B1 if the page is restored, and to branch to step 504A1 if the page is not restored.

[0107] Step 503A1 is used to branch to step 503A2 if the page can be restored by locking, and to step 504B1 if this is not possible.

[0108] Step 503A2 is used to acquire all locks and branch to step 504B1 once all locks have been acquired. If the page is not restored, execution can only continue as long as necessary locks are acquired. Execution waits until the page is restored. If the restoration is performed using locks, the REDO transaction operation must wait without locks until the page restoration is complete. Otherwise, if the page is restored, the REDO transaction can be executed as usual. If it is possible to execute REDO transactions in parallel within a normal HSB operation, then this is also possible during synchronization.

[0109] Step 504B1 is used for the parallel execution of REDO transactions. When the backup node receives a REDO transaction, it extracts the necessary information (for example, the table ID and the transaction ID) and checks whether the corresponding page has been restored.

[0110] Step 504B2 branches to step 503 if the primary node notifies the backup node that the checkpoints are complete. Otherwise, if there is no notification, step 505 follows.

[0111] Step 505 is used to extract the page ID and provide confirmation. When the backup node receives a notification that the checkpoint has been fully sent by the primary node, the backup node extracts the page ID from the notification. When this page is fully restored, it confirms to the primary node that the checkpoint image has been received.

[0112] Step 506 is used to return to the normal procedure by switching from the local to the distributed commit protocol.

[0113] Further embodiments of the invention will now be described.

[0114] It should be clear to those skilled in the art that all or some of the logical process steps of the preferred embodiment can alternatively be implemented in a logic device or in a plurality of logic devices, which includes logic elements arranged to perform the logical process steps of the method, and that such logic elements can include hardware components, firmware components, or a combination of hardware and firmware components.

[0115] It should be equally clear to those skilled in the art that all or some of the logic components of the preferred embodiment can alternatively be implemented in a logic device comprising logic elements for carrying out the steps of the method, and that such logic elements can comprise components such as logic gates in, for example, a programmable logic assembly or an application-specific integrated circuit. Furthermore, such a logic assembly can be implemented in elements that enable such implementation in order to temporarily or permanently establish logical structures in such an assembly or circuit, using, for example, a virtual hardware description language that can be stored and transmitted using fixed or portable storage media.

[0116] In a further alternative embodiment, the present invention can be implemented in the form of a computer-executed method for installing a service, which includes steps for installing computer program code such that, when installed and executed on a computer infrastructure, it causes the computer system to perform all the steps of the method.

[0117] It will be recognized as advantageous that the method and components of the preferred embodiment can alternatively be implemented completely or partially in a parallel data processing system which has two or more processors to execute parallel software.

[0118] Referring to Fig.Section 6 describes an exemplary parallel data processing implementation, 10P, which features parallel groups of hot-standby database systems for parallel database processing. The preferred embodiment is implemented in a single-processor server in a distributed database environment, but another embodiment could be implemented in a server with parallel processors in a distributed database environment. The parallel hot-standby database system 10P is described in the general context of instructions that can be executed by a parallel computer system, such as parallel program modules executed by the parallel data processing system 10P. In general, parallel program modules can contain routines, programs, objects, components, logic, and data structures that perform specific tasks or implement certain abstract data types.The parallel hot-standby database system 10P features: the parallel computer servers 12A and 12B. A direct connection or a network enables access between the parallel computer servers 12A and 12B.

[0119] The parallel computer server 12A has: CPU 22AA, CPU 22AB; network adapter 24A; bus 28A and main memory 30A. Similarly, the parallel computer server 12B has: CPU 22BA, CPU 22BB; network adapter 24B; bus 28B and main memory 30B.

[0120] Buses 28A and 28B represent one or more of various arbitrary types of bus structures, including a main memory bus or main memory control unit, a peripheral bus, an accelerated graphics port, and a processor or local bus that utilizes any bus architecture from many different bus architectures.

[0121] The main memory locations 30A and 30B contain data carriers readable by a computer system in the form of volatile main memory 32A and 32B (such as random access memory and cache memory (not shown)) and in the form of non-volatile or persistent main memory 34A and 34B.

[0122] The persistent main memory 34A contains: at least two databases 100AA and 100AB; and the replicator module 200A. During execution, the replicator rejects the objects 200AA and 200AB; and the corresponding databases 100AA' and 100AB' are instantiated in the respective main memory areas 33AA and 33AB in the volatile main memory 32A.

[0123] Similarly, persistent main memory 34B contains: at least two databases 100BA and 100BB; and the replicator module 200B. During execution, the replicator rejects objects 200BA and 200BB; and the corresponding databases 100BA' and 100BB' are instantiated in the respective main memory areas 33BA and 33BB in volatile main memory 32B.

[0124] The persistent main memory modules 34A and 34B also store: the corresponding operating systems, one or more application programs, a database management system, and other program modules. The operating system, one or more application programs, other program modules, and program data, or a specific combination thereof, can each include a network environment implementation. The replicator modules 200A and 200B are provided to execute the functions and / or methodological procedures of the implementations in a parallel environment.

[0125] The database and the replicator modules are autonomous parts of the parallel implementation. During operation, these two types of modules are retrieved from persistent main memory 34A and 34B and loaded into volatile main memory 32A and 34B, so that they can be executed separately and consequently in parallel by corresponding CPUs (CPU 22AA, 22AB, 22BA, 22BB).

[0126] This example shows two CPUs per server, but any number of CPUs can be used to build alternative parallel configurations. This example uses two separate CPUs, but a single processing unit with multiple processor cores could also be used to build an alternative configuration.

[0127] In this parallel implementation, the CPUs are physical CPUs, but in an alternative implementation, virtual CPUs can be simulated. In a virtual parallel data processing implementation, a computer server has a virtual data processing environment, and virtual parallel processing units could be used to build a virtual parallel data processing implementation. A computer server has a virtual data processing environment that includes a virtual processing unit with multiple virtual processor cores.

[0128] Other embodiments may include any combination of: real processing units; processor cores of real processing units; virtual processing units; and virtual parallel processing cores.

[0129] It should be clear to those skilled in the art that many improvements and modifications can be made to the foregoing exemplary embodiment without deviating from the scope of the present invention.

Claims

[1] Computer system (10) used to replicate a database image from a functioning primary node (12) in a distributed database environment, wherein the computer system comprises: one or more computer processors (22); and one or more computer-readable storage media (30); wherein program instructions (200A) are stored on the computer-readable storage media (34) for execution by at least one of the one or more computer processors, wherein the program instructions include instructions that cause the at least one of the one or more computer processors to: to provide a checkpoint image of the primary node including a database structure and a plurality of database pages (301); to create a replica database (100B) on a backup node by initializing a backup node (12') and storing the specified database structure on the initialized backup node; to send each database page of the checkpoint image to the backup node for storage; After the creation of a checkpoint image has started, each subsequent transaction is stored on the primary node, thereby generating a corresponding REDO transaction to send to the backup node; to identify each data page on which each subsequent transaction performs operations; In parallel with sending the database pages, send each generated REDO transaction to the backup node in the order in which the corresponding transaction took place, so that the backup node can replicate the transactions in the correct order; and to prioritize each flagged database page so that it arrives at the backup node before or at roughly the same time as a corresponding REDO transaction, allowing the corresponding REDO transaction to perform operations on the flagged database page without having to wait until each database page is saved to the backup node. [2] Computer system according to claim 1, wherein a modified database page is given a higher priority than an unmodified database page. [3] Computer system according to claim 1, wherein a database page in main memory (32) is given a higher priority than database pages in persistent memory (34). [4] Computer system (10) used to replicate a database image from a functioning primary node in a distributed database environment, wherein the computer system comprises: one or more computer processors (22); and one or more computer-readable storage media (30); wherein program instructions (200A) are stored on the computer-readable storage media (34) for execution by at least one of the one or more computer processors, wherein the program instructions include instructions that cause the at least one of the one or more computer processors to: to provide a checkpoint image of the primary node including a database structure and a plurality of database pages (301); to create a replica database (100B) on a backup node by initializing a backup node (12') and storing the specified database structure on the initialized backup node; to send each database page of the checkpoint image to the backup node for storage; After the creation of a checkpoint image has started, each subsequent transaction is stored on the primary node, thereby generating a corresponding REDO transaction to send to the backup node; to identify each data page on which each subsequent transaction performs operations; In parallel with sending the database pages, send each generated REDO transaction to the backup node in the order in which the corresponding transaction took place, so that the backup node can replicate the transactions in the correct order; and to prioritize each flagged database page so that it arrives at the backup node before or at roughly the same time as a corresponding REDO transaction, allowing the corresponding REDO transaction to perform operations on the flagged database page without having to wait until each database page is saved to the backup node, where a modified database page is given a higher priority than an unchanged database page, where a database page in main memory (32) is given a higher priority than database pages in persistent storage (34). [5] Computer system according to claim 1 or 3, further comprising: Identifying two or more data pages on which a REDO transaction performs operations; and sending the two or more data pages in parallel with sending the generated REDO transaction. [6] Computer system according to claim 1 or 3, wherein the primary node notifies the backup node that all database pages have been sent (305). [7] Computer system according to claim 1 or 3, wherein the backup node notifies the primary node that all database pages have been received (307). [8] Computer system according to claim 1 or 3, wherein REDO transactions and database pages are entangled in a send buffer memory (206) before being sent to a backup node. [9] Computer system according to claim 1 or 3, wherein transactions continuously load the primary node. [10] Method (300) for replicating a database image of a functioning primary node to a backup node of a distributed database environment, wherein the method comprises: Specifying (301) a checkpoint image of a primary node (12) including a database structure and a plurality of database pages; Creating a replica database (100B) on a backup node (12') by initializing a backup node and storing the specified database structure on the initialized backup node; Sending each database page of the checkpoint image to the backup node for storage; After the creation of a checkpoint image has started, each subsequent transaction is stored on the primary node, thereby generating a corresponding REDO transaction to send to the backup node; Identifying each data page on which each subsequent transaction performs operations; In parallel with sending the database pages, sending each generated REDO transaction to the backup node in the order in which the corresponding transaction took place, so that the backup node can replicate the transactions in the correct order; and Prioritizing each flagged database page so that it arrives at the backup node before or at roughly the same time as a corresponding REDO transaction, allowing the corresponding REDO transaction to perform operations on the flagged database page without having to wait for each database page to be saved to the backup node. [11] Method according to claim 10, wherein a modified database page is given a higher priority than an unmodified database page. [12] Method according to claim 10, wherein a database page in main memory (32) is given a higher priority than database pages in persistent memory (34). [13] Method (300) for replicating a database image of a functioning primary node to a backup node of a distributed database environment, wherein the method comprises: Specifying (301) a checkpoint image of a primary node (12) including a database structure and a plurality of database pages; Creating a replica database (100B) on a backup node by initializing a backup node (12') and storing the specified database structure on the initialized backup node; Sending each database page of the checkpoint image to the backup node for storage; After the creation of a checkpoint image has started, each subsequent transaction is stored on the primary node, thereby generating a corresponding REDO transaction to send to the backup node; Identifying each data page on which each subsequent transaction performs operations; In parallel with sending the database pages, send each generated REDO transaction to the backup node in the order in which the corresponding transaction took place, so that the backup node can replicate the transactions in the correct order; and Prioritizing each flagged database page so that it arrives at the backup node before or at roughly the same time as a corresponding REDO transaction, allowing the corresponding REDO transaction to perform operations on the flagged database page without having to wait until each database page is saved to the backup node. where a modified database page is given a higher priority than an unchanged database page, where a database page in main memory (32) is given a higher priority than database pages in persistent storage (34). [14] The method of claim 10 or 13, further comprising: Identifying two or more data pages on which a REDO transaction performs operations; and sending the two or more data pages in parallel with sending the generated REDO transaction. [15] Method according to claim 10 or 13, wherein the primary node notifies the backup node that all database pages have been sent (305). [16] Method according to claim 10 or 13, wherein the backup node notifies the primary node that all database pages have been received (307). [17] Method according to claim 10 or 13, wherein REDO transactions and database pages are entangled in a send buffer memory (206) before being sent to a backup node. [18] Method according to claim 10 or 13, wherein transactions continuously load the primary node. [19] Computer program product for replicating a database image from a functioning primary node to a backup node in a distributed database environment, wherein the computer program product comprises a computer-readable storage medium which has computer-readable program code implemented therein, wherein the computer-readable program code is configured to perform any one of the method claims. [20] Computer program stored on a computer-readable data carrier and capable of being loaded into the internal memory of a digital computer, wherein the computer program includes parts of software code when the program is executed on a computer to perform the method according to any one of the method claims.

Images