A method and device for sending redo logs to a standby database

By adding recovery counts when the primary server is shut down and checking consistency after restart, the problem of data loss error judgment in multi-instance database systems is solved to ensure data consistency between the primary and secondary servers.

CN114328021BActive Publication Date: 2024-12-27CETC JINCANG (BEIJING) TECH CO LTD
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202111633423.3
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Filing Date
2021-12-29
Publication Date
2024-12-27
Estimated Expiration
2041-12-29

AI Technical Summary

Technical Problem

In a multi-instance database system, if data is lost when the primary database instance is closed abnormally, the backup server will mistakenly believe that there is no data loss because it has received the consistency mark before, resulting in data inconsistency and loss problems.

Method used

When the primary server is shut down, add recovery counts in the last redo log that is not synchronized, and check recovery count consistency when sending a new redo log after restart to ensure data integrity.

Benefits of technology

Through the recovery counting mechanism, we can accurately judge whether the data is lost, avoid misjudgment, ensure the data consistency of the redo logs between the main and standby servers, and prevent data loss.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN114328021B_ABST
    Figure CN114328021B_ABST
Patent Text Reader

Abstract

The present disclosure relates to a method and device for sending a redo log to a standby database, wherein the method comprises: when detecting that the first master instance in the main server is shut down, adding a first recovery count to the last redo log that has not been synchronized to the standby server and sending it to the first standby instance of the standby server, after obtaining that the first master instance is shut down, the second master instance in the main server generates a second recovery count and sends it to the second standby instance of the standby server. The first and second standby redo logs are associated with the first and second recovery counts, respectively. When the first master instance in the main server is restarted and starts working, when the first master instance sends the newly generated redo log to the first standby instance, the standby server checks whether the first recovery count of the first standby redo log and the second recovery count of the second standby redo log are the same. If they are the same, it is determined that there is no loss in the first standby redo log, which can ensure the consistency of the redo log data between the main server and the standby server and avoid data loss.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The present disclosure relates to the technical field of multi-instance databases, and in particular to a method and device for sending a redo log to a standby database. Background Art

[0002] Usually in a multi-instance database system, if the primary database instance 1 fails, there are two situations: first, the primary database instance 1 successfully sends all redo logs to the standby database instance 1 before shutdown; second, the primary database instance 1 loses redo logs when sending redo logs to the standby database instance 1 before shutdown. In the first case, the data of the standby server is consistent with that of the primary server, but in the second case, due to the loss of redo logs, the standby server is inconsistent with the primary server, and there is a problem of data loss.

[0003] In the related art, before the main database instance 1 is closed, a consistency mark is added to the last redo log message sent to the standby server. If the standby server receives this consistency mark, it indicates that the main database instance 1 has sent all redo logs to the standby server before the abnormal shutdown. Otherwise, the standby server believes that all redo logs have not been successfully copied to the standby server when the main database instance 1 is abnormally closed, and takes corresponding measures.

[0004] However, if the primary database instance 1 successfully copied the redo log to the standby server before the first abnormal shutdown, that is, the standby server received the consistency mark, but the primary database instance 1 was abnormally shut down again when it resent the redo log after recovery, and there was data loss before this abnormal shutdown, and when the primary database instance 1 recovered again and sent the redo log to the standby server, the standby server would mistakenly believe that there was no data loss because it had received the consistency mark before. Summary of the invention

[0005] In order to solve the above technical problem, the present disclosure provides a method and device for sending a redo log to a standby database.

[0006] In a first aspect, an embodiment of the present disclosure provides a method for sending a redo log to a standby database, including:

[0007] When it is detected that the first primary instance in the primary server is shut down, a first recovery count is added to the last redo log that the first primary instance has not synchronized to the standby server and sent to the first standby instance of the standby server; wherein the first primary instance and the first standby instance correspond one to one;

[0008] After the first standby instance receives the first recovery count, the first standby redo log is associated with the first recovery count;

[0009] After obtaining the shutdown status information of the first master instance, the second master instance in the master server generates a second recovery count and sends it to the second standby instance of the standby server; wherein the second master instance and the second standby instance correspond one to one;

[0010] After the second standby instance receives the second recovery count, the second standby redo log is associated with the second recovery count;

[0011] When the first master instance in the master server is restarted and starts working, when the first master instance sends the newly generated redo log to the first standby instance, the standby server checks that the first recovery count of the first standby redo log is the same as the second recovery count of the second standby redo log, and determines that the first standby redo log is not lost.

[0012] In a second aspect, an embodiment of the present disclosure provides a device for sending a redo log to a standby database, including:

[0013] A detection module, configured to, when detecting that a first primary instance in a primary server is shut down, add a first recovery count to the last redo log that the first primary instance has not synchronized to the standby server, and send the first recovery count to the first standby instance of the standby server, wherein the first primary instance and the first standby instance correspond to each other one by one;

[0014] A first associating module, configured to associate the first standby redo log with the first recovery count after the first standby instance receives the first recovery count;

[0015] A first sending module, configured for the second master instance in the master server to generate a second recovery count and send the second recovery count to the second standby instance of the standby server after acquiring the shutdown status information of the first master instance; wherein the second master instance and the second standby instance correspond one to one;

[0016] A second associating module, configured to associate the second standby redo log with the second recovery count after the second standby instance receives the second recovery count;

[0017] The first confirmation module is used for, when the first master instance in the master server is restarted and starts working, when the first master instance sends the generated new redo log to the first standby instance, the standby server checks that the first recovery count of the first standby redo log is the same as the second recovery count of the second standby redo log, and determines that the first standby redo log is not lost.

[0018] In a third aspect, an embodiment of the present disclosure provides a device for sending a redo log to a standby database, including:

[0019] a processor, a memory for storing instructions executable by the processor;

[0020] The processor is used to read executable instructions from the memory and execute the instructions to implement a method for sending a redo log to a standby database as described in the foregoing embodiment of the present disclosure.

[0021] In a fourth aspect, an embodiment of the present disclosure provides a medium for sending a redo log to a standby database, including:

[0022] The storage medium stores a computer program, and the computer program is used to execute the method of sending the redo log to the standby database described in the foregoing embodiment of the present disclosure.

[0023] Compared with the prior art, the technical solution provided by the embodiments of the present disclosure has the following advantages:

[0024] In the embodiment of the present disclosure, when it is detected that the first master instance in the main server is shut down, a first recovery count is added to the last redo log that has not been synchronized to the standby server and sent to the first standby instance of the standby server. After the first standby instance receives the first recovery count, the first standby redo log and the first recovery count are associated. After the second master instance in the main server obtains the shutdown status information of the first master instance, it generates a second recovery count and sends it to the second standby instance of the standby server. After the second standby instance receives the second recovery count, the second standby redo log is associated with the second recovery count. When the first master instance in the main server is restarted and starts working, the first master instance sends the generated new redo log to the first standby instance. The standby server checks that the first recovery count of the first standby redo log is the same as the second recovery count of the second standby redo log, and determines that the first standby redo log is not lost, thereby ensuring the consistency of the redo log data between the main server and the standby server and avoiding data loss. BRIEF DESCRIPTION OF THE DRAWINGS

[0025] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present disclosure and, together with the description, serve to explain the principles of the present disclosure.

[0026] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, for ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative labor.

[0027] Figure 1 A flowchart of a method for sending a redo log to a standby database provided in an embodiment of the present disclosure;

[0028] Figure 2 A schematic diagram of a method for sending a redo log to a standby database provided in an embodiment of the present disclosure;

[0029] Figure 3 A schematic diagram of another method for sending a redo log to a standby database provided in an embodiment of the present disclosure;

[0030] Figure 4 A schematic diagram of the structure of another method for sending a redo log to a standby database provided in an embodiment of the present disclosure;

[0031] Figure 5 A schematic diagram of the structure of another method for sending a redo log to a standby database provided in an embodiment of the present disclosure;

[0032] Figure 6 A flowchart of another method for sending a redo log to a standby database provided in an embodiment of the present disclosure;

[0033] Figure 7 A schematic diagram of a device structure for sending a redo log to a standby database provided in an embodiment of the present disclosure;

[0034] Figure 8 A schematic diagram of the structure of an electronic device provided in an embodiment of the present disclosure. DETAILED DESCRIPTION

[0035] In order to more clearly understand the above-mentioned objectives, features and advantages of the present disclosure, the scheme of the present disclosure will be further described below. It should be noted that the embodiments of the present disclosure and the features in the embodiments can be combined with each other without conflict.

[0036] In the following description, many specific details are set forth to facilitate a full understanding of the present disclosure, but the present disclosure may also be implemented in other ways different from those described herein; it is obvious that the embodiments in the specification are only part of the embodiments of the present disclosure, rather than all of the embodiments.

[0037] Figure 1 A flow chart of a method for sending a redo log to a standby database provided in an embodiment of the present disclosure includes:

[0038] Step 101: When it is detected that the first primary instance in the primary server is shut down, a first recovery count is added to the last redo log that the first primary instance has not synchronized to the standby server and sent to the first standby instance of the standby server.

[0039] Among them, an instance refers to a series of processes in the operating system and the memory blocks allocated to these processes. In other words, an instance is a program, which is a layer of data management software located between the user and the operating system. Any operation performed by the user on the data in the database, such as data definition, data query, data maintenance, database operation control, etc., is performed under the database instance. The application can only communicate with the database through the database instance; the recovery count refers to the number of times the instance in the main database is abnormally recovered.

[0040] In the embodiment of the present disclosure, there can be many instances in the primary server. In the embodiment of the present disclosure, each instance corresponds to an initial recovery count, such as count0, which is stored in the shared storage space. Assuming that before the first primary instance is closed, the recovery count is the initial recovery count count0, then before the first primary instance is closed, the redo log that has not been copied to the standby server will be synchronized to the standby server, and the first recovery count count1 will be added to the last log. At this time, the first recovery count count1=count0+1.

[0041] Specifically, Figure 2 As shown, in the first primary instance of the primary server, the redo record 1 and redo record 2 data in the redo log buffer are written into the redo log file 1, and then the redo record 1 is asynchronously copied to the first standby instance, and a confirmation character 1 is returned. Then, the redo record 2 is added with the first recovery count count1 and asynchronously copied to the first standby instance, and a confirmation character 2 is returned. Finally, in the redo log buffer area of ​​the first standby instance of the standby server, the received redo record 1 and the redo record 2 with the first recovery count count1 added are written into the redo log file 2.

[0042] Optionally, if logs are lost, the first recovery count count1 may not be sent to the first standby instance. Figure 3 and Figure 4 As shown, Figure 3 In the example, the first primary instance in the primary server asynchronously replicates redo record 1 to the first standby instance, but redo record 2 with the first recovery count count1 added is lost, resulting in the first recovery count count1 being unable to be sent to the first standby instance; Figure 4 In the example, the redo record 1 of the first primary instance of the primary server and the redo record 2 to which the first recovery count count1 is added are both lost, which also causes the first recovery count count1 to be unable to be sent to the first standby instance.

[0043] It should be noted that there is a one-to-one correspondence between the first primary instance and the first backup instance.

[0044] Step 102: After the first standby instance receives the first recovery count, the first standby redo log is associated with the first recovery count.

[0045] The redo log is used to record information about database modifications, such as modifications made by users to the database and modifications made by database administrators to the database structure, to ensure that the database can be restored in conjunction with the database backup file when a database failure occurs.

[0046] In the embodiment of the present disclosure, after the first standby instance of the standby server receives the first recovery count count1 sent by the primary server, the first standby redo log is associated with the first recovery count count1.

[0047] Step 103: After obtaining the shutdown status information of the first master instance, the second master instance in the master server generates a second recovery count and sends it to the second standby instance of the standby server.

[0048] In the embodiment of the present disclosure, the instances in the primary server can communicate with each other. For example, if the second primary instance does not receive a message sent by the first primary instance within a preset time period or the second primary instance does not receive a confirmation message after sending a message to the first primary instance, the first primary instance is confirmed to be closed. After the second primary instance in the primary server receives the shutdown information of the first primary instance, it generates a second recovery count count2 and sends it to the second standby instance of the standby server. Continuing with the above example, the initial recovery count is count0, and the second recovery count count2 at this time is count0+1. Specifically, Figure 5 As shown, the recovery counter 2 is increased in the second master instance of the master server, and count2 is placed in the shared storage space so that other master instances can know the updated recovery count, and then the second recovery count count2 is asynchronously copied to the second standby instance of the standby server.

[0049] It should be noted that there is a one-to-one correspondence between the second primary instance and the second backup instance.

[0050] Step 104: After receiving the second recovery count, the second standby instance associates the second standby redo log with the second recovery count.

[0051] In the embodiment of the present disclosure, after the second standby instance of the standby server receives the second recovery count count2 sent by the primary server, the second standby redo log is associated with the second recovery count count2.

[0052] Step 105: After the first master instance in the master server is restarted and starts working, when the first master instance sends the generated new redo log to the first standby instance, the standby server checks that the first recovery count of the first standby redo log is the same as the second recovery count of the second standby redo log, and determines that the first standby redo log is not lost.

[0053] In the embodiment of the present disclosure, after the second master instance sends a request to the master server to start the first master instance, the master server restarts the first master instance, and a new redo log is generated after the first master instance is started. At this time, when the first master instance sends the new redo log to the first standby instance, the standby server has already recognized the sending failure of the first master instance, and checks whether the first recovery count of the first standby redo log and the second recovery count of the second standby redo log are the same. If they are the same, it is determined that the first standby redo log is not lost, and the first standby instance can directly roll forward the existing available redo log.

[0054] Optionally, if the standby server checks that the first recovery count of the first standby redo log and the second recovery count of the second standby redo log are different, it is determined that the redo log is lost when the first primary instance is shut down, and a notification message is generated and sent to the target device in a preset manner. In other words, the user or database administrator needs to be prompted to take action to avoid data loss.

[0055] In a scheme for sending a redo log to a standby database provided in an embodiment of the present disclosure, when it is detected that a first master instance in a master server is shut down, a first recovery count is added to the last redo log that has not been synchronized to the standby server and sent to the first standby instance of the standby server. After the first standby instance receives the first recovery count, the first standby redo log is associated with the first recovery count. After receiving shutdown status information of the first master instance, the second master instance in the master server generates a second recovery count and sends it to the second standby instance of the standby server. After the second standby instance receives the second recovery count, the second standby redo log is associated with the second recovery count. When the first master instance in the master server is restarted and starts working, when the first master instance sends the newly generated redo log to the first standby instance, the standby server checks that the first recovery count of the first standby redo log is the same as the second recovery count of the second standby redo log, and determines that the first standby redo log is not lost. By adding an abnormal recovery count mechanism, each time the first master instance in the master server is abnormal, the recovery count will be increased, and then by comparing the first recovery count of the first master instance with the second recovery count of the second master instance, it is accurately determined whether there is data loss. If a data loss problem occurs, the user or administrator can be notified in time to intervene and handle it to ensure the normal operation of the data.

[0056] In some embodiments, the second master instance sends the second recovery count to the shared storage space, with the purpose of enabling other master instances to know the updated recovery count and thus determine whether there is data loss.

[0057] In some other embodiments, an initial recovery count is obtained from a shared storage space, and a preset count step is added to the initial recovery count to obtain a first recovery count / a second recovery count.

[0058] Specifically, assuming that the initial recovery count is A and the preset counting step is B, the first recovery count / the second recovery count is A+B.

[0059] In some other embodiments, the second master instance sends a request to start the first master instance to the master server, and after receiving the request to start the first master instance, the master server controls the first master instance to restart.

[0060] Figure 6 A flowchart of another method for sending a redo log to a standby database provided in an embodiment of the present disclosure includes:

[0061] When it is detected that the first master instance of the main server is shut down, the logs that have not been synchronized to the standby server by the first master instance are sent to the first standby instance of the standby server, and the first recovery count is added to the last redo log. After the first standby instance receives the first recovery count, it associates the first standby redo log with the first recovery count, and then increases the counter of the second master instance of the main server. At this time, the recovery count is the second recovery count, and then the second recovery count of the second master instance is put into the shared space. At this time, other master instances can know the updated recovery count.

[0062] Furthermore, the second primary instance sends the second recovery count to the standby server. After receiving the second recovery count, the second standby instance in the standby server associates the second standby redo log with the second recovery count, and then sends a request to the primary server to start the first primary instance. Subsequently, the primary server restarts the first primary instance. After the first primary instance is started, a new redo log is generated. When the new redo log of the first primary instance is copied to the first standby instance, the standby server has already identified that the first primary instance has failed. At this time, it is checked whether the recovery count of the first standby instance and the recovery count of the second standby instance are the same. If they are the same, it means that a redo log is lost when the first primary instance is shut down. At this time, it is necessary to notify the user or administrator to intervene. Otherwise, it means that no redo log is lost when the first primary instance is shut down, and the first standby instance can directly roll forward the existing available redo log.

[0063] Figure 7A schematic diagram of a device structure for sending a redo log to a standby database provided in an embodiment of the present disclosure includes: a detection module 701, a first association module 702, a first sending module 703, a second association module 704, and a first confirmation module 705, wherein:

[0064] The detection module 701 is used to detect that the first primary instance in the primary server is shut down, add a first recovery count to the last redo log that the first primary instance has not synchronized to the standby server, and send the log to the first standby instance of the standby server; wherein the first primary instance and the first standby instance correspond to each other one by one;

[0065] A first associating module 702 is configured to associate the first standby redo log with the first recovery count after the first standby instance receives the first recovery count;

[0066] A first sending module 703 is used for the second master instance in the master server to generate a second recovery count and send it to the second standby instance of the standby server after acquiring the shutdown status information of the first master instance; wherein the second master instance and the second standby instance have a one-to-one correspondence;

[0067] A second associating module 704 is configured to associate the second standby redo log with the second recovery count after the second standby instance receives the second recovery count;

[0068] The first confirmation module 705 is used for when the first master instance in the master server is restarted and starts working, when the first master instance sends the newly generated redo log to the first standby instance, the standby server checks that the first recovery count of the first standby redo log is the same as the second recovery count of the second standby redo log, and determines that the first standby redo log is not lost.

[0069] Optionally, the device further comprises:

[0070] The second confirmation module is used for the standby server to check if the first recovery count of the first standby redo log and the second recovery count of the second standby redo log are different, then it is determined that the redo log is lost when the first primary instance is shut down, and a notification message is generated and sent to the target device in a preset manner.

[0071] Optionally, the device further comprises:

[0072] The second sending module is used for the second master instance to send the second recovery count to the shared storage space.

[0073] Optionally, the device further comprises:

[0074] A first acquisition module, used for acquiring an initial recovery count from a shared storage space;

[0075] The second acquisition module is used to add the preset counting step length to the initial recovery count to obtain the first recovery count / the second recovery count.

[0076] Optionally, the device further comprises:

[0077] A third sending module, used for the second master instance to send a request to start the first master instance to the master server;

[0078] The control module is used for the main server to control the first main instance to restart after receiving the request to start the first main instance.

[0079] Figure 8 A schematic diagram of the structure of an electronic device provided in an embodiment of the present disclosure.

[0080] The following specific reference Figure 8 , which shows a schematic diagram of the structure of an electronic device 800 suitable for implementing the embodiment of the present disclosure. The electronic device 800 in the embodiment of the present disclosure may include, but is not limited to, mobile terminals such as mobile phones, notebook computers, digital broadcast receivers, PDAs (personal digital assistants), PADs (tablet computers), PMPs (portable multimedia players), vehicle-mounted terminals (such as vehicle-mounted navigation terminals), etc., and fixed terminals such as digital TVs, desktop computers, etc. Figure 8 The electronic device shown is only an example and should not bring any limitation to the functions and scope of use of the embodiments of the present disclosure.

[0081] like Figure 8 As shown, the electronic device 800 may include a processing device (e.g., a central processing unit, a graphics processing unit, etc.) 801, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 802 or a program loaded from a storage device 808 into a random access memory (RAM) 803. In the RAM 803, various programs and data required for the operation of the electronic device 800 are also stored. The processing device 801, the ROM 802, and the RAM 803 are connected to each other via a bus 804. An input / output (I / O) interface 805 is also connected to the bus 804.

[0082] Typically, the following devices may be connected to the I / O interface 805: input devices 806 including, for example, a touch screen, a touch pad, a keyboard, a mouse, a camera, a microphone, an accelerometer, a gyroscope, etc.; output devices 807 including, for example, a liquid crystal display (LCD), a speaker, a vibrator, etc.; storage devices 808 including, for example, a magnetic tape, a hard disk, etc.; and communication devices 809. The communication device 809 may allow the electronic device 800 to communicate with other devices wirelessly or by wire to exchange data. Although Figure 8The electronic device 800 is shown with various devices, but it should be understood that it is not required to implement or possess all the devices shown. More or fewer devices may be implemented or possessed instead.

[0083] In particular, according to an embodiment of the present disclosure, the process described above with reference to the flowchart can be implemented as a computer software program. For example, an embodiment of the present disclosure includes a computer program product, which includes a computer program carried on a non-transitory computer-readable medium, and the computer program contains program code for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from the network through the communication device 809, or installed from the storage device 808, or installed from the ROM 802. When the computer program is executed by the processing device 801, the above-mentioned functions defined in the method for generating traffic detection rules in the embodiment of the present disclosure are executed.

[0084] It should be noted that the computer-readable medium disclosed above may be a computer-readable signal medium or a computer-readable storage medium or any combination of the above two. The computer-readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or device, or any combination of the above. More specific examples of computer-readable storage media may include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In the present disclosure, a computer-readable storage medium may be any tangible medium containing or storing a program that may be used by or in combination with an instruction execution system, device or device. In the present disclosure, a computer-readable signal medium may include a data signal propagated in a baseband or as part of a carrier wave, in which a computer-readable program code is carried. This propagated data signal may take a variety of forms, including but not limited to an electromagnetic signal, an optical signal, or any suitable combination of the above. The computer readable signal medium may also be any computer readable medium other than a computer readable storage medium, which may send, propagate or transmit a program for use by or in conjunction with an instruction execution system, apparatus or device. The program code contained on the computer readable medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (radio frequency), etc., or any suitable combination of the above.

[0085] In some embodiments, the client and server may communicate using any currently known or future developed network protocol such as HTTP, and may be interconnected with any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include a local area network ("LAN"), a wide area network ("WAN"), an internet (e.g., the Internet), and a peer-to-peer network (e.g., an ad hoc peer-to-peer network), as well as any currently known or future developed network.

[0086] The computer-readable medium may be included in the electronic device, or may exist independently without being incorporated into the electronic device.

[0087] The computer-readable medium carries one or more programs. When the one or more programs are executed by the electronic device, the electronic device: when detecting that the first master instance in the main server is shut down, adds a first recovery count to the log that the first master instance has not synchronized to the standby server and sends it to the first standby instance of the standby server; after the first standby instance receives the first recovery count, associates the first standby redo log with the first recovery count; after receiving the shutdown information of the first master instance, the second master instance in the main server generates a second recovery count and sends it to the second standby instance of the standby server; after the second standby instance receives the second recovery count, associates the second standby redo log with the second recovery count; after detecting that the first master instance in the main server is restarted, when the first master instance sends a new redo log to the first standby instance, the standby server checks that the first recovery count of the first standby redo log is the same as the second recovery count of the second standby redo log, and then determines that the first standby redo log is not lost.

[0088] Computer program code for performing the operations of the present disclosure may be written in one or more programming languages ​​or a combination thereof, including, but not limited to, object-oriented programming languages, such as Java, Smalltalk, C++, and conventional procedural programming languages, such as "C" or similar programming languages. The program code may be executed entirely on the user's computer, partially on the user's computer, as a separate software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving a remote computer, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., through the Internet using an Internet service provider).

[0089] It should be noted that, in this article, relational terms such as "first" and "second" are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "include", "comprise" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, the elements defined by the sentence "comprise a ..." do not exclude the existence of other identical elements in the process, method, article or device including the elements.

[0090] The above description is only a specific embodiment of the present disclosure, so that those skilled in the art can understand or implement the present disclosure. Various modifications to these embodiments will be apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the present disclosure. Therefore, the present disclosure will not be limited to the embodiments described herein, but will conform to the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A method for sending a redo log to a standby database, characterized in that: include: When it is detected that the first primary instance in the primary server is shut down, a first recovery count is added to the last redo log that the first primary instance has not synchronized to the standby server and sent to the first standby instance of the standby server; wherein the first primary instance and the first standby instance correspond one to one; After the first standby instance receives the first recovery count, associating the first standby redo log with the first recovery count; After acquiring the shutdown status information of the first master instance, the second master instance in the master server generates a second recovery count and sends it to the second standby instance of the standby server; wherein the second master instance and the second standby instance correspond one to one; After the second standby instance receives the second recovery count, associating the second standby redo log with the second recovery count; When the first master instance in the master server is restarted and starts working, when the first master instance sends the newly generated redo log to the first standby instance, the standby server checks that the first recovery count of the first standby redo log is the same as the second recovery count of the second standby redo log, and determines that the first standby redo log is not lost.

2. The method for sending redo logs to a standby database according to claim 1, characterized in that: Also includes: The standby server checks that the first recovery count of the first standby redo log and the second recovery count of the second standby redo log are different, determines that the redo log is lost when the first primary instance is shut down, generates a notification message and sends it to the target device in a preset manner.

3. The method for sending redo logs to a standby database according to claim 1, characterized in that: Also includes: The second master instance sends the second recovery count to the shared storage space.

4. The method for sending redo logs to a standby database according to claim 1, characterized in that: Generating the first recovery count / the second recovery count includes: Get the initial restore count from shared storage; A preset counting step is added to the initial recovery count to obtain the first recovery count / the second recovery count.

5. The method for sending redo logs to a standby database according to claim 1, characterized in that: Also includes: The second master instance sends a request to the master server to start the first master instance; After receiving the request to start the first master instance, the master server controls the first master instance to restart.

6. A device for sending redo logs to a standby database, characterized in that: include: A detection module, configured to, when detecting that a first primary instance in a primary server is shut down, add a first recovery count to the last redo log that the first primary instance has not synchronized to the standby server, and send the first recovery count to the first standby instance of the standby server; wherein the first primary instance and the first standby instance correspond one to one; A first associating module, configured to associate a first standby redo log with the first recovery count after the first standby instance receives the first recovery count; A first sending module, configured for the second master instance in the master server to generate a second recovery count and send the second recovery count to the second standby instance of the standby server after acquiring the shutdown status information of the first master instance; wherein the second master instance and the second standby instance correspond one to one; A second associating module, configured to associate a second standby redo log with the second recovery count after the second standby instance receives the second recovery count; The first confirmation module is used for, when the first master instance in the master server is restarted and starts working, when the first master instance sends the generated new redo log to the first standby instance, the standby server checks that the first recovery count of the first standby redo log is the same as the second recovery count of the second standby redo log, and then determines that the first standby redo log is not lost.

7. The device for sending redo logs to a standby database according to claim 6, characterized in that: Also includes: The second confirmation module is used for the standby server to check if the first recovery count of the first standby redo log and the second recovery count of the second standby redo log are different, then determine that the redo log is lost when the first primary instance is closed, and generate a notification message to be sent to the target device in a preset manner.

8. The device for sending redo logs to a standby database according to claim 6, characterized in that: Also includes: A second sending module is configured to send the second restoration count by the second master instance to the shared storage space.

9. An electronic device, characterized in that: The electronic device comprises: processor; a memory for storing instructions executable by the processor; The processor is used to read the executable instructions from the memory and execute the instructions to implement the method for sending redo logs to a standby database as described in any one of claims 1 to 5.

10. A computer-readable storage medium, characterized in that: The storage medium stores a computer program, and the computer program is used to execute the method for sending a redo log to a standby database as described in any one of claims 1 to 5.