{"id":9632,"date":"2022-10-19T20:55:17","date_gmt":"2022-10-20T03:55:17","guid":{"rendered":"https:\/\/www.pingcap.com\/?p=9632"},"modified":"2025-11-14T01:42:37","modified_gmt":"2025-11-14T09:42:37","slug":"disaster-recovery-for-databases-how-it-evolves-over-years","status":"publish","type":"post","link":"https:\/\/www.pingcap.com\/ko\/blog\/disaster-recovery-for-databases-how-it-evolves-over-years\/","title":{"rendered":"Disaster Recovery for Databases: How It Evolves over the Years"},"content":{"rendered":"

Disaster recovery (DR) is a core feature of enterprise-level databases. Database vendors are constantly looking to improve DR, and in the last 10 years they\u2019ve made major innovations.<\/p>\n\n\n\n

This article is a brief history of database DR, with an emphasis on DR and high availability (HA) innovations in cloud-based distributed databases<\/a>.<\/p>\n\n\n\n

<\/p>\n\n\n\n

>> Download the IDC InfoBrief: Competing in the Digital-First Economy<\/a><\/strong> <\/span><<<\/p>\n\n\n\n

<\/p>\n\n\n\n

<\/span>Measuring HA and DR<\/strong><\/span><\/h2>\n\n\n\n

The goal of HA and DR is to keep a system up and running at an operational level. They both try to eliminate single points of failure in the system and automate the failover or recovery process. <\/p>\n\n\n\n

High availability is usually measured by the percentage of time the system is up per year. Disaster recovery focuses on returning a system to service after a disaster with minimal data loss. This is measured by two metrics: the time it takes to recover or Recovery Time Objective (RTO), and the loss of data volume, or Recovery Point Objective (RPO). <\/strong>RPO and RTO should be reduced as much as possible.<\/p>\n\n\n\n

<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

HA\/DR and their measurements <\/em><\/p>\n\n\n\n

<\/p>\n\n\n\n

Each disaster is unique, so Fault Tolerance Target (FTT) describes the maximum scope of disasters that the system can survive. A commonly-used FTT is the region level, which indicates that a disaster has impacted a geographic area like a state or city.<\/p>\n\n\n\n

<\/span>A brief history of DR<\/strong><\/span><\/h2>\n\n\n\n

Database DR technologies have gone through three stages: backup and restore, active-passive, and multi-active.<\/strong><\/p>\n\n\n\n

Backup and restore <\/strong><\/h3>\n\n\n\n

In the earliest stage of disaster recovery, databases leveraged data blocks and transaction logs to create a backup for full and incremental data. If a disaster occured, the database was restored from the backup and application transaction logs. <\/p>\n\n\n\n

In recent years, public cloud database services have combined storage replication with traditional database backup technologies and offered cross-region auto-recovery backup based on snapshots. This approach regularly generates snapshots from the database in the source region and replicates the snapshot files to the destination region. If the source region crashes, the database is recovered from the destination region, and the services will continue. The RTO and RPO of this solution can be as long as a few hours, so it is most appropriate for applications that don\u2019t have strict availability requirements.<\/strong><\/p>\n\n\n\n

<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

The backup and restore DR approach <\/em><\/p>\n\n\n\n

<\/p>\n\n\n\n

Active-passive DR<\/strong><\/h3>\n\n\n\n

Database clusters mark the second phase of development. In a cluster, a master node reads and writes data.  One or more backup nodes receive the transaction logs and apply them, providing read capabilities with some delay.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Active-passive DR<\/em><\/p>\n\n\n\n

<\/p>\n\n\n\n

Although this solution involves the concept of a cluster,  it is still based on a monolithic database. The scalability is limited to read operations; it can\u2019t scale writes. Of course, compared with its predecessor, the RTO is reduced to a few minutes and the RPO a few seconds. <\/strong><\/p>\n\n\n\n

Amazon Aurora, which uses logical replication with cross-region read replicas, is one of the early cloud database services built on this technology.<\/p>\n\n\n\n

<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Aurora logical replication with cross-region read replicas<\/em><\/p>\n\n\n\n

<\/p>\n\n\n\n

In recent years, Aurora has built on this design and offered Global Database service. This service uses storage replication technology to asynchronously replicate data from a source region to a destination region. If the source region goes down, the service can immediately failover to the backup cluster. RTO can be reduced to a few minutes, and RPO is less than 1 second.<\/strong><\/p>\n\n\n\n

Multi-active disaster recovery<\/strong><\/h3>\n\n\n\n

In multi-active disaster recovery, a database provides at least three read and write service nodes for the same copy of the data, and the database can scale out or scale in based on the workload. The requirements behind this capability are from the widespread internet-scale applications, which requires higher performance, lower latency, higher availability, elastic scalability, and elasticity from a database. <\/p>\n\n\n\n

Multi-activeness took shape with traditional sharding databases, which shared data based on one or multiple columns. The sharding solution achieves DR through transaction logs replication. For example, Google once maintained an extremely large MySQL sharding system. This solution offers some level of scalability, but cannot improve the disaster recovery capability as shards increase. The performance will degrade significantly and the maintenance cost will soar. Therefore, sharding is a transitional solution for multi-activeness.<\/p>\n\n\n\n

In recent years, shared-nothing databases based on the Raft or Paxos consensus protocol developed quickly. They solved the scalability and availability challenges mentioned above. Key players in the multi-active era include \ud2f0DB<\/a> and CockRoachDB. Their databases, along with their DR technologies, make most of the legacy databases and relational database services (RDS) obsolete.<\/p>\n\n\n\n

<\/p>\n\n\n\n

\n