As an outstanding data service provider in the field of communication operators, ANTDB has always attached great importance to data security and continuously improved its data disaster recovery capabilities through technological progress and solution innovation. In the information age, data has become an important resource, and how to store and manage this data has become crucial for enterprises. Therefore, data security has become a hot topic of social concern. As an important tool for processing data, databases are constantly improving their capabilities to ensure the data security of enterprises. Database disaster recovery refers to the delayed replication solution provided by antDB database when the business accidentally deletes data, which can quickly recover the accidentally deleted data and ensure the stable operation of the business system. There are many successful cases that prove that the disaster recovery capability of antDB database is very strong. Next, we will take a closer look at the disaster recovery profile of antdb from three aspects of its deferred replication function.
Databases running online are generally deployed with high availability to ensure stable operation of the database. When the antdb database is deployed for high availability, it can be deployed in two modes, as follows:
1) Synchronous replication high availability mode: After all modifications of a transaction are transferred to one or more synchronous backup servers, the antdb database will consider the transaction to be executed normally.
Figure 1: Synchronous replication of antdb
l 2) Asynchronous replication high availability mode: After a transaction is successfully executed on the primary database (regardless of whether the backup server receives the transaction-related information), the antdb database considers the transaction to be executed normally.
Figure 2: AntDB asynchronous replication principle.
By default, asynchronous replication of the standby database plays back the received data files immediately after obtaining the data files to ensure that transactions that have been committed on the primary database can be committed on the standby database, thereby ensuring the consistency of the primary and standby data. The deferred replication feature is based on asynchronous replication, which can control the playback time of data files in the secondary database by configuring the corresponding parameters.
We can use the T+1 service of ** as an example to introduce the handler of the deferred standby:
*T+1 in business: The transaction ends at time T, but the funds need to be delayed by 1 business day before they arrive in the account.
Delay t+n in the standby: At time t, the transaction is completed, and the standby database needs to be delayed for n times before the data file can be played back in the standby.
Primary: The transaction commit time is t
Delayed standby: The transaction commit time is t+n
For more information about the processing process of the antdb database, please refer to the following figure:
Figure 3: The principle of ANTDB deferred replication.
Through the above description of the principle of deferred replication, we can learn the applicable scenarios of deferred replication:
1) Supplementary solution for backup and recovery of massive databases. This allows users to effectively reduce costs through deferred replication.
2) Point-in-time misoperation scenarios. If the primary database is incorrectly operated at time T (DML operations only, such as TRUNCATE and Drop), you can restore data within T within N time periods, because the secondary database is delayed until T+N before the WAL log stream is redone.