Data recovery methods, apparatus, computer equipment, and computer-readable storage media

Abstract

This application discloses a data recovery method, apparatus, computer equipment, and computer-readable storage medium, relating to the field of computer technology. Through table-level rapid recovery technology, it minimizes data recovery time and quickly restores system operation after a risk occurs, reducing the impact of the risk. The method includes: responding to a data recovery request, acquiring abnormal data and an abnormal time, and determining the abnormal data table corresponding to the abnormal data and the abnormal data table identifier of the abnormal data table; when the abnormal time matches a preset time interval, determining target update information in a distributed message queue system based on the abnormal time and the abnormal data table identifier; if target update information exists, updating the data in the backup data table in the online backup database using the target update information to obtain the target data table; obtaining the target data table in the online backup database, and using the target data table to recover data from the abnormal data table in the production database.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a data recovery method, apparatus, computer device, and computer-readable storage medium. Background Technology

[0002] With the continuous development of computer technology and the arrival of the big data era, the volume of business data has increased exponentially. In actual operation, a large amount of business data is stored in different data tables according to their respective categories, and the business system then retrieves the corresponding business data tables from the database according to specific business needs. When some important business data tables in the database are corrupted, data recovery of the database is necessary to ensure the normal operation of the subsequent business system.

[0003] In related technologies, developers primarily use backup and recovery methods, restoring previous business data using backup data stored on magnetic tape. When the amount of backup data is large, the speed of backing up and restoring the database using full backup data from magnetic tape becomes slow, resulting in prolonged business system interruptions and severely impacting business continuity. Summary of the Invention

[0004] In view of this, this application provides a data recovery method, apparatus, computer equipment, and computer-readable storage medium. The main purpose is to solve the problem that when the amount of backup data is large, the speed of backing up and restoring the database using full backup data in magnetic tape becomes slow, resulting in long business system interruption time and seriously affecting business continuity.

[0005] According to a first aspect of this application, a data recovery method is provided, the method comprising:

[0006] In response to a data recovery request, abnormal data and abnormal time are obtained, and the abnormal data table corresponding to the abnormal data and the abnormal data table identifier of the abnormal data table are determined, wherein the abnormal time is the time when the abnormal data was generated.

[0007] When the abnormal time falls within a preset time interval, the target update information is determined in the distributed message queue system based on the abnormal time and the abnormal data table identifier.

[0008] If the target update information exists, the target update information is used to update the data in the backup data table in the online backup database to obtain the target data table. The backup data table is the data table in the online backup database that is associated with the abnormal data table identifier.

[0009] The target data table is obtained from the online backup database, and the target data table is used to recover the abnormal data table in the production database.

[0010] Optionally, before acquiring the abnormal data and abnormal time in response to the data recovery request, the method further includes:

[0011] When data changes occur in the production database, the specified data table where the data change occurred is determined, and the specified update information of the specified data table is obtained. The specified update information includes the specified change time, the specified incremental update data, and the specified data table identifier.

[0012] The specified update information is sent to the distributed message queue system, so that the distributed message queue system stores the specified update information in the corresponding cluster node and counts the occupancy time of the cluster node. The distributed message queue system includes multiple cluster nodes.

[0013] Among the multiple cluster nodes, a cluster node to be consumed is determined. The update information to be consumed stored in the cluster node to be consumed is then sent to the online backup database for data update.

[0014] Optionally, the step involves determining a cluster node to be consumed among the plurality of cluster nodes, consuming the update information to be consumed stored in the cluster node to be consumed, and then sending the update information to be consumed to the online standby database for data update.

[0015] The occupancy time of each cluster node in the plurality of cluster nodes is counted, and the occupancy time is compared with the preset storage time;

[0016] Whenever a cluster node's occupancy time equals the preset storage time, the cluster node is designated as the cluster node to be consumed, and the update information to be consumed stored in the cluster node to be consumed is consumed. The update information to be consumed is then sent to the online backup database for data update.

[0017] Optionally, consuming the pending update information stored in the cluster nodes and sending the pending update information to the online backup database for data update includes:

[0018] The data consumption program is executed to consume the information to be consumed and update, and the information to be consumed and update is sent to the online backup database. In the online backup database, the data table to be updated is determined according to the data table identifier to be consumed in the information to be consumed.

[0019] In the online backup database, the data in the data table to be updated is replaced with the incremental update data of the consumption information to be consumed, and the update time of the data table to be updated is set according to the consumption change time in the consumption information to be consumed.

[0020] Optionally, after responding to a data recovery request, acquiring abnormal data and abnormal time, and determining the abnormal data table corresponding to the abnormal data and the abnormal data table identifier of the abnormal data table, the method further includes: when the abnormal time does not fall within the preset time interval, using backup data in the local tape to perform backup and recovery of the production database.

[0021] Optionally, when the abnormal time falls within a preset time interval, the target update information is determined in the distributed message queue system based on the abnormal time and the abnormal data table identifier, including:

[0022] When the abnormal time falls within the preset time interval, the distributed message queue system queries all target cluster nodes associated with the abnormal data table identifier and reads all update information stored in all target cluster nodes as the target update information.

[0023] Optionally, updating the backup data table in the online backup database using the target update information includes:

[0024] The data consumption program is executed to consume the target update information and then sends the target update information to the online backup database.

[0025] In the online backup database, the data in the backup data table is replaced with the target incremental update data in the target update information, and the update time of the backup data table is set according to the target change time in the target update information.

[0026] According to a second aspect of this application, a data recovery apparatus is provided, the apparatus comprising:

[0027] The acquisition module is used to acquire abnormal data and abnormal time in response to a data recovery request, and to determine the abnormal data table corresponding to the abnormal data and the abnormal data table identifier of the abnormal data table, wherein the abnormal time is the time when the abnormal data was generated.

[0028] The query module is used to determine the target update information in the distributed message queue system based on the abnormal time and the abnormal data table identifier when the abnormal time hits a preset time interval;

[0029] The update module is used to update the data of the backup data table in the online backup database using the target update information if the target update information exists, so as to obtain the target data table. The backup data table is the data table in the online backup database associated with the abnormal data table identifier.

[0030] The first recovery module is used to obtain the target data table from the online backup database and use the target data table to recover data from the abnormal data table in the production database.

[0031] Optionally, the device further includes:

[0032] The determination module is used to determine the specified data table where the data change has occurred when the production database undergoes a data change, and to obtain the specified update information of the specified data table. The specified update information includes the specified change time, the specified incremental update data, and the specified data table identifier.

[0033] The first sending module is used to send the specified update information to the distributed message queue system, so that the distributed message queue system stores the specified update information in the corresponding cluster node and counts the occupancy time of the cluster node. The distributed message queue system includes multiple cluster nodes.

[0034] The second sending module is used to determine the cluster node to be consumed among the plurality of cluster nodes, and to send the update information to be consumed to the online backup database for data update by consuming the update information to be consumed stored in the cluster node to be consumed.

[0035] Optionally, the second sending module is used to count the occupancy time of each cluster node in the plurality of cluster nodes, compare the occupancy time with the preset storage time; whenever there is a cluster node whose occupancy time is equal to the preset storage time, the cluster node is designated as the cluster node to be consumed, and the update information to be consumed stored in the cluster node to be consumed is consumed, and the update information to be consumed is sent to the online backup database for data update.

[0036] Optionally, the second sending module is configured to execute a data consumption program to consume the update information to be consumed, send the update information to be consumed to an online backup database, determine the data table to be updated in the online backup database according to the data table identifier to be consumed in the information to be consumed, replace the data in the data table to be updated with the incremental update data to be consumed in the information to be consumed in the online backup database, and set the update time of the data table to be updated according to the change time to be consumed in the information to be consumed.

[0037] Optionally, the device further includes:

[0038] The second recovery module is used to back up and restore the production database using backup data in the local tape when the abnormal time does not fall within the preset time interval.

[0039] Optionally, the query module is used to query all target cluster nodes associated with the abnormal data table identifier in the distributed message queue system when the abnormal time falls within the preset time interval, and read all update information stored in all target cluster nodes as the target update information.

[0040] Optionally, the update module is configured to execute a data consumption program to consume the target update information, send the target update information to the online backup database, and in the online backup database, replace the data in the backup data table with the target incremental update data in the target update information, and set the update time of the backup data table according to the target change time in the target update information.

[0041] According to a third aspect of this application, a computer device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the method described in any of the first aspects above.

[0042] According to a fourth aspect of this application, a computer-readable storage medium is provided, on which a computer program is stored, wherein the computer program, when executed by a processor, implements the steps of the method described in any one of the first aspects above.

[0043] Using the above technical solutions, this application provides a data recovery method, apparatus, computer equipment, and computer-readable storage medium. In response to a data recovery request, this application acquires abnormal data and an abnormal time, and determines the abnormal data table corresponding to the abnormal data and the abnormal data table identifier of the abnormal data table. When the abnormal time falls within a preset time interval, target update information is determined in a distributed message queue system based on the abnormal time and the abnormal data table identifier. If target update information exists, it is used to update the data in the backup data table in the online backup database to obtain the target data table. The backup data table is the data table in the online backup database associated with the abnormal data table identifier. Finally, the target data table is obtained from the online backup database, and the target data table is used to recover the abnormal data table in the production database. In this embodiment, it is not necessary to use all the data stored in the online backup database to recover the data in the production database. Instead, a table-level fast recovery method is used to determine the abnormal data table where the abnormal data is located. By consuming the target update information corresponding to the abnormal data table, the table data of the backup data table in the online backup database is updated to the state before the abnormal data was generated, and then the updated backup data table is used to recover the abnormal data table. The table-level fast recovery technology provided in this application can minimize data recovery time and quickly restore system operation after a risk occurs, thereby reducing the impact of the risk.

[0044] The above description is only an overview of the technical solution of this application. In order to better understand the technical means of this application and to implement it in accordance with the contents of the specification, and to make the above and other objects, features and advantages of this application more obvious and understandable, the following are specific embodiments of this application. Attached Figure Description

[0045] Various other advantages and benefits will become apparent to those skilled in the art upon reading the following detailed description of preferred embodiments. The accompanying drawings are for illustrative purposes only and are not intended to limit the scope of this application. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings:

[0046] Figure 1 This illustration shows a schematic flowchart of a data recovery method provided in an embodiment of this application;

[0047] Figure 2 This illustration shows a schematic flowchart of a data recovery method provided in an embodiment of this application;

[0048] Figure 3 This illustration shows a schematic flowchart of a data recovery method provided in an embodiment of this application;

[0049] Figure 4 This paper shows a schematic diagram of the structure of a data recovery device provided in an embodiment of this application;

[0050] Figure 5 A schematic diagram of the device structure of a computer device provided in an embodiment of this application is shown. Detailed Implementation

[0051] Exemplary embodiments of the present application will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the present application are shown in the drawings, it should be understood that the present application may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this application will be thorough and complete, and will fully convey the scope of the present application to those skilled in the art.

[0052] With the continuous development of computer technology and the arrival of the big data era, the volume of business data has increased exponentially. In actual operation, a large amount of business data is stored in different data tables according to their respective categories, and the business system then retrieves the corresponding business data tables from the database according to specific business needs. When some important business data tables in the database are corrupted, data recovery of the database is required to ensure the normal operation of the subsequent business system. Currently, developers mainly use backup and recovery methods, using backup data on magnetic tape to restore previous business data. When the amount of backup data is large, the speed of backing up and restoring the database using full backup data on magnetic tape becomes slow, resulting in long business system interruption times and seriously affecting business continuity. Therefore, this application provides a data recovery method.

[0053] In response to a data recovery request, the system acquires the abnormal data and the abnormal time, and determines the abnormal data table corresponding to the abnormal data and its identifier. When the abnormal time falls within a preset time interval, the system determines the target update information based on the abnormal time and the identifier of the abnormal data table in the distributed message queue system. If the target update information exists, it is used to update the data in the backup data table in the online backup database to obtain the target data table. The backup data table is the data table in the online backup database associated with the identifier of the abnormal data table. Finally, the target data table is obtained from the online backup database and used to recover the abnormal data table in the production database. In this embodiment, it is not necessary to use all the data stored in the online backup database to recover the data in the production database. Instead, a table-level fast recovery method is used to determine the abnormal data table where the abnormal data is located. By consuming the target update information corresponding to the abnormal data table, the table data of the backup data table in the online backup database is updated to the state before the abnormal data occurred. Then, the updated backup data table is used to recover the abnormal data table. The table-level fast recovery technology provided in this application can minimize the data recovery time after a risk occurs, quickly restore system operation, and reduce the impact of the risk.

[0054] This application provides a data recovery method, such as... Figure 1 As shown, the method includes:

[0055] 101. In response to a data recovery request, obtain the abnormal data and the abnormal time, and determine the abnormal data table corresponding to the abnormal data and the abnormal data table identifier of the abnormal data table. The abnormal time is the time when the abnormal data was generated.

[0056] The production database is the main database used to store production data in the production environment, and the abnormal data table is a data table in the production database that generates abnormal data due to misoperation. The abnormal data can be accidentally deleted data, erroneous data, etc. This application does not specify the generation method and data type of abnormal data.

[0057] Specifically, when staff write scripts to update data in a data table in the production environment, errors or other misoperations may cause abnormal data. Some of these abnormal data can disrupt normal business operations, and staff may only discover the error during troubleshooting. In such cases, staff can access the data recovery system from their terminal and upload a data recovery request containing the abnormal data and the time of the error. The data recovery system responds to the request by retrieving the abnormal data and the time of the error. For example, if a staff member discovers that data A01 was accidentally deleted at 15:29:00 on April 21, 2023, at 18:01:00, then the staff member needs to send the abnormal data A01 and the time 15:29:00 on April 21, 2023, to the data recovery system to request data recovery. Further, the system identifies the corresponding abnormal data table and its identifier in the production database. Continuing with the example of the abnormal data A01, in the production database, we can determine that the data table associated with the data identifier A01 is table A. Therefore, table A is regarded as the abnormal data table, and the data table identifier A corresponding to table A is regarded as the abnormal data table identifier.

[0058] 102. When an abnormal time falls within a preset time range, the target update information is determined in the distributed message queue system based on the abnormal time and the abnormal data table identifier.

[0059] The distributed message queue system is a Kafka cluster, and Kafka is a high-throughput distributed message queue system. A Kafka cluster consists of multiple Kafka nodes that can store messages. In this embodiment, the messages stored in the Kafka nodes are the target update information.

[0060] Specifically, the abnormal time is compared with a preset time interval. When the comparison result indicates that the abnormal time falls within the preset time interval (i.e., a match is found), all target update information corresponding to the abnormal data table identifier is queried in the Kafka distributed message queue system cluster. It should be noted that, considering the same data table may undergo multiple data changes at different times, and the update information generated by each data change may be stored on different Kafka nodes, after the update information is stored on the Kafka node, a tag with the corresponding data table identifier needs to be added to that Kafka node. This allows subsequent identification of update information whose tag content matches the abnormal data table identifier and whose data change time is before the abnormal time, as the target update information.

[0061] 103. If target update information exists, the target update information is used to update the data in the standby data table in the online standby database to obtain the target data table. The standby data table is the data table in the online standby database associated with the abnormal data table identifier.

[0062] The online standby database is an online database connected to the production database network. It can be Oracle, DB2, MySQL, etc., and its type can be the same as that of the production database. This application does not specify the type of the online standby database.

[0063] Specifically, the data recovery system can query target update information in the Kafka cluster based on the abnormal data table identifier and the time of the anomaly. If target update information exists in the Kafka cluster, it means that the abnormal data table containing the abnormal data underwent data changes within the preset time interval. In this case, the data in the standby data table in the online standby database is not the latest data before the anomaly time, so it is necessary to consume the target update information, update the standby data table in the online standby database, and then use the updated standby data table to recover the abnormal data table in the production database. If target update information does not exist in the Kafka cluster, it means that the abnormal data table containing the abnormal data did not undergo data changes within the preset time interval. In this case, the standby data table in the online standby database is the latest data table before the anomaly occurred, so it can be directly used to recover the abnormal data table in the production database.

[0064] 104. Obtain the target data table from the online backup database, and use the target data table to recover data from the abnormal data table in the production database.

[0065] Specifically, the data recovery system determines the backup data table indicated by the abnormal data table identifier in the online backup database, sends the data in the backup data table to the production database, and replaces the data in the abnormal data table in the production database with the data in the backup data table, thus completing rapid table-level data recovery.

[0066] The data recovery method provided in this embodiment, in response to a data recovery request, acquires abnormal data and abnormal time, and determines the abnormal data table corresponding to the abnormal data and the abnormal data table identifier of the abnormal data table. When the abnormal time matches a preset time interval, target update information is determined in the distributed message queue system based on the abnormal time and the abnormal data table identifier. If target update information exists, it is used to update the data in the backup data table in the online backup database to obtain the target data table. The backup data table is the data table in the online backup database associated with the abnormal data table identifier. Finally, the target data table is obtained in the online backup database, and the target data table is used to recover the abnormal data table in the production database. In this embodiment, it is not necessary to use all the data stored in the online backup database to recover the data in the production database. Instead, a table-level fast recovery method is used to determine the abnormal data table where the abnormal data is located. By consuming the target update information corresponding to the abnormal data table, the table data of the backup data table in the online backup database is updated to the state before the abnormal data was generated, and then the updated backup data table is used to recover the data in the abnormal data table. The table-level fast recovery technology provided in this application can minimize data recovery time and quickly restore system operation after a risk occurs, thereby reducing the impact of the risk.

[0067] Furthermore, as a refinement and extension of the specific implementation methods of the above embodiments, and to fully illustrate the implementation process of this embodiment, this application provides a data recovery method, such as... Figure 2 As shown, the method includes:

[0068] 201. When data changes occur in the production database, identify the specified data table where the data change occurred, obtain the specified update information for the specified data table, and push the specified update information to the online standby database with a delay.

[0069] In the embodiments of this application, such as Figure 3As shown, the data in the production database changes as various business processes in the production environment operate. Therefore, when a specified data table in the production database experiences data changes, the data recovery system does not directly send the incrementally updated specified data table to the online standby database for data updates. Instead, it pushes the specified update information corresponding to the specified data table to the Kafka cluster for storage. After the specified update information has been stored for a preset period, the system consumes the specified update information and sends it to the online standby database to delay the arrival time of the incremental update data in the online standby database.

[0070] First, when data changes occur in the production database, the specified data table where the data change occurred is identified, and the specified update information for the specified data table is obtained. This specified update information includes the specified change time, the specified incremental update data, and the specified data table identifier. It should be noted that the specified update information is the data information of the changed incremental data. For example, if data A01 in data table A changes to A02 at 10:00:00, then the update information is [Change Time: 10:00:00, Data Table Identifier: A, Incremental Update Data A02]. Further, the specified update information is sent to the Kafka cluster, so that the Kafka cluster stores the specified update information in the corresponding cluster nodes and counts the cluster node occupancy time. It should be noted that the Kafka cluster includes multiple Kafka nodes that can store messages; in this embodiment, the messages stored in the Kafka nodes are the update information.

[0071] Furthermore, the cluster nodes to be consumed are determined among multiple cluster nodes. Specifically, the occupancy time of each cluster node storing updated information is first calculated, and then compared with the preset storage time. Whenever a cluster node's occupancy time equals the preset storage time, that cluster node is designated as the cluster node to be consumed.

[0072] Finally, the data consumption program consumes the pending update information stored in the cluster nodes and sends the pending incremental update data from this information to the online backup database for data updates. Specifically, the data consumption program consumes the pending update information and sends it to the online backup database. Then, in the online backup database, the data table to be updated is determined based on the pending data table identifier in the pending consumption information. Finally, in the online backup database, the data in the data table to be updated is replaced with the pending incremental update data from the pending consumption information to complete the update. Simultaneously, the update time for the data table to be updated is set according to the pending change time in the pending consumption information, so that relevant personnel can know when the data in the data table to be updated was generated. It should be noted that, considering that the same data table may undergo multiple data changes at different times, the update information generated by each data change may be stored in different Kafka nodes. Therefore, after the update information is stored in the Kafka node, a tag with the corresponding data table identifier needs to be added to the Kafka node so that the update information whose tag content is an abnormal data table identifier and whose data change time is before the abnormal time can be identified later as the target update information.

[0073] 202. In response to a data recovery request, obtain the abnormal data and the abnormal time, and determine the abnormal data table corresponding to the abnormal data and the abnormal data table identifier of the abnormal data table. The abnormal time is the time when the abnormal data was generated.

[0074] In this embodiment, when staff members write scripts to update data in a data table in the production environment, errors or other misoperations may cause abnormal data. Some of this abnormal data can disrupt normal business operations, and staff members may only discover the error during troubleshooting. In such cases, staff members can access the data recovery system from their terminal and upload a data recovery request containing the abnormal data and the time of the error. The data recovery system responds to the request by obtaining the abnormal data and the time of the error, identifies the abnormal data table in the production database, and uses the table's identifier as its identifier. This facilitates subsequent data recovery based on the table identifier and the time of the error.

[0075] For example, if staff discover at 18:01:00 on April 21, 2023 that data A01 was mistakenly deleted at 15:29:00 on April 21, 2023, then the staff need to send the abnormal data A01 and the abnormal time 15:29:00 on April 21, 2023 to the data recovery system to request data recovery. Further, the abnormal data table corresponding to the abnormal data and the abnormal data table identifier of the abnormal data table are identified in the production database. Continuing with the example of abnormal data A01, the data table associated with the data identifier A01 in the production database is identified as table A, table A is designated as the abnormal data table, and the data table identifier A corresponding to table A is designated as the abnormal data table identifier.

[0076] 203. Determine the preset time interval and compare the abnormal time with the preset time interval.

[0077] In this embodiment, the data recovery system first determines a preset time interval based on time intervals pre-set by relevant personnel. Then, it compares the abnormal time with the preset time interval to determine whether the abnormal data generated by the erroneous operation will affect the normal operation of the business. When the abnormal time does not fall within the preset time interval, step 204 is executed, using backup data from the local tape to back up and restore the production database. When the abnormal time falls within the preset time interval, step 205 is executed, determining the target update information in the Kafka cluster based on the abnormal time and the abnormal data table identifier, and then executing subsequent steps to recover the data based on the target update information.

[0078] Specifically, the data recovery system queries a preset time interval and the current time point. Based on these two points, it determines a historical time point. By using the historical time point as the start time point and the current time point as the end time point, a preset time interval is obtained. For example, if the preset time interval is set to 24 hours, and the current time point is 2023-04-21 18:00:00, then pushing the current time point back 24 hours yields a historical time point of 2023-04-20 18:00:00. The preset time interval is then from 2023-04-20 18:00:00 to 2023-04-21 18:00:00. When the abnormal time is 2023-04-20 20:00:00, it means the abnormal time falls within the preset time interval. When the abnormal time is 2023-04-19 12:00:00, it means the abnormal time does not fall within the preset time interval.

[0079] 204. When the abnormal time does not fall within the preset time range, the production database is backed up and restored using the backup data in the local tape.

[0080] In this embodiment, by comparing the abnormal time with a preset time interval, it can be determined whether the abnormal data generated by the erroneous operation will affect the normal operation of the business. When the abnormal time does not match the preset time interval, it indicates that the erroneous operation occurred a long time ago, and the abnormal data generated by the erroneous operation will not affect the normal operation of the business. In this case, there is no need for emergency recovery; the relevant data can be stably restored using traditional backup and recovery methods, that is, using backup data from local tapes to back up and restore the production database.

[0081] 205. When an abnormal time falls within a preset time range, the target update information is determined in the distributed message queue system based on the abnormal time and the abnormal data table identifier.

[0082] In this step, comparing the abnormal time with a preset time interval determines whether the abnormal data generated by the erroneous operation will affect the normal operation of the business. When the abnormal time matches the preset time interval, it means that the erroneous operation will soon be discovered due to its impact on the normal operation of the business. In this case, it is necessary to urgently retrieve the data. That is, first determine whether the target update information exists. If it exists, the data is restored through the target update information. If it does not exist, the data is restored directly by retrieving the backup data table from the online backup database.

[0083] Specifically, when the comparison result indicates that the anomaly time is within a preset time interval (i.e., the preset time interval is hit), the Kafka cluster queries all target cluster nodes associated with the anomaly table identifier and reads all update information stored on all target cluster nodes as the target update information. By querying the target update information in the Kafka cluster, it is determined whether the anomaly table involved in the anomaly data has undergone data changes within the preset time interval. This allows for subsequent determination of whether the data in the online backup database needs to be updated based on the presence of target update information.

[0084] 206. If target update information exists, the target update information is used to update the data in the standby data table in the online standby database to obtain the target data table. The standby data table is the data table in the online standby database associated with the abnormal data table identifier.

[0085] In this step, if target update information exists in the Kafka cluster, it indicates that the abnormal data table containing the anomalous data has undergone data changes within the preset time interval. At this time, the data in the online standby database's standby table is not the latest data before the anomaly occurred, and it's necessary to consume the target update information from the Kafka cluster to update the standby table in the online standby database. Specifically, the data consumption program consumes the target update information and sends it to the online standby database. Then, in the online standby database, the standby table is backed up first so that data can be rolled back later. Next, the data in the standby table is replaced with the target incremental update data from the target update information, and the update time of the standby table is set according to the target change time in the target update information. Finally, the updated standby table is used to restore the anomalous data table in the production database. Alternatively, if target update information does not exist in the Kafka cluster, it indicates that the abnormal data table containing the anomalous data has not undergone data changes within the preset time interval. At this time, the data in the standby table in the online standby database is the latest data before the anomalous data occurred, and the standby table in the online standby database can be directly used to restore the anomalous data table in the production database.

[0086] 207. Obtain the target data table from the online backup database, and use the target data table to recover data from the abnormal data table in the production database.

[0087] In this step, the data recovery system determines the backup data table indicated by the abnormal data table identifier in the online backup database, sends the data in the backup data table to the production database, and replaces the data in the abnormal data table in the production database with the data in the backup data table, thus completing the rapid data recovery at the table level.

[0088] The method provided in this application embodiment, in response to a data recovery request, acquires abnormal data and abnormal time, and determines the abnormal data table corresponding to the abnormal data and the abnormal data table identifier of the abnormal data table. When the abnormal time matches a preset time interval, target update information is determined in the distributed message queue system based on the abnormal time and the abnormal data table identifier. If target update information exists, the target update information is used to update the data in the backup data table in the online backup database to obtain the target data table. The backup data table is the data table in the online backup database associated with the abnormal data table identifier. Finally, the target data table is obtained in the online backup database, and the target data table is used to recover the abnormal data table in the production database. In this application embodiment, it is not necessary to use all the data stored in the online backup database to recover the data in the production database. Instead, a table-level fast recovery method is used to determine the abnormal data table where the abnormal data is located. By consuming the target update information corresponding to the abnormal data table, the table data of the backup data table in the online backup database is updated to the state before the abnormal data was generated, and then the updated backup data table is used to recover the data in the abnormal data table. The table-level fast recovery technology provided in this application can minimize data recovery time and quickly restore system operation after a risk occurs, thereby reducing the impact of the risk.

[0089] Furthermore, as Figure 1 To specifically implement the method, this application provides a data recovery device, such as... Figure 4 As shown, the device includes: an acquisition module 401, a query module 402, an update module 403, and a first recovery module 404.

[0090] The acquisition module 401 is used to acquire abnormal data and abnormal time in response to a data recovery request, and to determine the abnormal data table corresponding to the abnormal data and the abnormal data table identifier of the abnormal data table, wherein the abnormal time is the time when the abnormal data was generated.

[0091] The query module 402 is used to determine the target update information in the distributed message queue system based on the abnormal time and the abnormal data table identifier when the abnormal time hits a preset time interval;

[0092] The update module 403 is used to update the backup data table in the online backup database with the target update information if the target update information exists, so as to obtain the target data table. The backup data table is the data table in the online backup database associated with the abnormal data table identifier.

[0093] The first recovery module 404 is used to obtain the target data table from the online backup database and use the target data table to recover data from the abnormal data table in the production database.

[0094] In specific application scenarios, the device further includes: a determining module 405, a first sending module 406, and a second sending module 407.

[0095] The determining module 405 is used to determine the specified data table that has undergone data change when the production database undergoes data change, and to obtain the specified update information of the specified data table. The specified update information includes the specified change time, the specified incremental update data, and the specified data table identifier of the specified data table.

[0096] The first sending module 406 is used to send the specified update information to the distributed message queue system, so that the distributed message queue system stores the specified update information in the corresponding cluster node and counts the occupancy time of the cluster node. The distributed message queue system includes multiple cluster nodes.

[0097] The second sending module 407 is used to determine the cluster node to be consumed among the plurality of cluster nodes, and to send the update information to be consumed to the online backup database for data update by consuming the update information to be consumed stored in the cluster node to be consumed.

[0098] In a specific application scenario, the second sending module 407 is used to count the occupancy time of each cluster node in the plurality of cluster nodes, compare the occupancy time with the preset storage time; whenever there is a cluster node whose occupancy time is equal to the preset storage time, the cluster node is designated as the cluster node to be consumed, and the update information to be consumed stored in the cluster node to be consumed is consumed, and the update information to be consumed is sent to the online backup database for data update.

[0099] In a specific application scenario, the second sending module 407 is used to execute a data consumption program to consume the update information to be consumed, and send the update information to be consumed to an online backup database. In the online backup database, the data table to be updated is determined according to the data table identifier to be consumed in the information to be consumed. In the online backup database, the data in the data table to be updated is replaced with the incremental update data to be consumed in the information to be consumed, and the update time of the data table to be updated is set according to the change time to be consumed in the information to be consumed.

[0100] In specific application scenarios, the device further includes a second recovery module 408.

[0101] The second recovery module 408 is used to back up and restore the production database using backup data in the local tape when the abnormal time does not fall within the preset time interval.

[0102] In a specific application scenario, the query module 403 is used to query all target cluster nodes associated with the abnormal data table identifier in the distributed message queue system when the abnormal time hits the preset time interval, and read all the update information stored in all the target cluster nodes as the target update information.

[0103] In a specific application scenario, the update module 403 is used to execute a data consumption program to consume the target update information and send the target update information to the online backup database. In the online backup database, the target incremental update data in the target update information is used to replace the data in the backup data table, and the update time of the backup data table is set according to the target change time in the target update information.

[0104] The apparatus provided in this application embodiment can, in response to a data recovery request, acquire abnormal data and abnormal time, and determine the abnormal data table corresponding to the abnormal data and the abnormal data table identifier of the abnormal data table. When the abnormal time matches a preset time interval, target update information is determined in the distributed message queue system based on the abnormal time and the abnormal data table identifier. If target update information exists, the target update information is used to update the data in the backup data table in the online backup database to obtain the target data table. The backup data table is the data table in the online backup database associated with the abnormal data table identifier. Finally, the target data table is obtained in the online backup database, and the target data table is used to recover the abnormal data table in the production database. In this application embodiment, it is not necessary to use all the data stored in the online backup database to recover the data in the production database. Instead, a table-level fast recovery method is used to determine the abnormal data table where the abnormal data is located. By consuming the target update information corresponding to the abnormal data table, the table data of the backup data table in the online backup database is updated to the state before the abnormal data was generated, and then the updated backup data table is used to recover the data in the abnormal data table. The table-level fast recovery technology provided in this application can minimize data recovery time and quickly restore system operation after a risk occurs, thereby reducing the impact of the risk.

[0105] It should be noted that other corresponding descriptions of the functional units involved in the data recovery device provided in this application embodiment can be found in the following references. Figures 1 to 3 The corresponding descriptions in [the document] will not be repeated here.

[0106] Based on the above, Figures 1 to 3 Accordingly, this embodiment also provides a storage medium storing a computer program thereon, which, when executed by a processor, implements the steps of the data recovery method described above.

[0107] Based on this understanding, the technical solution of this application can be embodied in the form of a software product. The software product to be identified can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, or portable hard drive), including several instructions to cause a computer device (such as a personal computer, server, or network device) to execute the methods described in the various implementation scenarios of this application.

[0108] Based on the above, Figures 1 to 3 The method shown, and Figure 4 The data recovery apparatus embodiment shown above, in order to achieve the above objectives, in an exemplary embodiment, see [reference needed]. Figure 5 Furthermore, a device is provided, comprising a communication bus, a processor, a memory, and a communication interface. It may also include an input / output interface and a display device, wherein the various functional units can communicate with each other via the bus. The memory stores a computer program, and the processor executes the program stored in the memory to perform the data recovery method described in the above embodiments.

[0109] Optionally, the physical device may also include a user interface, a network interface, a camera, radio frequency (RF) circuitry, sensors, audio circuitry, a Wi-Fi module, etc. The user interface may include a display screen, input units such as a keyboard, etc., and optional user interfaces may also include USB interfaces, card reader interfaces, etc. The network interface may optionally include standard wired interfaces, wireless interfaces (such as Wi-Fi interfaces), etc.

[0110] Those skilled in the art will understand that the physical device structure for data recovery provided in this embodiment does not constitute a limitation on the physical device, and may include more or fewer components, or combine certain components, or have different component arrangements.

[0111] The storage medium may also include an operating system and a network communication module. The operating system is a program that manages the hardware and software resources of the aforementioned physical device, supporting the operation of information processing programs and other software and / or programs to be identified. The network communication module is used to enable communication between the various components within the storage medium, as well as communication with other hardware and software in the information processing physical device.

[0112] Through the above description of the embodiments, those skilled in the art can clearly understand that this application can be implemented using software plus necessary general-purpose hardware platforms, or it can be implemented using hardware. By applying the technical solution of this application, in response to a data recovery request, abnormal data and abnormal time are obtained, and the abnormal data table corresponding to the abnormal data and the abnormal data table identifier of the abnormal data table are determined. When the abnormal time hits a preset time interval, the target update information is determined in the distributed message queue system based on the abnormal time and the abnormal data table identifier. If the target update information exists, the data in the backup data table in the online backup database is updated using the target update information to obtain the target data table. The backup data table is the data table in the online backup database associated with the abnormal data table identifier. Finally, the target data table is obtained in the online backup database, and the target data table is used to recover the abnormal data table in the production database. Compared with the prior art, in the embodiments of this application, it is not necessary to use all the data stored in the online backup database to recover the data in the production database. Instead, a table-level fast recovery approach is adopted. This involves identifying the table containing the abnormal data, consuming the target update information corresponding to that table, updating the data in the backup table in the online backup database to the state before the abnormal data occurred, and then using the updated backup table to recover the data from the abnormal table. The table-level fast recovery technology provided in this application can minimize data recovery time after a risk occurs, quickly restore system operation, and reduce the impact of the risk.

[0113] Those skilled in the art will understand that the accompanying drawings are merely schematic diagrams of a preferred embodiment, and the modules or processes shown in the drawings are not necessarily essential for implementing this application.

[0114] Those skilled in the art will understand that the modules in the apparatus of the implementation scenario can be distributed within the apparatus of the implementation scenario as described, or they can be located in one or more apparatuses different from this implementation scenario, with corresponding changes. The modules of the above-described implementation scenario can be combined into one module, or they can be further divided into multiple sub-modules.

[0115] The serial numbers in this application are for descriptive purposes only and do not represent the superiority or inferiority of the implementation scenario.

[0116] The above disclosures are only a few specific implementation scenarios of this application. However, this application is not limited to these. Any variations that can be conceived by those skilled in the art should fall within the protection scope of this application.

Claims

1. A data recovery method, characterized in that, include: When a specified data table in the production database has undergone data changes, the specified update information corresponding to the specified data table is pushed to the Kafka cluster for storage. After the specified update information has been stored for a preset period of time, the specified update information is consumed and then pushed to the online backup database with a delay. The online backup database is an online database that is connected to the production database via the network. In response to a data recovery request, abnormal data and abnormal time are obtained, and the abnormal data table corresponding to the abnormal data and the abnormal data table identifier of the abnormal data table are determined, wherein the abnormal time is the time when the abnormal data was generated. When the abnormal time falls within a preset time interval, the target update information is determined in the distributed message queue system based on the abnormal time and the abnormal data table identifier, including: querying all target cluster nodes associated with the abnormal data table identifier in the Kafka cluster, and reading all update information stored in all target cluster nodes as the target update information; If the target update information exists in the Kafka cluster, the target update information is used to update the data in the backup data table in the online backup database to obtain the target data table. The backup data table is the data table in the online backup database associated with the abnormal data table identifier. The target data table is obtained from the online backup database, and the target data table is used to restore the data of the abnormal data table in the production database. If the target update information is not available in the Kafka cluster, the abnormal data table in the production database is directly restored using the backup data table in the online backup database.

2. The method according to claim 1, characterized in that, Before responding to the data recovery request and obtaining the abnormal data and abnormal time, the method further includes: When data changes occur in the production database, the specified data table where the data change occurred is determined, and the specified update information of the specified data table is obtained. The specified update information includes the specified change time, the specified incremental update data, and the specified data table identifier. The specified update information is sent to the distributed message queue system, so that the distributed message queue system stores the specified update information in the corresponding cluster node and counts the occupancy time of the cluster node. The distributed message queue system includes multiple cluster nodes. Among the multiple cluster nodes, a cluster node to be consumed is determined. The update information to be consumed stored in the cluster node to be consumed is then sent to the online backup database for data update.

3. The method according to claim 2, characterized in that, The step of determining the cluster node to be consumed among the multiple cluster nodes, consuming the update information to be consumed stored in the cluster node to be consumed, and sending the update information to be consumed to the online backup database for data update includes: The occupancy time of each cluster node in the plurality of cluster nodes is counted, and the occupancy time is compared with the preset storage time; Whenever a cluster node's occupancy time equals the preset storage time, the cluster node is designated as the cluster node to be consumed, and the update information to be consumed stored in the cluster node to be consumed is consumed. The update information to be consumed is then sent to the online backup database for data update.

4. The method according to claim 3, characterized in that, The process of consuming the pending update information stored in the cluster nodes and sending the pending update information to the online backup database for data update includes: The data consumption program is executed to consume the information to be consumed and update, and the information to be consumed and update is sent to the online backup database. In the online backup database, the data table to be updated is determined according to the data table identifier to be consumed in the information to be consumed. In the online backup database, the data in the data table to be updated is replaced with the incremental update data of the consumption information to be consumed, and the update time of the data table to be updated is set according to the consumption change time in the consumption information to be consumed.

5. The method according to claim 1, characterized in that, After responding to a data recovery request, acquiring abnormal data and abnormal time, and determining the abnormal data table corresponding to the abnormal data and the abnormal data table identifier of the abnormal data table, the method further includes: when the abnormal time does not fall within the preset time interval, using backup data in the local tape to perform backup and recovery of the production database.

6. The method according to claim 1, characterized in that, When the abnormal time falls within a preset time interval, the target update information is determined in the distributed message queue system based on the abnormal time and the abnormal data table identifier, including: When the abnormal time falls within the preset time interval, the distributed message queue system queries all target cluster nodes associated with the abnormal data table identifier and reads all update information stored in all target cluster nodes as the target update information.

7. The method according to claim 1, characterized in that, The step of updating the backup data table in the online backup database using the target update information includes: The data consumption program is executed to consume the target update information and then sends the target update information to the online backup database. In the online backup database, the data in the backup data table is replaced with the target incremental update data in the target update information, and the update time of the backup data table is set according to the target change time in the target update information.

8. A data recovery device, characterized in that, include: The acquisition module is used to push specified update information corresponding to a specified data table that has undergone data changes to a Kafka cluster for storage when such data exists in the production database. After the specified update information has been stored for a preset duration, the module consumes the specified update information and sends it to an online standby database. The online standby database is an online database connected to the production database via a network. In response to a data recovery request, the module acquires abnormal data and abnormal time, and determines the abnormal data table corresponding to the abnormal data and the abnormal data table identifier of the abnormal data table. The abnormal time is the time when the abnormal data was generated. The query module is used to determine the target update information in the distributed message queue system based on the abnormal time and the abnormal data table identifier when the abnormal time hits the preset time interval. This includes: querying all target cluster nodes associated with the abnormal data table identifier in the Kafka cluster and reading all update information stored in all target cluster nodes as the target update information. The update module is used to update the data of the backup data table in the online backup database using the target update information if the target update information exists in the Kafka cluster, thereby obtaining the target data table. The backup data table is a data table in the online backup database associated with the abnormal data table identifier. The target data table is obtained from the online backup database, and the target data table is used to restore the data of the abnormal data table in the production database. The first recovery module is used to directly recover the abnormal data table in the production database using the backup data table in the online backup database if the target update information is not available in the Kafka cluster.

9. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 7.

Images