Accounting data disaster recovery method and device and electronic equipment
By updating the standby database based on accounting transaction information when the primary database of the distributed accounting database fails, the system unavailability problem during the primary-standby database switchover is solved, and the system performance and throughput are improved.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- NETSUNION CLEARING CORP
- Filing Date
- 2024-10-12
- Publication Date
- 2026-04-17
AI Technical Summary
In existing technologies, the accounting business system is unavailable during the switchover between the primary and standby databases, which affects performance.
When the primary database of the distributed accounting database fails, the system identifies the target account in the standby database that has not completed the accounting update based on the accounting transaction information pushed by the second accounting application, closes its write permissions, updates the standby database based on the accounting transaction information, and restores write permissions after the update is completed.
This reduces the scope and duration of system unavailability when the primary database fails, thereby improving system throughput and performance.
Smart Images
Figure CN121880449A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of database technology, and in particular to a method, apparatus and electronic device for disaster recovery of accounting data. Background Technology
[0002] Currently, most mainstream accounting data disaster recovery solutions rely on the database's own disaster recovery capabilities. This is mainly achieved by establishing a standby database identical to the primary database and updating it in real time. In the event of a disaster in the primary database, automatic failover occurs between the primary and standby databases to promptly take over the accounting business system and ensure the continuity of accounting operations.
[0003] However, the service is unavailable during the switchover between the primary and standby databases, which affects the performance of the accounting business system. Summary of the Invention
[0004] This application proposes a disaster recovery method, apparatus, and electronic device for accounting data to reduce the scope and duration of system unavailability when the main database is abnormal, thereby improving system performance.
[0005] The technical solution of this application is as follows:
[0006] According to a first aspect of the embodiments of this application, the embodiments of this application provide a disaster recovery method for accounting data, including:
[0007] In the event of a failure of the primary database of the distributed accounting database, the target accounts in the backup database that have not completed accounting updates are identified based on the accounting transaction information pushed by the second accounting application in the distributed accounting system. The second accounting application is deployed in the same region as the primary database of the distributed accounting database.
[0008] Disable write permissions for the target account to the standby database;
[0009] Update the backup database based on the transaction history information;
[0010] In response to the completion of data updates in the standby database, write permissions for the target account to the standby database are restored.
[0011] According to a second aspect of the embodiments of this application, the embodiments of this application provide an accounting data disaster recovery device, including:
[0012] The determination module is used to determine the target account in the standby database that has not completed the accounting update in the event of a failure of the primary database of the distributed accounting database, based on the accounting transaction information pushed by the second accounting application in the distributed accounting system. The second accounting application is deployed in the same region as the primary database of the distributed accounting database.
[0013] Disable module, used to close write permissions for the target account to the standby database;
[0014] The synchronization module is used to update the backup database based on accounting transaction information;
[0015] The recovery module is used to restore the target account's write permissions to the standby database in response to the completion of data updates in the standby database.
[0016] According to a third aspect of the embodiments of this application, a terminal device is provided, comprising:
[0017] processor;
[0018] Memory used to store processor-executable instructions;
[0019] The processor is configured to execute instructions to implement the accounting data disaster recovery method as described in the first aspect embodiment above.
[0020] According to a fourth aspect of the embodiments of this application, a computer-readable storage medium is provided, which, when the instructions in the computer-readable storage medium are executed by the processor of a terminal device, enables the terminal device to perform the accounting data disaster recovery method as described in the first aspect embodiment above.
[0021] According to a fifth aspect of the embodiments of this application, a computer program product is provided, including a computer program that, when executed by a processor, implements the accounting data disaster recovery method of the first aspect embodiment described above.
[0022] The technical solution provided by the embodiments of this application brings at least the following beneficial effects: In the event of a failure of the primary database of a distributed accounting database, based on the accounting transaction information pushed by the second accounting application in the distributed accounting system, the target accounts in the standby database that have not completed accounting updates are identified. Then, write permissions for the target accounts to the standby database are disabled. Next, based on the accounting transaction information, the standby database is updated, and in response to the completion of the data update in the standby database, write permissions for the target accounts are restored. Thus, by implementing application-layer logic processing to disable write permissions for some target accounts and updating the standby database based on the accounting transaction information pushed by the second accounting application, the overhead of database synchronization is reduced. This reduces the scope and duration of system unavailability when the primary database fails, improving system throughput and ultimately enhancing system performance.
[0023] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description
[0024] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application, and do not constitute an undue limitation of this application.
[0025] Figure 1 A flowchart illustrating a disaster recovery method for accounting data provided in the first embodiment of this application;
[0026] Figure 2 This is a schematic diagram of the structure of an accounting data disaster recovery system provided in the first embodiment of this application;
[0027] Figure 3 A flowchart illustrating another accounting data disaster recovery method provided in the second embodiment of this application;
[0028] Figure 4 This is a schematic diagram of the structure of an accounting data disaster recovery device provided in the third embodiment of this application. Detailed Implementation
[0029] To enable those skilled in the art to better understand the technical solutions of this application, the technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings.
[0030] The acquisition, storage, use, and processing of data in this application all comply with the relevant provisions of national laws and regulations.
[0031] It should be noted that the terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.
[0032] The accounting data disaster recovery method in this application embodiment is executed by the accounting data disaster recovery device provided in this application embodiment. The accounting data disaster recovery device can be configured in a computer or other device to reduce the scope and duration of system unavailability when the main database is abnormal, thereby improving system performance.
[0033] The following description, with reference to the accompanying drawings, describes a method and apparatus for disaster recovery of accounting data according to embodiments of this application.
[0034] Figure 1 The flowchart of an accounting data disaster recovery method provided in this application embodiment is executed by a first accounting application in a distributed accounting system. The first accounting application and the backup database of the distributed accounting database are deployed in the same area, and include the following steps.
[0035] Step 101: In the event of a failure of the primary database of the distributed accounting database, the target accounts in the standby database that have not completed accounting updates are identified based on the accounting transaction information pushed by the second accounting application in the distributed accounting system. The second accounting application and the primary database of the distributed accounting database are deployed in the same region.
[0036] The transaction records may include a snapshot of the account balance and the corresponding account information, and this application does not impose any restrictions on this.
[0037] In this application, the accounting business application system adopts a distributed microservice architecture. For example... Figure 2 As shown, Figure 2 This is a schematic diagram of the structure of an accounting data disaster recovery system. Figure 2 The central accounting data disaster recovery system includes a primary database, a backup database, cached logs, a second accounting application deployed in the same region as the primary database, a primary accounting application deployed in the same region as the backup database, and a message queue. The primary database is deployed in the local region, the backup database is deployed in a remote region, and the cached logs are stored on the server of the backup database.
[0038] When a user conducts accounting transactions through the client, the transaction is first received and processed by a second accounting application deployed locally. Furthermore, the second accounting application generates the corresponding accounting transaction information for that user and synchronously updates the accounting transaction information for that user's account in the main database.
[0039] When the primary database fails, it will automatically switch to the standby database to ensure normal business operations. Correspondingly, at the application level, the second accounting application will switch to the first accounting application, which will then process subsequent user-submitted accounting requests and save the transaction records to the standby database. This ensures system performance. Simultaneously, the second accounting application will push transaction records generated within a preset time period to the first accounting application. The first accounting application can then receive and parse this transaction information, identifying the corresponding account as the target account in the standby database that has not yet completed its accounting updates. This allows for targeted control of write permissions on the standby database based on the target account, thereby reducing the scope and duration of system unavailability when the primary database fails.
[0040] Optionally, after receiving the transaction information pushed by the second accounting application, the first accounting application can save this information in a cached log. When the primary database is running normally, the primary and standby databases synchronize data asynchronously. However, if the primary database malfunctions, the standby database can be updated based on the cached log. This reduces the overhead of database synchronization and improves system throughput. Simultaneously, the first accounting application reads the transaction information from the cached log and uses this information to determine the target accounts in the standby database that have not yet completed their transaction updates.
[0041] Furthermore, the retention period for transaction information in the cached logs is longer than the latency of data synchronization between the primary and standby databases. This ensures the accuracy of updating the standby database based on the cached logs.
[0042] Optionally, the time difference between the generation time of each transaction record in the cache log and the current time can be determined. If the time difference corresponding to a certain transaction record is greater than or equal to a preset threshold, that transaction record is deleted from the cache log. This removes redundant information from the cache log and improves the efficiency of updating the standby database based on the cache log. The preset threshold is the retention period of the transaction record information in the cache log.
[0043] Optionally, the accounting data disaster recovery system may also include a message queue (MQ), deployed within the same region as the primary database. The message queue receives accounting transaction information pushed by the second accounting application and then pushes this information to the first accounting application. The first accounting application can store the received accounting transaction information in a cache log.
[0044] Step 102: Disable write permissions for the target account to the standby database.
[0045] In this application, the cached logs contain accounting transaction information that has not been updated to the backup database in a timely manner. Therefore, before activating the backup database, the data in the backup database needs to be updated to ensure the accuracy of the accounting information stored in the backup database.
[0046] Understandably, only the transaction information corresponding to the target account in the backup database is not updated in a timely manner. Therefore, the primary accounting application can disable the target account at the application layer. When the target account subsequently requests accounting transactions again, the primary accounting application will not process those transactions, thus effectively closing the target account's write permissions to the backup database. As a result, only a portion of accounts are temporarily unavailable, improving system availability and performance.
[0047] Step 103: Update the backup database based on the transaction history information.
[0048] In this application, the consistency of the transaction details for a target account pushed by the second accounting application can be compared with the corresponding transaction details in the backup database. If the transaction details for a target account pushed by the second accounting application are inconsistent with the transaction details for that target account in the backup database, the transaction details for that target account in the backup database are updated based on the transaction details pushed by the second accounting application. This ensures the accuracy of the transaction details for the target account in the backup database.
[0049] Understandably, during the update of the backup database, all accounting transactions except for the target account can continue to function normally. This reduces the scope and duration of accounting service unavailability should the primary database fail.
[0050] Step 104: In response to the completion of data updates in the standby database, restore the target account's write permissions to the standby database.
[0051] In this application, after updating the standby database, the target account's write permissions to the standby database can be restored, allowing the target account to use it normally.
[0052] In this application, in the event of a primary database failure in a distributed accounting database, the system identifies target accounts in the standby database that have not completed accounting updates based on accounting transaction information pushed by the second accounting application within the distributed accounting system. Then, write permissions for these target accounts to the standby database are disabled. Next, the standby database is updated based on the accounting transaction information, and write permissions for the target accounts are restored upon completion of the update in the standby database. Thus, by implementing application-layer logic processing, disabling write permissions for some target accounts and updating the standby database based on accounting transaction information pushed by the second accounting application reduces the overhead of database synchronization. This reduces the scope and duration of system unavailability when the primary database fails, improving system throughput and ultimately enhancing system performance.
[0053] Figure 3 Another accounting data disaster recovery method provided in this application embodiment is executed by a first accounting application in a distributed accounting system. The first accounting application and the backup database of the distributed accounting database are deployed in the same region.
[0054] like Figure 3 As shown, the method includes:
[0055] Step 301: Obtain the accounting transaction information pushed by the second accounting application from the message queue, and store the obtained accounting transaction information in the cache log. The second accounting application and the main database of the distributed accounting database are deployed in the same region.
[0056] In this application, when the second accounting application generates accounting transaction information, this information can be stored in its corresponding message queue (MQ). Subsequently, the MQ asynchronously pushes the accounting transaction information to the first accounting application, which then stores it in a cached log. This achieves decoupling of the various functions of the system.
[0057] Step 302: In the event of a failure of the primary database of the distributed accounting database, retrieve the unpushed accounting transaction information from the message queue, and determine the target account in the standby database that has not completed the accounting update based on the retrieved unpushed accounting transaction information.
[0058] In this application, when the transaction information is asynchronously pushed to the first accounting application via the MQ corresponding to the second accounting application, some transaction information may not be synchronized to the cached logs in the MQ, and this transaction information may also not be synchronized to the backup database. Therefore, in the event of a primary database failure, the unpushed transaction information in the MQ can be retrieved and parsed to identify the account corresponding to that transaction information as the target account. This avoids the omission of target accounts and allows for subsequent targeted processing of the backup database based on the target account, thereby reducing the scope and duration of system unavailability when the primary database fails.
[0059] Step 303: Read the transaction information from the cache log and determine the target account in the standby database that has not completed the transaction update based on the read transaction information.
[0060] Step 304: Disable write permissions for the target account to the standby database.
[0061] Step 305: Update the backup database based on the transaction history information.
[0062] Step 306: In response to the completion of data updates in the standby database, restore the target account's write permissions to the standby database.
[0063] The specific implementation process of steps 303-306 in this application can be found in the detailed description of any embodiment of this application, and will not be repeated here.
[0064] In this application, accounting transaction information pushed by the second accounting application is obtained from the message queue and stored in the cache log. Then, in the event of a failure of the primary database of the distributed accounting database, unpushed accounting transaction information is retrieved from the message queue. Based on this unpushed information, the target accounts in the standby database that have not completed accounting updates are identified. Simultaneously, accounting transaction information is read from the cache log, and the target accounts in the standby database that have not completed accounting updates are identified. Write permissions for the target accounts to the standby database are then disabled, and the standby database is updated based on the accounting transaction information. Upon completion of the data update in the standby database, write permissions for the target accounts are restored. Thus, by using application-layer logic, disabling write permissions for some target accounts and updating the standby database based on accounting transaction information retrieved from the cache log and message queue reduces the overhead of database synchronization. This reduces the scope and duration of system unavailability when the primary database fails, improving system throughput and ultimately enhancing system performance.
[0065] Figure 4 This is a block diagram illustrating an accounting data disaster recovery device according to an exemplary embodiment. (Refer to...) Figure 4 The device includes a determination module 410, a disable module 420, a synchronization module 430, and a recovery module 440.
[0066] The determination module 410 is used to determine the target account in the standby database that has not completed the accounting update in the event of a failure of the main database of the distributed accounting database, based on the accounting transaction information pushed by the second accounting application in the distributed accounting system. The second accounting application and the main database of the distributed accounting database are deployed in the same region.
[0067] Disable module 420 to disable write permissions for the target account to the standby database;
[0068] Synchronization module 430 is used to update the backup database based on accounting transaction information;
[0069] Recovery module 440 is used to restore the target account's write permissions to the standby database in response to the completion of data updates in the standby database.
[0070] In one possible implementation of the embodiments of this application, it further includes:
[0071] The storage module is used to store the accounting transaction information pushed by the second accounting application in the cache log. The storage duration of the accounting transaction information in the cache log is longer than the data synchronization delay between the main database and the standby database.
[0072] The aforementioned determination module 410 is used to read accounting transaction information from the cache log and determine the target account in the standby database that has not completed accounting updates based on the read accounting transaction information.
[0073] In one possible implementation of this application embodiment, the storage module is used for:
[0074] Retrieve the transaction information pushed by the second accounting application from the message queue and store the retrieved transaction information in the cache log;
[0075] The aforementioned determining module 410 is also used to obtain unpushed accounting transaction information from the message queue, and determine the target account in the backup database that has not completed accounting updates based on the obtained unpushed accounting transaction information.
[0076] In one possible implementation of this application embodiment, a deletion module is further included, used for:
[0077] Determine the time difference between the generation time of each transaction record in the cache log and the current time.
[0078] If the time difference corresponding to any transaction record is greater than or equal to a preset threshold, delete any transaction record from the cache log.
[0079] In one possible implementation of this application embodiment, the transaction information includes a snapshot of the account balance.
[0080] Regarding the apparatus in the above embodiments, the specific manner in which each module performs its operation has been described in detail in the embodiments related to the method, and will not be elaborated upon here.
[0081] In this application, in the event of a primary database failure in a distributed accounting database, the system identifies target accounts in the standby database that have not completed accounting updates based on accounting transaction information pushed by the second accounting application within the distributed accounting system. Then, write permissions for these target accounts to the standby database are disabled. Next, the standby database is updated based on the accounting transaction information, and write permissions for the target accounts are restored upon completion of the update in the standby database. Thus, by implementing application-layer logic processing, disabling write permissions for some target accounts and updating the standby database based on accounting transaction information pushed by the second accounting application reduces the overhead of database synchronization. This reduces the scope and duration of system unavailability when the primary database fails, improving system throughput and ultimately enhancing system performance.
[0082] To implement the above embodiments, this application also proposes a computer device, including a processor and a memory;
[0083] The processor reads executable program code stored in memory to run a program corresponding to the executable program code, so as to implement the accounting data disaster recovery method as described in the above embodiment.
[0084] To implement the above embodiments, this application also proposes a computer-readable storage medium storing a computer program that, when executed by a processor, implements the accounting data disaster recovery method as described in the above embodiments.
[0085] In the description of this specification, the terms "first," "second," etc., are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Therefore, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this application, "multiple" means at least two, such as two, three, etc., unless otherwise explicitly specified.
[0086] Although embodiments of this application have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting this application. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of this application.
Claims
1. A method for disaster recovery of accounting data, characterized by, Executed by a first accounting application in a distributed accounting system, wherein the first accounting application and a backup database of the distributed accounting database are deployed in the same region, the method includes: In the event of a failure of the primary database of the distributed accounting database, the target account in the backup database that has not completed accounting updates is determined based on the accounting transaction information pushed by the second accounting application in the distributed accounting system. The second accounting application is deployed in the same region as the primary database of the distributed accounting database. Disable the target account's write permissions to the backup database; Update the backup database based on the aforementioned transaction history information; In response to the completion of data updates in the backup database, write permissions for the target account to the backup database are restored.
2. The method of claim 1, wherein, Also includes: The accounting transaction information pushed by the second accounting application is stored in the cache log, and the storage duration of the accounting transaction information in the cache log is longer than the data synchronization delay between the main database and the backup database. The step of determining the target account in the backup database that has not completed accounting updates based on the accounting transaction information pushed by the second accounting application in the distributed accounting system includes: The transaction information is read from the cached logs, and the target accounts in the backup database that have not completed the transaction update are determined based on the read transaction information.
3. The method as described in claim 2, characterized in that, The step of storing the transaction information pushed by the second accounting application in the cache log includes: Retrieve the transaction information pushed by the second accounting application from the message queue, and store the retrieved transaction information in the cache log; The step of determining the target account in the backup database that has not completed the accounting update based on the accounting transaction information pushed by the second accounting application in the distributed accounting system also includes: Unpushable transaction information is retrieved from the message queue, and the target account in the backup database that has not completed the transaction update is determined based on the retrieved unpushable transaction information.
4. The method as described in claim 1, characterized in that, The transaction history information includes a snapshot of the account balance.
5. The method according to any one of claims 1-4, characterized in that, Also includes: Determine the time difference between the generation time of each transaction record in the cached log and the current time. If the time difference corresponding to any transaction record is greater than or equal to a preset threshold, then that transaction record is deleted from the cache log.
6. A disaster recovery device for accounting data, characterized in that, The device includes: The determination module is used to determine the target account in the backup database that has not completed the accounting update in the event of a failure of the main database of the distributed accounting database, based on the accounting transaction information pushed by the second accounting application in the distributed accounting system, wherein the second accounting application and the main database of the distributed accounting database are deployed in the same region. The disabled module is used to close the target account's write permissions to the backup database; The synchronization module is used to update the backup database based on the accounting transaction information; The recovery module is used to restore the target account's write permissions to the backup database in response to the completion of data updates in the backup database.
7. The apparatus as claimed in claim 6, characterized in that, Also includes: The storage module is used to store the accounting transaction information pushed by the second accounting application in the cache log, wherein the storage duration of the accounting transaction information in the cache log is greater than the data synchronization delay between the main database and the backup database; The determining module is used to read accounting transaction information from the cached log and determine the target account in the backup database that has not completed accounting updates based on the read accounting transaction information.
8. A disaster recovery system for accounting data, characterized in that, The system includes a first accounting application, a second accounting application, a message queue, a main database, and a backup database; the second accounting application synchronously sends accounting transaction information to the message queue and the main database; the message queue asynchronously sends the accounting transaction information to the first accounting application; the first accounting application stores the accounting transaction information in a cache log.
9. A terminal device, characterized in that, include: processor; Memory used to store the processor's executable instructions; The processor is configured to execute the instructions to implement the data accounting data disaster recovery method as described in any one of claims 1-5.
10. A non-transitory computer-readable storage medium storing computer instructions, wherein, The computer instructions are used to cause the computer to perform the method according to any one of claims 1-5.