GBASE Chat | Financial Disaster Recovery Solutions (Part 1)

A couple of days ago, while browsing online, I came across an article on database disaster recovery solutions with the eye-catching title “A Second-Level RTO Disaster Recovery Solution.” The entire piece revolved around the concept of “second-level” disaster recovery. This surprised me. Disaster recovery should sacrifice a small portion of production efficiency to add redundancy, thereby achieving overall data security for the information system and ensuring stable operations. Admittedly, RTO is an important disaster recovery metric, but a disaster recovery solution should describe the comprehensive system-level data protection provided by a full-fledged disaster recovery system, ensuring the availability of every component so that the system can operate 24×7 without interruption—rather than emphasizing speed alone. In my view, a disaster recovery solution should be expressed through an effective disaster recovery system.

The Baidu Baike entry for “disaster recovery system,” reviewed and approved by the “Science China” encyclopedia project, describes it as follows:

“In IT, a disaster recovery system provides an environment that can withstand various disasters. When a computer system suffers from irresistible natural disasters such as fire, flood, earthquake, or war, as well as man-made disasters like computer crime, computer viruses, power outages, network/communication failures, hardware/software errors, and human operational errors, the disaster recovery system ensures the security of user data (data disaster recovery). A more complete disaster recovery system can even provide uninterrupted application services (application disaster recovery).”

Therefore, data protection is the goal of disaster recovery, and providing uninterrupted services is its successful, effective expression.

So, how can we achieve comprehensive system-level data protection?

We know that in general, an information system consists of three major parts: storage, processing services, and transmission. To ensure security at every link, a disaster recovery solution must introduce redundancy in all three areas, thus meeting the goal of an uninterrupted system and satisfying the financial industry’s “five nines” requirement.

Redundancy in these three areas manifests as:

1. Storage security – Non-stop: achieved through data redundancy;

2. Service security – Non-stop: achieved through database server redundancy;

3. Transmission security – Non-stop: achieved through system redundancy.

Take GBase as an example. Let’s see how a truly comprehensive disaster recovery system is built. We know that typical database information systems are divided into transactional processing systems and analytical processing systems. Correspondingly, GBase has two different database service engines: the transaction processing engine and the analytical processing engine—namely GBase 8s and GBase 8a. Below, let’s examine how these two database server engines construct disaster recovery solutions when handling transactional data and analytical data, respectively, to illustrate how they protect our data security and deliver genuine, meticulous care in fulfilling the mission of disaster recovery.

Storage Security – Non-stop

In most cases, people choose RAID5 for storage-level protection. RAID5 is indeed helpful for disk data protection, especially recovery, but if it is not a disk array, database-level protection proves more effective for the logical verification of critical data.

For the transaction processing engine, GBase 8s provides disk mirroring technology, offering disk-level redundancy for important data, ensuring not only the numerical accuracy of the data but also its logical correctness.

For the analytical processing engine, GBase 8a provides multi-copy technology, delivering storage-level redundancy to guarantee uninterrupted data provision.

It is worth noting that disk mirroring and node-level data redundancy differ at the disk and database levels; the disk level does not perform logical verification.

Service Security – Non-stop

Transaction Processing Engine:

Non-stop service in the transaction processing engine is realized through a shared cluster, which we call the SSC cluster. When the primary server fails, an SSC standby server can immediately take over. The number of standby servers is configurable; typically, 2–3 standby servers are used to provide redundancy for the primary server, with the entire cluster sharing a single copy of data. Deployment overview:

SSC uses a shared-disk approach between standby nodes and the primary, avoiding the problem of duplicate data storage, saving space, and simplifying installation and configuration. Moreover, when the primary fails, it enables rapid takeover. Additionally, we can easily configure multiple SSC standby nodes to achieve load balancing.

Because SSC standby nodes leverage the primary server’s disk and can be started quickly and easily, they are well suited for scale-out scenarios. Since SSC standby servers are very close to the primary (they share the same disks), they are most appropriate as failover servers when the primary encounters problems.

Basic working principle of the SSC cluster:

For an SSC secondary server, the primary server only needs to send the log position of the logical log pages to the SSC secondary. Using the log position received from the primary, the SSC secondary reads the logical log pages from disk and applies them to its in-memory data buffers.

An SSC secondary server does not write anything to the shared disk blocks, nor does it flush shared memory data to disk, even during a checkpoint operation. If an SSC secondary needs to flush shared memory data, it will write to a temporary ‘paging file’ instead, and that paging file is cleared only at the next checkpoint. Meanwhile, the primary does not flush data pages from shared memory until it confirms that no SSC secondary still needs that data page.

The following diagram shows the deployment solution for localizing intermediary businesses at a rural commercial bank:

This solution adopts a fully all-domestic configuration to host intermediary businesses such as ETC top-up services, channel service integration, and business traffic control. Through the SSC configuration, it meets the 7×24 business continuity requirement, possesses the ability to automatically and rapidly switch over within seconds upon failure, and achieves load balancing. It delivers:

• High performance: millisecond-level response for tables with hundreds of millions of rows, satisfying peak business processing demands;

• High availability: transparent, automatic, and rapid failover with a switchover time of less than 30 seconds, ensuring business continuity and security;

• High stability: guarantees 7×24 business operations for the bank’s money-related transactions;

• All-domestic: a fully integrated all-domestic platform solution.

Analytical Processing Engine:

Non-stop service in the analytical processing engine is implemented through a federated architecture. The GBase 8a MPP Cluster product comprises three core components—the distributed management cluster GCWare, the distributed scheduling cluster GCluster, and the distributed storage cluster GNode. Their functions are as follows:

GCluster: responsible for SQL parsing, SQL optimization, distributed execution plan generation, and execution scheduling.

GCWare: used for sharing information among GCluster instances on each node (including cluster structure, node status, node resource status, etc.), as well as providing operational nodes and controlling data consistency across nodes during multi-copy data operations.

Typically, the GCluster and GCWare components are deployed on the same physical nodes and are collectively referred to as the coordinator.

Coordinators provide pooled management; multiple coordinator servers reside in a shared management pool, and a problem on any single node will not affect normal system operation—no switching is required. The federated architecture is deployed as follows:

The advantage of the federated architecture—non-stop operation—has helped hundreds of financial institutions conduct their business safely and smoothly. Its extremely high availability has made GBase 8a the top choice for the financial industry when procuring analytical databases.