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.
Basculement d'Amazon DocumentDB
Dans certains cas, tels que certains types de maintenance planifiée, ou dans le cas peu probable d'une défaillance d'un nœud principal ou d'une zone de disponibilité, Amazon DocumentDB (compatible avec MongoDB) détecte la panne et remplace le nœud principal. Au cours d'un basculement, le délai d'écriture est réduit. En effet, le rôle du nœud principal est transféré à l'un des réplicas en lecture et il n'est pas nécessaire de créer et d'allouer un nouveau nœud principal. La détection d'un échec ou la promotion d'un réplica vous permettent de recommencer à écrire dans le nouveau nœud principal dès que la promotion est terminée.
Pour que le basculement fonctionne, votre cluster doit comporter au moins deux instances : une instance principale et au moins une instance de réplication.
Note
Cette rubrique s'applique uniquement aux clusters originaux basés sur des instances Amazon DocumentDB. Elle ne s'applique pas aux clusters élastiques ou globaux.
Contrôle de la cible de basculement
Amazon DocumentDB vous fournit des niveaux de basculement afin de contrôler quelle instance de réplique est promue en instance principale en cas de basculement.
Niveaux de basculement
Chaque instance de réplique est associée à un niveau de basculement (0 à 15). Lorsqu'un basculement survient en raison d'une maintenance ou d'une défaillance matérielle peu probable, l'instance principale bascule vers une réplique ayant la priorité la plus élevée (le niveau numéroté le plus bas). Si plusieurs répliques ont le même niveau de priorité, le niveau principal bascule vers le réplica de ce niveau dont la taille est la plus proche de celle du niveau principal précédent.
En définissant le niveau de basculement pour un groupe de réplicas sélectionnés pour 0 (la priorité la plus haute), vous pouvez vous assurer qu'un basculement promeut l'un des réplicas dans ce groupe. Une manière efficace d'empêcher que des réplicas spécifiques ne soient promus en principal en cas de basculement consiste à leur attribuer un niveau de priorité faible (chiffre élevé). Cela s'avère utile dans les cas où les réplicas spécifiques font l'objet d'une utilisation intensive de la part d'une application et le basculement vers l'un d'entre eux pourrait avoir un impact négatif sur une application critique.
Vous pouvez définir le niveau de basculement d'une instance lorsque vous la créez ou plus tard en la modifiant. Le définition d'un niveau de basculement d'une instance en modifiant cette dernière ne déclenche pas un basculement. Pour plus d'informations, consultez les rubriques suivantes :
Lorsque vous lancez manuellement un basculement, vous avez deux moyens de contrôler quelle instance de réplica est promue en instance principale : le niveau de basculement comme décrit précédemment, et le paramètre --target-db-instance-identifier.
--target-db-instance-identifier
Pour le test, vous pouvez forcer un événement de basculement à l'aide de l'opération failover-db-cluster. Vous pouvez utiliser le paramètre --target-db-instance-identifier pour spécifier le réplica à promouvoir en réplica principal. L'utilisation du paramètre --target-db-instance-identifier remplace le niveau de priorité de basculement. Si vous ne spécifiez pas le paramètre --target-db-instance-identifier, le basculement principal est conforme au niveau de priorité de basculement.
Que se passe-t-il lors d'un basculement
Le basculement est automatiquement géré par Amazon DocumentDB afin que vos applications puissent reprendre les opérations de base de données le plus rapidement possible sans intervention administrative.
-
Si vous avez une instance de réplique Amazon DocumentDB dans la même zone de disponibilité ou dans une autre zone de disponibilité en cas de basculement : Amazon DocumentDB renverse le nom canonique record CNAME () de votre instance pour qu'il pointe vers la réplique saine, qui est à son tour promue pour devenir la nouvelle instance principale. Le basculement complet s'effectue généralement en 30 secondes.
-
Si vous ne possédez pas d'instance de réplique Amazon DocumentDB (par exemple, un cluster d'instances unique) : Amazon DocumentDB tentera de créer une nouvelle instance dans la même zone de disponibilité que l'instance d'origine. Ce remplacement de l'instance d'origine s'effectue de manière optimale et peut échouer si, par exemple, un problème affecte de manière générale la zone de disponibilité.
Votre application devrait tenter une nouvelle connexion à la base de données dans le cas d'une perte de connexion.
Test du basculement
En cas de basculement d'un cluster, l'une des répliques Amazon DocumentDB (instances en lecture seule) du cluster devient l'instance principale (le rédacteur du cluster).
Lorsque l'instance principale échoue, Amazon DocumentDB bascule automatiquement vers une réplique Amazon DocumentDB, le cas échéant. Vous pouvez forcer un basculement lorsque vous souhaitez simuler un échec d'une instance principale à des fins de test. Chaque instance d'un cluster possède sa propre adresse de point de terminaison. Vous devez donc nettoyer et rétablir toutes les connexions existantes qui utilisent ces adresses de point de terminaison lorsque le basculement est effectué.
Pour forcer un basculement, utilisez l'opération failover-db-cluster avec ces paramètres.
-
--db-cluster-identifier: obligatoire. Nom du cluster qui doit basculer. -
--target-db-instance-identifier—Facultatif. Le nom de l'instance à promouvoir comme instance principale.
L'opération suivante force un basculement du cluster sample-cluster. Il ne précise pas quelle instance doit être créée comme nouvelle instance principale. Amazon DocumentDB choisit donc l'instance en fonction de la priorité du niveau de basculement.
Pour Linux, macOS ou Unix :
aws docdb failover-db-cluster \ --db-cluster-identifier sample-cluster
Pour Windows :
aws docdb failover-db-cluster ^ --db-cluster-identifier sample-cluster
L'opération suivante force un basculement du cluster sample-cluster, en spécifiant quelle sample-cluster-instance est à promouvoir en tant que rôle principal. (Notez la valeur "IsClusterWriter": true dans la sortie).
Pour Linux, macOS ou Unix :
aws docdb failover-db-cluster \ --db-cluster-identifier sample-cluster \ --target-db-instance-identifier sample-cluster-instance
Pour Windows :
aws docdb failover-db-cluster ^ --db-cluster-identifier sample-cluster ^ --target-db-instance-identifier sample-cluster-instance
Le résultat de cette opération ressemble à ce qui suit (JSONformat).
{
"DBCluster": {
"HostedZoneId": "Z2SUY0A1719RZT",
"Port": 27017,
"EngineVersion": "3.6.0",
"PreferredMaintenanceWindow": "thu:04:05-thu:04:35",
"BackupRetentionPeriod": 1,
"ClusterCreateTime": "2018-06-28T18:53:29.455Z",
"AssociatedRoles": [],
"DBSubnetGroup": "default",
"MasterUsername": "master-user",
"Engine": "docdb",
"ReadReplicaIdentifiers": [],
"EarliestRestorableTime": "2018-08-21T00:04:10.546Z",
"DBClusterIdentifier": "sample-cluster",
"ReaderEndpoint": "sample-cluster.node.us-east-1.docdb.amazonaws.com",
"DBClusterMembers": [
{
"DBInstanceIdentifier": "sample-cluster-instance",
"DBClusterParameterGroupStatus": "in-sync",
"PromotionTier": 1,
"IsClusterWriter": true
},
{
"DBInstanceIdentifier": "sample-cluster-instance-00",
"DBClusterParameterGroupStatus": "in-sync",
"PromotionTier": 1,
"IsClusterWriter": false
},
{
"DBInstanceIdentifier": "sample-cluster-instance-01",
"DBClusterParameterGroupStatus": "in-sync",
"PromotionTier": 1,
"IsClusterWriter": false
}
],
"AvailabilityZones": [
"us-east-1b",
"us-east-1c",
"us-east-1a"
],
"DBClusterParameterGroup": "default.docdb3.6",
"Endpoint": "sample-cluster.node.us-east-1.docdb.amazonaws.com",
"IAMDatabaseAuthenticationEnabled": false,
"AllocatedStorage": 1,
"LatestRestorableTime": "2018-08-22T21:57:33.904Z",
"PreferredBackupWindow": "00:00-00:30",
"StorageEncrypted": false,
"MultiAZ": true,
"Status": "available",
"DBClusterArn": "arn:aws:rds:us-east-1:123456789012:cluster:sample-cluster",
"VpcSecurityGroups": [
{
"Status": "active",
"VpcSecurityGroupId": "sg-12345678"
}
],
"DbClusterResourceId": "cluster-ABCDEFGHIJKLMNOPQRSTUVWXYZ"
}
}