Data replication state testing method for disaster recovery database and related device
By submitting characteristic transactions to the primary database and querying the latest unique identifier of the standby database, combined with timestamps and delay models, the problem of the existing technology that cannot accurately determine the data synchronization method between the primary and standby databases is solved, and efficient disaster recovery database replication status testing is achieved.
Patent Information
- Application Number
- CN202311267499.8
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2023-09-27
- Publication Date
- 2025-10-10
- Estimated Expiration
- 2043-09-27
AI Technical Summary
The existing technology cannot accurately determine the data synchronization method between the primary database and the standby database, resulting in inaccurate determination results.
By submitting a characteristic transaction to the primary database and recording the unique identifier, the latest unique identifier of the standby database is immediately queried to determine whether it is consistent with the unique identifier of the characteristic transaction. The data synchronization delay is calculated based on the timestamp, and a delay model is used to extend the data synchronization time. Network delay is constructed or the load is increased to distinguish synchronous replication from asynchronous replication.
It achieves accurate judgment of the data replication status of the disaster recovery database, improves the accuracy and efficiency of judgment, and can distinguish between synchronous replication and asynchronous replication.
Smart Images

Figure CN117290337B_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to the technical field of databases, and in particular to a method for testing the data replication status of a disaster recovery database and related equipment. Background Art
[0002] To ensure the security of a database cluster, a primary database and a standby database are configured. The standby database, also known as a disaster recovery database, provides a backup for the primary database. Synchronous replication and asynchronous replication are two methods for synchronizing data from the primary database to the standby database. Synchronous replication involves updating the standby database's data immediately when the primary database's data changes, ensuring data consistency between the primary and standby databases. Asynchronous replication involves replicating data from the primary database to the standby database when pre-set synchronization conditions are met, such as when a set time is reached.
[0003] There are multiple master nodes in a database cluster, each of which has one or more standby databases. The data synchronization method between each master database and the corresponding standby database is synchronous replication or asynchronous replication. The existing methods for determining the data synchronization method between the master database and the corresponding standby database include:
[0004] (1) Check the configuration parameters of the database cluster. However, the actual data synchronization method between the primary database and the corresponding standby database may differ from the configuration parameters recorded in the database cluster configuration file, so the results obtained by this method may not be accurate.
[0005] (2) Check the log data of the primary and standby databases for synchronization differences using log and database-related views. However, due to the different log application mechanisms and configurations of database clusters, log refresh and log application mechanisms also vary. Therefore, this method cannot ensure that the data of the primary and standby databases are absolutely synchronized for users.
[0006] (3) Analyze the data differences between the primary and standby databases. However, there is a lack of characteristic data for this analysis. Furthermore, even with asynchronous replication, the data synchronization time consumed by asynchronous replication is in the millisecond range when there is no performance bottleneck. It is difficult for humans to distinguish between synchronous and asynchronous replication. Therefore, this method has a large error and low accuracy.
[0007] In summary, the existing technology cannot accurately determine the data synchronization method between the primary database and the corresponding standby database. Summary of the Invention
[0008] In view of the above problems, the present invention is proposed to provide a data replication status testing method and related equipment for a disaster recovery database that overcomes the above problems or at least partially solves the above problems. It can solve the problem in the prior art that it is impossible to accurately determine the data synchronization method between the primary database and the corresponding standby database, and achieve the purpose of efficiently completing the disaster recovery database replication status test.
[0009] Specifically, a first aspect of the present invention provides a method for testing the data replication status of a disaster recovery database, comprising:
[0010] Submitting a feature transaction to the master database of the database cluster and recording a unique identifier of the feature transaction;
[0011] After successfully submitting the feature transaction to the primary database, immediately querying the latest unique identifier in the standby database;
[0012] According to whether the unique identifier of the characteristic transaction is consistent with the latest unique identifier of the standby database, it is determined whether the data synchronization mode of the standby database is synchronous replication or asynchronous replication.
[0013] According to one embodiment of the present invention, when submitting a characteristic transaction to the primary database of the database cluster, the timestamp of the characteristic transaction is also recorded; when immediately querying the latest unique identifier in the standby database, the timestamp corresponding to the latest unique identifier is also queried; and
[0014] After determining whether the data synchronization mode of the standby database is synchronous replication or asynchronous replication, the method further includes:
[0015] If the data synchronization mode of the standby database is asynchronous replication, obtain the timestamp corresponding to the submission of the current feature transaction by the primary database, and calculate the delay of the data synchronization of the standby database based on the timestamp corresponding to the unique identifier in the standby database and the timestamp corresponding to the submission of the current feature transaction in the primary database.
[0016] According to one embodiment of the present invention, after submitting the feature transaction to the master database of the database cluster, the method further includes:
[0017] A delay model is adopted to extend the data synchronization time of the standby database.
[0018] According to one embodiment of the present invention, the delay model extends the data synchronization time of the standby database by constructing a network delay between the primary database and the standby database, constructing a large business pressure on the standby database, increasing the disk load, and increasing the CPU load.
[0019] According to one embodiment of the present invention, before submitting the characteristic transaction to the primary database, a communication connection with the standby database is established.
[0020] According to an embodiment of the present invention, if the database cluster includes both synchronously replicated standby databases and asynchronously replicated standby databases, when immediately querying the latest identifier in the standby database, the latest identifier in each of the standby databases is queried in parallel.
[0021] A second aspect of the present invention provides a data replication status testing device for a disaster recovery database, comprising:
[0022] A master database transaction submission module is used to submit a feature transaction to the master database of the database cluster and record the unique identifier of the feature transaction;
[0023] A standby database real-time query module, which is used to query the latest unique identifier in the standby database immediately after the characteristic transaction is successfully submitted to the primary database;
[0024] The data comparison module is used to determine whether the data synchronization mode of the standby database is synchronous replication or asynchronous replication according to whether the unique identifier of the characteristic transaction is consistent with the latest unique identifier of the standby database.
[0025] According to an embodiment of the present invention, the data replication status testing device further includes a synchronization delay amplification module, and the synchronization delay amplification module is used to extend the data synchronization time of the standby database by using a delay model.
[0026] A third aspect of the present invention provides a machine-readable storage medium having a machine executable program stored thereon. When the machine executable program is executed by a processor, the method for testing the data replication status of a disaster recovery database described in any one of the above embodiments is implemented.
[0027] The fourth aspect of the present invention provides a computer device, comprising a memory, a processor, and a machine executable program stored in the memory and running on the processor, and when the processor executes the machine executable program, it implements the data replication status testing method of the disaster recovery database described in any one of the above embodiments.
[0028] In the technical solution provided by the application, after a feature transaction is successfully submitted to a master database of a database cluster, the latest unique identifier in a standby database is immediately queried, and whether the data synchronization mode of the standby database is synchronous replication or asynchronous replication is determined according to whether the latest unique identifier is consistent with the unique identifier of the feature transaction. Since the latest unique identifier in the standby database is not updated in time when the standby database adopts asynchronous replication after the master database completes the feature transaction, and the standby database is updated in time along with the data change of the master database when the standby database adopts synchronous replication, therefore, based on the characteristics of synchronous replication and asynchronous replication, whether the data synchronization mode of the standby database is synchronous replication or asynchronous replication can be accurately determined according to whether the unique identifier of the feature transaction is consistent with the latest unique identifier of the standby database.
[0029] The above and other objects, advantages and features of the present application will become more apparent from the following detailed description of specific embodiments thereof, taken in conjunction with the accompanying drawings. BRIEF DESCRIPTION OF DRAWINGS
[0030] Some specific embodiments of the present application will be described in detail below with reference to the accompanying drawings, in an exemplary and non-limiting manner. The same reference numerals in the drawings denote the same or similar components or parts. It should be understood by those skilled in the art that the drawings are not necessarily drawn to scale. In the drawings:
[0031] Figure 1 is a schematic flow chart of a data replication state testing method of a disaster recovery database according to an embodiment of the present application;
[0032] Figure 2 is a schematic structural diagram of a data replication state testing device of a disaster recovery database according to an embodiment of the present application;
[0033] Figure 3 is a schematic structural diagram of a data replication state testing device provided with a synchronous demonstration amplification module according to an embodiment of the present application;
[0034] Figure 4 is a schematic diagram of data flow when a data replication state testing device of a disaster recovery database according to an embodiment of the present application is tested;
[0035] Figure 5 is a schematic structural diagram of a machine-readable storage medium according to an embodiment of the present application;
[0036] Figure 6 is a schematic structural diagram of a computer device according to an embodiment of the present application. DETAILED DESCRIPTION
[0037] Reference will now be made to Figures 1 to 6To describe a method for testing the data replication status of a disaster recovery database and related equipment according to an embodiment of the present invention. In the description of this embodiment, it should be understood that the terms "first" and "second" are used for descriptive purposes only, and cannot be understood as indicating or implying relative importance or implicitly indicating the number of technical features indicated. Thus, the features defined as "first" and "second" may explicitly or implicitly include at least one such feature, that is, include one or more such features. In the description of the present invention, the meaning of "plurality" is at least two, such as two, three, etc., unless otherwise clearly and specifically defined. When a feature "includes or contains" one or some of the features it covers, unless otherwise specifically described, this indicates that other features are not excluded and may further include other features.
[0038] In the description of the present embodiment, reference to the terms "one embodiment," "some embodiments," "illustrative embodiments," "example," "specific example," or "some examples" means that the specific features, structures, materials, or characteristics described in conjunction with the embodiment or example are included in at least one embodiment or example of the present invention. In this specification, the exemplary 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 any appropriate manner in any one or more embodiments or examples.
[0039] See also Figure 1 , Figure 1 The figure shows a schematic flow chart of a method for testing the data replication status of a disaster recovery database according to an embodiment of the present invention. The method is used to test the standby database to identify whether the data synchronization mode actually adopted by the standby database is synchronous replication or asynchronous replication. Figure 1 The process shown is a detailed introduction to the testing method of this embodiment.
[0040] like Figure 1 As shown, in this embodiment, the data replication status testing method of the disaster recovery database includes the following steps:
[0041] Step S1: Submit a feature transaction to the master database of the database cluster and record the unique identifier corresponding to the feature transaction, that is, the unique ID of the feature transaction;
[0042] Step S2: After the above-mentioned characteristic transaction is successfully submitted to the primary database, the latest unique identifier in the standby database is immediately queried, that is, the latest unique ID in the standby database is queried;
[0043] Step S3: According to whether the unique identifier of the characteristic transaction is consistent with the latest unique identifier of the standby database, it is determined whether the data synchronization mode of the standby database is synchronous replication or asynchronous replication.
[0044] In the above step S1, the characteristic transaction submitted to the main database is a read-write mixed transaction statement, and each time the characteristic transaction is submitted, the unique identifier of the characteristic transaction is recorded once to ensure the uniqueness of the data submitted to the main database.
[0045] In the above step S2, after the primary database receives the characteristic transaction, the primary database will process the characteristic transaction to update the data, and return a response indicating that the characteristic transaction was successfully submitted after the processing is completed. Therefore, in this embodiment, after sending the characteristic transaction to the primary database, a waiting state is entered, and after receiving the response indicating that the characteristic transaction was successfully submitted from the primary database, the latest unique identifier in the standby database is immediately queried. The latest unique identifier in the standby database refers to the corresponding unique identifier generated when the standby database receives the characteristic transaction for the most recent time. In this embodiment, after successfully submitting the above characteristic transaction to the primary database, a query statement is immediately sent to the standby database to query the latest unique identifier in the standby database. Since only the latest unique identifier in the standby database is queried, the time consumed by the query is very short, at the single-digit millisecond level.
[0046] In this embodiment, immediately querying the latest unique identifier in the standby database means that after receiving a successful submission response, no other actions are performed or waiting is performed, and a query statement is immediately sent to the standby database for query, so as to ensure the timeliness of the query to the standby database.
[0047] In step S3 above, when the standby database's data synchronization mode is synchronous replication, the standby database maintains data consistency with the primary database. However, when the standby database's data synchronization mode is asynchronous replication, the standby database will not promptly update its data, and its latest unique identifier will not be consistent with the unique identifier of the currently submitted feature transaction. Therefore, in this embodiment, when the unique identifier of the feature transaction is consistent with the standby database's latest unique identifier, the standby database's data synchronization mode is determined to be synchronous replication. When the unique identifier of the feature transaction is inconsistent with the standby database's latest unique identifier, the standby database's data synchronization mode is determined to be asynchronous replication.
[0048] In summary, in this embodiment, after a feature transaction is successfully submitted to the primary database of a database cluster, the latest unique identifier in the standby database is immediately queried. Based on whether the latest unique identifier matches the unique identifier of the feature transaction, the standby database's data synchronization method is determined to be synchronous replication or asynchronous replication. Because when a standby database uses asynchronous replication, the standby database's latest unique identifier is not updated promptly after the primary database completes the feature transaction, while when a standby database uses synchronous replication, the standby database is updated promptly as the primary database's data changes. Therefore, based on the characteristics of asynchronous replication and synchronous replication, this embodiment can accurately determine whether the standby database's data synchronization method is synchronous replication or asynchronous replication based on whether the unique identifier of the feature transaction matches the standby database's latest unique identifier.
[0049] In one embodiment of the present invention, when submitting a feature transaction to the primary database of the database cluster in the above step S1, the timestamp of submitting the feature transaction is also recorded; accordingly, when immediately querying the latest unique identifier in the standby database in step S2, the timestamp corresponding to the latest unique identifier is also queried.
[0050] After determining in the above step S3 whether the data synchronization mode of the standby database is synchronous replication or asynchronous replication, the method further includes:
[0051] If the data synchronization mode of the standby database is asynchronous replication, the timestamp of the latest unique identifier in the standby database is obtained, and the data synchronization delay of the standby database is calculated based on the timestamp and the timestamp corresponding to the characteristic transaction currently submitted by the primary database.
[0052] For example, the timestamp of the latest unique identifier in the standby database is T1, and the timestamp corresponding to the characteristic transaction currently committed by the primary database is T2. Then, the data synchronization delay of the standby database is T2-T1.
[0053] In this embodiment, the timestamp corresponding to the characteristic transaction currently submitted by the primary database refers to the timestamp when the primary database submitted the current characteristic transaction to the standby database. Through the configuration of this embodiment, when it is determined that the standby database's data synchronization mode is asynchronous replication, the standby database's data synchronization delay is also calculated, thereby further improving the effectiveness of testing the replication status of the disaster recovery database.
[0054] In one embodiment of the present invention, after submitting the characteristic transaction to the primary database of the database cluster in the above step S1, the method further includes: using a delay model to extend the data synchronization time of the standby database.
[0055] After adopting the delay model to extend the data synchronization time of the standby database, if the standby database adopts synchronous replication, the data synchronization delay of the standby database will increase, which will cause the time for the characteristic transaction to be submitted to the primary database to be longer; when the standby database adopts asynchronous replication, it will not affect the time for the characteristic transaction to be submitted to the primary database.
[0056] For example, assuming that the time required to submit a feature transaction to the primary database is 10ms without a delay model, the delay model can extend the data synchronization time of the standby database to 100ms. When the standby database uses synchronous replication for data synchronization, the primary database must synchronize the feature transaction data to the standby database before returning a response indicating the completion of the feature transaction submission. Therefore, after the delay model is set, the time required to submit a feature transaction to the primary database is 110ms. When the standby database uses asynchronous replication for data synchronization, the primary database can return a response indicating the completion of the feature transaction submission without synchronizing the feature transaction data to the standby database. Therefore, after the delay model is set, the time required to submit a feature transaction to the primary database remains 10ms.
[0057] Through the configuration of this embodiment, the data synchronization time of the standby database can be extended, thereby magnifying the difference between synchronous replication and asynchronous replication, and further improving the accuracy of the judgment of the data synchronization mode of the standby database.
[0058] In one embodiment of the present invention, the delay model extends the data synchronization time of the standby database by at least one of constructing a network delay between the primary database and the standby database, constructing a large business pressure on the standby database, increasing the disk load, and increasing the CPU load.
[0059] In one embodiment of the present invention, before submitting a feature transaction to the primary database, a communication connection with the standby database is established.
[0060] Through the setting method of this embodiment, a communication connection can be established with the standby database before submitting the feature transaction to the primary database. When a response to the successful submission of the feature transaction from the primary database is obtained, the latest unique identifier in the standby database can be immediately queried, thereby ensuring the timeliness of the query to the standby database and improving the accuracy of the judgment of the data synchronization method of the standby database.
[0061] In one embodiment of the present invention, if a database cluster includes both synchronous standby databases and asynchronous standby databases, when immediately querying the latest unique identifier in the standby database, the latest unique identifier in each standby database is queried in parallel.
[0062] If the query is performed on each standby database one by one, the timeliness of the query on each standby database cannot be ensured, and the accuracy of the determination of the data synchronization mode of the standby database is reduced. Therefore, in the embodiment, the query on each standby database is performed in parallel to ensure the timeliness of the query on the latest unique identifier in each standby database, and the accuracy of the determination of the data synchronization mode of each standby database is improved.
[0063] A data replication state testing method of a disaster recovery database corresponding to the above embodiment, Figure 2 A structural block diagram of a data replication state testing device of a disaster recovery database is shown in the application, and corresponding function modules are preset in the data replication state testing device to perform the data replication state testing method of the disaster recovery database. For the convenience of description, only the part related to the embodiment of the application is shown.
[0064] In the embodiment, the data replication state testing device of the disaster recovery database comprises:
[0065] The master library transaction submission module 101 is configured to submit a feature transaction to the master database of the database cluster and record the unique identifier corresponding to the feature transaction.
[0066] The standby library real-time query module 102 is configured to query the latest unique identifier in the standby database immediately after the submission of the feature transaction to the master database is successful.
[0067] The data comparison module 103 is configured to determine whether the data synchronization mode of the standby database is synchronous replication or asynchronous replication according to whether the unique identifier of the feature transaction is consistent with the latest unique identifier of the standby database.
[0068] In an embodiment of the application, the master library transaction submission module 101 records the timestamp of the feature transaction when submitting the feature transaction to the master database of the database cluster, and the standby library real-time query module 102 queries the timestamp corresponding to the latest unique identifier in the standby database when querying the latest unique identifier. And the data comparison module 103 is further configured to:
[0069] If the data synchronization mode of the standby database is asynchronous replication, the data synchronization delay of the standby database is calculated according to the timestamp of the feature transaction and the timestamp corresponding to the latest unique identifier of the standby database.
[0070] In an embodiment of the application, the data replication state testing device further comprises a synchronous delay amplification module 104, as shown in Figure 3 The synchronous delay amplification module is configured to:
[0071] After the master transaction submission module submits the feature transaction to the master database of the database cluster, the delay model is used to prolong the data synchronization time of the standby database.
[0072] In an embodiment of the present application, the delay model prolongs the data synchronization time of the standby database by at least one of constructing network delay between the master database and the standby database, constructing large business pressure in the standby database, increasing disk load, and increasing CPU load.
[0073] In an embodiment of the present application, the standby database real-time query module 102 establishes a communication connection with the standby database before submitting the feature transaction to the master database.
[0074] In an embodiment of the present application, if the database cluster simultaneously exists a synchronous standby database and an asynchronous standby database, when the latest identifier in the standby database is queried immediately, the standby database real-time query module 102 simultaneously queries the latest identifier in each standby database.
[0075] It should be noted that the information interaction, execution process, and the like between the above modules are based on the same concept as the method embodiments of the present application, and the specific functions and the technical effects brought by the same can be referred to the method embodiments part, which will not be described here.
[0076] As shown in the above, the data flow direction of the disaster recovery database data replication state testing device during testing is as shown in Figure 4 As shown in the above, the data flow direction of the disaster recovery database data replication state testing device during testing is as shown in When the master database submits the feature transaction to the master database, and the master database synchronizes data to the standby database, the synchronous delay amplification module 104 is used to delay the time length of data synchronization; after the master database completes the submission of the feature transaction, a response of completing the submission of the feature transaction is returned; after receiving the response of completing the submission of the feature transaction, the standby database real-time query module 102 immediately sends a query request to the standby database to obtain the latest unique identifier in the standby database; after obtaining the latest unique identifier in the standby database, the data comparison module 103 judges whether the unique identifier of the feature transaction is consistent with the latest unique identifier of the standby database; if yes, it is judged that the data synchronization mode of the standby database is synchronous replication; if not, it is judged that the data synchronization mode of the standby database is asynchronous replication, and the data synchronization delay of the standby database is calculated.
[0077] The embodiment also provides a machine readable storage medium and a computer device. Figure 5 is a schematic diagram of the machine readable storage medium 830 according to an embodiment of the present application; Figure 68 is a schematic diagram of a computer device 900 according to an embodiment of the present invention. A machine-readable storage medium 830 stores a machine-executable program 840, which, when executed by a processor, implements the data replication status testing method for a disaster recovery database according to any of the above embodiments.
[0078] The computer device 900 may include a memory 920, a processor 910, and a machine executable program 840 stored in the memory 920 and running on the processor 910, and when the processor 910 executes the machine executable program 840, it implements the data replication status testing method of the disaster recovery database of any of the above embodiments.
[0079] 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 sequenced 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, device or apparatus (such as a computer-based system, a system including a processor, or other system that can fetch instructions from an instruction execution system, device or apparatus and execute instructions), or used in combination with these instruction execution systems, devices or apparatuses.
[0080] For the purposes of this embodiment, machine-readable storage medium 830 can be any device that can contain, store, communicate, propagate, or transmit a program for use with or in conjunction with an instruction execution system, device, or apparatus. More specific examples (not an exhaustive list) of computer-readable media include: an electrical connection having one or more wires (electronic device), a portable computer disk cartridge (magnetic device), random access memory (RAM), read-only memory (ROM), erasable and programmable read-only memory (EPROM or flash memory), fiber optic devices, and portable compact disc read-only memory (CDROM). Furthermore, the machine-readable medium can even be paper or other suitable medium on which the program is printed, as the program can be obtained electronically, for example, by optically scanning the paper or other medium, followed by editing, deciphering, or otherwise processing it in a suitable manner, if necessary, and then stored in a computer memory.
[0081] 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 embodiments, multiple steps or methods can be implemented by software or firmware stored in a memory and executed by a suitable instruction execution system.
[0082] Computer device 900 may be, for example, a server, desktop computer, laptop computer, tablet computer, or smartphone. In some examples, computer device 900 may be a cloud computing node. Computer device 900 may be described in the general context of computer system-executable instructions (such as program modules) executed by a computer system. Generally, program modules may include routines, programs, object programs, components, logic, data structures, etc. that perform specific tasks or implement specific abstract data types. Computer device 900 may be implemented in a distributed cloud computing environment where tasks are performed by remote processing devices linked via a communication network. In a distributed cloud computing environment, program modules may be located on local or remote computing system storage media, including storage devices.
[0083] Computer device 900 may include a processor 910 adapted to execute stored instructions, and a memory 920 that provides temporary storage for the instructions during operation. Processor 910 may be a single-core processor, a multi-core processor, a computing cluster, or any number of other configurations. Memory 920 may include random access memory (RAM), read-only memory, flash memory, or any other suitable storage system.
[0084] The processor 910 may be connected to an I / O interface (input / output interface) suitable for connecting the computer device 900 to one or more I / O devices (input / output devices) via a system interconnect (e.g., PCI, PCI-Express, etc.). The I / O devices may include, for example, a keyboard and a pointing device, wherein the pointing device may include a touchpad or a touch screen, etc. The I / O devices may be built-in components of the computer device 900, or may be devices externally connected to the computing device.
[0085] The processor 910 may also be linked to a display interface suitable for connecting the computer device 900 to a display device via a system interconnect. The display device may include a display screen as a built-in component of the computer device 900. The display device may also include a computer monitor, television, or projector externally connected to the computer device 900. In addition, a network interface controller (NIC) may be suitable for connecting the computer device 900 to a network via a system interconnect. In some embodiments, the NIC may use any suitable interface or protocol (such as an Internet Small Computer System Interface) to transmit data. The network may be a cellular network, a radio network, a wide area network (WAN), a local area network (LAN), or the Internet, etc. Remote devices may be connected to the computing device via a network.
[0086] At this point, those skilled in the art will recognize that, although a number of exemplary embodiments of the present invention have been shown and described in detail herein, many other variations or modifications consistent with the principles of the present invention may be directly determined or derived from the disclosure 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 deemed to cover all such other variations or modifications.
Claims
1. A method for testing the data replication status of a disaster recovery database, characterized in that: include: Submitting a feature transaction to the master database of the database cluster and recording a unique identifier of the feature transaction; After the characteristic transaction is successfully submitted to the primary database, the latest unique identifier in the standby database is immediately queried. The immediate query of the latest unique identifier in the standby database means that after receiving a successful submission response, no other actions are performed and no waiting is performed, and a query statement is immediately sent to the standby database for query; determining whether the data synchronization mode of the standby database is synchronous replication or asynchronous replication according to whether the unique identifier of the characteristic transaction is consistent with the latest unique identifier of the standby database; After submitting the feature transaction to the master database of the database cluster, the method further includes: A delay model is used to extend the data synchronization time of the standby database, thereby amplifying the difference between the synchronous replication and the asynchronous replication; The delay model prolongs the data synchronization time of the standby database by constructing a network delay between the primary database and the standby database, increasing at least one of a disk load and a CPU load on the standby database.
2. The data replication status testing method according to claim 1, wherein: When submitting the characteristic transaction to the primary database of the database cluster, the timestamp of the characteristic transaction is also recorded; when immediately querying the latest unique identifier in the standby database, the timestamp corresponding to the latest unique identifier is also queried; as well as After determining whether the data synchronization mode of the standby database is synchronous replication or asynchronous replication, the method further includes: If the data synchronization mode of the standby database is asynchronous replication, obtain the timestamp corresponding to the submission of the current feature transaction by the primary database, and calculate the delay of the data synchronization of the standby database based on the timestamp corresponding to the unique identifier in the standby database and the timestamp corresponding to the submission of the current feature transaction in the primary database.
3. The data replication status testing method according to claim 1, wherein: Before submitting the characteristic transaction to the primary database, a communication connection is established with the standby database.
4. The data replication status testing method according to claim 1, wherein: If the database cluster includes both synchronously replicated standby databases and asynchronously replicated standby databases, when immediately querying the latest identifier in the standby database, the latest identifier in each of the standby databases is queried in parallel.
5. A data replication status testing device for a disaster recovery database, characterized in that: include: A master database transaction submission module is used to submit a feature transaction to the master database of the database cluster and record the unique identifier of the feature transaction; A standby database real-time query module is configured to immediately query the latest unique identifier in the standby database after the characteristic transaction is successfully submitted to the primary database. Immediately querying the latest unique identifier in the standby database means that after receiving a successful submission response, no other actions are performed and no waiting is performed, and a query statement is immediately sent to the standby database for query; a data comparison module, configured to determine whether the data synchronization mode of the standby database is synchronous replication or asynchronous replication according to whether the unique identifier of the characteristic transaction is consistent with the latest unique identifier of the standby database; The data replication status testing device also includes a synchronization delay amplification module, which is used to use a delay model to extend the data synchronization time of the standby database, thereby amplifying the difference between the synchronous replication and the asynchronous replication; the delay model extends the data synchronization time of the standby database by constructing a network delay between the primary database and the standby database, increasing the disk load on the standby database, and increasing the CPU load.
6. A machine-readable storage medium having a machine-executable program stored thereon, wherein when the machine-executable program is executed by a processor, the method for testing the data replication status of a disaster recovery database according to any one of claims 1 to 4 is implemented.
7. A computer device comprising a memory, a processor, and a machine executable program stored in the memory and running on the processor, wherein when the processor executes the machine executable program, the method for testing the data replication status of a disaster recovery database according to any one of claims 1 to 4 is implemented.
Citation Information
Patent Citations
Data replication in data storage systems
US20050091391A1
Method of providing synchronous message exchange in an asychronous operating environment
US4823304A