By Guangguo
In the digital era, data is regarded as one of the most important assets for enterprises. However, with the explosion of data volume and the increasing complexity of businesses, the security and availability of data have become more and more urgent. Therefore, database disaster recovery deployment becomes an indispensable part of modern enterprises. Disaster recovery deployment not only effectively prevents data loss caused by unexpected events such as natural disasters, human errors, or system failures, but also quickly recovers services in case of emergencies, improving the overall operation resilience and stability. By implementing effective disaster recovery strategies, enterprises can ensure the continuity of key businesses, maintain customer trust, and gain a competitive edge in a competitive market. To cope with the increasingly complex data environment and uncertainty, enterprises must adopt a systematic database disaster recovery solution to build a reliable disaster recovery mechanism.
Different enterprises and different businesses in the same enterprise differ in requirements for data disaster recovery. Next, let's discuss several common disaster recovery solutions and their main differences.
Features | Description | Level |
---|---|---|
Disaster recovery in the same data center | The primary and secondary nodes of a database are deployed on different physical machines in the same data center. The database nodes are dispersed by machine dimension. | Low (machine-level disaster recovery, which can handle only single-machine failures) |
Zone-disaster recovery | The primary and secondary nodes of a database are deployed in different data centers in the same region. For example, the primary node is deployed in data center A and the secondary node is in data center B in Beijing. The database nodes are dispersed by data center dimension. | Medium (data center-level disaster recovery, which can cope with data center-level faults) |
Geo-disaster recovery | The database's primary and secondary nodes are deployed in different regions (for example, the primary and secondary nodes are deployed in Beijing and Shanghai respectively), or multiple database instances form a disaster recovery cluster. Different database instances are deployed in different regions. The database nodes or instances are dispersed by region dimension. | High (region-level disaster recovery, which can handle region-level faults) |
ApsaraDB RDS for PostgreSQL, a cloud-native architecture-based database product that is optimized for both software and hardware and fully compatible with open-source PostgreSQL, supports all of the aforementioned disaster recovery solutions. Let's take a look at how to implement the preceding solutions on ApsaraDB RDS for PostgreSQL.
ApsaraDB RDS for PostgreSQL natively supports disaster recovery in the same data center. If you create an ApsaraDB RDS for PostgreSQL instance that has more than one node (High-availability or Cluster Edition), different nodes of the instance are deployed on different physical machines without any additional configuration.
The process of creating an ApsaraDB RDS for PostgreSQL instance for zone-disaster recovery is simple. You only need to select different zones for different nodes of the instance when creating the instance.
For users who use an ECS instance to manage their PostgreSQL instances, they can utilize the cloud migration feature of ApsaraDB RDS for PostgreSQL to build an ApsaraDB RDS for PostgreSQL instance that is available in a different zone from the self-built PostgreSQL instance and serves as a secondary instance of the self-built PostgreSQL instance. Therefore, the self-built PostgreSQL instance and ApsaraDB RDS for PostgreSQL instance constitute a zone-disaster recovery cluster. ApsaraDB RDS for PostgreSQL instances can be promoted as primary nodes to provide services when the self-built instance is unavailable due to the failure of the data center where the instance is located. This allows the implementation of zone-disaster recovery across data centers. The following figure shows the disaster recovery cluster topology.
To build a secondary ApsaraDB RDS for PostgreSQL instance in a zone different from that of the self-built PostgreSQL instance by using the cloud migration feature of ApsaraDB RDS for PostgreSQL, you need to perform the following steps:
Read capability expansion in the cloud: After the disaster recovery relationship is established, the target ApsaraDB RDS for PostgreSQL instance synchronizes data from the self-built PostgreSQL instance in real time and provides read-only services. Therefore, the business side can distribute a portion of the read-only traffic to the ApsaraDB RDS for PostgreSQL instance and use it as a read-only instance in the cloud of the self-built PostgreSQL instance to provide services for the business, thereby using the ApsaraDB RDS for PostgreSQL instance to share the business pressure. The following figure shows the topology of the read capability expansion in the cloud.
Migration to the cloud: The migration feature of ApsaraDB RDS for PostgreSQL can be used not only for setting up disaster recovery but also for migrating to the cloud. You can migrate data from a self-built PostgreSQL instance to an ApsaraDB RDS for PostgreSQL instance with the services continuously online during the migration. After the migration, data on the ApsaraDB RDS for PostgreSQL instance and that on the self-built PostgreSQL instance remain high consistency and compatibility. The following figure shows the topology of the migration to the cloud scenario.
For scenarios with cross-region disaster recovery requirements, you can use the cloud migration feature of ApsaraDB RDS for PostgreSQL to create a cluster that supports geo-disaster recovery by combining ApsaraDB RDS for PostgreSQL instances in different regions. You can also combine self-built PostgreSQL instances and ApsaraDB RDS for PostgreSQL instances in different regions. If the source region is unavailable due to force majeure or other factors, the ApsaraDB RDS for PostgreSQL instance in the destination region is promoted to the primary instance to provide read and write services. In this way, services can be quickly restored. The following figure shows the topology of the geo-disaster recovery cluster.
For two different regions on Alibaba Cloud, you can use the Cloud Enterprise Network (CEN) product to connect the networks of the two regions, thereby synchronizing data between self-built PostgreSQL instances and ApsaraDB RDS for PostgreSQL instances in different regions and between ApsaraDB RDS for PostgreSQL instances in different regions. You can also implement cross-region access between applications and ApsaraDB RDS for PostgreSQL instances. For more information about how to connect two networks in different regions, see Manage inter-region connections.
To use the cloud migration feature of ApsaraDB RDS for PostgreSQL to build a geo-disaster recovery cluster that consists of ApsaraDB RDS for PostgreSQL instances in different regions, you need to perform the following steps:
To use the cloud migration feature of ApsaraDB RDS for PostgreSQL to build a geo-disaster recovery cluster that consists of self-built PostgreSQL instances and ApsaraDB RDS for PostgreSQL instances in different regions, you need to perform the following steps:
Remote read-only: If you have built a geo-disaster recovery cluster, the ApsaraDB RDS for PostgreSQL instance in the destination region synchronizes data from the ApsaraDB RDS for PostgreSQL instance in the source region or a self-built PostgreSQL instance in real time. In addition, the ApsaraDB RDS for PostgreSQL instance can provide read-only services. Therefore, you can use the geo-disaster recovery cluster as a global database cluster that is deployed across regions for business scenarios with global deployment requirements. The following figure shows the topology of an ApsaraDB RDS for PostgreSQL instance that uses the read-only capability of the instance in the destination region to handle read-only traffic.
In some specific scenarios, enterprises may need to deploy their business in multiple clouds to reduce the risk of data loss and business interruption due to the failure of a single cloud vendor or other reasons. This improves data availability and security, ensuring business continuity. You can use the cloud migration feature of ApsaraDB RDS for PostgreSQL to create an ApsaraDB RDS for PostgreSQL instance that serves as a disaster recovery instance for other cloud vendors. In scenarios where database services are interrupted due to faults or other reasons, you can quickly upgrade an ApsaraDB RDS for PostgreSQL instance to a primary instance to provide readable and writable services. This allows you to quickly restore your business or migrate your business across clouds at a low cost. The following figure shows the topology of the cross-cloud disaster recovery instance.
Due to the different cloud service providers of the source instance, the network connection solutions between third-party clouds and Alibaba Cloud are also different. Common network connection solutions include VPN, dedicated line, or public Internet. If you need to build an ApsaraDB RDS for PostgreSQL instance for third-party cloud source instances over the Internet, you can refer to the following documentation for configuration: Use an ApsaraDB RDS for PostgreSQL instance to access an external database over the Internet.
To build a cross-cloud disaster recovery cluster that consists of third-party cloud PostgreSQL instances and ApsaraDB RDS for PostgreSQL instances, you need to perform the following steps:
Cross-cloud migration: The cloud migration feature of ApsaraDB RDS for PostgreSQL can also be used in cross-cloud migration scenarios. You can use this feature to migrate data from a third-party cloud PostgreSQL instance to the ApsaraDB RDS for PostgreSQL instance without loss. This greatly reduces the migration requirements for PostgreSQL instances in cross-cloud scenarios. The following figure shows the topology of the cross-cloud migration scenario.
With the cloud migration feature of ApsaraDB RDS for PostgreSQL, you can easily build a disaster recovery cluster from a self-built PostgreSQL instance to an ApsaraDB RDS for PostgreSQL instance, between ApsaraDB for RDS PostgreSQL instances, and from a third-party cloud PostgreSQL instance to an ApsaraDB RDS for PostgreSQL instance. This allows you to meet your business requirements in complex disaster recovery scenarios such as zone-disaster recovery, geo-disaster recovery, and cross-cloud disaster recovery and ensure that businesses can quickly resume business operations in the face of natural disasters, network attacks, or system failures, thereby maintaining customer trust and market competitiveness.
In addition, the cloud migration feature can also be used for data migration scenarios such as migrating a self-built PostgreSQL instance to an ApsaraDB RDS for PostgreSQL instance and a third-party cloud PostgreSQL instance to an ApsaraDB RDS for PostgreSQL instance, which greatly reduces the threshold for database migration and guarantee data security and business stability in the ever-changing market environment in a better manner. Finally, this feature can also be used in various flexible instance deployment scenarios, such as read capability expansion in the cloud and remote read-only, to easily meet various requirements for flexible deployment of database instances in increasingly complex business scenarios.
For more information about the cloud migration feature of ApsaraDB RDS for PostgreSQL, see Migration to Cloud.
Does a Single Table with 5 Million Rows Need Database Sharding and Table Sharding?
Alibaba Clouder - November 12, 2018
Alibaba Clouder - July 22, 2020
Alibaba Container Service - December 19, 2024
digoal - January 30, 2022
Alibaba Cloud Community - October 9, 2022
afzaalvirgoboy - February 25, 2020
Follow our step-by-step best practices guides to build your own business case.
Learn MoreAlibaba Cloud PolarDB for PostgreSQL is an in-house relational database service 100% compatible with PostgreSQL and highly compatible with the Oracle syntax.
Learn MoreProtect, backup, and restore your data assets on the cloud with Alibaba Cloud database services.
Learn MoreAn online MPP warehousing service based on the Greenplum Database open source program
Learn MoreMore Posts by ApsaraDB