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.
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 les valeurs Lag Bytes dans le tableau de bord de surveillance. En cas de panne régionale dans la région de l'instance principale, la valeur Lag Bytes est signalée pour l'instance principale.
Connectez-vous ensuite à l'instance dupliquée avec un client PostgreSQL en suivant les instructions de la page État de la réplication (consultez l'onglet Client psql). Consultez les instructions concernant les métriques pg_catalog.pg_last_wal_receive_lsn() et pg_catalog.pg_last_wal_replay_lsn(). 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 représente 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).