Database backup machine access method, device and system

Abstract

The present invention discloses a method, device, and system for accessing a database backup machine, belonging to the field of database technology. The method includes: sending a redo log from a first device to a second device, and detecting whether a response message from the second device has been received; if a response message from the second device has been received, writing the modified data corresponding to the redo log to a first data file; after the first and second devices perform a master-slave switch, adjusting the largest LSN in the first data file to be consistent with the largest LSN in the first log file; sending an access request to the second device; and, based on the access request, connecting the first device as a backup machine to the second device. The present invention solves the technical problem in the related art of the original host being unable to access the new host after a master-slave switch.

Description

Technical Field

[0001] The present invention relates to the field of database technology, and in particular to a method, device and system for accessing a backup database machine. Background Art

[0002] To ensure high availability, relational databases employ a master-slave replication mechanism. When user modifications are processed on the primary server, resulting in data changes, the replication mechanism transmits these modifications to the backup server in the form of logs. The backup server then needs to synchronize and replay the master logs. Synchronizing the master logs involves the backup server's receiving thread receiving the master logs and persisting them to local files. Replaying the master logs involves the replay thread reading the synchronization logs and executing the operations recorded in the logs on the backup server. This effectively re-executes the modifications on the backup server consistent with the master's data, ensuring data consistency on the backup server.

[0003] When redo logs are used to record modifications to database data, they are typically identified by an LSN (log sequence number). The LSN is a numerical value that increases gradually as logs are written. In the actual master-slave replication setup, the standby server typically lags behind the master server, resulting in a delay between the master and standby servers. In related art, when using redo logs for master-slave replication, after the master server flushes the redo logs to its redo files, it directly writes the modified data in the buffer to the master server's data files. Therefore, the LSN on the master server will be larger than the LSN on the standby server, meaning the master server's data files will contain more modifications than the standby server's. Consequently, after a master-slave switchover, the standby server (original master) will be unable to connect to the master server (original standby) because the data files on the current standby server (original master) contain modifications not present on the new master server (original standby).

[0004] In the related art, in current relational databases, in the above situation, only manual repair methods can be used, and rapid automatic access cannot be achieved.

[0005] Currently, no effective solutions have been found for the above-mentioned problems existing in the related technologies. Summary of the Invention

[0006] The present invention provides a method, device and system for accessing a database backup machine to solve the technical problem in related technologies that an original host cannot access a new host after a primary-backup switch.

[0007] According to one aspect of an embodiment of the present application, a method for accessing a database standby machine is provided, the method being applied to a first device, the first device being connected to a second device, comprising: sending a redo log in the first device to the second device, and detecting whether a response message fed back by the second device is received, the response message comprising a logical sequence number LSN of the redo log in the second log file, for instructing the second device to refresh the redo log to the second log file, wherein the first device is a host machine, the second device is a standby machine, and the second log file is used to store redo logs in ascending order on the second device; if a response message fed back by the second device is received, the modified data corresponding to the redo log is written to the disk of the first data file. component; after the first device and the second device perform active-standby switching, adjust the maximum LSN in the first data file and the maximum LSN in the first log file to be consistent, the first data file is a data file in the disk of the first database on the first device, and the first log file is used to store redo logs in ascending order on the first device; send an access request to the second device, the access request includes the maximum LSN in the first data file and the first redo log history file, the first redo log history file is used to record the database identifier of the redo log and the LSN of the first redo log stored in the database corresponding to the database identifier; according to the access request, connect the first device as a standby device to the second device.

[0008] Furthermore, after connecting the first device as a backup device to the second device, the method also includes: receiving a synchronization log sent by the second device, and determining whether the synchronization log carries a database identifier; if the synchronization log carries a database identifier, parsing the synchronization log to obtain a first database identifier corresponding to the synchronization log and a first LSN corresponding to the synchronization log; obtaining the last historical record in the first redo log history file, and obtaining a second database identifier corresponding to the last historical record; determining whether the first database identifier is the same as the second database identifier; if the first database identifier is different from the second database identifier, adding the first database identifier and the first LSN to the last historical record.

[0009] Furthermore, if response information is received from the second device, writing the modified data corresponding to the redo log to the disk of the first data file includes: if response information is received from multiple second devices, searching for the largest LSN in the response information of the multiple second devices; determining the redo log corresponding to the largest LSN in the first log file, and writing the modified data corresponding to the redo log to the disk of the first data file.

[0010] Furthermore, adjusting the maximum LSN in the first data file to be consistent with the maximum LSN in the first log file includes: obtaining the LSN on each data page in the first data file, recording the second largest LSN among all data pages; converting the second LSN into an offset position in the first log file; clearing the redo log after the offset position, so that the maximum LSN in the first data file is adjusted to be consistent with the maximum LSN in the first log file.

[0011] According to another aspect of an embodiment of the present application, a method for accessing a database standby machine is provided, which is applied to a second device, the second device being connected to a first device, and includes: receiving a redo log sent by the first device; after refreshing the redo log to a second log file, sending a response message to the first device, the response message including a logical sequence number LSN of the redo log in the second log file, for instructing the second device to refresh the redo log to the second log file, wherein the first device is a host machine and the second device is a standby machine; after the first device and the second device perform a master-slave switching, obtaining an access request sent by the first device; parsing the first redo log history file in the access request, and obtaining the second redo log history file corresponding to the second device; if the modification set in the first redo log history file is a subset of the modification set in the second redo log history file, connecting the first device to the second device as a standby machine.

[0012] Furthermore, the second device includes multiple devices, and the master-slave switching between the first device and the second device includes: if the first device fails, selecting a target device with the largest LSN from multiple second devices and using the target device as the new master; connecting the first device to the target device as a backup device, and connecting the devices in the second device other than the target device to the target device as backup devices.

[0013] Furthermore, connecting devices other than the target device in the second device as backup devices to the target device includes: obtaining master and backup configuration information of devices other than the target device in the second device; and modifying the host configuration in the master and backup configuration information to the target device.

[0014] According to another aspect of the embodiment of the present application, there is also provided an access device for a database standby machine, which is applied to a first device and includes: an interaction module for sending the redo log generated by the first device to the second device, and detecting whether a response information fed back by the second device is received, the response information including the logical sequence number LSN of the redo log in the second log file, for instructing the second device to refresh the redo log to the second log file, wherein the first device is a host, the second device is a standby machine, and the second log file is used to store the redo log in ascending order on the second device; a disk write module for writing the modified data corresponding to the redo log to the first data file if a response information fed back by the second device is received; an adjustment module for After the first device and the second device perform master-slave switching, the maximum LSN in the first data file and the maximum LSN in the first log file are adjusted to be consistent, the first data file is a data file in the disk of the first database on the first device, and the first log file is used to store redo logs in ascending order on the first device; a sending module is used to send an access request to the second device, the access request includes the maximum LSN in the first data file and the first redo log history file, the first redo log history file is used to record the database identifier of the redo log and the LSN of the first redo log stored in the database corresponding to the database identifier; the access module is used to connect the first device as a backup device to the second device according to the access request.

[0015] Furthermore, the access device of the database standby machine includes: a recording module, used to receive the synchronization log sent by the second device, and determine whether the synchronization log carries a database identifier; if the synchronization log carries a database identifier, parse the synchronization log to obtain the first database identifier corresponding to the synchronization log and the first LSN corresponding to the synchronization log; obtain the last historical record in the first redo log history file, and obtain the second database identifier corresponding to the last historical record; determine whether the first database identifier is the same as the second database identifier; if the first database identifier is different from the second database identifier, add the first database identifier and the first LSN to the last historical record.

[0016] Furthermore, the disk placement module includes a first disk placement unit, which is used to find the largest LSN in the response information of the multiple second devices if response information is received from multiple second devices; determine the redo log corresponding to the largest LSN in the first log file, and place the modified data corresponding to the redo log on the disk to the first data file.

[0017] Furthermore, the adjustment module includes a first adjustment unit, which is used to obtain the LSN on each data page in the first data file and record the largest second LSN among all data pages; convert the second LSN into an offset position in the first log file; clear the redo log after the offset position, so that the maximum LSN in the first data file is adjusted to be consistent with the maximum LSN in the first log file.

[0018] According to another aspect of an embodiment of the present application, there is also provided an access device for a database standby machine, which is applied to a second device and includes: a receiving module for receiving a redo log sent by the first device; a sending module for sending a response message to the first device after refreshing the redo log to a second log file, the response message including the logical sequence number LSN of the redo log in the second log file, for instructing the second device to refresh the redo log to the second log file, wherein the first device is a host and the second device is a standby machine; an acquisition module for acquiring an access request sent by the first device after the first device and the second device perform a master-slave switching; a parsing module for parsing the first redo log history file in the access request and acquiring the second redo log history file corresponding to the second device; a judgment module for connecting the first device as a standby machine to the second device if the modification set in the first redo log history file is a subset of the modification set in the second redo log history file.

[0019] The acquisition module includes a first acquisition unit, which is used to select a target device with the largest LSN from multiple second devices and use the target device as a new host if the first device fails; connect the first device to the target device as a backup device, and connect the devices in the second device other than the target device to the target device as backup devices.

[0020] The first acquisition unit is further configured to acquire master / slave configuration information of devices other than the target device in the second device; and modify the host configuration in the master / slave configuration information to the target device.

[0021] According to another aspect of an embodiment of the present application, a database backup machine access system is also provided, which includes a first device and a second device, wherein the first device is connected to the second device and includes the apparatus as applied to the first device as described above; the second device includes the apparatus as applied to the second device as described above.

[0022] Through the present invention, a delayed flushing method is adopted. After the master-slave switch, the modification amount corresponding to the data page that has been written to disk on the first device (as the backup machine) is less than or equal to the second device (as the current master), and the redo log and data page on the first device are consistent. That is, the modification record of the redo log on the first device is applied to the data page, and based on the redo log history record, the set of modification records of different databases included in the first device is compared with the second device. The set of redo log history records on the first device is a subset of the second device. Based on this, it can be avoided to a certain extent that the machine to be connected as a backup machine contains modifications that are not on the new master. This embodiment can make the backup machine to be connected reach a state where it can connect to the master in a relatively short time. The traditional method is to use the backup and recovery function of the database to restore the backup machine node to a certain historical state or the latest state of the master. The recovery speed is slow and not easy to program. It is more likely to require manual intervention. However, the operation process of this embodiment is simple and easy to implement. When the difference between the master and backup machines is not large, both can be successfully connected, reducing manual intervention. BRIEF DESCRIPTION OF THE DRAWINGS

[0023] The drawings described herein are used to provide a further understanding of the present invention and constitute a part of this application. The exemplary embodiments of the present invention and their descriptions are used to explain the present invention and do not constitute an improper limitation of the present invention. In the drawings:

[0024] Figure 1 This is a hardware structure block diagram of a computer according to an embodiment of the present invention;

[0025] Figure 2 This is a flow chart of a method for accessing a database standby machine according to an embodiment of the present invention;

[0026] Figure 3 is a flowchart of another method for accessing a database standby machine according to an embodiment of the present invention;

[0027] Figure 4 Schematic diagram of the master-slave replication process in the first scenario of an embodiment of the present invention;

[0028] Figure 5 Schematic diagram of the master-slave replication process in the second scenario of an embodiment of the present invention;

[0029] Figure 6 Schematic diagram of the database initialization and host startup process according to an embodiment of the present invention;

[0030] Figure 7 This is a schematic diagram of the startup and playback process on a database standby machine according to an embodiment of the present invention;

[0031] Figure 8 1 is a flow chart of the execution of the normal delayed dirty flushing according to an embodiment of the present invention;

[0032] Figure 9 This is a flow chart of an embodiment of the present invention in which a host computer with abnormally delayed dirty flushing does not receive a response from a standby computer;

[0033] Figure 10 This is a schematic diagram of a process for performing master-slave replication on multiple backup machines according to an embodiment of the present invention;

[0034] Figure 11 This is a structural block diagram of an access device for a database backup machine according to an embodiment of the present invention;

[0035] Figure 12 This is a structural block diagram of another access device for a database standby machine according to an embodiment of the present invention. DETAILED DESCRIPTION

[0036] In order to enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are only embodiments of a part of the present application, not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without making creative work should fall within the scope of protection of this application. It should be noted that, in the absence of conflict, the embodiments in the present application and the features in the embodiments can be combined with each other.

[0037] It should be noted that the terms "first", "second", etc. in the specification and claims of the present application and the above-mentioned drawings are used to distinguish similar objects and are not necessarily used to describe a specific order or sequential order. It should be understood that the data used in this way can be interchangeable where appropriate, so that the embodiments of the present application described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having" and any of their variations are intended to cover non-exclusive inclusions, for example, a process, method, product or device comprising a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0038] Example 1

[0039] The method embodiment provided in the first embodiment of the present application can be executed on a mobile phone, computer, tablet or similar computing device. Taking running on a computer as an example, Figure 1 This is a hardware structure diagram of a computer according to an embodiment of the present invention. Figure 1 As shown, the computer may include one or more ( Figure 1Only one is shown in the figure) processor 102 (processor 102 may include but is not limited to a microprocessor MCU or a programmable logic device FPGA and other processing devices) and a memory 104 for storing data. Optionally, the above computer may also include a transmission device 106 and an input and output device 108 for communication functions. It will be understood by those skilled in the art that Figure 1 The structure shown is only for illustration and does not limit the structure of the above-mentioned computer. Figure 1 More or fewer components than shown, or with Figure 1 Different configurations shown.

[0040] Memory 104 can be used to store computer programs, such as software programs and modules of application software, such as the computer program corresponding to a method for identifying motion-stillness ratio in a video according to an embodiment of the present invention. Processor 102 executes the computer program stored in memory 104 to perform various functional applications and data processing, thereby implementing the aforementioned method. Memory 104 may include high-speed random access memory (RAM) and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some examples, memory 104 may further include memory remotely located relative to processor 102, and such remote memory may be connected to the computer via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0041] The transmission device 106 is used to receive or send data via a network. A specific example of the aforementioned network may include a wireless network provided by a computer's communications provider. In one embodiment, the transmission device 106 includes a network interface controller (NIC), which can be connected to other network devices via a base station to enable communication with the Internet. In another embodiment, the transmission device 106 may be a radio frequency (RF) module, which is used to communicate with the Internet wirelessly.

[0042] In this embodiment, a method for accessing a database backup machine is provided, which is applied to a first device. Figure 2 Flowchart of a method for accessing a database standby machine according to an embodiment of the present invention. Figure 2 As shown, the process includes the following steps:

[0043] Step S10: Send the redo log generated by the first device to the second device, and detect whether a response message fed back by the second device is received, wherein the response message includes a logical sequence number (LSN) of the redo log in the second log file, which is used to instruct the second device to flush the redo log to the second log file, wherein the first device is a master device, the second device is a slave device, and the second log file is used to store the redo log in ascending order on the second device;

[0044] The first device (database host A) and the second device (database standby host B) are in a normal master-slave relationship. When the first device, acting as the database host, processes services, it records a historical record of the redo log on the first device. Specifically, the record records the starting number of the LSN and the database identifier of the first device when data is modified on the first device, that is, the identifier of the first database and the LSN of the first redo log generated by the data modification on database host A. The first database is the database corresponding to the first device. The redo log that appears later in this embodiment is the redo log, and redohistory is the historical record of the redo log. When synchronizing the redo log of a first device to a second device, the second device records the redo history on the first device based on the database identifier carried in the redo log. The first device then detects whether it has received a response from the second device. The response includes the logical sequence number (LSN) of the redo log in the second log file. The response instructs the second device to flush the redo log to the second log file. The second log file is used to store the redo log in ascending order on the second device. The LSN (log sequence number) occupies 8 bytes in the InnoDB storage engine. The LSN value gradually increases as the log is written.

[0045] Step S20: If the response information fed back by the second device is received, the modified data corresponding to the redo log is written to the disk to the first data file.

[0046] If the first device receives the response information fed back by the second device, it means that the second device has backed up the current redo log. In this embodiment, after the redo log is written to the disk (i.e., refreshed to the first log file), the first device does not immediately write the modified data of the redo log to the disk. Instead, it waits until the first device receives the response information sent by the second device before writing the modified data corresponding to the redo log to the first data file. As long as the second device receives the redo log and writes the redo log to the second log file, it can replay the redo log and write the modified data of the redo log to the second data file. Figure 8 The execution process of normal delayed flushing is as follows: the (database) DB host processes business, modifies data in the buffer, generates a redo log, writes the redo log to the host's corresponding log file, and sends the redo log to the DB standby machine. The DB standby machine receives the redo log and writes the redo log to the standby machine's corresponding log file. After the disk is completed, the DB standby machine sends a response message with the location of the redo log's LSN. The DB host writes the modified data in the buffer corresponding to the response LSN to the host's data file. After writing the redo log to the standby machine's corresponding log file, the DB standby machine can replay the redo log. In the related art: after the DB host redo log is refreshed to the first log file, the modified data in the buffer is written to the disk. Due to the master-slave delay, the amount of modification written to the data file by the DB host may be greater than that of the DB standby, resulting in the DB host as the standby being unable to access the DB standby as the master after the master-slave switch. In this embodiment, after the redo log is completed, the first device does not immediately write the modified data of the redo log to the disk (that is, refreshed to the first log file), but waits until the first device receives the response information sent by the second device before writing the modified data corresponding to the redo log to the first data file. Since the second device can replay the redo log and write the redo log to the second log file as soon as it receives the redo log and writes the redo log to the second data file, it can achieve that when the first device switches to the standby to access the second device as the master, the amount of modification corresponding to the data page that the first device has written to the data file is less than or equal to that of the second device.

[0047] refer to Figure 4The first device is serverA, which serves as the master, and the second device is serverB, which serves as the backup. The corresponding modification operation in the redo log redo_1a is to change data1 to data2. After the redo log (redo_2a) on serverA is transferred to serverB and written to disk on serverB (that is, redo_2a is written to the second log file), ServerA must receive a response from serverB confirming that "redo_2a" has been written to disk. Only then will serverA perform the corresponding modification in the redo_2a log: changing data2 to data3. Figure 4 In the scenario where serverA has not yet received the response from serverB that "redo_2a has been flushed to disk", the data modifications made by redo_2a on serverA have not yet been flushed to disk. ServerA continues to process user business and generates a redo log (redo_3a). Because the data modifications made by redo_2a have not been flushed to disk, the data modifications made by redo_3a will not be flushed to disk either.

[0048] Step S30: After the first device and the second device perform a master-slave switch, the maximum LSN in the first data file is adjusted to be consistent with the maximum LSN in the first log file, where the first data file is a data file on a disk of the first database on the first device, and the first log file is used to store redo logs in ascending order on the first device.

[0049] The first device (database host A) and the second device (database standby device B) are in a normal master-slave relationship. If the first device (host A) fails and stops, the second device will be switched to the master to continue processing user services and generate redo logs on the second device B. After the failure of the first device is repaired, the first device will be reconnected to the second device as a standby device, which is a master-slave switch. Figure 5 , serverB node switches to the host, and then there may be user services to access (i.e. read and write) the database on serverB, combined with the above Figure 4In this example, server A fails and stops. Server B becomes the master, continuing to process user traffic. A redo log (redo_3b) is generated on server B. Server A reconnects to server B and scans the records in the first data file of the first device (server A). Since server A did not receive the response from server B indicating that "redo_2a has been flushed to disk," server A's first data file does not contain the changes corresponding to redo_2a. This means that server A's redo log (redo_2a) has not been applied to the data, while the previous redo log has been applied. After the master-slave switchover, the changes corresponding to the data pages flushed to disk on the first standby server are less than or equal to those on the second master server. At this point, the maximum LSN in the first data file is aligned with the maximum LSN in the first log file. For example, redo_2a and all subsequent redo logs (such as redo_3a in the figure above) are deleted from the redo log file. At this point, the data on server A and the redo log are completely consistent.

[0050] Further, adjusting the maximum LSN in the first data file to be consistent with the maximum LSN in the first log file includes:

[0051] Step A, obtaining the LSN on each data page in the first data file, and recording the largest second LSN among all data pages;

[0052] Step B: converting the second LSN into an offset position in the first log file;

[0053] Step C: Clear the redo log after the offset position to adjust the maximum LSN in the first data file to be consistent with the maximum LSN in the first log file.

[0054] Obtain all data pages in the first data file, scan all data pages (Page), extract the corresponding LSN from each page, and output the largest LSN among them, that is, find the largest LSN from the data page. Calculate the offset position of the second LSN in the first log file based on the second LSN, and clear the redo log after the offset position in the first log file based on the offset position. You can also reset the relevant fields in the redo log after the offset position. The purpose of both operations is to identify the redo log after the offset position as invalid redo log when reading and writing redo logs subsequently, that is, clear the redo log records after the specified LSN, clean up redundant redo logs, and adjust the maximum LSN in the first data file to be consistent with the maximum LSN in the first log file.

[0055] Step S40: Send an access request to the second device, the access request including the largest LSN in the first data file and a first redo log history file, the first redo log history file being used to record a database identifier of the redo log and the LSN of the first redo log stored in the database corresponding to the database identifier;

[0056] Step S50: According to the access request, the first device is connected to the second device as a backup device.

[0057] Start the first device with the backup configuration and execute the command to establish the master-slave relationship. This process will send an access request (redo log dump request) to the current host, i.e., the second device. The access request contains the largest LSN in the first data file, i.e., the redo log synchronization point required by the first device, and the first redo log history file. The first redo log history file is used to record the database identifier of the redo log and the LSN of the first redo log stored in the database corresponding to the database identifier. According to the access request, the first device is connected to the second device as a backup machine.

[0058] Redo log history: records the history of redo logs generated on the database. Each record in the history consists of two parts: the database identifier (server UUID is used as the identifier below) and the starting LSN when the data was modified. For example, the following three lines constitute a redo history:

[0059] Server uuid1,1;

[0060] Server uuid2,200;

[0061] Server uuid3,300 indicates that the database modification consists of three parts, including three redo history records: LSNs 1 to 199 were modified on the database corresponding to server uuid1, LSNs 200 to 299 were modified on the database corresponding to server uuid2, and the redo log from LSN 300 to the current one was modified on the database corresponding to server uuid3.

[0062] In this embodiment, by delaying dirty flushing, after the master-slave switch, the modifications corresponding to the data pages already written to disk on the first device (serving as the backup) are ensured to be less than or equal to those on the second device (serving as the current master), and the redo logs and data pages on the first device are made consistent. Specifically, the modification records in the redo logs on the first device are applied to the data pages. Based on the redo log history, the set of modification records for different databases included in the first device is compared with that on the second device. The set of redo log history records on the first device is a subset of the set on the second device. This, to a certain extent, prevents the situation where the backup machine to be connected contains modifications not present on the new master. This embodiment allows the backup machine to be connected to the master in a relatively short period of time. Traditionally, the backup machine to be connected relies on the database's backup and recovery function to restore the backup node to a certain historical or latest state of the master. This recovery is slow and not easily programmable, and is more likely to require manual intervention. However, this embodiment has a simple operation process and is easy to program. When the difference between the primary and backup machines is not large, successful connection is achieved, reducing manual intervention.

[0063] In one implementation of this embodiment, after the first device is connected to the second device as a standby device, the method further includes:

[0064] Step D: receiving the synchronization log sent by the second device, and determining whether the synchronization log carries a database identifier;

[0065] Step E: If the synchronization log carries a database identifier, parse the synchronization log to obtain a first database identifier corresponding to the synchronization log and a first LSN corresponding to the synchronization log;

[0066] Step F, obtaining the last historical record in the first redo log history file, and obtaining a second database identifier corresponding to the last historical record;

[0067] Step G, determining whether the first database identifier is the same as the second database identifier;

[0068] Step H: If the first database identifier is different from the second database identifier, then add the first database identifier and the first LSN to the end of the last historical record.

[0069] After the first device is successfully connected to the second device as a backup device, the first device receives the synchronization log sent by the second device. The synchronization log is the log after the largest LSN in the first data file in the access request, that is, the second device synchronizes the same day after the largest LSN to the first device, and the first device determines whether the synchronization log carries a database identifier; if the synchronization log carries a database identifier, it means that this synchronization log is the first redo log stored in the database corresponding to the carried database identifier. At this time, the synchronization log is parsed to obtain the first database identifier and the first LSN corresponding to the synchronization log, and the first database identifier and the first LSN are added to the first redo log history file. Specifically, the last historical record in the first redo log history file is obtained, and the second database identifier corresponding to the last historical record is obtained. It is determined whether the first database identifier and the second database identifier are the same. If the first database identifier and the second database identifier are different, the first database identifier and the first LSN are added after the last historical record.

[0070] This embodiment briefly describes the database initialization and host startup process, as well as the startup and playback process on the database standby machine:

[0071] Database initialization and host startup process: refer to Figure 6During database initialization, a first redo log (SERVER_UUID_LOG) is generated. This log contains the database identifier (server UUID) of the current first database and the LSN (the starting point of the redo log) where the first redo log is located. This database identifier and LSN pair constitutes a redo history record, indicating that all subsequently generated redo logs are generated from the current server UUID. This server UUID and LSN pair is also recorded in the redo log history file (redo history file). When the database host starts, the redo history file is read and loaded into memory. Before the host generates any redo logs, it checks whether the current server UUID is the same as the server UUID and LSN corresponding to the last redo history record in the in-memory redo history file. If they are not, a second redo log is generated, containing the server UUID of the current second database and the LSN of the current second log. The server UUID of the second database and the LSN of the second log are added to the redo history information in the in-memory redo history file in an end-append manner. If they are the same, no redo history is generated.

[0072] Startup and playback process on the DB standby machine: Reference Figure 7 When the DB standby server starts, it reads the redo history file and loads it into memory. The standby server does not generate a redo log of the SERVER_UUID_LOG type because it does not generate its own redo logs but only replays the redo logs transmitted from the primary server. When the DB standby server encounters a redo history record (i.e., a redo log of the SERVER_UUID_LOG type) while replaying the redo logs, it parses the target server uuid and target LSN of the record. It then determines whether the parsed target server uuid is the same as the server uuid in the last server uuid and LSN data pair in the redo history information in memory. If they are not the same, the target server uuid and target LSN data pair is written to the redo history information in memory by appending them to the end. If they are the same, no redo history is generated.

[0073] In another implementation of this embodiment, upon receiving the response information fed back by the second device, writing the modified data corresponding to the redo log to the first data file includes:

[0074] Step I: if response information fed back by multiple second devices is received, searching for the largest LSN in the response information of the multiple second devices;

[0075] Step J: Determine the redo log corresponding to the largest LSN in the first log file, and write the modified data corresponding to the redo log to the first data file.

[0076] If there are multiple second devices, that is, if there are multiple backup machines performing master-slave replication with the master, if response information is received from multiple second devices, the largest LSN in the response information of the multiple second devices is found, the redo log corresponding to the largest LSN in the first log file is determined, and the modified data corresponding to the redo log is written to the disk of the first data file. For reference, Figure 10 , the first device is the DB host, and the second device includes DB standby 1 and DB standby 2. The host sends the redo log to standby 1 and standby 2, and receives the position of the response LSN sent by standby 1 and standby 2, then the host writes the modified data in the buffer corresponding to the maximum response LSN to the disk. Under normal circumstances: the corresponding data modifications are written to the disk according to the maximum response LSN received by the first device. Under abnormal circumstances: in the first scenario, if there are several standby machines disconnected among multiple standby machines, the maximum response LSN sent to the host by the standby machine (one or more) that is normally connected is obtained to write the data modifications to the disk. In the second scenario, if all standby machines are disconnected, the host directly writes the current redo log to the data file, that is, the host will no longer wait for the standby machine, that is, it will not perform delayed flushing, but will directly flush. In the third scenario, the maximum response LSN value received by the master from the standby machine lags far behind the LSN of the latest redo log written to the log file on the master. This indicates that the data on all standby machines may lag behind the master, causing the standby machine to synchronize from an older redo log LSN. In this case, the master directly writes the current redo log to the data file, that is, adopting the "LSN interval threshold method". In this case, the master no longer waits for the standby machine, that is, does not perform delayed flushing, but flushes directly.

[0077] Reference Figure 9In this embodiment, the delayed flushing process may experience anomalies. After detecting whether a response message from the second device has been received, the method further includes: if no response message from the second device is received within a preset time, writing the modified data corresponding to the redo log to the first data file. If the master sends a redo log to the backup server but does not receive a response from the backup server for a long time, the master will no longer wait for the backup server, that is, will not perform a delayed flushing, but will directly flush the data. Specifically, a time threshold is set; when the master waits for longer than this threshold, a direct flushing is performed.

[0078] After detecting whether the response information fed back by the second device has been received, the method further includes: if the response information fed back by the second device is received, obtaining the LSN in the response information and obtaining the current maximum LSN in the first log file; calculating the difference between the LSN in the response information and the current maximum LSN, and comparing the difference with a preset LSN interval threshold; if the difference is greater than the preset LSN interval threshold, writing the modified data corresponding to the redo log to the first data file. The value of the standby response LSN received by the host is far behind the LSN of the latest redo log written to the disk on the host. It may be that the data on the DB standby has lagged behind the host, causing the DB standby to need to synchronize from an older redo log LSN. The difference between the value of the standby response LSN received by the host and the LSN of the latest redo log written to the disk on the host is compared with the LSN interval threshold. If it is greater, the host will no longer wait for the standby, that is, will not perform a delayed flush, but will directly flush. After the standby catches up with the host, the delayed flush function on the host is restored.

[0079] In this embodiment, a method for accessing a database backup machine is provided. Figure 3 Flowchart of a method for accessing a database standby machine according to an embodiment of the present invention. Figure 3 As shown, the database standby machine access method of this embodiment is applied to the second device, and the second device is connected to the first device. The process includes the following steps:

[0080] Step S60: receiving the redo log sent by the first device;

[0081] Step S70: After flushing the redo log to the second log file, a response message is sent to the first device, where the response message includes the logical sequence number (LSN) of the redo log in the second log file, instructing the second device to flush the redo log to the second log file. The first device is a master device, and the second device is a slave device.

[0082] Step S80: After the first device and the second device perform active / standby switching, obtain an access request sent by the first device;

[0083] Step S90: parsing the first redo log history file in the access request and obtaining a second redo log history file corresponding to the second device;

[0084] Step S100: If the modification set in the first redo log history file is a subset of the modification set in the second redo log history file, the first device is connected to the second device as a standby device.

[0085] The second device receives the redo log sent by the first device as a backup machine, and after refreshing the redo log to the second log file, sends a response message to the first device. The response message includes the logical sequence number LSN of the redo log in the second log file, which is used to instruct the second device to refresh the redo log to the second log file. After the first device and the second device perform the master-slave switch, the second device switches to the host. There may be user business to access (i.e., read and write) the database on the second device. The second device switches to the host to continue processing user business and generate redo logs on the second device. After the first device fault is repaired, the first device accesses the second device as a backup machine, and the second device obtains the access request sent by the first device and parses the access request. The first redo log history file is obtained, and the second redo log history file corresponding to the second device is obtained. The second device performs calculations based on the first redo log history file and the second redo log history file to determine whether the modification set in the first redo log history file is a subset of the modification set of the second redo log history file. If the modification set in the first redo log history file is a subset of the modification set of the second redo log history file, it means that the modifications in the first device are less than those in the second device. In this case, the first device is connected to the second device as a backup device. That is, after the master-slave switching, the situation where the first device to be connected as a backup device contains modifications that are not on the new host than the second device of the new host, resulting in inability to connect, can be avoided to a certain extent.

[0086] In a database HA (High availability) environment, this embodiment addresses the problem of a node being unable to access the main machine as a backup machine due to having more data than the main machine. This embodiment proposes using historical records of the redo log and a delayed flushing mechanism to resolve the inability to access the main machine, allowing the backup node to be connected to reach a state where it can access the main machine in a very short time. The traditional method is to use the backup and recovery function of the database to restore the backup node to a certain historical state or the latest state of the main machine. The recovery speed is slow and not easy to program, and manual intervention is more likely to be required. The operation process is simple and easy to implement. When the difference between the main and backup machines is not too large, successful access can be achieved, reducing manual intervention.

[0087] In this embodiment, the second device includes a plurality of devices, and the master-slave switching between the first device and the second device includes:

[0088] Step K: If the first device fails, select a target device with the largest LSN from the multiple second devices and use the target device as a new host;

[0089] Step L: connect the first device as a backup device to the target device, and connect the devices other than the target device in the second device as backup devices to the target device.

[0090] During the process of the first device as the host and the second device as the backup device establishing a master-slave connection, the first device fails and stops. At this time, a target device needs to be selected from multiple second devices as the new host to handle the business. At this time, the target device with the largest LSN in the log files corresponding to all second devices is selected as the new host. The largest LSN in the log file indicates that the corresponding second device includes the most modifications. The first device is connected to the target device as a backup device, and the devices in the second device except the target device are connected to the target device as backup devices.

[0091] Assume that the first device, A, serves as the DB master, and the second devices, B1, B2, ..., Bn, serve as DB backups. In this scenario with one master and multiple backups, the master-slave switchover process is as follows: Master A and the backups (B1, B2, ..., Bn) are in a normal master-slave relationship and are both operational. Master A's node stops due to a fault. The backup node with the largest redo LSN is selected from nodes B1-Bn and becomes the new master, assumed to be Bm. User services may then access (read and write) the database on node Bm. The original master (i.e., the DB of host A's node) is connected to the new master (i.e., node Bm) as a backup. All nodes from B1-Bn, except Bm, are connected to node Bm as backups.

[0092] The process of the original host A connecting to the new host Bm as a backup machine includes: after the original host A and the original backup machine Bm perform master-slave switching, adjusting the largest LSN in the first data file and the largest LSN in the first log file to be consistent; sending an access request to Bm; and according to the access request, connecting the first device as a backup machine to the second device.

[0093] Connecting the devices other than the target device in the second device to the target device as backup devices includes: obtaining the master-slave configuration information of the devices other than the target device in the second device; and modifying the master configuration in the master-slave configuration information to the target device. The process of connecting the nodes B1 to Bn other than Bm to the Bm node as backup devices includes: closing the master-slave synchronization; modifying the master-slave relationship, configuring the master to be Bm; and starting the master-slave synchronization. During the process of starting the master-slave synchronization, an abnormal situation may occur: when selecting the node with the largest redo lsn from the nodes B1 to Bn, Bj in B1 to Bn processes a fault state (such as a network failure or power outage and restart, etc.), which may cause the redo lsn of the selected node Bm to be the largest except for Bj. In fact, the redo lsn of Bj is the largest. After Bj resolves the fault, the process for Bj to connect to host Bm is as follows: (1) Disable master-slave synchronization; (2) Modify the master-slave relationship and configure Bm as the master; (3) Start master-slave synchronization: (3.1) Start Bj node with the backup configuration and execute the command to establish master-slave. This process will send a redo log dump request to the master (i.e., Bm node). The request contains: Lsn: the redo log synchronization point required by the backup and Redo history: the redo history on the backup; (3.2) Bm node checks whether access is allowed based on the redo history in the dump request: In the case of normal delayed flushing, the check passes and a "allowed access" response is sent to Bj node; In the case of abnormal delayed flushing, the check is likely to fail. Node A will not be able to connect to node B and needs to be restored through backup and recovery, first restoring node A and then connecting to node B. Through the above steps, this solution enables the master-slave relationship to be quickly rebuilt when a failure occurs between the database master and backup servers, ensuring HA (High availability).

[0094] Through the description of the above embodiments, those skilled in the art can clearly understand that the method according to the above embodiment can be implemented by means of software plus the necessary general hardware platform, and of course it can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of the present invention is essentially or the part that contributes to the prior art can be embodied in the form of a software product, which is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk), and includes a number of instructions for enabling a terminal device (which can be a mobile phone, computer, server, or network device, etc.) to execute the methods described in each embodiment of the present invention.

[0095] Example 2

[0096] This embodiment also provides a database backup machine access device for implementing the five examples and preferred embodiments described above. Details already described will not be repeated. As used below, the term "module" may refer to a combination of software and / or hardware that implements a predetermined function. Although the devices described in the following embodiments are preferably implemented in software, implementation using hardware, or a combination of software and hardware, is also possible and contemplated.

[0097] Figure 11 is a structural block diagram of an access device for a database standby machine according to an embodiment of the present invention. Figure 11 As shown, the device includes: an interaction module 10, a disk placement module 20, an adjustment module 30, a sending module 40, and an access module 50, wherein:

[0098] The interaction module 10 is used to send the redo log generated by the first device to the second device, and detect whether the response information fed back by the second device is received, the response information including the redo log generated by the first device

[0099] a logical sequence number (LSN) of the log in the second log file, used to instruct the second device to flush the redo log to the second log file, wherein the first device is a master device, the second device is a slave device, and the second log file is used to store the redo log in ascending order on the second device;

[0100] The disk write module 20 is configured to write the modified data corresponding to the redo log to the first data file upon receiving the response information fed back by the second device;

[0101] an adjustment module 30, configured to adjust the maximum LSN in the first data file to be consistent with the maximum LSN in the first log file after the first device and the second device perform a master / slave switch, the first data file being a data file on a disk of the first database on the first device, and the first log file being used to store redo logs in ascending order on the first device;

[0102] a sending module 40 configured to send an access request to the second device, the access request including the largest LSN in the first data file and a first redo log history file, the first redo log history file being configured to record a database identifier of the redo log and the LSN of a first redo log entry stored in a database corresponding to the database identifier;

[0103] The access module 50 is configured to connect the first device as a backup device to the second device according to the access request.

[0104] Optionally, the access device of the database standby machine includes: a recording module, used to receive the synchronization log sent by the second device, and determine whether the synchronization log carries a database identifier; if the synchronization log carries a database identifier, parse the synchronization log to obtain the first database identifier corresponding to the synchronization log and the first LSN corresponding to the synchronization log; obtain the last historical record in the first redo log history file, and obtain the second database identifier corresponding to the last historical record; determine whether the first database identifier is the same as the second database identifier; if the first database identifier is different from the second database identifier, add the first database identifier and the first LSN to the last historical record.

[0105] Optionally, the disk placement module includes a first disk placement unit, which is used to search for the largest LSN in the response information of the multiple second devices if response information is received from the multiple second devices; determine the redo log corresponding to the largest LSN in the first log file, and place the modified data corresponding to the redo log on the disk to the first data file.

[0106] Optionally, the adjustment module includes a first adjustment unit, which is used to obtain the LSN on each data page in the first data file and record the largest second LSN among all data pages; convert the second LSN into an offset position in the first log file; and clear the redo log after the offset position so that the maximum LSN in the first data file is adjusted to be consistent with the maximum LSN in the first log file.

[0107] Figure 12 is a structural block diagram of another database standby machine access device according to an embodiment of the present invention. Figure 12 As shown, the device includes: a receiving module 60, a sending module 70, an acquisition module 80, a parsing module 90, and a judgment module 100, wherein:

[0108] A receiving module 60, configured to receive the redo log sent by the first device;

[0109] a sending module 70 configured to send a response message to the first device after flushing the redo log to the second log file, the response message including a logical sequence number (LSN) of the redo log in the second log file, for instructing the second device to flush the redo log to the second log file, wherein the first device is a master device and the second device is a slave device;

[0110] An acquisition module 80 is configured to acquire an access request sent by the first device after the first device and the second device perform active / standby switching;

[0111] a parsing module 90 configured to parse the first redo log history file in the access request and obtain a second redo log history file corresponding to the second device;

[0112] The judgment module 100 is configured to connect the first device as a standby device to the second device if the modification set in the first redo log history file is a subset of the modification set in the second redo log history file.

[0113] It should be noted that the above modules can be implemented through software or hardware. For the latter, it can be implemented in the following ways, but not limited to: the above modules are all located in the same processor; or the above modules are located in different processors in any combination.

[0114] Example 3

[0115] An embodiment of the present invention also provides an access system for a database standby machine, which includes a first device and a second device, wherein the first device is connected to the second device and includes the apparatus as applied to the first device as described above; the second device includes the apparatus as applied to the second device as described above.

[0116] The serial numbers of the above-mentioned embodiments of the present application are for description only and do not represent the advantages or disadvantages of the embodiments.

[0117] In the above embodiments of the present application, the description of each embodiment has its own focus. For parts that are not described in detail in a certain embodiment, please refer to the relevant description of other embodiments.

[0118] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. Among them, the device embodiments described above are only schematic. For example, the division of the units is only a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of units or modules, which can be electrical or other forms.

[0119] The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of these units may be selected to achieve the purpose of this embodiment according to actual needs.

[0120] In addition, the functional units in the various embodiments of the present application may be integrated into a single processing unit, or each unit may exist physically separately, or two or more units may be integrated into a single unit. The aforementioned integrated units may be implemented in the form of hardware or software functional units.

[0121] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application is essentially or the part that contributes to the prior art or all or part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including a number of instructions for enabling a computer device (which can be a personal computer, a server or a network device, etc.) to execute all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: various media that can store program codes, such as a USB flash drive, a read-only memory (ROM), a random access memory (RAM), a mobile hard disk, a magnetic disk or an optical disk.

[0122] The above is only a preferred embodiment of the present application. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principles of the present application. These improvements and modifications should also be regarded as the scope of protection of the present application.

Claims

1. A method for accessing a backup database server, characterized in that: The method is applied to a first device, where the first device is connected to a second device, and includes: Sending the redo log in the first device to the second device, and detecting whether a response message fed back by the second device is received, the response message including the logical sequence number (LSN) of the redo log in the second log file, which is used to instruct the second device to flush the redo log to the second log file, wherein the first device is a master device and the second device is a slave device, and the second log file is used to store the redo log in ascending order on the second device; If a response message fed back by the second device is received, writing the modified data corresponding to the redo log to the first data file; After the first device and the second device perform a master-slave switch, adjusting the maximum LSN in the first data file to be consistent with the maximum LSN in the first log file, where the first data file is a data file on a disk of the first database on the first device, and the first log file is used to store redo logs in ascending order on the first device; Sending an access request to the second device, the access request including the largest LSN in the first data file and a first redo log history file, the first redo log history file being used to record a database identifier of a redo log and an LSN of a first redo log stored in a database corresponding to the database identifier; According to the access request, the first device is connected to the second device as a backup device.

2. The method according to claim 1, characterized in that After connecting the first device as a standby device to the second device, the method further includes: receiving a synchronization log sent by the second device, and determining whether the synchronization log carries a database identifier; If the synchronization log carries a database identifier, parsing the synchronization log to obtain a first database identifier corresponding to the synchronization log and a first LSN corresponding to the synchronization log; Obtain the last historical record in the first redo log history file, and obtain a second database identifier corresponding to the last historical record; Determining whether the first database identifier is the same as the second database identifier; If the first database identifier is different from the second database identifier, the first database identifier and the first LSN are added after the last historical record.

3. The method according to claim 1, characterized in that If the response information fed back by the second device is received, writing the modified data corresponding to the redo log to the first data file includes: If response information fed back by multiple second devices is received, searching for the largest LSN in the response information of the multiple second devices; A redo log corresponding to the largest LSN in the first log file is determined, and modified data corresponding to the redo log is written to the first data file.

4. The method according to claim 1, wherein Adjusting the maximum LSN in the first data file to be consistent with the maximum LSN in the first log file includes: Obtain the LSN on each data page in the first data file, and record the largest second LSN among all data pages; Convert the second LSN into an offset position in the first log file; The redo log after the offset position is cleared, so that the maximum LSN in the first data file is adjusted to be consistent with the maximum LSN in the first log file.

5. A method for accessing a database backup machine, characterized in that: The method is applied to a second device, where the second device is connected to the first device, and includes: receiving a redo log sent by the first device; After flushing the redo log to the second log file, sending a response message to the first device, the response message including the logical sequence number (LSN) of the redo log in the second log file, for instructing the second device to flush the redo log to the second log file, wherein the first device is a master device and the second device is a slave device; After the first device and the second device perform a master-slave switch, obtaining an access request sent by the first device, the access request including: a maximum LSN in a first data file and a first redo log history file, the first redo log history file being used to record a database identifier of a redo log and an LSN of a first redo log stored in a database corresponding to the database identifier, and adjusting the maximum LSN in the first data file and the maximum LSN in the first log file to be consistent, the first data file being a data file in a disk of a first database on the first device; Parsing the first redo log history file in the access request and obtaining a second redo log history file corresponding to the second device; If the modification set in the first redo log history file is a subset of the modification set in the second redo log history file, the first device is connected to the second device as a standby device.

6. The method according to claim 5, characterized in that The second device includes a plurality of devices, and the master-slave switching between the first device and the second device includes: If the first device fails, select a target device with the largest LSN from multiple second devices and use the target device as a new host; The first device is connected to the target device as a backup device, and the devices other than the target device in the second device are connected to the target device as backup devices.

7. The method according to claim 6, characterized in that Connecting a device other than the target device in the second device as a standby device to the target device includes: Obtaining master and backup configuration information of devices other than the target device in the second device; The host configuration in the master / slave configuration information is modified to the target device.

8. A database standby machine access device, characterized in that: Applied to a first device, the first device is connected to a second device, comprising: an interaction module, configured to send a redo log generated by the first device to a second device, and detect whether a response message fed back by the second device is received, the response message including a logical sequence number (LSN) of the redo log in the second log file, for instructing the second device to flush the redo log to the second log file, wherein the first device is a master device, the second device is a slave device, and the second log file is used to store the redo log in ascending order on the second device; a disk-writing module, configured to write the modified data corresponding to the redo log to the first data file upon receiving a response message fed back by the second device; an adjustment module, configured to adjust the maximum LSN in the first data file to be consistent with the maximum LSN in the first log file after the first device and the second device perform a master-slave switch, the first data file being a data file in a disk of a first database on the first device, and the first log file being used to store redo logs in ascending order on the first device; a sending module, configured to send an access request to the second device, the access request including the largest LSN in the first data file and a first redo log history file, the first redo log history file being used to record a database identifier of the redo log and the LSN of a first redo log stored in a database corresponding to the database identifier; An access module is used to connect the first device as a backup device to the second device according to the access request.

9. A database standby machine access device, characterized in that: Applied to a second device, the second device being connected to the first device, comprising: a receiving module, configured to receive the redo log sent by the first device; a sending module, configured to send a response message to the first device after flushing the redo log to the second log file, the response message including a logical sequence number (LSN) of the redo log in the second log file, for instructing the second device to flush the redo log to the second log file, wherein the first device is a master device and the second device is a slave device; an acquisition module configured to acquire, after the first device and the second device perform a master-slave switch, an access request sent by the first device, the access request including: a maximum LSN in a first data file and a first redo log history file, the first redo log history file being used to record a database identifier of the redo log and the LSN of a first redo log stored in a database corresponding to the database identifier, and adjusting the maximum LSN in the first data file and the maximum LSN in the first log file to be consistent, the first data file being a data file in a disk of a first database on the first device; a parsing module, configured to parse the first redo log history file in the access request and obtain a second redo log history file corresponding to the second device; The judgment module is configured to connect the first device as a standby device to the second device if the modification set in the first redo log history file is a subset of the modification set in the second redo log history file.

10. A database standby machine access system, characterized in that: It includes a first device and a second device, wherein: The first device is connected to the second device, comprising the apparatus according to claim 8; The second device comprises the apparatus according to claim 9.

Images