Promouvoir des instances dupliquées pour la migration régionale ou la reprise après sinistre

Cette page explique comment utiliser et promouvoir des instances répliquées interrégionales avec accès en lecture (instances répliquées créées dans une région différente de celle de l'instance primaire) lors d'une migration régionale ou d'une reprise après sinistre.

Présentation

Il existe deux scénarios courants pour la promotion des instances dupliquées interrégionales :

  • La migration régionale : migration planifiée d'une base de données vers une autre région.
  • La reprise après sinistre : basculement d'une base de données vers une autre région en cas d'indisponibilité de la région principale.

Ces deux cas d'utilisation impliquent la configuration de la réplication interrégionale, puis la promotion de l'instance dupliquée. La principale différence entre les deux consiste à savoir si la promotion de l'instance dupliquée est planifiée (dans le cas d'une migration régionale) ou non planifiée (un basculement vers la région de l'instance dupliquée est nécessaire pour la continuité des opérations, car l'instance primaire est devenue indisponible).

Migration régionale

Vous pouvez utiliser une instance dupliquée interrégionale pour migrer votre base de données vers une autre région avec un temps d'arrêt minimal. L'idée générale est de créer une instance dupliquée dans une autre région, d'attendre que la réplication rattrape l'instance primaire, puis de promouvoir l'instance dupliquée avant d'acheminer les clients vers l'instance promue.

Les étapes nécessaires à la promotion sont identiques à celles requises pour promouvoir une instance dupliquée régionale. Suivez ces instructions pour vous assurer que l'instance ainsi promue reçoit bien toutes les transactions qui ont été validées sur l'instance primaire d'origine. Une fois que vous avez promu l'instance dupliquée et vérifié qu'elle fonctionne comme attendu, mettez à jour tous les clients de la base de données afin qu'ils se connectent à cette nouvelle instance.

Reprise après sinistre

Les instances dupliquées interrégionales peuvent être utilisées lors d'une procédure de reprise après sinistre. Vous pouvez promouvoir une instance répliquée interrégionale afin de basculer vers une autre région en cas d'indisponibilité prolongée de la région principale.

Pour en savoir plus sur la reprise après sinistre, consultez la page À propos de la reprise après sinistre dans Cloud SQL.

Reprise après sinistre (DR) avancée

Si vous utilisez l'édition Cloud SQL Enterprise Plus, vous pouvez créer une instance répliquée en cascade et l'utiliser comme instance répliquée de reprise après sinistre pour la reprise après sinistre avancée. Avec la reprise après sinistre avancée, vous effectuez un basculement d'instance dupliquée pour remplacer l'instance principale par l'instance dupliquée de reprise après sinistre désignée. L'ancienne instance principale devient une instance répliquée de l'instance répliquée de reprise après sinistre promue. Vous ne pouvez effectuer un basculement d'instance dupliquée que vers l'instance dupliquée de reprise après sinistre désignée. Vous pouvez toujours promouvoir d'autres instances dupliquées avec accès en lecture sans basculement.

Pour rétablir l'état d'origine de votre déploiement après le basculement de l'instance dupliquée sans perte de données, vous pouvez effectuer un basculement. Comme l'ancienne instance principale est une instance dupliquée de la nouvelle instance principale, vous pouvez à nouveau changer les rôles pour restaurer l'ancienne instance principale.

Pour plus d'informations, consultez la section Reprise après sinistre (DR) avancée. La reprise après sinistre avancée est disponible en version bêta.

Vérifier les critères de basculement

Étant donné que la réplication est asynchrone, vous risquez de perdre certaines transactions récentes validées sur l'instance principale (non répliquées sur l'instance dupliquée) en cas de panne régionale et de tentative de basculement. Chaque fois qu'une instance principale devient indisponible, les étapes suivantes montrent (1) comment déterminer la quantité de données (le cas échéant) qui a pu être perdue lors du basculement entre régions et (2) comment vérifier que l'instance dupliquée promue représente le plus d'écritures récentes possible.

Vous pouvez vérifier l'état de la réplication de l'instance dupliquée à l'aide du tableau de bord de groupe de disponibilité permanente Always On de SQL Server Management Studio (SSMS) ou avec un autre outil. Pour plus d'informations sur l'utilisation de Transact-SQL, consultez les ressources suivantes :

Promouvoir une instance dupliquée avec accès en lecture

Une fois que vous avez confirmé que les critères de basculement sont remplis, vous pouvez promouvoir l'une des instances dupliquées en instance autonome avec accès en écriture. Imaginez le scénario suivant :

  • La région A (us-central1) possède une instance primaire haute disponibilité (db-a-0).
  • La région B (us-west1) possède une instance dupliquée interrégionale haute disponibilité (db-b-1) associée à db-a-0.
  • La région C (us-east1) possède une instance dupliquée interrégionale (db-c-1) associée à db-a-0.

Vous pouvez choisir de promouvoir db-b-1 dans la région B pour qu'elle devienne une instance autonome avec accès en écriture.

Pour obtenir des instructions détaillées, consultez la section Promouvoir une instance dupliquée.

Vérifier que le type de machine est approprié

Assurez-vous que le type de machine de l'instance nouvellement promue est adapté à sa charge de travail en surveillant les métriques sur l'instance telles que l'utilisation du processeur et de la mémoire. Si l'instance promue est plus petite que l'ancienne instance principale, nous vous recommandons de redimensionner l'instance promue afin qu'elle corresponde à l'ancienne instance principale et qu'elle puisse gérer la même charge.

Activer la haute disponibilité pour l'instance promue

Pour une configuration de reprise après sinistre, nous vous recommandons de configurer l'instance dupliquée que vous souhaitez promouvoir en tant qu'instance dupliquée à haute disponibilité. Vous pouvez également configurer l'instance nouvellement promue comme instance à haute disponibilité. Si vous choisissez de ne pas configurer la haute disponibilité pour l'instance dupliquée avec accès en lecture, vous pouvez également configurer l'instance avec la haute disponibilité si et quand vous la promouvez.

Lorsqu'elles sont promues, les instances dupliquées avec accès en lecture sont automatiquement configurées avec des sauvegardes. La configuration d'une instance dupliquée avec accès en lecture pour la haute disponibilité s'effectue de la même manière que pour une instance principale. Pour en savoir plus, consultez la section Configurer la haute disponibilité sur l'instance.

Recréer des instances dupliquées supplémentaires

Si vous promouvez une instance dupliquée pour en faire une instance primaire, vous devez recréer toutes les autres instances dupliquées de l'ancienne instance primaire. Prenons par exemple la configuration référencée précédemment et répétée ici :

  • La région A (us-central1) possède une instance primaire haute disponibilité (db-a-0).
  • La région B (us-west1) possède une instance dupliquée interrégionale (db-b-1) associée à db-a-0.
  • La région C (us-east1) possède une instance dupliquée interrégionale (db-c-1) associée à db-a-0.

Si l'instance primaire (db-a-0) devient indisponible, vous pouvez promouvoir l'instance dupliquée de la région B pour qu'elle devienne l'instance primaire. Pour disposer à nouveau d'instances dupliquées supplémentaires dans les régions A et C, supprimez les anciennes instances (l'ancienne instance primaire dans la région A et l'instance dupliquée dans la région C), puis créez des instances dupliquées avec accès en lecture à partir de la nouvelle instance primaire dans la région B.

La configuration obtenue est la suivante :

  • La région A (us-central1) dispose maintenant d'une instance dupliquée interrégionale (db-a-1).
  • La région B (us-west1) est maintenant associée à l'instance principale (db-b-1).
  • La région C (us-east1) dispose désormais d'une nouvelle instance dupliquée interrégionale (db-c-2).