Exécution d'une reprise après sinistre | Amazon Neptune - Amazon Neptune
Dissociation et promotionBasculement planifié géré

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.

Exécution d'une reprise après sinistre | Amazon Neptune

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

  • Objectif de temps de restauration (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, il RTO mesure les temps d'arrêt. Pour une base de données mondiale Neptune, cela RTO peut être de l'ordre de quelques minutes.

  • Objectif du point de restauration (RPO) : durée pendant laquelle les données sont perdues. Pour une base de données mondiale Neptune, elle RPO est généralement mesurée en secondes (voirBasculement planifié géré pour les bases de données Neptune globales).

Une base de données Neptune globale permet deux approches différentes de basculement :

  • Detach-and-promote (restauration non planifiée manuelle) — Pour effectuer une restauration après une panne imprévue ou pour effectuer des tests de reprise après sinistre (test DR), effectuez une opération entre régions detach-and-promote sur l'un des clusters de base de données secondaires de la base de données globale. Ce processus manuel dépend de la rapidité avec laquelle vous pouvez effectuer les tâches répertoriées dansDissociation et promotion. RTO RPOIl s'agit généralement d'un nombre de secondes, mais cela dépend du délai 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 aux autres procédures opérationnelles planifiées, telles que le déplacement du cluster 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 les clusters principaux avant d'apporter d'autres modifications, il RPO est effectivement égal à 0 (c'est-à-dire qu'il n'y a aucune perte de données). Consultez Basculement planifié géré pour les bases de données Neptune globales.

Detach-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 globale Neptune subit une panne inattendue dans sa base de données principale Région AWS, votre cluster de base de données Neptune principal et son nœud d'écriture deviennent indisponibles, et la réplication entre le cluster principal et les secondaires cesse. Pour minimiser à la fois les temps d'arrêt (RTO) et les pertes 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 d'avoir une stratégie en place pour agir rapidement dès les premiers signes d'un problème à l'échelle de la région.

  • Utilisez Amazon CloudWatch régulièrement pour suivre les temps de latence des clusters secondaires afin d'identifier la région secondaire présentant le moins de latence en cas de basculement.

  • Assurez-vous de tester cette stratégie 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 interruption 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. Identifiez un cluster de base de données dans un cluster secondaire Région AWS à utiliser comme nouveau cluster de base de données principal de la base de données globale. Si la base de données globale compte deux Régions AWS secondaires (ou plus), choisissez le cluster secondaire ayant le retard le moins important.

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

    La suppression d'un cluster secondaire d'une base de données Neptune globale interrompt immédiatement la réplication des données du cluster principal vers le cluster secondaire et le promeut en tant que cluster de bases de données autonome avec des fonctionnalités complètes en lecture/écriture. Tous les autres clusters secondaires de la base de données globale restent disponibles et peuvent accepter les appels de lecture à partir de votre application.

    Avant de recréer la base de données Neptune globale, vous devez également dissocier les autres clusters secondaires pour éviter les incohérences de données entre clusters (voir Suppression d'un cluster).

  4. Reconfigurez votre application pour envoyer toutes les opérations d'écriture au cluster de bases de données Neptune autonome que vous avez choisi en tant que 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 Neptune globale, vous pouvez modifier le point de terminaison en supprimant -ro de la chaîne du point de terminaison de cluster dans votre application.

    Par exemple, le point de terminaison du cluster secondaire my-global.cluster-ro-aaaaaabbbbbb.us-west-1.neptune.amazonaws.com devient my-global.cluster-aaaaaabbbbbb.us-west-1.neptune.amazonaws.com lorsque ce cluster est dissocié 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 Neptune globale lorsque vous commencez à y ajouter des régions lors de l'étape suivante.

  5. Ajoutez un 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-en Régions AWS d'autres si nécessaire pour recréer la topologie requise pour prendre en charge 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 la base de données Neptune globale (ce que l'on appelle aussi « problèmes de split-brain »).

Basculement planifié géré pour les bases de données Neptune globales

Le basculement planifié géré vous permet de déplacer le cluster principal de votre base de données globale Neptune vers un autre Région AWS cluster quand vous le souhaitez. Certaines organisations préfèrent changer régulièrement l'emplacement de leur cluster principal.

Note

Le processus de basculement planifié géré décrit ici est conçu pour être utilisé sur une base de données Neptune globale saine. Pour se remettre d'une interruption non planifiée ou pour effectuer des tests de reprise après sinistre, suivez plutôt le processus de dissociation et de promotion de cluster.

Lors d'un basculement planifié géré, le cluster principal est basculé vers la région secondaire de votre choix tandis que la topologie de réplication existante de la base de données globale est conservé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 bases de données dans la région principale devient en lecture seule, et le cluster secondaire choisi promeut l'une de ses instances en lecture seule au statut d'enregistreur complet, permettant ainsi au cluster d'endosser le rôle de cluster principal. Comme tous les clusters secondaires ont é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 est uniquement indisponible pendant une courte période durant laquelle le cluster principal et les clusters secondaires sélectionnés endossent leur nouveau rôle.

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 :

  • Mettez les applications hors ligne dans la mesure du possible afin de réduire les écritures sur le cluster principal.

  • Vérifiez les temps de latence pour tous les clusters Neptune secondaires dans la base de données globale et choisissez le cluster secondaire présentant le moins de retard global pour qu'il devienne le cluster principal. Utilisez Amazon CloudWatch pour consulter les statistiques NeptuneGlobalDBProgressLag de tous les établissements secondaires. Cette métrique indique le retard d'un cluster secondaire (en millisecondes) par rapport au cluster de bases de données principal. 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 le basculement sera long. Choisissez donc le cluster secondaire avec le moins de retard. Pour plus d’informations, consultez Métriques de Neptune CloudWatch .

Au cours d'un basculement planifié géré, le cluster de bases 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 bases 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, corrigez les types de différences de configuration suivants entre les clusters de la base de données globale avant le basculement :

  • Configurez les paramètres du nouveau cluster principal pour qu'ils correspondent à ceux du cluster principal actuel.

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

  • Configurez les intégrations avec d'autres AWS services : si votre base de données globale Neptune s'intègre AWS à des services AWS Identity and Access Management tels que IAM (), Amazon S3, AWS Lambda ou assurez-vous que ceux-ci 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, veillez à modifier vos applications afin qu'elles utilisent le nouveau point de terminaison du nouveau cluster principal.

Utilisation du AWS CLI pour lancer un basculement planifié géré

Utilisez la failover-global-clusterCLIcommande (qui enveloppe le FailoverGlobalClusterAPI) 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

failover-global-clusterAPIIl n'est pas disponible dans l'aperçu. Elle fera partie de la version GA.