The replication pair-consistent group feature allows you to batch manage multiple disks in disaster recovery scenarios. You can restore the data of all disks in the same replication pair-consistent group to the same point in time to implement disaster recovery for instances. This topic describes the use scenarios, limits, supported operations, and relevant terms of the replication pair-consistent group feature.
Scenarios
The replication pair-consistent group feature can be used in the following scenarios:
Management of virtual groups
When a business system is deployed in a cluster file system that spans multiple Elastic Compute Service (ECS) instances, all disks on the instances need to be managed together as a virtual group to ensure that each of these disks is write order-consistent in asynchronous replication. Examples of virtual group scenarios: a self-managed MySQL cluster is built on multiple ECS instances, a single Logical Volume Manager (LVM) logical volume is created across multiple disks, and MySQL or SAP HANA clusters are migrated to the cloud.
Multi-disk protection and recovery
When a business system spans multiple disks, a policy needs to be applied to protect and restore all these disks together.
Multi-disk data backup
Disks on multiple ECS instances that reside in the same region need to be batch backed up and high point-in-time consistency is required.
Disaster recovery of distributed application systems
Disaster recovery needs to be implemented for distributed application systems, such as super computing systems, large websites, and multi-application collaborative systems.
Usage notes
Feature principles
The replication pair-consistent group feature allows data to be asynchronously replicated between disks across zones within the same region or across regions. When a primary site fails, you can fail over to the corresponding secondary site and restore data from the secondary site. The following figures show how the replication pair-consistent group feature works when a replication pair-consistent group spans different zones within a single region or spans different regions.
A replication pair-consistent group spans different zones within a single region
A replication pair-consistent group spans different regions
Supported operations
The following table describes the operations supported by the replication pair-consistent group feature.
Operation | Description | References |
Create a replication pair-consistent group | Before you can use the replication pair-consistent group feature to implement multi-disk geo-disaster recovery, you must create a replication pair-consistent group. After a replication pair-consistent group is created, you can modify its name and description based on your business requirements. | |
Add replication pairs | After a replication pair-consistent group is created, you can add replication pairs that replicate in the same direction as the group to the group. | |
Remove replication pairs | You can remove replication pairs that you no longer need from replication pair-consistent groups. When a replication pair is removed from a replication pair-consistent group, the replication pair is disassociated from the group but is not deleted. | |
Activate async replication for replication pair-consistent groups | After replication pairs are added to a replication pair-consistent group, you must activate the replication pairs by activating async replication for the group to asynchronously replicate data from the disks on the primary site to the disks in the secondary site on a periodic basis. | Activate async replication for replication pair-consistent groups |
Disable async replication for replication pair-consistent groups | If you no longer need to replicate data by using a replication pair-consistent group or if you want to perform a failover on a replication pair-consistent group, you can disable async replication for the replication pairs in the replication pair-consistent group. | Disable async replication for replication pair-consistent groups |
Implement disaster recovery | After you create and activate a replication pair-consistent group, if the disks at the primary site (primary disks) fail, you can use the replication pair-consistent group to batch restore data stored on the primary disks. | Use replication pair-consistent groups to implement disaster recovery |
Delete a replication pair-consistent group | You can delete a replication pair-consistent group that you no longer need. |
Terms
The following table describes the terms related to the replication pair-consistent group feature.
Term | Description |
asynchronous replication | Asynchronous replication is an operation that replicates data between disks across zones or regions on a periodic basis. In asynchronous replication, data on the source disk (primary disk) and destination disk (secondary disk) is crash-consistent but is inconsistent in time. For more information, see Overview. |
replication pair | A pair of disks that have an asynchronous replication relationship. |
primary site | A primary data center that can run independently to support the normal operation of business in normal cases. |
secondary site | A data center that serves as a disaster recovery site for a primary site. If the primary site fails, the secondary site takes over the business to ensure business continuity. |
recovery point objective (RPO) | The amount of data that may be lost due to a disk exception. RPO is measured in time and is used as a data metric. The default RPO is 15 minutes in replication pair-consistent groups. This value indicates that if an exception occurs on disks in the primary site, data written to the disks up to 15 minutes prior to the exception may be lost when the disks are restored. |
failover | A feature that allows you to enable read and write permissions on the disks in the secondary site and fail over to the secondary site. |
reverse replication | A feature that can reverse replication relationships to replicate the latest data from the disks in the secondary site to the disks in the primary site. |
Limits
Region limits
The following table describes the regions and zones in which the async replication feature is supported:
- China (Hangzhou): Hangzhou Zone G, Hangzhou Zone H, Hangzhou Zone I, and Hangzhou Zone K
- China (Shanghai): Shanghai Zone B, Shanghai Zone E, Shanghai Zone F, Shanghai Zone G, and Shanghai Zone L
- China (Beijing): Beijing Zone F, Beijing Zone G, Beijing Zone H, and Beijing Zone J
- China (Shenzhen): Shenzhen Zone D
- China (Heyuan): Heyuan Zone A and Heyuan Zone B
- China (Chengdu): Chengdu Zone A and Chengdu Zone B
- China (Hong Kong): Hong Kong Zone B and Hong Kong Zone C
- Singapore: Singapore Zone B and Singapore Zone C
- US (Silicon Valley): Silicon Valley Zone A and Silicon Valley Zone B
- US (Virginia): Virginia Zone A and Virginia Zone B
Instance type limits
The following table describes the quotas used for the replication pair-consistent group feature.
Item | Limit |
Replication pairs that can be added to a single replication pair-consistent group | 17 |
RPO | 15 minutes (Data is restored to up to 15 minutes prior to a disk failure in the primary site.) |
Disk limits
The limits described in the following table apply to primary and secondary disks when you use the replication pair-consistent group feature.
- ①: After a replication pair is activated, the secondary disk enters the read-only state and no users have write permissions on the disk.
- ②: Due to RPO, data of a snapshot created for a primary disk may not be consistent with that of a snapshot created at the same time for the associated secondary disk.
| Item | Supported by the primary disk | Supported by the secondary disk |
| Read and write operations | √ | × ① |
| Disk deletion | × | × |
| Disk initialization | × | × |
| Disk resizing | × | × |
| Disk attaching | √ | × |
| Snapshot creation | √ | √ ② |
| Rollback based on snapshots | √ | × |
| Disk category change | × | × |
| Performance level change | × | × |
| Disk encryption | × | × |
| Multi-attach | × | × |
| Disk migration along with instances | × | × |