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 d'Amazon Neptune avec une base de données mondiale
Une base de données mondiale Amazon Neptune couvre plusieurs bases de données Régions AWS, ce qui permet des lectures globales à faible latence et une restauration rapide dans les rares cas où une panne affecte l'ensemble d'une base de données. Région AWS
Une base de données Neptune globale se compose d'un cluster de bases de données principal dans une région et de jusqu'à cinq clusters de bases de données secondaires dans différentes régions.
Les écritures ne peuvent avoir lieu que dans la région principale. Les régions secondaires ne prennent en charge que les lectures. Chaque région secondaire peut comporter jusqu'à 16 instances de lecteur.
## Bases de données mondiales dans Amazon Neptune
En utilisant une base de données Neptune globale, vous pouvez exécuter vos applications distribuées dans le monde entier à l'aide d'une base de données unique couvrant plusieurs régions Régions AWS.
Une base de données Neptune globale se compose d'un cluster de bases de données principal dans une Région AWS principale et de jusqu'à cinq clusters de bases de données en lecture seule dans des Régions AWS secondaires. Lorsque vous effectuez une opération d'écriture dans le cluster de bases de données principal, Neptune réplique les données écrites dans tous les clusters de bases de données secondaires à l'aide d'une infrastructure dédiée, avec une latence généralement inférieure à une seconde.
Le schéma suivant montre un exemple de base de données globale qui comprend deux Régions AWS bases de données :
![\[Une base de données Neptune globale dispose d'un cluster de bases de données principal et d'au moins un cluster de bases de données secondaire.\]](http://docs.aws.amazon.com/fr_fr/neptune/latest/userguide/images/neptune-gdb-example.png)
Vous pouvez mettre à l'échelle chaque cluster secondaire indépendamment pour gérer les charges de travail en lecture seule en ajoutant une ou plusieurs instances de réplica en lecture.
Pour effectuer des opérations d'écriture, vous devez vous connecter au point de terminaison du cluster de bases de données principal. Seul le cluster principal peut exécuter les opérations d'écriture. Ensuite, comme le montre le schéma ci-dessus, la réplication est effectuée par le [volume de stockage du cluster](feature-overview-storage.md), et non par le moteur de base de données.
Les bases de données Neptune globales sont conçues pour les applications ayant une empreinte mondiale. Les clusters de bases de données secondaires en lecture seule prennent en charge les opérations de lecture au plus près des utilisateurs de l'application.
Une base de données Neptune globale permet deux approches différentes de basculement.
+ Pour effectuer une reprise après une panne dans la région principale, utilisez le detach-and-promote processus [manuel non planifié](neptune-gdb-disaster-recovery.md#neptune-gdb-detach-and-promote), qui consiste à détacher l'un des clusters secondaires, à le transformer en cluster autonome, puis à le promouvoir en tant que nouveau cluster principal.
+ Pour les procédures opérationnelles planifiées telles que la maintenance, utilisez le [basculement planifié géré](neptune-gdb-disaster-recovery.md#neptune-gdb-managed-failover), dans lequel vous déplacez le cluster principal vers l'une de ses régions secondaires sans perte de données.
## Avantages liés à l'utilisation de bases de données globales dans Amazon Neptune
En utilisant une base de données Neptune globale, vous bénéficiez des avantages suivants :
+ **Lectures globales avec latence locale** : si vous avez des bureaux répartis dans le monde entier, une base de données globale permet à ceux qui se trouvent dans les régions secondaires d'accéder aux données dans leur propre région avec une latence locale.
+ **Clusters de bases de données Neptune secondaires évolutifs** : vous pouvez mettre à l'échelle les clusters secondaires en ajoutant d'autres instances de réplicas en lecture seule. Comme les clusters secondaires sont en lecture seule, ils peuvent chacun prendre en charge jusqu'à 16 réplicas en lecture plutôt que la limite habituelle qui s'élève à 15 réplicas.
+ **Réplication rapide vers les clusters de bases de données secondaires** : la réplication des clusters de bases de données principaux vers les clusters secondaires est rapide, avec une latence généralement en dessous d'une seconde et un impact moindre sur les performances du cluster de bases de données principal. La réplication étant effectuée au niveau du stockage, les ressources de l'instance de base de données sont entièrement disponibles pour les charges de travail de lecture et d'écriture des applications.
+ **Récupération suite aux pannes à l'échelle de la région** : les clusters de bases de données secondaires vous permettent de déplacer une base de données globale vers une nouvelle région plus rapidement, avec un RTO moins élevé et avec moins de perte de données (RPO plus faible) que les solutions de réplication traditionnelles.
## Limitations des bases de données globales Amazon Neptune
Les limitations suivantes s'appliquent actuellement aux bases de données globales :
+ Les bases de données globales Neptune sont disponibles dans les Régions AWS suivantes :
+ USA Est (Virginie du Nord) : `us-east-1`
+ USA Est (Ohio) : `us-east-2`
+ USA Ouest (Californie du Nord) : `us-west-1`
+ USA Ouest (Oregon) : `us-west-2`
+ Canada-Ouest (Calgary) : `ca-west-1`
+ Europe (Espagne) : `eu-south-2`
+ Europe (Irlande) : `eu-west-1`
+ Europe (Londres) : `eu-west-2`
+ Europe (Francfort) : `eu-central-1`
+ Asie-Pacifique (Tokyo) : `ap-northeast-1`
+ Asie-Pacifique (Osaka) : `ap-northeast-3`
+ Asie-Pacifique (Singapour) : `ap-southeast-1`
+ Asie-Pacifique (Jakarta) : `ap-southeast-3`
+ Asie-Pacifique (Melbourne) : `ap-southeast-4`
+ Asie-Pacifique (Malaisie) : `ap-southeast-5`
+ Israël (Tel Aviv) : `il-central-1`
+ Les bases de données globales Neptune ne prennent pas en charge les types `db.t3.medium` d'`db.t4g.medium`instance.
+ Les bases de données globales Neptune ne prennent pas en charge l'autoscaling pour les clusters de bases de données secondaires.
+ Vous ne pouvez pas appliquer un groupe de paramètres personnalisés au cluster de bases de données globale pendant que vous effectuez une mise à niveau majeure de la version de cette base de données globale. À la place, créez vos groupes de paramètres personnalisés dans chaque région du cluster global, puis appliquez-les manuellement aux clusters régionaux après la mise à niveau.
+ Vous ne pouvez pas arrêter ni démarrer les clusters de bases de données dans une base de données globale individuellement.
+ Les instances de réplication en lecture d'un cluster de base de données secondaire peuvent redémarrer dans certaines circonstances, notamment lors des mises à niveau planifiées pendant votre période de maintenance. Si l'instance d'enregistreur du cluster de bases de données principal redémarre ou bascule, toutes les instances des régions secondaires redémarrent également. Le cluster secondaire n'est pas disponible tant que tous les réplicas ne sont pas de nouveau synchronisés avec l'instance d'enregistreur du cluster de bases de données principal.
# Configuration d'une base de données mondiale Amazon Neptune
Vous pouvez créer une base de données Neptune globale de l'une des manières suivantes :
+ [Créez une base de données globale avec de nouveaux clusters de bases de données et de nouvelles instances de base de données](#neptune-gdb-creating-cli).
+ [Créez une base de données globale en utilisant un cluster de bases de données Neptune existant comme cluster principal](#neptune-gdb-add-existing).
**Topics**
+ [Exigences de configuration d'une base de données globale dans Amazon Neptune](#neptune-gdb-setup-config)
+ [Utilisation du AWS CLI pour créer une base de données globale dans Amazon Neptune](#neptune-gdb-creating-cli)
+ [Conversion d'un cluster de bases de données existant en base de données globale](#neptune-gdb-add-existing)
+ [Ajout de régions de base de données globales secondaires à une région principale dans Amazon Neptune](#neptune-gdb-attaching)
+ [Connexion à une base de données Neptune globale](#neptune-gdb-connect)
## Exigences de configuration d'une base de données globale dans Amazon Neptune
Une base de données mondiale Neptune comprend au moins deux bases de données. Régions AWS La Région AWS principale contient un cluster de bases de données Neptune qui dispose d'une seule instance d'enregistreur. Une à cinq Régions AWS secondaires contiennent chacune un cluster de bases de données Neptune en lecture seule entièrement composé d'instances de réplica en lecture. Au moins un secondaire Région AWS est requis.
Les exigences spécifiques suivantes s'appliquent aux clusters de bases de données Neptune qui composent une base de données globale :
+ **Exigences relatives aux classes d'instances de base de données** : une base de données globale nécessite des classes d'instances de base de données `r5` ou `r6g` optimisées pour les charges de travail gourmandes en mémoire, telles qu'un type d'instance `db.r5.large`.
+ **Région AWS exigences** — Une base de données globale a besoin d'un cluster de base de données Neptune principal dans un Région AWS cluster de base de données Neptune et d'au moins un cluster de base de données Neptune secondaire dans une région différente. Vous pouvez créer jusqu'à cinq clusters de bases de données Neptune secondaires en lecture seule, chacun dans une région différente. En d'autres termes, deux clusters de bases de données Neptune d'une base de données globale Neptune ne peuvent pas se trouver dans la même Région AWS.
+ **Exigences relatives à la version du moteur** : la version de moteur Neptune utilisée par tous les clusters de bases de données de la base de données globale doit être identique et doit être supérieure ou égale à. `1.2.0.0` Si vous ne spécifiez pas la version du moteur lors de la création d'une base de données globale, d'un cluster ou d'une instance, la version du moteur la plus récente est utilisée.
**Important**
Bien que les groupes de paramètres du cluster de bases de données puissent être configurés indépendamment pour chaque cluster d'une base de données globale, il est préférable de veiller à la cohérence des paramètres entre les clusters afin d'éviter des changements de comportement inattendus au cas où un cluster secondaire serait promu au statut principal. Par exemple, utilisez les mêmes paramètres pour les index d'objets, les flux, etc. dans tous les clusters de bases de données.
## Utilisation du AWS CLI pour créer une base de données globale dans Amazon Neptune
**Note**
Les exemples présentés dans cette section suivent la convention UNIX qui consiste à utiliser une barre oblique inverse (`\`) comme caractère d'extension de ligne. Pour Windows, remplacez la barre oblique inverse par un accent circonflexe (`^`).
**Pour créer une base de données globale à l'aide du AWS CLI**
1. Commencez par créer une base de données globale vide à l'aide de la `[create-global-cluster](https://docs.aws.amazon.com/cli/latest/reference/neptune/create-global-cluster.html)` AWS CLI commande (qui enveloppe l'[CreateGlobalCluster](api-global-dbs.md#CreateGlobalCluster)API). Spécifiez le nom de la Région AWS que vous souhaitez utiliser comme région principale, définissez Neptune comme moteur de base de données et, si vous le souhaitez, spécifiez la version du moteur que vous souhaitez utiliser (il doit s'agir de la version 1.2.0.0 ou supérieure) :
```
aws neptune create-global-cluster
--region (primary region, such as us-east-1) \
--global-cluster-identifier (ID for the global database) \
--engine neptune \
--engine-version (engine version; this is optional)
```
1. Quelques minutes peuvent s'écouler avant que la base de données globale ne soit disponible. Par conséquent, avant de passer à l'étape suivante, utilisez la commande d'interface `[describe-global-clusters](https://docs.aws.amazon.com/cli/latest/reference/neptune/describe-global-clusters.html)` (qui enveloppe l'API [DescribeGlobalClusters](api-global-dbs.md#DescribeGlobalClusters)) pour vérifier que la base de données globale est disponible :
```
aws neptune describe-global-clusters \
--region (primary region) \
--global-cluster-identifier (global database ID)
```
1. Une fois que la base de données globale Neptune est disponible, vous pouvez créer un cluster de bases de données Neptune qui sera son cluster principal :
```
aws neptune create-db-cluster \
--region (primary region) \
--db-cluster-identifier (ID for the primary DB cluster) \
--engine neptune \
--engine-version (engine version; must be >= 1.2.0.0) \
--global-cluster-identifier (global database ID)
```
1. Utilisez la `[describe-db-clusters](https://docs.aws.amazon.com/cli/latest/reference/neptune/describe-db-clusters.html)` AWS CLI commande pour confirmer que le nouveau cluster de base de données est prêt pour que vous puissiez ajouter son instance de base de données principale :
```
aws neptune describe-db-clusters \
--region (primary region) \
--db-cluster-identifier (primary DB cluster ID)
```
Lorsque la réponse affiche `"Status": "available"`, passez à l'étape suivante.
1. Créez l'instance de base de données principale pour le cluster principal à l'aide de la `[create-db-instance](https://docs.aws.amazon.com/cli/latest/reference/neptune/create-db-instance.html)` AWS CLI commande. Vous devez utiliser l'un des types d'instance `r5` ou `r6g` optimisés pour la mémoire, tels que `db.r5.large`.
```
aws neptune create-db-instance \
--region (primary region) \
--db-cluster-identifier (primary cluster ID) \
--db-instance-class (instance class) \
--db-instance-identifier (ID for the DB instance) \
--engine neptune \
--engine-version (optional: engine version)
```
**Note**
Si vous prévoyez d'ajouter des données au nouveau cluster de bases de données principal à l'aide du chargeur en bloc Neptune, procédez *avant* d'ajouter des régions secondaires. Cette approche est plus rapide et plus rentable que d'effectuer un chargement en bloc une fois la base de données globale entièrement configurée.
Ajoutez maintenant une ou plusieurs régions secondaires à la nouvelle base de données globale, comme décrit dans la section [Ajouter une région secondaire à l'aide du AWS CLI](#neptune-gdb-attach-cli).
## Conversion d'un cluster de bases de données existant en base de données globale
Pour transformer un cluster de bases de données existant en base de données globale, utilisez la `[create-global-cluster](https://docs.aws.amazon.com/cli/latest/reference/neptune/create-global-cluster.html)` AWS CLI commande pour créer une nouvelle base de données globale dans le même emplacement Région AWS que le cluster de bases de données existant, et définissez son `--source-db-cluster-identifier` paramètre sur le nom de ressource Amazon (ARN) du cluster existant qui s'y trouve :
```
aws neptune create-global-cluster \
--region (region where the existing cluster is located) \
--global-cluster-identifier (provide an ID for the new global database) \
--source-db-cluster-identifier (the ARN of the existing DB cluster) \
--engine neptune \
--engine-version (engine version; this is optional)
```
Ajoutez maintenant une ou plusieurs régions secondaires à la nouvelle base de données globale, comme décrit dans la section [Ajouter une région secondaire à l'aide du AWS CLI](#neptune-gdb-attach-cli).
### Utilisation d'un cluster de bases de données restauré à partir d'un instantané comme cluster principal
Vous pouvez convertir un cluster de bases de données restauré en base de données globale Neptune à partir d'un instantané. Une fois la restauration terminée, convertissez le cluster de bases de données créé en cluster principal d'une nouvelle base de données globale, comme décrit ci-dessus.
## Ajout de régions de base de données globales secondaires à une région principale dans Amazon Neptune
Une base de données globale Neptune a besoin d'au moins un cluster de base de données Neptune secondaire dans un cluster de base de données Région AWS différent du cluster de base de données principal. Vous pouvez attacher jusqu'à cinq clusters de bases de données secondaires au cluster de bases de données principal.
Chaque cluster de bases de données secondaire que vous ajoutez réduit d'une unité le nombre maximum d'instances de réplicas en lecture que vous pouvez avoir sur le cluster principal. Par exemple, s'il existe quatre clusters secondaires, le nombre maximum d'instances de réplica en lecture que vous pouvez avoir sur le cluster principal est de `15 - 4 = 11`. Par exemple, si vous avez 14 instances de lecteur dans le cluster de bases de données principal et un seul cluster secondaire, vous ne pouvez pas ajouter de cluster secondaire.
### Utilisation du AWS CLI pour ajouter une région secondaire à une base de données globale dans Neptune
**Pour ajouter une base de données secondaire Région AWS à une base de données globale Neptune à l'aide du AWS CLI**
1. Utilisez la `[create-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/neptune/create-db-cluster.html)` AWS CLI commande pour créer un nouveau cluster de base de données dans une région différente de celle de votre cluster principal et définissez son `--global-cluster-identifier` paramètre pour spécifier l'ID de la base de données globale :
```
aws neptune create-db-cluster \
--region (the secondary region) \
--db-cluster-identifier (ID for the new secondary DB cluster) \
--global-cluster-identifier (global database ID)
--engine neptune \
--engine-version (optional: engine version)
```
1. Utilisez la `[describe-db-clusters](https://docs.aws.amazon.com/cli/latest/reference/neptune/describe-db-clusters.html)` AWS CLI commande pour confirmer que le nouveau cluster de base de données est prêt pour que vous puissiez ajouter son instance de base de données principale :
```
aws neptune describe-db-clusters \
--region (primary region) \
--db-cluster-identifier (primary DB cluster ID)
```
Lorsque la réponse affiche `"Status": "available"`, passez à l'étape suivante.
1. Créez l'instance de base de données principale pour le cluster principal à l'aide de la `[create-db-instance](https://docs.aws.amazon.com/cli/latest/reference/neptune/create-db-instance.html)` AWS CLI commande, en utilisant un type d'instance dans la classe d'`r6g`instance `r5` or :
```
aws neptune create-db-instance \
--region (secondary region) \
--db-cluster-identifier (secondary cluster ID) \
--db-instance-class (instance class) \
--db-instance-identifier (ID for the DB instance) \
--engine neptune \
--engine-version (optional: engine version)
```
**Note**
Si vous n'avez pas l'intention de traiter un grand nombre de demandes de lecture dans la région secondaire et que vous souhaitez principalement y conserver vos données de manière fiable, vous pouvez créer un cluster de bases de données secondaire sans instances de base de données. Vous réalisez ainsi des économies, car vous ne payez alors que les frais correspondant au stockage du cluster secondaire, que Neptune synchronisera avec le stockage du cluster de bases de données principal.
## Connexion à une base de données Neptune globale
Vous ne vous connectez pas de la même façon à une base de données Neptune globale selon que vous devez y écrire ou y lire des données :
+ Pour les demandes ou requêtes en lecture seule, vous vous connectez au point de terminaison de lecteur du cluster Neptune dans votre Région AWS.
+ Pour exécuter des requêtes de mutation, connectez-vous au point de terminaison du cluster de base de données principal, qui peut se trouver dans une autre application Région AWS que celle de votre application.
# Gestion d'une base de données Amazon Neptune globale
À l'exception du processus de basculement planifié géré, vous effectuez la plupart des opérations de gestion sur les clusters individuels constituant une base de données Neptune globale. Le processus de basculement planifié géré est disponible uniquement pour les bases de données Neptune globales, pas pour les clusters de bases de données Neptune individuels. Pour en savoir plus, veuillez consulter la section [Basculement planifié géré pour les bases de données Neptune globales](neptune-gdb-disaster-recovery.md#neptune-gdb-managed-failover).
Pour restaurer une base de données Neptune globale suite à une panne non planifiée dans sa région principale, consultez [Detach-and-promote une base de données globale Neptune en cas de panne imprévue](neptune-gdb-disaster-recovery.md#neptune-gdb-detach-and-promote).
Vous pouvez configurer les groupes de paramètres de cluster de bases de données indépendamment pour chaque cluster Neptune d'une base de données globale, mais il est préférable d'utiliser des paramètres cohérents entre tous les clusters afin d'éviter tout comportement inattendu en cas de promotion d'un cluster secondaire en tant que cluster principal. Par exemple, utilisez les mêmes paramètres pour les index d'objets, les flux, etc. dans tous les clusters de bases de données.
# Dissociation d'un cluster d'une base de données Neptune globale
Il existe plusieurs raisons pour lesquelles vous pouvez souhaiter supprimer un cluster de bases de données d'une base de données globale. Par exemple :
+ Si le cluster principal se dégrade ou devient isolé, vous pouvez le supprimer de la base de données globale pour qu'il devienne un cluster provisionné autonome qui permettra de créer une autre base de données globale (voir [Detach-and-promote une base de données globale Neptune en cas de panne imprévue](neptune-gdb-disaster-recovery.md#neptune-gdb-detach-and-promote)).
+ Pour supprimer une base de données globale, vous devez d'abord supprimer (dissocier) tous les clusters associés en vous occupant du cluster principal en dernier (voir [Suppression d'une base de données Neptune globale](neptune-gdb-deleting.md)).
Vous pouvez utiliser la commande [remove-from-global-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/remove-from-global-cluster.html)CLI (qui enveloppe l'[RemoveFromGlobalCluster](api-global-dbs.md#RemoveFromGlobalCluster)API) pour détacher un cluster de base de données Neptune d'une base de données globale :
```
aws neptune remove-from-global-cluster \
--region (region of the cluster to remove) \
--global-cluster-identifier (global database ID) \
--db-cluster-identifier (ARN of the cluster to remove)
```
Le cluster de bases de données dissocié devient alors un cluster de bases de données autonome.
# Suppression d'une base de données Neptune globale
Vous ne pouvez pas supprimer une base de données globale et les clusters associés en une seule étape. Au lieu de cela, vous devez supprimer ses composants un par un :
1. Dissociez tous les clusters de bases de données secondaires de la base de données globale, comme décrit dans [Suppression d'un cluster](neptune-gdb-detaching.md). Si vous le souhaitez, vous pouvez maintenant les supprimer individuellement.
1. Dissociez le cluster de bases de données principal de la base de données globale.
1. Supprimez toutes les instances de base de données de réplica en lecture du cluster principal.
1. Supprimez l'instance de base de données principale (enregistreur) du cluster principal. Si vous effectuez cette opération sur la console, le cluster de bases de données est également supprimé.
1. Supprimez la base de données globale elle-même. Pour ce faire AWS CLI, utilisez la commande [delete-global-cluster](https://docs.aws.amazon.com/cli/latest/reference/neptune/delete-global-cluster.html)CLI (qui enveloppe l'[DeleteGlobalCluster](api-global-dbs.md#DeleteGlobalCluster)API), comme suit :
```
aws neptune delete-global-cluster \
--region (region of the DB cluster to delete) \
--global-cluster-identifier (global database ID)
```
# Modification d'une base de données globale Neptune
Les groupes de paramètres du cluster de bases de données peuvent être configurés indépendamment pour chaque cluster d'une base de données Neptune globale. Toutefois, il est préférable de veiller à la cohérence des paramètres entre les clusters afin d'éviter des changements de comportement inattendus au cas où un cluster secondaire serait promu au statut principal.
Vous pouvez modifier les paramètres de la base de données globale elle-même à l'aide de la commande [modify-global-cluster](https://docs.aws.amazon.com/cli/latest/reference/neptune/modify-global-cluster.html)CLI (qui enveloppe l'[ModifyGlobalCluster](api-global-dbs.md#ModifyGlobalCluster)API). Par exemple, vous pouvez modifier l'identifiant de la base de données globale tout en désactivant la protection contre la suppression comme suit :
```
aws neptune modify-global-cluster \
--region (region of the DB cluster to modify) \
--global-cluster-identifier (current global database ID) \
--new-global-cluster-identifier (new global database ID to assign) \
--no-deletion-protection
```
# Exécution d'une reprise après sinistre \$1 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 de l'objectif de délai de reprise (RTO) et de l'objectif de point de reprise (RPO) :
+ **Objectif de délai de reprise (RTO)** : rapidité avec laquelle un système revient à un état de fonctionnement normal après un sinistre. En d’autres termes, le RTO mesure la durée d’indisponibilité. Pour une base de données Neptune globale, le RTO peut être de l'ordre de quelques minutes.
+ **Objectif de point de reprise (RPO)** : 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 (voir [Basculement planifié géré pour les bases de données Neptune globales](#neptune-gdb-managed-failover)).
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. Pour ce processus, le RTO manuel dépend de la rapidité avec laquelle vous pouvez effectuer les tâches répertoriées dans [Dissociation et promotion](#neptune-gdb-detach-and-promote). Le RPO est généralement mesuré en secondes, mais cela dépend du retard de réplication du stockage sur le réseau au moment de l'interruption.
+ **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. Étant donné que cette fonction synchronise les clusters de bases de données secondaires avec le cluster principal avant toute modification, le RPO est égal à 0 (aucune donnée perdue). Consultez [Basculement planifié géré pour les bases de données Neptune globales](#neptune-gdb-managed-failover).
## 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.
1. 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.
1. 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 de base de données secondaire d'une base de données globale Neptune arrête immédiatement la réplication des données du cluster principal vers ce cluster secondaire et en fait un cluster de base de données autonome doté de fonctionnalités complètes. read/write 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](neptune-gdb-detaching.md)).
1. 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.
1. 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](neptune-gdb-setup.md#neptune-gdb-attaching).
1. 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](#neptune-gdb-detach-and-promote) 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 Neptune CloudWatch](cw-metrics.md).
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 Gestion des identités et des accès AWS 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 commande [failover-global-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/failover-global-cluster.html)CLI (qui enveloppe l'[FailoverGlobalCluster](api-global-dbs.md#FailoverGlobalCluster)API) 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)
```
# Surveillance de votre base de données mondiale Amazon Neptune à l'aide de métriques CloudWatch
Neptune prend en charge les CloudWatch mesures suivantes que vous pouvez utiliser pour surveiller une base de données globale Neptune :
+ **`GlobalDbDataTransferBytes`**— Le nombre d'octets de données de journalisation transférés du primaire Région AWS vers le secondaire Région AWS dans une base de données globale Neptune.
+ **`GlobalDbReplicatedWriteIO`**— Nombre d' I/O opérations d'écriture répliquées depuis le volume principal Région AWS de la base de données globale vers le volume de cluster d'un volume secondaire Région AWS.
Les calculs de facturation pour chaque cluster de bases de données dans une base de données globale Neptune utilisent la métrique `VolumeWriteIOPS` pour prendre en compte les écritures effectuées dans ce cluster. Pour le cluster de bases de données principal, les calculs de facturation utilisent `NeptuneGlobalDbReplicatedWriteIO` afin de prendre en compte la réplication entre régions vers les clusters de bases de données secondaires.
+ **`GlobalDbProgressLag`** : retard du cluster secondaire en millisecondes par rapport au cluster principal pour les transactions utilisateur et système.
| Métrique | Dimension | Publiée dans | Unités |
| --- | --- | --- | --- |
| `GlobalDbDataTransferBytes` | SourceRegion, DBCluster Identifiant | Secondary | Octets |
| `GlobalDbReplicatedWriteIO` | SourceRegion, DBCluster Identifiant | Secondary | Nombre |
| `GlobalDbProgressLag` | DBClusterIdentifiant, SecondaryRegion : dans DBCluster Identifiant principal, SourceRegion : dans secondaire | Principal, secondaire | Millisecondes |