Utilisation du bascultune Neptune - Amazon Neptune

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Utilisation du bascultune Neptune

Une base de données globale Neptune fournit des fonctionnalités de basculement plus complètes qu'un cluster de base de données Neptune autonome. En utilisant une base de données globale, vous pouvez planifier et effectuer une récupération après sinistre rapidement. La reprise après sinistre est généralement évaluée à l'aide de l'évaluation de l'objectif de temps de restauration (RTO) et de l'objectif de point de récupération (RPO) :

  • Objectif de temps de récupération (RTO)— Il s'agit de la rapidité avec laquelle un système revient à un état de fonctionnement après un sinistre. En d'autres termes, le RTO mesure les temps d'arrêt. Pour une base de données globale Neptune, le RTO peut être de l'ordre des minutes.

  • Objectif de point de récupération (RPO)— La durée pendant laquelle les données sont perdues. Pour une base de données Neptune globale, le RPO est généralement mesuré en secondes (voirBasculement planifié géré pour les Amazon Neptune).

Pour une base de données globale Neptune, il existe deux approches de basculement différentes :

  • RDetach-and-promote (restauration manuelle non planifiée)— Pour se remettre d'une interruption non planifiée ou pour effectuer des tests de reprise après sinistre (test DR), effectuez une detach-and-promote sur l'un des clusters de base de données globale. Pour ce processus, le RTO manuel dépend de la rapidité avec laquelle vous pouvez effectuer les tâches répertoriées dans Détacher et promouvoir. Le RPO est généralement un nombre de secondes, mais cela dépend du retard de réplication du stockage sur le réseau au moment de la panne.

  • Basculement planifié géré— Cette approche est destinée à la maintenance opérationnelle et à d'autres procédures opérationnelles planifiées telles que le déplacement du cluster de base de données principal de la base de données globale vers l'une des régions secondaires. Comme ce processus synchronise les clusters de base de données secondaires avec le cluster principal avant toute modification, le RPO est effectivement égal à 0 (c'est-à-dire qu'il n'y a aucune donnée perdue). Consultez Basculement planifié géré pour les Amazon Neptune.

RDetach-and-promote une base de données globale Neptune en cas de panne imprévue

Dans les très rares cas où votre base de données Neptune globale subit une panne inattendue dans son principaleRégion AWS, votre cluster de base de données Neptune principal et son nœud de scripteur ne sont plus disponibles, et la réplication entre le cluster principal et les clusters secondaires s'interrompt. Pour minimiser les temps d'arrêt (RTO) et la perte de données (RPO) qui en résultent, effectuez rapidement une analyse interrégionale detach-and-promote pour reconstruire la base de données globale.

Astuce

Il est conseillé de comprendre ce processus avant de l'utiliser et de mettre en place un plan pour agir rapidement dès les premiers signes d'un problème régional.

  • Utiliser Amazon CloudWatch régulièrement pour suivre les temps de latence des clusters secondaires afin de pouvoir identifier la région secondaire présentant le délai de latence le plus faible en cas de basculement.

  • Assurez-vous de tester votre plan pour vérifier que les procédures sont complètes et précises.

  • Utilisez un environnement simulé pour vous assurer que votre personnel est formé et prêt à effectuer rapidement un basculement après sinistre si cela s'avère nécessaire.

Pour basculer vers un cluster secondaire après une panne non planifiée dans la région principale

  1. Arrêtez d'émettre des requêtes de mutation et d'autres opérations d'écriture sur le cluster de bases de données principal

  2. Identifier un cluster de base de données dans un cluster secondaireRégion AWSà utiliser comme nouveau cluster de base de données globale. Si la base de données globale possède au moins deux données secondairesRégions AWS, choisissez le cluster secondaire dont le délai de latence est le plus faible.

  3. Détachez le cluster de bases de données secondaire que vous avez choisi dans la base de données globale Neptune.

    La suppression d'un cluster de base de données secondaire d'une base de données globale Neptune interrompt immédiatement la réplication des données du cluster principal vers le cluster secondaire et les promeut en cluster de base de données autonome avec des capacités complètes en lecture/écriture. Tous les autres clusters secondaires de la base de données globale seront toujours disponibles et pourront accepter des appels de lecture depuis votre application.

    Avant de recréer la base de données globale Neptune, vous devrez également détacher les autres clusters secondaires pour éviter les incohérences de données entre les clusters (voirSupprimer un cluster).

  4. Reconfigurez votre application pour envoyer toutes les opérations d'écriture au cluster de base de données Neptune autonome que vous avez choisi de devenir le nouveau cluster principal, à l'aide de son nouveau point de terminaison. Si vous avez accepté les noms par défaut lors de la création de la base de données globale Neptune, vous pouvez modifier le point de terminaison en supprimant-roà partir de la chaîne de point de terminaison du cluster dans votre application.

    Par exemple, le point de terminaison du cluster secondairemy-global.cluster-ro-aaaaaabbbbbb.us-west-1.neptune.amazonaws.comdevientmy-global.cluster-aaaaaabbbbbb.us-west-1.neptune.amazonaws.comlorsque ce cluster est détaché de la base de données globale.

    Ce cluster de bases de données Neptune devient le cluster principal d'une nouvelle base de données globale Neptune lorsque vous commencez à y ajouter des régions lors de l'étape suivante.

  5. Ajoutez une Région AWS au cluster de base de données. Lorsque vous effectuez cette opération, le processus de réplication du cluster primaire vers le cluster secondaire commence. Consultez Ajout de régions de base de données globales secondaires à une région principale dans Amazon Neptune .

  6. Ajoutez d'autres Régions AWS si nécessaire pour recréer la topologie nécessaire à la prise en charge de votre application.

Assurez-vous que les écritures d'application sont envoyées au cluster de bases de données Neptune approprié avant, pendant et après l'application de ces modifications. Cela évite les incohérences de données parmi les clusters de bases de données Neptune globale (ces problèmes sont connus sous le nom de « split-brain »).

Basculement planifié géré pour les Amazon Neptune

Le basculement planifié géré vous permet de relocaliser le cluster principal de votre base de données Neptune globale vers un autreRégion AWSquand tu le souhaites. Certaines organisations souhaiteront changer régulièrement les emplacements de clusters principaux.

Note

Le processus de basculement planifié géré décrit ici est destiné à être utilisé sur une base de données globale Neptune saine. Pour se remettre d'une panne non planifiée ou pour effectuer des tests de reprise après sinistre (DR), suivez ladétacher et promouvoirProcessus à la place.

Lors d'un basculement planifié géré, votre cluster principal est basculé vers la région secondaire de votre choix tandis que la topologie de réplication existante de votre base de données globale est préservée. Avant le début du processus de basculement planifié géré, la base de données globale synchronise tous les clusters secondaires avec son cluster principal. Une fois que tous les clusters sont synchronisés, le basculement planifié géré commence. Le cluster de base de données de la région principale est placé en lecture seule, et le cluster secondaire choisi promeut l'une de ses instances en lecture seule à l'état d'écriture complet, ce qui permet au cluster d'endosser le rôle de cluster principal. Tous les clusters secondaires ayant été synchronisés avec le cluster principal au début du processus, le nouveau cluster principal poursuit les opérations de la base de données globale sans perdre de données. La base de données n'est pas disponible pendant une courte période pendant laquelle les clusters principaux et secondaires sélectionnés endossent leurs nouveaux rôles.

Pour optimiser la disponibilité des applications, effectuez le basculement pendant les heures creuses, à un moment où les écritures sur le cluster de bases de données principal sont minimales. Procédez également comme suit avant de démarrer le basculement :

  • Déconnectez les applications dans la mesure du possible pour réduire les écritures sur le cluster principal.

  • Vérifiez les temps de latence de tous les clusters de bases de données Neptune secondaires dans la base de données globale et choisissez le cluster secondaire présentant le délai global le plus faible pour devenir le principal. Utiliser Amazon CloudWatch pour consulter le pluginNeptuneGlobalDBProgressLagmétrique pour tous les clusters secondaires. Cette métrique indique la distance d'un cluster secondaire par rapport au cluster de bases de données principal, en millisecondes. Sa valeur est directement proportionnelle au temps nécessaire à Neptune pour terminer le basculement. En d'autres termes, plus la valeur de retard est élevée, plus la panne de basculement sera longue. Par conséquent, choisissez le secondaire avec le moins de retard. Pour plus d'informations, consultez Neptune CloudWatch Métriques.

Lors d'un basculement planifié géré, le cluster de base de données secondaire choisi est promu à son nouveau rôle de cluster principal, mais il n'hérite pas de la configuration complète du cluster de base de données principal. Une incompatibilité de configuration peut provoquer des problèmes de performances, des incompatibilités de charge de travail et d'autres comportements anormaux. Pour éviter de tels problèmes, résolvez les types de différences de configuration suivants entre les clusters de bases de données globaux avant le basculement :

  • Configurer les paramètres du nouveau serveur principal pour qu'ils correspondent à ceux du système principal actuel.

  • Configuration des outils, des options et des alarmes de surveillance— Configurez le cluster de bases de données qui sera le nouveau principal avec la même capacité de journalisation, les mêmes alarmes, etc. que le cluster de bases de données principal actuel.

  • Configuration des intégrations avec d'autresAWSservices— Si votre base de données globale Neptune s'intègre àAWSdes services, tels queAWS Identity and Access Management(IAM), Amazon S3 ouAWS Lambda, assurez-vous qu'ils sont configurés selon les besoins pour s'intégrer au nouveau cluster de base de données principal.

Lorsque le processus de basculement est terminé et que le cluster de bases de données promu est prêt à gérer les opérations d'écriture pour la base de données globale, assurez-vous de modifier vos applications pour utiliser le nouveau point de terminaison pour le nouveau serveur principal.

Utilisation deAWS CLIpour initier un basculement planifié géré

Utiliser lefailover-global-clusterCommande CLI (qui encapsule leFailoverGlobalClusterAPI) pour basculer sur votre base de données globale Neptune :

aws neptune failover-global-cluster \ --region (the region where the primary cluster is located) \ --global-cluster-identifier (global database ID) \ --target-db-cluster-identifier (the ARN of the secondary DB cluster to promote)
Note

Dans lafailover-global-clusterL'API n'est pas disponible dans la préversion. Il fera partie de la sortie de l'AG.