The replication pair-consistent group feature allows you to batch manage multiple cloud disks in disaster recovery scenarios. This feature helps ensure that the data of all disks within the same replication pair-consistent group can be restored to the same point in time to allow for the recovery of one or more instances. This topic describes the use scenarios, limits, supported operations, and relevant terms of the replication pair-consistent group feature.
- 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 within the same region need to be batch backed up with high point-in-time consistency.
- 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.
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.
|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.
|Create a replication pair-consistent group|
|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.||Add replication pairs|
|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.||Remove replication pairs|
|Activate async replication for one or more replication pair-consistent groups||After replication pairs are added to a replication pair-consistent group, you must activate these replication pairs by activating async replication for the group to asynchronously replicate data from the disks in primary site to the disks in the secondary site on a periodic basis.||Activate async replication for replication pair-consistent groups|
|Stop async replication for one or more 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 stop the member replication pairs by stopping async replication for the group.||Disable the async replication feature for replication pair-consistent groups|
|Implement disaster recovery||After you create and activate a replication pair-consistent group, if disks in the primary site fail, you can use this group to batch restore the 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.||Delete a replication pair-consistent group|
|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||The data center that serves as a disaster recovery site for a primary site. If the primary site fails, the secondary site takes over 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. It is used as a data metric and holds a default value of 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 from 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.|
|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 when disks in a primary site fail.)|
|Item||Support by the primary disk||Support by the secondary disk|
|Read and write operations||√||×①|
|Rollback based on snapshots||√||×|
|Disk category change||×||×|
|Performance level change||×||×|
|Disk migration along with instances||×||×|
- ①: After a replication pair-consistent group is activated, the secondary disks enter the read-only state and no users have write permissions on the disks.
- ②: Due to RPOs, 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.