Disaster recovery data processing method, device and system

Abstract

Disclosed in the embodiments of the present description are a failover data processing method, apparatus, and system, the method comprising: after a failover database acquires a first service processing request sent by a service requesting party, determining whether the type of the first service processing request is an inflow type and acquiring a first determining result; if the first determining result is affirmative, then determining a corresponding gateway account on the basis of the user information in the first service processing request, performing gateway accounting on a transaction in the first service processing request on the basis of the gateway account, and adding the corresponding user to a gateway blacklist; determining an asynchronously generated real blacklist, and merging the real blacklist with the gateway blacklist to acquire a total blacklist; locking the users in the total blacklist that do not belong to the real blacklist, and merging and updating the gateway account data corresponding to the locked users. Using the embodiments in the present description enables normal transactions of user accounts other than the real blacklist during a failover period.

Description

technical field [0001] The embodiments of this specification relate to the technical field of computer data processing, and in particular, to a disaster recovery data processing method, device, and system. Background technique [0002] A network failure or unexpected termination of the database may cause some or all services to be unavailable, which is called database failover (FO for short, disaster recovery) in the industry. A general database has a master database and a standby database, and database failover usually occurs on the master database. When the main database is unavailable, it takes a certain amount of time to pull up the standby database. During this period, in order to ensure the business, the account data is usually written into the FO database (or disaster recovery database). After the standby database is pulled up or the main database is repaired, the data in the disaster recovery database is written to the main database or the standby database. [0003...

AI Technical Summary

Problems solved by technology

[0003] However, when using a disaster recovery database for accounting data processing, the instant the main database is down, the data status of the main database and other real-time synchronous databases may be inconsistent, making it impossible to accurately know the accurate accounting data of users in the main database during the disaster recovery period, for example The user's accurate balance limits the user's normal transactions and brings a bad experience to the user

At the same time, in the process of process switching, there may be inconsistencies in the status of some distributed servers, resulting in the risk of simultaneous accounting of the main database and disaster recovery database.

Images