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 désigner une instance répliquée interrégionale avec accès en lecture en tant qu'instance répliquée de reprise après sinistre (instance répliquée de DR) 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.
Commencez par vérifier la valeur Replication Lag de l'instance dupliquée dans le tableau de bord de surveillance, qui indique de combien de secondes l'instance dupliquée est en retard par rapport à son instance principale. La valeur de cette métrique à l'instant précédant l'indisponibilité de l'instance principale indique la période pendant laquelle des transactions validées au niveau de l'instance principale ont pu être perdues. Par exemple, si la valeur Replication Lag indique 5 secondes, cela signifie que l'instance dupliquée peut avoir perdu des écritures sur l'instance principale au cours des cinq secondes précédant l'indisponibilité de l'instance principale.
(La quantité réelle de données perdues peut être inférieure, car le paramètre Replication
Lag inclut également les transactions qui ont été reçues par l'instance dupliquée, mais qui n'ont pas encore été appliquées.)
Connectez-vous ensuite à l'instance dupliquée avec un client MySQL en suivant les instructions de la page État de la réplication (consultez l'onglet Client mysql). Consultez les instructions concernant les métriques Master_Log_File, Read_Master_Log_Pos, Relay_Master_Log_File et Exec_Master_Log_Pos. Vérifiez que l'instance dupliquée a traité toutes les transactions qu'elle a reçues de l'instance principale. Ainsi, lorsqu'elle est promue, l'instance dupliquée reflète bien l'ensemble des transactions reçues avant que l'instance principale ne devienne indisponible.
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).