Disques asynchrones de basculement et de restauration
Restez organisé à l'aide des collections
Enregistrez et classez les contenus selon vos préférences.
Ce document explique comment effectuer un basculement et un retour en arrière des disques de réplication asynchrone.
En cas de panne dans la région principale, il est de votre responsabilité d'identifier la panne et de redémarrer votre charge de travail à l'aide des disques secondaires de la région secondaire. La réplication asynchrone n'offre pas de surveillance des interruptions. Vous pouvez identifier une panne à l'aide des métriques RPO, des vérifications d'état, des métriques spécifiques aux applications et en contactant Cloud Customer Care.
Après un basculement de la région principale vers la région secondaire, la région secondaire devient la région principale agissant.
Une fois la panne ou la catastrophe résolue, vous pouvez lancer la restauration pour démarrer la réplication de la région secondaire d'origine (la région principale agissante) vers la région principale d'origine. Vous pouvez éventuellement répéter le processus pour replacer la charge de travail dans la région principale d'origine. Le transfert de la charge de travail vers la région principale d'origine n'est pas strictement nécessaire, mais peut être effectué en fonction des exigences de reprise après sinistre, telles que la localisation ou les ressources disponibles.
Lorsque vous identifiez qu'un sinistre s'est produit, lancez le basculement vers la région secondaire. Un basculement déplace la charge de travail de la région principale vers la région secondaire. Après le basculement, le disque secondaire devient le disque principal agissant et la région secondaire devient la région principale d'action.
Vous pouvez effectuer un basculement pour un seul disque ou pour tous les disques d'un groupe de cohérence.
Disque unique
Pour basculer un seul disque, procédez comme suit:
Une fois la catastrophe résolue, lancez un basculement vers la région principale d'origine. Un basculement configure et démarre la réplication du disque principal actif vers un nouveau disque secondaire dans la région secondaire active.
Vous pouvez effectuer un basculement pour un seul disque ou pour tous les disques d'un groupe de cohérence.
Disque unique
Pour effectuer un basculement sur un seul disque, procédez comme suit:
Créez un disque secondaire dans la région secondaire active. La région secondaire agissante est la région principale d'origine.
Démarrez la réplication à partir du disque principal actif vers le nouveau disque secondaire.
Facultatif: déplacez la charge de travail de la région principale agissante vers la région principale d'origine en procédant comme suit:
Attendez que la configuration initiale soit terminée. La réplication initiale est terminée lorsque la métrique disk/async_replication/time_since_last_replication est disponible dans Cloud Monitoring.
Si la métrique RPO ne s'affiche pas dans Cloud Explorer, cela signifie que la réplication initiale n'est pas terminée.
Recommandation: Pour éviter toute perte de données, planifiez un temps d'arrêt pour la charge de travail et mettez-la hors connexion.
Facultatif: déplacez la charge de travail de la région principale agissante vers la région principale d'origine en procédant comme suit:
Attendez que la configuration initiale soit terminée. La réplication initiale est terminée lorsque la métrique RPO est disponible.
Si la métrique RPO ne s'affiche pas dans Cloud Explorer, cela signifie que la réplication initiale n'est pas terminée.
Recommandation: Pour éviter toute perte de données, planifiez un temps d'arrêt pour la charge de travail et mettez-la hors connexion.
Sauf indication contraire, le contenu de cette page est régi par une licence Creative Commons Attribution 4.0, et les échantillons de code sont régis par une licence Apache 2.0. Pour en savoir plus, consultez les Règles du site Google Developers. Java est une marque déposée d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/09/03 (UTC).
[[["Facile à comprendre","easyToUnderstand","thumb-up"],["J'ai pu résoudre mon problème","solvedMyProblem","thumb-up"],["Autre","otherUp","thumb-up"]],[["Difficile à comprendre","hardToUnderstand","thumb-down"],["Informations ou exemple de code incorrects","incorrectInformationOrSampleCode","thumb-down"],["Il n'y a pas l'information/les exemples dont j'ai besoin","missingTheInformationSamplesINeed","thumb-down"],["Problème de traduction","translationIssue","thumb-down"],["Autre","otherDown","thumb-down"]],["Dernière mise à jour le 2025/09/03 (UTC)."],[[["\u003cp\u003ePersistent Disk Asynchronous Replication (PD Async Replication) allows for failover to a secondary region in case of an outage in the primary region, though it does not offer outage monitoring.\u003c/p\u003e\n"],["\u003cp\u003eFailover involves stopping replication, creating or using VMs in the secondary region, and attaching the secondary disks to these VMs, making the secondary region the new acting primary region.\u003c/p\u003e\n"],["\u003cp\u003eFailback can be initiated after an outage is resolved, establishing replication from the acting primary region back to the original primary region, with the option to move the workload back to the original primary region.\u003c/p\u003e\n"],["\u003cp\u003eFailover and failback can be performed on either single disks or entire consistency groups, with specific steps for each scenario including creating and attaching disks.\u003c/p\u003e\n"],["\u003cp\u003eWhen failing back, there is an optional step to move the workload back to the original region, which includes waiting for initial replication to complete and temporarily stopping the workload to prevent data loss.\u003c/p\u003e\n"]]],[],null,["# Failover and failback asynchronous disks\n\n*** ** * ** ***\n\nThis document describes how to failover and failback Asynchronous Replication\ndisks.\n\nIn the event of an outage in the primary region, it is your responsibility\nto identify the outage and failover restart your workload using the secondary\ndisks, in the secondary region. Asynchronous Replication doesn't offer outage\nmonitoring. You can identify an outage using\n[RPO metrics](/compute/docs/disks/async-pd/performance#monitor_rpo),\n[health checks](/load-balancing/docs/health-check-concepts),\napplication-specific metrics, and by contacting Cloud Customer Care.\n\nFollowing a failover from the primary region to the secondary region, the\nsecondary region becomes the acting primary region.\n\nAfter the outage or disaster gets resolved, you can initiate failback to start\nreplication from the original secondary region (the acting primary region) to\nthe original primary region. You can optionally repeat the process to move the\nworkload back to the original primary region. Moving the workload back to the\noriginal primary region isn't strictly necessary, but can be done based on\ndisaster recovery requirements, such as locality or available resources.\n\nTo learn more about failover and failback, see\n[About Asynchronous Replication](/compute/docs/disks/async-pd/about#failover_and_failback).\n\nFailover to the secondary region\n--------------------------------\n\nWhen you identify that a disaster has occurred, initiate failover to the\nsecondary region. A failover moves the workload from the primary region to the\nsecondary region. After the failover, the secondary disk is the acting primary\ndisk and the secondary region is the action primary region.\n\nYou can failover a single disk, or all disks in a consistency group. \n\n### Single disk\n\nTo failover a single disk, do the following:\n\n1. [Stop disk replication](/compute/docs/disks/async-pd/manage-replication#stop_replication_for_a_single_disk).\n2. If you don't already have a VM in the same region as the secondary disk, [create one](/compute/docs/instances/create-start-instance).\n3. Attach the secondary disk to the VM:\n\n - For secondary boot disks, [update the boot disk for the VM](/compute/docs/disks/detach-reattach-boot-disk#update_a_boot_disk_for_an_instance).\n - For secondary data disks, [add the disk to the VM](/compute/docs/disks/add-persistent-disk#create_disk).\n\n The secondary disk is now the workload's acting primary disk and the\n secondary region is the acting primary region.\n\n### Consistency group\n\nTo failover a consistency group, do the following:\n\n1. [Stop consistency group replication](/compute/docs/disks/async-pd/manage-replication#stop_replication_for_a_consistency_group).\n2. If you don't already have VMs in the same region as the secondary disks, [create them](/compute/docs/instances/create-start-instance).\n3. Attach the secondary disks to the VMs:\n\n - For secondary boot disks, [update the boot disk for the VM](/compute/docs/disks/detach-reattach-boot-disk#update_a_boot_disk_for_an_instance).\n - For secondary data disks, [add the disk to the VM](/compute/docs/disks/add-persistent-disk#create_disk).\n\nFailback to the original primary region\n---------------------------------------\n\nAfter a disaster has resolved, initiate a failback to the original primary\nregion. A failback configures and starts replication from the acting primary\ndisk to a new secondary disk in the acting secondary region.\n\nYou can failback a single disk, or all disks in a consistency group. \n\n### Single disk\n\nTo failback a single disk, do the following:\n\n1. [Create a secondary disk](/compute/docs/disks/async-pd/configure#create_a_secondary_disk) in the acting secondary region. The acting secondary region is the original primary region.\n2. [Start replication](/compute/docs/disks/async-pd/manage-replication#start_replication) from the acting primary disk to the new secondary disk.\n3. Optional: Move the workload from the acting primary region to the\n original primary region by doing the following:\n\n 1. Wait for the initial replication to complete. The initial replication is complete when the [`disk/async_replication/time_since_last_replication` metric](/compute/docs/disks/async-pd/performance#monitor_rpo) is available in Cloud Monitoring. If you don't see the RPO metric in Cloud Explorer, that means the initial replication isn't complete.\n 2. Recommended: To avoid data loss, schedule downtime for the workload and bring the workload offline.\n 3. [Stop replication](/compute/docs/disks/async-pd/manage-replication#stop_replication_for_a_single_disk).\n 4. Attach the secondary disk to a VM:\n\n - For secondary boot disks, [update the boot disk for the VM](/compute/docs/disks/detach-reattach-boot-disk#update_a_boot_disk_for_an_instance).\n - For secondary data disks, [add the disk to the VM](/compute/docs/disks/add-persistent-disk#create_disk).\n\n The secondary disk is now the workload's primary disk in the original\n primary region.\n 5. Reconfigure replication in the original primary region by doing the\n following:\n\n 1. [Create a new secondary disk](/compute/docs/disks/async-pd/configure#create_a_secondary_disk) in the original secondary region.\n 2. [Start replication](/compute/docs/disks/async-pd/manage-replication#start_replication) from the primary disk to the new secondary disk.\n\n### Consistency group\n\nTo failback a consistency group, do the following:\n\n1. [Create a new consistency group in the acting primary region](/compute/docs/disks/async-pd/manage-consistency-groups#create_a_consistency_group). The acting primary region is the original secondary region.\n2. [Add the acting primary disks to the consistency group](/compute/docs/disks/async-pd/manage-consistency-groups#add_a_disk_to_a_consistency_group)\n3. [Create secondary disks](/compute/docs/disks/async-pd/configure#create_a_secondary_disk) in the acting secondary region that reference the acting primary disks.\n4. [Start replication](/compute/docs/disks/async-pd/manage-replication#start_replication).\n5. Optional: Move the workload from the acting primary region to the\n original primary region by doing the following:\n\n 1. Wait for the initial replication to complete. The initial replication is complete when the [RPO metric is available.](/compute/docs/disks/review-disk-metrics#performance_metrics). If you don't see the RPO metric in Cloud Explorer, that means the initial replication isn't complete.\n 2. Recommended: To avoid data loss, schedule downtime for the workload and bring the workload offline.\n 3. [Stop replication](/compute/docs/disks/async-pd/manage-replication#stop_replication_for_a_consistency_group).\n 4. Attach the secondary disk to VMs:\n\n - For secondary boot disks, [update the boot disk for the VM](/compute/docs/disks/detach-reattach-boot-disk#update_a_boot_disk_for_an_instance).\n - For secondary data disks, [add the disk to the VM](/compute/docs/disks/add-persistent-disk#create_disk).\n\n The secondary disks are now the workload's primary disks in the\n original primary region.\n 5. Reconfigure replication in the original primary region by doing the\n following:\n\n 1. [Add the primary disks to the original consistency group](/compute/docs/disks/async-pd/manage-consistency-groups#add_a_disk_to_a_consistency_group).\n 2. [Create new secondary disks](/compute/docs/disks/async-pd/configure#create_a_secondary_disk) in the original secondary region.\n 3. [Start replication](/compute/docs/disks/async-pd/manage-replication#start_replication).\n\nWhat's next\n-----------\n\n- Learn how to [monitor Asynchronous Replication performance](/compute/docs/disks/async-pd/performance)."]]
