Management method of shared storage multi-write database cluster and related products

Abstract

The invention provides a management method of a shared storage multi-write database cluster and a related product. The write permission of the same data page of the database cluster is migrated between at least two instances; the management method comprises the steps that under the condition that any instance becomes a new holder of write permission, the operation of writing a data page is recorded on a new holding log; before the write permission is migrated, the newly held log is refreshed; and after the write permission is migrated, recording a migration record of the write permission on the originally held log, and storing a complete page of the data page on the originally held memory and marking the complete page as a past mirror image. According to the management method of the shared storage multi-write database cluster, when a new holder modifies the data of the data page for the first time, the complete page of the data page does not need to be stored in the pre-write log, so that the condition of expansion of the pre-write log can be inhibited, the read-write cost and space occupation of the pre-write log can be reduced, and the performance of the database cluster can be ensured.

Description

Technical Field

[0001] The present invention relates to the technical field of databases, and in particular, to a management method for a shared storage multi-write database cluster and related products. Background Art

[0002] With the increase in data and throughput, the performance of traditional single-database architectures cannot meet the requirements of fast response to client queries. In this situation, cluster databases have become the new development direction of database systems. One structure of cluster databases is a database cluster with a shared storage architecture, that is, multiple server nodes share the same storage medium, and each node can access the data in the shared storage medium and provide services externally. The database cluster with a shared-nothing architecture means that each node has its own data storage, and the nodes do not share with each other, and the data in the database is distributed to multiple nodes. However, whether it is a database cluster with a shared storage structure or a database cluster with a shared-nothing structure, when the database is running, there will always be a situation of downtime (including but not limited to reasons such as operating system restart, host power failure, database process crashing due to program defects, being killed by a forced termination program command, etc.), and it is possible that only part of the data page is written to the disk, resulting in an inconsistent situation of the page, that is, data page breakage.

[0003] Currently, in the prior art, databases generally use the Full Page Write mechanism to solve page breakage. That is, when writing to a data page for the first time after a Checkpoint, the complete data page will be written to the Write-Ahead Logging. When a host crashes, the redo operation will overwrite the current damaged data page with the complete data page saved in the Write-Ahead Logging to achieve the recovery of the correct data page. For a database cluster with a shared storage architecture, in order to achieve instance recovery only by reading the Write-Ahead Logging file of the node to be recovered, whenever the write permission of the same data page migrates between multiple instances, the instance that becomes the holder of the write permission will also perform a full page write in the Write-Ahead Logging when modifying the data page for the first time. And the instance that becomes the holder will retain the current mirror of the data block. If a certain instance fails, the previous mirror in other instances can be used to recover the data without waiting for the completion of the entire database checkpoint operation. However, if there are multiple migrations of the holder of the same data page within a checkpoint cycle, there will be multiple full page mirrors in the Write-Ahead Logging, which will cause the expansion of the Write-Ahead Logging, resulting in more read and write costs and space occupation of the Write-Ahead Logging in the cluster database, and reducing the performance of the cluster database. Summary of the Invention

[0004] An object of the present invention is to provide a management method and related products for a shared storage multi-write database cluster that can overcome at least one of the above-mentioned technical defects in the prior art.

[0005] A further object of the present invention is to suppress the expansion of the write-ahead log by reducing or even no longer recording full-page images in the write-ahead log, reducing the read / write cost and space occupancy of the write-ahead log, and ensuring the performance of the database cluster.

[0006] In particular, the present invention provides a management method for a shared storage multi-write database cluster. The shared storage multi-write database cluster includes multiple primary nodes, at least two primary nodes each run an instance, and the write permission for the same data page in the database cluster migrates between at least two instances; and,

[0007] The management method includes:

[0008] When any instance becomes the new holder of the write permission, record the operation to write to the data page on the new hold log, where the new hold log is the write-ahead log of the primary node where the new holder is located;

[0009] Before the write permission migrates, flush the new hold log to disk;

[0010] When the new holder becomes the original holder of the write permission after the write permission migrates, record the migration record of the write permission on the original hold log, and save the complete page of the data page on the original hold memory and mark it as a past image, where the original hold log is the write-ahead log of the primary node where the original holder is located, and the original hold memory is the memory of the primary node where the original holder is located.

[0011] Further, when any primary node fails and instance recovery is performed, the management method further includes:

[0012] Merge the write-ahead logs of each primary node to obtain a recovery log;

[0013] Read the log records starting from the most recent checkpoint of the recovery log and find the latest migration record;

[0014] Judge whether the instance running on the surviving primary node is the new holder according to the latest migration record;

[0015] If not, obtain the surviving image, where the surviving image is the past image saved on the memory of the surviving primary node;

[0016] Recover the data page according to the recovery log and the surviving image.

[0017] Further, the step of recovering the data page according to the recovery log and the surviving image includes:

[0018] Skip parsing the pre-mirror log records, which are the log records in the recovery log before the surviving mirror;

[0019] Recover the data pages according to the log records in the recovery log after the surviving mirror and the surviving mirror.

[0020] Further, when the instance running on the surviving primary node is the new holder, the management method further includes:

[0021] Skip reading and parsing the recovery log.

[0022] Further, before the step of determining whether the surviving instance is the new holder of the write permission according to the latest migration record, the management method further includes:

[0023] Skip parsing the pre-migration log records, which are the log records in the recovery log before the latest migration record.

[0024] Further, when executing the step of flushing the new-held log to disk, the management method further includes:

[0025] Eliminate the past mirrors saved on the primary node where the original holder is located.

[0026] Further, when any instance becomes the new holder of the write permission, the management method further includes:

[0027] Eliminate the old version of the past mirrors saved on the primary node where the new holder is located.

[0028] Further, when multiple primary nodes have exceptions and instance recovery is performed, the management method further includes:

[0029] Merge the write-ahead logs of each primary node to obtain the recovery log;

[0030] Redo from the most recent checkpoint of the recovery log.

[0031] Specifically, the present invention further provides a machine-readable storage medium, on which a machine-executable program is stored, and when the machine-executable program is executed by a processor, the management method of the above-mentioned shared storage multi-write database cluster is implemented.

[0032] Specifically, the present invention further provides a computer device, including a memory, a processor, and a machine-executable program stored on the memory and running on the processor, and when the processor executes the machine-executable program, the management method of the above-mentioned shared storage multi-write database cluster is implemented.

[0033] The management method of the shared storage multi-write database cluster of the present invention, in the case where the write permission of the same data page migrates among multiple instances, after the write permission migrates, a migration record of the write permission will be recorded on the original holding log, and the complete page of the data page will be saved on the original holding memory and marked as a past mirror. Furthermore, when the new holder first modifies the data of the data page, it is not necessary to save the complete page of the data page to the write-ahead log, that is, it is no longer necessary to record the full-page mirror of the data page on the write-ahead log. Compared with the full-page mirror, the migration record occupies less space. Therefore, the management method of the shared storage multi-write database cluster of the present invention can suppress the occurrence of write-ahead log expansion, reduce the read-write cost and space occupancy of the write-ahead log, and ensure the performance of the database cluster.

[0034] The machine-readable storage medium of the present invention can implement the above-mentioned management method of the shared storage multi-write database cluster. Therefore, the beneficial technical effects that can be achieved by the above-mentioned management method of the shared storage multi-write database cluster can also be achieved by the machine-readable storage medium of the present invention.

[0035] The computer device of the present invention can implement the above-mentioned management method of the shared storage multi-write database cluster. Therefore, the beneficial technical effects that can be achieved by the above-mentioned management method of the shared storage multi-write database cluster can also be achieved by the computer device of the present invention.

[0036] According to the following detailed description of the specific embodiments of the present invention in conjunction with the drawings, those skilled in the art will become more clear about the above and other objects, advantages and features of the present invention. Description of the Drawings

[0037] Hereinafter, some specific embodiments of the present invention will be described in detail with reference to the drawings in an exemplary and non-limiting manner. The same reference numerals in the drawings denote the same or similar components or parts. Those skilled in the art should understand that these drawings are not necessarily drawn to scale. In the drawings:

[0038] Figure 1 is a schematic flowchart of the management method of the shared storage multi-write database cluster according to an embodiment of the present invention;

[0039] Figure 2 is one of the schematic flowcharts of the multiple owner permission migrations of the same data page between the first instance and the second instance in the management method of the shared storage multi-write database cluster according to an embodiment of the present invention;

[0040] Figure 3 is the second of the schematic flowcharts of the multiple owner permission migrations of the same data page between the first instance and the second instance in the management method of the shared storage multi-write database cluster according to an embodiment of the present invention;

[0041] Figure 4 is a schematic flowchart of a management method for a shared storage multi-write database cluster according to another embodiment of the present invention;

[0042] Figure 5 is a schematic flowchart of a management method for a shared storage multi-write database cluster according to yet another embodiment of the present invention;

[0043] Figure 6 is a schematic flowchart of a management method for a shared storage multi-write database cluster according to still another embodiment of the present invention;

[0044] Figure 7 is a schematic flowchart of a management method for a shared storage multi-write database cluster according to another embodiment of the present invention;

[0045] Figure 8 is a block diagram of a machine-readable storage medium according to an embodiment of the present invention;

[0046] Figure 9 is a block diagram of a computer device according to an embodiment of the present invention. Detailed implementation manners

[0047] In the description of this embodiment, it should be understood that the terms "first" and "second" are only used for descriptive purposes and cannot be construed as indicating or implying relative importance or implicitly specifying the quantity of the indicated technical features. Thus, features defined with "first" and "second" may explicitly or implicitly include at least one of such features, that is, including one or more of such features. In the description of the present invention, the meaning of "a plurality" is at least two, such as two, three, etc., unless otherwise specifically defined. When a certain feature "includes or contains" a certain or certain features it covers, unless otherwise specifically described, this indicates that other features are not excluded and other features may be further included.

[0048] Unless otherwise limited, all terms (including technical terms and scientific terms) used in the description of this embodiment have the same meaning as commonly understood by those of ordinary skill in the technical field to which this application belongs.

[0049] In the description of this embodiment, the description referring to terms such as "embodiment" etc. means that the specific features, structures, materials or characteristics described in connection with the embodiment or example are included in at least one embodiment or example of the present invention. In this specification, the schematic expressions of the above terms do not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials or characteristics described may be combined in a suitable manner in any one or more embodiments or examples.

[0050] Figure 1It is a schematic flowchart of a management method for a shared storage multi-write database cluster according to an embodiment of the present invention. Refer to Figure 1 In this embodiment, the shared storage multi-write database cluster includes multiple master nodes. At least two master nodes are respectively running instances, and the write permission of the same data page in the database cluster migrates among at least two instances. Moreover, the management method for the shared storage multi-write database cluster may include:

[0051] Step S101, when any instance becomes the new holder of the write permission, record the operation to write to the data page on the new hold log, where the new hold log is the write-ahead log of the master node where the new holder is located.

[0052] Step S102, before the write permission migrates, flush the new hold log to disk.

[0053] Step S103, when the new holder becomes the original holder of the write permission after the write permission migrates, record the migration record of the write permission on the original hold log, save the complete page of the data page on the original hold memory and mark it as a past mirror, where the original hold log is the write-ahead log of the master node where the original holder is located, and the original hold memory is the memory of the master node where the original holder is located.

[0054] Due to the management method for the shared storage multi-write database cluster in this embodiment, when the write permission of the same data page migrates among multiple instances, after the write permission migrates, the migration record of the write permission will be recorded on the original hold log, and the complete page of the data page will be saved on the original hold memory and marked as a past mirror. Furthermore, when the new holder first modifies the data of the data page, it is not necessary to save the complete page of the data page to the write-ahead log, that is, it is no longer necessary to record the full-page mirror of the data page on the write-ahead log. Compared with the full-page mirror, the migration record occupies less space. Therefore, the management method for the shared storage multi-write database cluster in this embodiment can suppress the situation of write-ahead log expansion, can reduce the read / write cost and space occupancy of the write-ahead log, and ensure the performance of the database cluster.

[0055] In this embodiment, the management method for the shared storage multi-write database cluster may further include:

[0056] When the data page is written for the first time, record the complete data page in the write-ahead log.

[0057] It can be understood that in the case where a data page is written for the first time, the management method of the shared storage multi-write database cluster in this embodiment will still record the complete data page (full-page mirror) in the write-ahead log to ensure the correctness of the data page when the database cluster performs instance recovery. Moreover, when the write permission of the subsequent data page is modified for the first time by the new holder during migration between instances, the management method of the shared storage multi-write database cluster in this embodiment no longer records the full-page mirror of the data page in the write-ahead log. In contrast, the write-ahead log can have fewer full-page mirrors.

[0058] The following combines Figure 2 and Figure 3 as well as two specific examples to illustrate the beneficial technical effects of this embodiment.

[0059] In the prior art, referring to Figure 2 , in chronological order of time points, the process of multiple operations such as owner permission migration, writing, flushing, and elimination of the same data page between the first instance and the second instance can be as follows:

[0060] T1 (time): On the first instance, the data page is modified for the first time, and the v0 version of the full-page mirror (Full Page Image, FPI) is recorded in the write-ahead log.

[0061] T2: On the first instance, the data page is modified and recorded in the write-ahead log (WAL).

[0062] T3: The second instance requests an X lock (exclusive lock) for the data page. The first instance flushes the write-ahead log (WAL) to disk. The second instance records the v1 version of the full-page mirror (FPI), and the v1 version of the past image (Past Image, PI) is retained on the first instance.

[0063] T4: On the second instance, the data page is modified and recorded in the write-ahead log (WAL).

[0064] T5: The first instance requests an X lock for the data page. The second instance flushes the write-ahead log (WAL) to disk. The first instance records the v2 version of the full-page mirror (FPI), and the v2 version of the past image (PI) is retained on the second instance. The first instance releases the v1 version of the original past image (PI).

[0065] T6: On the first instance, the data page is modified and recorded in the write-ahead log (WAL).

[0066] T7: The second instance requests an X lock for the data page. The first instance flushes the write-ahead log (WAL) to disk. The second instance records the v3 version of the full-page mirror (FPI), and the v3 version of the past image (PI) is retained on the first instance.

[0067] T8: On the second instance, when the data page is modified, it is recorded on the Write-Ahead Log (WAL).

[0068] T9: The first instance requests an exclusive lock (X lock) on the data page. The second instance flushes the Write-Ahead Log (WAL) to disk. The first instance records the v4 version of the Full Page Image (FPI), and on the second instance, the v4 version of the Past Image (PI) is retained. The first instance releases the v3 version of the original Past Image (PI).

[0069] T10: On the first instance, when the data page is modified, it is recorded on the Write-Ahead Log (WAL).

[0070] T11: On the first instance, the data page is selected for eviction (Least Recently Used, LRU). It is flushed to disk to release memory, and the Write-Ahead Log is flushed to disk. The second instance releases the v4 version of the Past Image (PI).

[0071] T12: On the first instance, the data page is loaded into memory and modified, and the v5 version of the Full Page Image (FPI) is recorded.

[0072] T13: On the first instance, when the data page is modified, it is recorded on the Write-Ahead Log (WAL).

[0073] And according to the management method of the shared storage multi-write database cluster of this embodiment, referring to Figure 3 , in chronological order of time points, the process of multiple operations such as owner permission migration, writing, flushing, and eviction of the same data page between the first instance and the second instance can be as follows:

[0074] T1: On the first instance, when the data page is modified for the first time, the v0 version of the Full Page Image (FPI) is recorded.

[0075] T2: On the first instance, when the data page is modified, it is recorded on the Write-Ahead Log (WAL).

[0076] T3: The second instance requests an exclusive lock (X lock) on the data page. The first instance flushes the Write-Ahead Log (WAL) to disk. On the first instance, the v1 version of the Past Image (PI) is retained, and the first instance records the Block Holder Movement Record (BHMR).

[0077] T4: On the second instance, when the data page is modified, it is recorded on the Write-Ahead Log (WAL).

[0078] T5: The first instance requests and obtains an exclusive lock (X lock) on the data page. The second instance flushes the Write-Ahead Log (WAL) to disk. On the second instance, the v2 version of the Past Image (PI) is retained, and the second instance records the Block Holder Movement Record (BHMR). The first instance releases the v1 version of the original Past Image (PI).

[0079] T6: On the first instance, the data page is modified and recorded on the Write-Ahead Log (WAL).

[0080] T7: The second instance requests and obtains an exclusive lock (X lock) on the data page. The first instance flushes the Write-Ahead Log (WAL) to disk, retains version v3 of the Past Image (PI) on the first instance, and the first instance records the Block History Migration Record (BHMR).

[0081] T8: On the second instance, the data page is modified and recorded on the Write-Ahead Log (WAL).

[0082] T9: The first instance requests and obtains an exclusive lock (X lock) on the data page. The second instance flushes the Write-Ahead Log (WAL) to disk, retains version v4 of the Past Image (PI) on the second instance, the second instance records the Block History Migration Record (BHMR), and the first instance releases version v3 of the original Past Image (PI).

[0083] T10: On the first instance, the data page is modified and recorded on the Write-Ahead Log (WAL).

[0084] T11: On the first instance, the data page is evicted (LRU), flushed to disk to release memory. The first instance records the Block History Migration Record (BHMR), flushes the Write-Ahead Log (WAL) to disk, and the second instance releases version v4 of the Past Image (PI).

[0085] T12: On the first instance, the data page is loaded into memory and modified, and version v5 of the Full Page Image (FPI) is recorded.

[0086] T13: On the first instance, the data page is modified and recorded on the Write-Ahead Log (WAL).

[0087] It can be understood that Figure 3 in, only versions v0 and v5 of the Full Page Image (FPI) of the data page are saved in the Write-Ahead Log of the first instance, and no Full Page Image (FPI) of the data page is saved in the Write-Ahead Log of the second instance, and Figure 2 compared with [reference], there are 4 fewer Full Page Images. Therefore, the management method of the shared storage multi-write database cluster in this embodiment can suppress the occurrence of Write-Ahead Log expansion, reduce the read and write costs and space occupancy of the Write-Ahead Log, and ensure the performance of the database cluster.

[0088] Figure 4 is a schematic flowchart of the management method of the shared storage multi-write database cluster according to another embodiment of the present invention. Refer to Figure 4, in this embodiment, the shared storage multi-write database cluster includes multiple primary nodes, at least two primary nodes are respectively running instances, and the write permission of the same data page of the database cluster migrates among at least two instances; and the management method of the shared storage multi-write database cluster may include:

[0089] Step S401, when any instance becomes the new holder of the write permission, record the operation to write to the data page on the new hold log, and discard the old version of the past image saved on the primary node where the new holder is located, where the new hold log is the pre-write log of the primary node where the new holder is located.

[0090] Step S402, before the write permission migrates, flush the new hold log to disk, and discard the past image saved on the primary node where the original holder is located.

[0091] Step S403, when the new holder becomes the original holder of the write permission after the write permission migrates, record the migration record of the write permission on the original hold log, save the complete page of the data page on the original hold memory and mark it as the past image, where the original hold log is the pre-write log of the primary node where the original holder is located, and the original hold memory is the memory of the primary node where the original holder is located.

[0092] It can be understood that in the prior art, the new holder of the write permission will dominate the discarding of the least recently used past image to free up memory. However, there are still multiple versions of the past image remaining in the memory of the primary node, occupying memory resources and reducing the performance of the database cluster. Furthermore, the management method of the shared storage multi-write database cluster in this embodiment will, when any instance becomes the new holder of the write permission, discard the old version of the past image saved on the primary node where the new holder of the write permission is located, and when flushing the new hold log to disk, discard the past image saved on the primary node where the original holder of the write permission is located, that is, when an instance becomes the new holder, it will discard the old version of the past image on its corresponding primary node, and when the instance that becomes the new holder saves the new version of the past image, it will discard the old version of the past image on the primary node where the original holder is located. Refer to Figure 2 and Figure 3 , compared with the prior art, during the migration of the write permission of the same data page among multiple instances, only one version of the past image is retained in the shared storage multi-write database cluster of this embodiment, thereby greatly reducing the memory occupied by the past image in each primary node of the database cluster and improving the performance of the database cluster.

[0093] Figure 5 is a schematic flowchart of the management method of the shared storage multi-write database cluster according to another embodiment of the present invention. Refer to Figure 5, in this embodiment, when any master node fails and instance recovery is performed, the management method of the shared storage multi-write database cluster may include:

[0094] Step S501, merge the write-ahead logs of each master node to obtain a recovery log.

[0095] Step S502, start reading log records from the most recent checkpoint of the recovery log and find the latest migration record.

[0096] Step S503, determine whether the instance running on the surviving master node is the new holder according to the latest migration record; if not, execute Step S504; if not, the steps of S607 in the following embodiment can be executed.

[0097] Step S504, obtain the surviving image, where the surviving image is the past image saved in the memory of the surviving master node.

[0098] Step S505, recover the data pages according to the recovery log and the surviving image. This step S505 may include steps S606 and S607 in the following embodiment.

[0099] It can be understood that the management method of the shared storage multi-write database cluster in this embodiment can use the past image saved in the memory and the recovery log with migration records in the above embodiment to recover the data of the data pages, so as to ensure the data correctness of the data pages when the management method of the shared storage multi-write database cluster in the above embodiment can suppress log expansion.

[0100] In addition, in the process of merging the write-ahead logs of each master node in Step S501, it can be merged in order according to the log identification serial number of the write-ahead log to ensure the correctness of the data pages after instance recovery.

[0101] Figure 6 is a schematic flowchart of the management method of the shared storage multi-write database cluster according to another embodiment of the present invention. Refer to Figure 6 , in this embodiment, when any master node fails and instance recovery is performed, the management method of the shared storage multi-write database cluster may include:

[0102] Step S601, merge the write-ahead logs of each master node to obtain a recovery log.

[0103] Step S602, start reading log records from the most recent checkpoint of the recovery log and find the latest migration record.

[0104] Step S603: Skip the parsing of the pre-migration log records, where the pre-migration log records are the log records in the recovery log before the latest migration record. After this step S603 is executed, step S604 can be executed.

[0105] Step S604: Determine whether the instance running on the surviving master node is the new holder based on the latest migration record; if not, execute step S605; if so, step S608 can be executed.

[0106] Step S605: Obtain the surviving image, where the surviving image is the past image saved on the surviving instance.

[0107] Step S606: Skip the parsing of the pre-image log records, where the pre-image log records are the log records in the write-ahead log before the surviving image.

[0108] Step S607: Restore the data pages based on the log records in the recovery log after the surviving image and the surviving image; after this step, the instance recovery process ends.

[0109] Step S608: Skip the reading and parsing of the recovery log; after this step, the instance recovery process ends.

[0110] It can be understood that since before the write permission is migrated, the modifications made by the new holder to the data pages are persisted to the shared disk of the shared storage multi-write database cluster of this embodiment, the log records before the migration record do not need to be redone. Therefore, when performing instance recovery, the management method of the shared storage multi-write database cluster of this embodiment can skip the redo of the log records in the write-ahead log before the latest migration record, so as to save the time of instance recovery, save the computing power resources of the shared storage multi-write database cluster, and thus ensure the performance of the shared storage multi-write database cluster.

[0111] When the past image is saved in the memory of the surviving master node, since the current past image already contains the changes made to the data pages by the log records with a log sequence number less than or equal to the version of this past image, therefore, for the management method of the shared storage multi-write database cluster of this embodiment, the log records with a log sequence number less than or equal to the version of this past image do not need to be redone, and then the parsing of the pre-image log records can be skipped through step S606 to further save the time of instance recovery, save the computing power resources of the shared storage multi-write database cluster, and thus ensure the performance of the shared storage multi-write database cluster. And the management method of the shared storage multi-write database cluster of this embodiment can parse and redo the log records in the recovery log after the surviving image by executing step S607 to ensure the data correctness of the data pages.

[0112] In the case where the instance running on the surviving primary node is the new holder of the write permission, that is, the instance currently performing the write operation on the data page can run normally, and the changes made by the instance previously running on the abnormal primary node have been persisted to the disk, and the data of the current data page is correct. Therefore, the management method of the shared storage multi-write database cluster in this embodiment can directly restart the instance or the abnormal primary node without performing any operations on the recovery log to complete the instance recovery.

[0113] Figure 7 is a schematic flowchart of the management method of the shared storage multi-write database cluster according to another embodiment of the present invention. Refer to Figure 7 In this embodiment, when multiple primary nodes are abnormal and instance recovery is performed, the management method of the shared storage multi-write database cluster may include:

[0114] Step S701, merge the write-ahead logs of each primary node to obtain a recovery log.

[0115] Step S702, start redoing from the most recent checkpoint of the recovery log.

[0116] It can be understood that even if there are surviving primary nodes, it is impossible to determine whether there is unpersisted data on the other two abnormal primary nodes. Therefore, when multiple primary nodes are abnormal and instance recovery is performed, the management method of the shared storage multi-write database cluster in this embodiment can start redoing the log records of the recovery log from the most recent checkpoint to ensure the correctness of the data on the data page.

[0117] The following will be combined with Figure 8 to detail the machine-readable storage medium of this embodiment. Figure 8 is a schematic structural diagram of the machine-readable storage medium according to an embodiment of the present invention. Refer to Figure 8 In this embodiment, a machine-executable program 11 is stored on the machine-readable storage medium. When the machine-executable program 11 is executed by a processor, the above-mentioned management method of the shared storage multi-write database cluster is implemented.

[0118] The machine-readable storage medium of this embodiment can implement the above-mentioned log retention method of the database cluster. Therefore, the beneficial technical effects that the above-mentioned management method of the shared storage multi-write database cluster can achieve are also possessed by the machine-readable storage medium of this embodiment.

[0119] The following will be combined with Figure 9 to detail the computer device of this embodiment. Figure 9 is a schematic structural diagram of the computer device according to an embodiment of the present invention. Refer to Figure 9, in this embodiment, the computer device includes a memory, a processor, and a machine-executable program 11 stored in the memory and running on the processor, and when the processor executes the machine-executable program 11, it implements the above-mentioned management method of the shared storage multi-write database cluster.

[0120] Since the computer device of this embodiment can implement the above-mentioned log retention method of the database cluster. Therefore, the beneficial technical effects that can be achieved by the above-mentioned management method of the shared storage multi-write database cluster are also possessed by the computer device of this embodiment.

[0121] It should be noted that the logic and / or steps represented in the flowchart or described in other ways herein, for example, can be considered as a definite sequence list of executable instructions for implementing logical functions, and can be specifically implemented in any machine-readable storage medium for use by an instruction execution system, apparatus, or device (such as a computer-based system, a system including a processor, or other systems that can fetch and execute instructions from the instruction execution system, apparatus, or device), or in conjunction with these instruction execution systems, apparatus, or devices.

[0122] For the description of this embodiment, the machine-readable storage medium 10 can be any device that can contain, store, communicate, propagate, or transmit a program for use by an instruction execution system, apparatus, or device or in conjunction with these instruction execution systems, apparatus, or devices. More specific examples (non-exhaustive list) of the computer-readable medium include the following: an electrical connection part with one or more wirings (electronic device), a portable computer disk case (magnetic device), a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber device, and a portable compact disc read-only memory (CDROM). In addition, the machine-readable storage medium 10 can even be paper or other suitable media on which a program can be printed, because the program can be obtained electronically, for example, by optically scanning the paper or other media, then editing, interpreting, or processing it in other suitable ways if necessary, and then storing it in the computer memory.

[0123] It should be understood that each part of the present invention can be implemented by hardware, software, firmware, or a combination thereof. In the above-mentioned embodiments, multiple steps or methods can be implemented by software or firmware stored in the memory and executed by a suitable instruction execution system.

[0124] The computer device 20 can be, for example, a server, a desktop computer, a laptop computer, a tablet computer, or a smart phone. In some examples, the computer device 20 can be a cloud computing node. The computer device 20 can be described in the general context of computer system-executable instructions, such as program modules, executed by a computer system. Generally, program modules can include routines, programs, object programs, components, logic, data structures, etc. that perform particular tasks or implement particular abstract data types. The computer device 20 can be implemented in a distributed cloud computing environment where tasks are performed by remote processing devices linked through a communication network. In a distributed cloud computing environment, program modules can be located on local or remote computing system storage media including storage devices.

[0125] The computer device 20 can include a processor 22 adapted to execute stored instructions and a memory 21 that provides temporary storage space for the operation of the instructions during operation. The processor 22 can be a single-core processor, a multi-core processor, a computing cluster, or any number of other configurations. The memory 21 can include random access memory (RAM), read-only memory, flash memory, or any other suitable storage system.

[0126] The processor 22 can be connected through a system interconnect (such as PCI, PCI-Express, etc.) to an I / O interface (input / output interface) adapted to connect the computer device 20 to one or more I / O devices (input / output devices). The I / O devices can include, for example, a keyboard and a pointing device, where the pointing device can include a touchpad or a touch screen, etc. The I / O devices can be built-in components of the computer device 20, or can be devices externally connected to the computing device.

[0127] The processor 22 can also be linked through a system interconnect to a display interface adapted to connect the computer device 20 to a display device. The display device can include a display screen as a built-in component of the computer device 20. The display device can also include a computer monitor, a television, or a projector, etc. externally connected to the computer device 20. In addition, a network interface controller (NIC) can be adapted to connect the computer device 20 to a network through a system interconnect. In some embodiments, the NIC can use any suitable interface or protocol (such as Internet Small Computer System Interface, etc.) to transmit data. The network can be a cellular network, a radio network, a wide area network (WAN), a local area network (LAN), or the Internet, etc. Remote devices can be connected to the computing device through the network.

[0128] At this point, those skilled in the art should recognize that although numerous exemplary embodiments of the present invention have been shown and described in detail herein, many other variations or modifications that conform to the principles of the present invention can still be directly determined or derived from the disclosed content of the present invention without departing from the spirit and scope of the present invention. Therefore, the scope of the present invention should be understood and recognized as covering all such other variations or modifications.

Claims

1. A management method for a shared storage multi-write database cluster, the shared storage multi-write database cluster including multiple master nodes, at least two of the master nodes respectively running instances, and the write permission of the same data page in the database cluster migrating between at least two of the instances; and, The management method includes: When any one of the instances becomes the new holder of the write permission, recording the operation to write to the data page on a new hold log, where the new hold log is the write-ahead log of the master node where the new holder is located; Before the write permission migrates, flushing the new hold log to disk; After the write permission migrates and the new holder becomes the original holder of the write permission, recording the migration record of the write permission on the original hold log, saving the complete page of the data page on the original hold memory and marking it as a past mirror, where the original hold log is the write-ahead log of the master node where the original holder is located, and the original hold memory is the memory of the master node where the original holder is located.

2. The management method for a shared storage multi-write database cluster according to claim 1, wherein, When any one of the master nodes has an exception and instance recovery is performed, the management method further includes: Merging the write-ahead logs of each master node to obtain a recovery log; Reading log records starting from the most recent checkpoint of the recovery log and finding the latest migration record; Judging whether the instance running on the surviving master node is the new holder according to the latest migration record; If not, obtaining a surviving mirror, where the surviving mirror is the past mirror saved on the memory of the surviving master node; Recovering the data page according to the recovery log and the surviving mirror.

3. The management method for a shared storage multi-write database cluster according to claim 2, wherein, The step of recovering the data page according to the recovery log and the surviving mirror includes: Skipping the parsing of log records before the mirror, where the log records before the mirror are the log records in the recovery log before the surviving mirror; Recovering the data page according to the log records in the recovery log after the surviving mirror and the surviving mirror.

4. The management method for a shared storage multi-write database cluster according to claim 2, wherein, When the instance running on the surviving master node is the new holder, the management method further includes: Skipping the reading and parsing of the recovery log.

5. The management method for a shared storage multi-write database cluster according to claim 2, wherein, Before the step of judging whether the surviving instance is the new holder of the write permission according to the latest migration record, the management method further includes: Skipping the parsing of log records before the migration, where the log records before the migration are the log records in the recovery log before the latest migration record.

6. The management method for a shared storage multi-write database cluster according to claim 1, wherein, When performing the step of flushing the new holding log to disk, the management method further includes: Eliminating the past image saved on the master node where the original holder is located.

7. The management method of a shared storage multi-write database cluster according to claim 1, wherein When any one of the instances becomes the new holder of the write permission, the management method further includes: Eliminating the old version of the past image saved on the master node where the new holder is located.

8. The management method of a shared storage multi-write database cluster according to claim 1, wherein When multiple master nodes have exceptions and instance recovery is performed, the management method further includes: Merging the write-ahead logs of each master node to obtain a recovery log; Redoing from the most recent checkpoint of the recovery log.

9. A machine-readable storage medium, on which a machine-executable program is stored, and when the machine-executable program is executed by a processor, it implements the management method of the shared storage multi-write database cluster according to any one of claims 1 to 8.

10. A computer device, including a memory, a processor, and a machine-executable program stored on the memory and running on the processor, and when the processor executes the machine-executable program, it implements the management method of the shared storage multi-write database cluster according to any one of claims 1 to 8.

Images