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.
# Migration vers Amazon DocumentDB
Amazon DocumentDB est un service de base de données entièrement géré compatible avec l'API MongoDB. Vous pouvez migrer vos données vers Amazon DocumentDB à partir de bases de données MongoDB exécutées sur site ou sur Amazon Elastic Compute Cloud (Amazon EC2) en suivant le processus détaillé dans cette section.
**Topics**
+ [Guide de démarrage rapide](migration-quick-start.md)
+ [Manuel de migration](docdb-migration-runbook.md)
+ [Migration depuis Couchbase Server](migration-from-couchbase.md)
# Migrer vers Amazon DocumentDB à l'aide du Service AWS de migration de base de données (DMS) : Guide de démarrage rapide
**Topics**
+ [Préparez la source DMS](#migrate-qs-dma-source)
+ [Configuration du DMS](#migrate-qs-dms-setup)
+ [Activer la compression DocumentDB](#migrate-qs-comp)
+ [Création d'une tâche de réplication](#migrate-qs-create)
+ [Surveiller la progression](#migrate-qs-monitor)
+ [Informations supplémentaires](#migrate-qs-info)
## Préparez la source DMS
Consultez [Activer les flux de changement](change_streams.md#change_streams-enabling) pour activer les flux de modifications DocumentDB ou pour activer le journal MongoDB pour prendre en charge la capture des données de modification (CDC) par DMS.
+ La source DMS doit conserver toutes les modifications en cours jusqu'à ce que le chargement complet du DMS soit terminé pour toutes les collections incluses.
+ Les flux de modifications de DocumentDB sont basés sur le temps. Assurez-vous que le `change_stream_log_retention_duration` paramètre est suffisamment grand pour couvrir le temps nécessaire au chargement complet.
+ Le MongoDB Oplog est de taille fixe. Assurez-vous qu'il est dimensionné pour supporter toutes les opérations à pleine charge.
## Configuration du DMS
Créez une instance DMS, des points de terminaison source et cible et testez chaque point de terminaison.
## Activer la compression DocumentDB
Activez la compression en attachant un groupe de paramètres personnalisé à votre cluster DocumentDB et en mettant à jour le paramètre default\$1collection\$1compression pour qu'il soit activé. Pour plus d’informations, consultez [Gestion de la compression de documents au niveau de la collection](doc-compression.md).
## Création d'une tâche de réplication
1. **Dans le volet de navigation de la console DMS, choisissez **Migrer ou répliquer**, puis Tâches.**
1. Choisissez **Créer tâche**.
1. Sur la page **Créer une tâche**, dans la section **Configuration des tâches** :
+ Entrez un **identifiant de tâche** unique et significatif (par exemple, mongodb-docdb-replication « »).
+ Choisissez le point de terminaison source que vous avez créé précédemment dans le menu déroulant **point de terminaison de la base de données source**.
+ Choisissez le point de terminaison cible que vous avez créé précédemment dans le menu déroulant **Point de terminaison de la base de données cible**.
+ Pour **Type de tâche**, choisissez **Migrer et répliquer**.
1. Dans la section **Paramètres** :
+ Pour les **journaux des tâches**, cochez la case **Activer CloudWatch** les journaux.
+ Pour le **mode édition** (en haut de la section), choisissez l'**éditeur JSON** et définissez les attributs suivants :
+ `ParallelApplyThreads`Réglé sur 5 (moins`TargetMetadata`). Cela permet environ 1 000 insert/update/delete opérations par seconde dans le CDC.
+ `MaxFullLoadSubTasks`Réglé sur 16 (moins`FullLoadSettings`). Envisagez de l'augmenter en fonction de la taille de votre instance.
+ Pour les collections volumineuses (plus de 100 Go), activez le partitionnement automatique (sous Table Mapping et sous l'`parallel-load`attribut) :
+ « type » : « partitions automatiques »
+ number-of-partitions« : 16
## Surveiller la progression
Utilisez la AWS DMS console ou créez un tableau de bord personnalisé ([outil de tableau de bord) pour](https://github.com/awslabs/amazon-documentdb-tools/tree/master/monitoring/docdb-dashboarder) suivre la migration. Concentrez-vous sur les indicateurs suivants :
+ **FullLoadThroughputBandwidthTarget**— Mesure la bande passante réseau (en Kb/seconde) utilisée par DMS lors du transfert de données vers la base de données cible pendant la phase de chargement complet de la migration.
+ **CDCLatencyCible** : mesure le délai (en secondes) entre le moment où une modification se produit dans la base de données source et le moment où cette modification est appliquée à la base de données cible.
+ **CDCThroughputRowsTarget**— Mesure le nombre de lignes par seconde que DMS applique à la base de données cible pendant la phase de réplication en cours de la migration.
## Informations supplémentaires
Pour plus d'informations sur Amazon DocumentDB et AWS DMS consultez : Voir pour plus d'informations.
+ [Manuel de migration vers Amazon DocumentDB](docdb-migration-runbook.md)
+ [Migration de MongoDB vers Amazon DocumentDB](https://docs.aws.amazon.com/dms/latest/sbs/chap-mongodb2documentdb.html)
# Manuel de migration vers Amazon DocumentDB
Ce runbook fournit un guide complet pour migrer une base de données MongoDB vers Amazon DocumentDB à l'aide de (DMS). AWS Database Migration Service Il est conçu pour aider les administrateurs de bases de données, les ingénieurs cloud et les développeurs tout au long du processus de end-to-end migration, de la découverte initiale à la validation après la migration.
Compte tenu des différences d'implémentation et de fonctionnalités prises en charge entre MongoDB et Amazon DocumentDB, ce runbook met l'accent sur une approche structurée et systématique. Il décrit les principales évaluations préalables à la migration, met en évidence les considérations relatives à la compatibilité et détaille les principales tâches requises pour garantir une migration réussie avec un minimum de perturbations.
Le runbook est organisé selon les rubriques suivantes :
+ **[Compatibilité](#mig-runbook-compatibility)**— Découvrez les fonctionnalités et les types de données MongoDB pris en charge dans Amazon DocumentDB, et identifiez les incompatibilités potentielles.
+ **[Découverte des charges de travail](#mig-runbook-workload)**— Analysez les charges de travail MongoDB existantes, y compris les read/write modèles, les volumes de données et les niveaux de performance de référence.
+ **[Migration d'index](#mig-runbook-index)**— Analysez les stratégies d'extraction et de transformation des index MongoDB pour des performances optimales dans Amazon DocumentDB.
+ **[Migration d'utilisateur](#mig-runbook-user)**— Détaillez l'approche de migration des utilisateurs, des rôles et des contrôles d'accès de la base de données vers Amazon DocumentDB.
+ **[Migrations des données](#mig-runbook-data)**— Couvrir les différentes méthodes utilisées pour la migration des données AWS DMS, notamment le chargement complet et la capture des données modifiées (CDC).
+ **[Contrôle](#mig-runbook-monitoring)**— Détaillez les différentes approches de surveillance lors de la migration à l'aide d'un DMS ou d'outils natifs.
+ **[Validation](#mig-runbook-validation)**— Fournir des procédures pour les contrôles d'intégrité des données, la validation fonctionnelle et la comparaison des performances après la migration.
En suivant les instructions de ce manuel, les équipes peuvent garantir une transition fluide, sécurisée et efficace vers Amazon DocumentDB, tout en préservant les fonctionnalités des applications et en minimisant les risques.
## Compatibilité
**Topics**
+ [Compatibilité avec les fonctionnalités de base](#w2aac23b9c13c13)
+ [Outil d'évaluation de compatibilité Amazon DocumentDB](#w2aac23b9c13c15)
Lors de la migration de MongoDB vers Amazon DocumentDB, une évaluation initiale approfondie et un contrôle de compatibilité des fonctionnalités sont essentiels pour une migration réussie. Ce processus commence par un inventaire complet de vos fonctionnalités MongoDB, y compris les opérateurs de pipeline d'agrégation, les modèles de requêtes, les index et les modèles de données.
Amazon DocumentDB étant compatible avec les API MongoDB 3.6, 4.0, 5.0 et 8.0, les applications utilisant de nouvelles fonctionnalités spécifiques à MongoDB peuvent nécessiter une refactorisation. Les domaines critiques à évaluer incluent les mécanismes de partitionnement (Amazon DocumentDB utilise une approche différente), les implémentations de transactions, les fonctionnalités des flux de modifications et les types d'index (en particulier les index épars et partiels).
Les caractéristiques de performance diffèrent également, Amazon DocumentDB étant optimisé pour les charges de travail d'entreprise avec des performances prévisibles. Les tests doivent impliquer l'exécution de charges de travail représentatives sur les deux systèmes afin d'identifier les modèles de requêtes susceptibles de nécessiter une optimisation.
Le suivi des plans d'exécution pour détecter les écarts de performance potentiels est important pendant la phase d'évaluation. Cela permet de créer une feuille de route de migration claire, d'identifier les modifications nécessaires aux applications et d'établir des délais réalistes pour une transition en douceur.
### Compatibilité avec les fonctionnalités de base
#### Support complet des fonctionnalités
+ **Opérations CRUD** : bénéficiez d'une prise en charge complète de toutes les opérations de base de création, de lecture, de mise à jour et de suppression, y compris les opérateurs de requêtes et de blocs, ce qui garantit une compatibilité parfaite entre les applications.
+ **Fonctionnalités d'indexation étendues : profitez de la prise en** charge complète des index à champ unique, composés, TTL, partiels, épars et bisphériques, afin d'optimiser les performances de vos requêtes et les index de texte (version 5) pour les recherches basées sur du texte.
+ **Réplication à l'échelle** de l'entreprise : bénéficiez d'un mécanisme de basculement automatique robuste avec des répliques en lecture pour une haute disponibilité supérieure sans frais d'exploitation.
+ **Solutions de sauvegarde avancées** — Ayez l'esprit tranquille grâce au système de sauvegarde automatique doté de fonctions de Point-in-Time restauration (PITR) et de snapshots manuels à la demande pour la protection des données.
#### AWS Fonctionnalités intégrées améliorées
+ **Agrégation rationalisée** — Tirez parti des étapes d'agrégation les plus couramment utilisées (`$match`,`$group`,, `$sort``$project`, etc.) avec des performances optimisées pour les charges de travail des entreprises.
+ **Assistance aux transactions** — Mettez en œuvre des transactions comportant plusieurs documents et collections multiples, ce qui est parfait pour répondre à la plupart des besoins des applications commerciales.
+ **Suivi des données en temps réel** : activez les flux de modifications à l'aide d'une simple commande et augmentez la période de rétention des flux de modifications grâce à un simple réglage de groupe de paramètres pour une surveillance en temps réel des modifications des données.
+ **Services basés sur la localisation** : implémentez des applications géospatiales prenant en charge les index des `$geoNear` opérateurs et des index 2dsphere.
+ **Capacités de recherche de texte** : utilisez la fonctionnalité de recherche de texte intégrée pour les besoins de découverte de contenu.
#### Avantages de l'architecture moderne
+ **Conception native pour le cloud** : profitez d'une architecture AWS optimisée qui remplace les fonctionnalités existantes, telles que des opérations de pipeline MapReduce d'agrégation plus efficaces.
+ **Sécurité améliorée** — Bénéficiez de l'authentification par certificat Gestion des identités et des accès AWS (IAM), SCRAM-SHA-1, SCRAM-SHA-256, X.509 et de l'authentification par mot de passe.
+ **Performances prévisibles** : bénéficiez de performances constantes optimisées spécifiquement pour les charges de travail des entreprises.
Pour une présentation complète des fonctionnalités d'Amazon DocumentDB, reportez-vous à la section [MongoDB APIs, opérations et types de données pris en charge dans Amazon DocumentDB](mongo-apis.md) et [Différences fonctionnelles : Amazon DocumentDB et MongoDB](functional-differences.md) pour optimiser le potentiel de votre base de données.
Amazon DocumentDB ne prend pas en charge tous les index proposés par MongoDB. Nous fournissons un [outil d'indexation](https://github.com/awslabs/amazon-documentdb-tools/blob/master/index-tool/README.md) gratuit pour vérifier la compatibilité. Nous vous recommandons d'exécuter l'outil d'indexation pour évaluer les incompatibilités et planifier des solutions de contournement en conséquence.
### Outil d'évaluation de compatibilité Amazon DocumentDB
L'outil de compatibilité [MongoDB vers Amazon DocumentDB est un utilitaire open source disponible sur Amazon DocumentDB GitHub qui permet d'évaluer la compatibilité](https://github.com/awslabs/amazon-documentdb-tools/blob/master/compat-tool/README.md) de la charge de travail MongoDB avec Amazon DocumentDB en analysant les journaux MongoDB ou le code source de l'application.
**Fonctions principales**
+ Identifie les modèles d'utilisation de l'API MongoDB dans votre charge de travail
+ Signale les problèmes de compatibilité potentiels avant la migration
+ Génère des rapports de compatibilité détaillés avec des recommandations
+ Disponible en tant qu'utilitaire autonome pouvant être exécuté localement
#### Méthodes d'évaluation
**Évaluation basée sur les journaux**
+ Avantages :
+ Capture le comportement d'exécution réel et les modèles de requête
+ Identifie les fréquences d'utilisation réelles et les caractéristiques de performance
+ Détecte les requêtes dynamiques susceptibles de ne pas être visibles dans le code source
+ Aucun accès au code source de l'application n'est requis
+ Inconvénients :
+ Nécessite un accès aux journaux MongoDB avec le profilage activé
+ Capture uniquement les opérations survenues pendant la période de journalisation
+ Peut manquer des fonctionnalités peu utilisées ou des charges de travail saisonnières
**Analyse du code source**
+ Avantages :
+ Couverture complète de toutes les opérations MongoDB potentielles dans la base de code
+ Peut identifier les problèmes dans les chemins de code rarement exécutés
+ Détecte la logique côté client susceptible d'être affectée par les différences d'Amazon DocumentDB
+ Il n'est pas nécessaire d'exécuter l'application pour effectuer une évaluation
+ Inconvénients :
+ Peut signaler un code qui existe mais qui n'est jamais exécuté en production
+ Nécessite l'accès au code source complet de l'application
+ Capacité limitée à analyser des requêtes construites dynamiquement
Pour de meilleurs résultats, nous recommandons d'utiliser les deux méthodes d'évaluation dans la mesure du possible afin d'obtenir une image complète des problèmes de compatibilité avant la migration.
## Découverte des charges de travail
La migration de MongoDB vers Amazon DocumentDB nécessite une connaissance approfondie de la charge de travail de base de données existante. La découverte de la charge de travail consiste à analyser les modèles d'utilisation de votre base de données, les structures de données, les performances des requêtes et les dépendances opérationnelles afin de garantir une transition fluide avec un minimum de perturbations. Cette section décrit les principales étapes de la découverte de la charge de travail afin de faciliter une migration efficace de MongoDB vers Amazon DocumentDB.
**Topics**
+ [Évaluation du déploiement MongoDB existant](#w2aac23b9c15b7)
+ [Identifier les différences entre les modèles de données](#w2aac23b9c15b9)
+ [Analyse des requêtes et des performances](#w2aac23b9c15c11)
+ [Examen de la sécurité et du contrôle d'accès](#w2aac23b9c15c13)
+ [Considérations relatives au fonctionnement et à la surveillance](#w2aac23b9c15c15)
### Évaluation du déploiement MongoDB existant
Avant la migration, il est essentiel d'évaluer l'environnement MongoDB actuel, notamment :
+ **Architecture du cluster** : identifiez le nombre de nœuds, d'ensembles de répliques et de configurations de partitionnement. Lors de la migration de MongoDB vers Amazon DocumentDB, il est important de comprendre votre configuration de partitionnement MongoDB, car Amazon DocumentDB ne prend pas en charge le sharding contrôlé par l'utilisateur. Les applications conçues pour un environnement MongoDB fragmenté nécessiteront des modifications architecturales, car Amazon DocumentDB utilise une approche de dimensionnement différente avec son architecture basée sur le stockage. Vous devrez adapter votre stratégie de distribution des données et éventuellement consolider les collections fragmentées lors de la migration vers Amazon DocumentDB.
+ **Stockage et volume de données** : mesurez la taille totale des données et la taille de l'index de votre cluster. Complétez cela avec l'[outil de révision Oplog](https://github.com/awslabs/amazon-documentdb-tools/tree/master/migration/mongodb-oplog-review) pour comprendre les modèles d'écriture et la vitesse de croissance des données. Pour plus d'informations sur le dimensionnement de votre cluster, consultez[Dimensionnement des instances](best_practices.md#best_practices-instance_sizing).
+ **Modèles de charge de travail** : analysez le débit de lecture et d'écriture, la fréquence d'exécution des requêtes et l'efficacité de l'indexation.
+ **Dépendances opérationnelles** — Documentez toutes les applications, services et intégrations basés sur MongoDB.
### Identifier les différences entre les modèles de données
Bien qu'Amazon DocumentDB soit compatible avec MongoDB, il existe des différences dans les fonctionnalités prises en charge, telles que :
+ **Transactions** — Amazon DocumentDB prend en charge les transactions ACID, mais avec certaines d'entre elles. [Limites](transactions.md#transactions-limitations)
+ **Conception du schéma** : assurez-vous que les structures des documents, les documents intégrés et les références sont conformes aux [meilleures pratiques d'Amazon DocumentDB](https://d1.awsstatic.com/product-marketing/Data%20modeling%20with%20Amazon%20DocumentDB.pdf).
### Analyse des requêtes et des performances
Comprendre le comportement des requêtes permet d'optimiser les performances de migration et de post-migration. Les principaux domaines à analyser sont les suivants :
+ **Requêtes lentes** : identifiez les requêtes dont le temps d'exécution est élevé à l'aide des outils de profilage de MongoDB.
+ **Modèles de requêtes** : catégorisez les types de requêtes courants, y compris les opérations CRUD et les agrégations.
+ **Utilisation des index** : déterminez si les index sont utilisés efficacement ou s'ils ont besoin d'être optimisés dans Amazon DocumentDB. Pour évaluer l'utilisation de l'index et optimiser les performances dans Amazon DocumentDB, utilisez l'étape du pipeline d'`$indexStats`agrégation associée à la `explain()` méthode pour vos requêtes critiques. Commencez par exécuter `db.collection.aggregate([{$indexStats{}}])` pour identifier les index utilisés. Vous pouvez effectuer une analyse plus détaillée en exécutant vos requêtes les plus fréquentes avec`explainPlan`.
+ **Concurrence et répartition de la charge de travail** : évaluez les ratios de lecture et d'écriture, le regroupement des connexions et les problèmes de performance.
### Examen de la sécurité et du contrôle d'accès
**Authentification et autorisation**
+ **MongoDB RBAC vers Amazon DocumentDB IAM et RBAC — Mappez les utilisateurs et** les rôles de contrôle d'accès basés sur les rôles de MongoDB aux politiques ( Gestion des identités et des accès AWS IAM) et aux utilisateurs d'authentification SCRAM d'Amazon DocumentDB.
+ **Stratégie de migration des utilisateurs** : planifiez la migration des utilisateurs de la base de données, des rôles personnalisés et des privilèges vers les mécanismes d'authentification pris en charge par Amazon DocumentDB.
+ **Différences de privilèges** : identifiez les privilèges MongoDB sans les équivalents directs d'Amazon DocumentDB (par exemple, les rôles d'administration du cluster).
+ **Authentification des applications** : mettez à jour les chaînes de connexion et la gestion des informations d'identification pour les politiques de mot de passe d'Amazon DocumentDB. Vous pouvez utiliser le gestionnaire de secrets pour stocker vos informations d'identification et alterner les mots de passe.
+ **Gestion des comptes de service** — Établissez des processus de gestion des informations d'identification des comptes de service dans AWS Secrets Manager.
+ Implémentation du **moindre privilège — Passez en** revue et affinez les contrôles d'accès afin de mettre en œuvre les principes du moindre privilège dans le nouvel environnement.
**Chiffrement**
Assurez-vous que le chiffrement au repos et en transit est conforme aux exigences de conformité.
**Configuration réseau**
Planifiez la configuration du [Virtual Private Cloud (VPC)](https://docs.aws.amazon.com/vpc/latest/userguide/create-vpc.html) et les règles du groupe de sécurité.
### Considérations relatives au fonctionnement et à la surveillance
Pour garantir la fiabilité du système, la découverte de la charge de travail doit également inclure :
+ **Stratégie de sauvegarde et de restauration** : évaluez les méthodes de sauvegarde existantes et les fonctionnalités de sauvegarde d'Amazon DocumentDB.
+ **AWS Backup intégration** — Tirez parti AWS Backup de la gestion centralisée des sauvegardes sur l'ensemble des AWS services, notamment Amazon DocumentDB.
+ **CloudWatch métriques** — Mappez les métriques de surveillance MongoDB aux métriques Amazon CloudWatch DocumentDB pour le processeur, la mémoire, les connexions et le stockage.
+ **Informations sur les performances** : implémentez Amazon DocumentDB Performance Insights pour visualiser le chargement de la base de données et analyser les problèmes de performances grâce à des analyses de requêtes détaillées.
+ **Profileur** : configurez le profileur Amazon DocumentDB pour capturer les opérations lentes (similaire au profileur de MongoDB mais avec des paramètres spécifiques à Amazon DocumentDB).
+ Activez via des groupes de paramètres avec des seuils appropriés.
+ Analyser les données du profileur pour identifier les opportunités d'optimisation
+ **CloudWatch Événements** — Configurez la surveillance pilotée par les événements pour les événements du cluster Amazon DocumentDB.
+ Configurez les notifications pour les événements de sauvegarde, les fenêtres de maintenance et les basculements.
+ Intégrez Amazon SNS pour les alertes et les réponses AWS Lambda automatisées.
+ **Journalisation des audits** : planifiez la configuration de la journalisation des audits afin de suivre l'activité des utilisateurs et les événements liés à la sécurité.
+ **Surveillance améliorée** — Activez une surveillance améliorée des mesures granulaires au niveau du système d'exploitation à intervalles d'une seconde.
## Migration d'index
La migration de MongoDB vers Amazon DocumentDB implique le transfert non seulement de données, mais également d'index afin de maintenir les performances des requêtes et d'optimiser les opérations de base de données. Cette section décrit le step-by-step processus détaillé de migration des index de MongoDB vers Amazon DocumentDB tout en garantissant la compatibilité et l'efficacité.
### Utilisation de l'outil d'indexation Amazon DocumentDB
**Cloner l'[outil d'indexation](https://github.com/awslabs/amazon-documentdb-tools/blob/master/index-tool/README.md)**
```
git clone https://github.com/aws-samples/amazon-documentdb-tools.git
cd amazon-documentdb-tools/index-tool
```
```
pip install -r requirements.txt
```
**Exporter des index depuis MongoDB (en cas de migration depuis MongoDB)**
```
python3 migrationtools/documentdb_index_tool.py --dump-indexes --dir mongodb_index_export --uri
'mongodb://localhost:27017'
```
**Exporter des index depuis Amazon DocumentDB (en cas de migration depuis Amazon DocumentDB)**
```
python3 migrationtools/documentdb_index_tool.py --dump-indexes --dir docdb_index_export --uri
'mongodb://user:password@mydocdb.cluster-cdtjj00yfi95.eu-west-
2.docdb.amazonaws.com:27017/?tls=true&tlsCAFile=rds-combined-ca-
bundle.pem&replicaSet=rs0&retryWrites=false'
```
**Indexes d'importation**
```
python3 migrationtools/documentdb_index_tool.py --restore-indexes --skip-incompatible --dir
mongodb_index_export --uri 'mongodb://user:password@mydocdb.cluster-cdtjj00yfi95.eu-west-
2.docdb.amazonaws.com:27017/?tls=true&tlsCAFile=rds-combined-ca-
bundle.pem&replicaSet=rs0&retryWrites=false'
```
**Vérifier les index**
```
python3 migrationtools/documentdb_index_tool.py --show-issues --dir mongodb_index_export
```
## Migration d'utilisateur
La migration des utilisateurs de MongoDB vers Amazon DocumentDB est essentielle pour garantir le contrôle d'accès, l'authentification et la sécurité des bases de données. Cette section décrit les étapes détaillées pour réussir la migration des utilisateurs de MongoDB tout en préservant leurs rôles et leurs autorisations à l'aide de l'outil utilisateur d'exportation Amazon DocumentDB.
### Utilisation de l'outil d'exportation pour les utilisateurs d'Amazon DocumentDB
Les utilisateurs et les rôles sont [https://github.com/awslabs/amazon-documentdb-tools/tree/master/migration/export-users](https://github.com/awslabs/amazon-documentdb-tools/tree/master/migration/export-users)exportés depuis MongoDB ou Amazon DocumentDB JavaScript vers des fichiers, qui peuvent ensuite être utilisés pour les recréer dans un autre cluster.
**Conditions préalables**
```
# Clone the repository
git clone https://github.com/awslabs/amazon-documentdb-tools.git
cd amazon-documentdb-tools/migration/export-users
```
```
# Install required dependencies
pip install pymongo
```
**Étape 1 : Exporter les utilisateurs et les rôles**
```
# Export users and roles to JavaScript files
python3 docdbExportUsers.py \
--users-file mongodb-users.js \
--roles-file mongodb-roles.js \
--uri "mongodb://admin:password@source-host:27017/"
```
**Étape 2 : Modifier le fichier utilisateur**
```
// Example of how to update the users.js file
// Find each user creation statement and add the password
db.getSiblingDB("admin").createUser({
user: "appuser",
// Add password here
pwd: "newpassword",
roles: [
{ role: "readWrite", db: "mydb" }
]
})
```
**Étape 3 : restauration des rôles personnalisés sur Amazon DocumentDB**
```
# Import roles first
mongo --ssl \
--host target-host:27017 \
--sslCAFile rds-combined-ca-bundle.pem \
--username admin \
--password password \
mongodb-roles.js
```
**Étape 4 : restaurer les utilisateurs sur Amazon DocumentDB**
```
# Import users after roles are created
mongo --ssl \
--host target-host:27017 \
--sslCAFile rds-combined-ca-bundle.pem \
--username admin \
--password password \
mongodb-users.js
```
**Remarques importantes**
+ Les mots de passe ne sont pas exportés pour des raisons de sécurité et doivent être ajoutés manuellement au fichier users.js.
+ Les rôles doivent être importés avant les utilisateurs afin de garantir une attribution correcte des rôles.
+ L'outil génère JavaScript des fichiers qui peuvent être exécutés directement avec le shell mongo.
+ Les rôles personnalisés et leurs privilèges sont préservés pendant la migration.
+ Cette approche permet de revoir et de modifier les autorisations des utilisateurs avant l'importation.
Cette méthode fournit une approche sécurisée et flexible pour la migration des utilisateurs et des rôles de MongoDB vers Amazon DocumentDB tout en permettant la réinitialisation des mots de passe pendant le processus de migration.
## Migrations des données
**Topics**
+ [Migration en ligne](#w2aac23b9c21b5)
+ [Migration hors ligne](#w2aac23b9c21b7)
+ [Conditions préalables](#w2aac23b9c21c11)
+ [Préparation d'un cluster Amazon DocumentDB](#w2aac23b9c21c13)
+ [Effectuer le vidage des données (mongodump)](#w2aac23b9c21c15)
+ [Transférer les fichiers de vidage vers l'environnement de restauration](#w2aac23b9c21c17)
+ [Restaurer les données sur Amazon DocumentDB (mongorestore)](#w2aac23b9c21c19)
### Migration en ligne
Cette section fournit des étapes détaillées pour effectuer une migration en ligne de MongoDB vers Amazon DocumentDB en minimisant les temps d'arrêt et AWS DMS en garantissant une réplication continue. Pour commencer, vous configurez un cluster Amazon DocumentDB comme cible et vous vous assurez que votre instance MongoDB est correctement configurée en tant que source, ce qui nécessite généralement le mode Replica Set pour la capture des données de modification. Ensuite, vous créez une instance de réplication DMS et définissez les points de terminaison source et cible avec les détails de connexion nécessaires. Après avoir validé les points de terminaison, vous configurez et lancez une tâche de migration qui peut inclure le chargement complet des données, la réplication continue, ou les deux.
#### Configurer la cible (Amazon DocumentDB)
**Note**
Si vous avez déjà configuré un cluster Amazon DocumentDB vers lequel effectuer la migration, vous pouvez ignorer cette étape.
**Création d'un groupe de paramètres personnalisé**
Consultez les AWS CLI procédures AWS Management Console ou dans[Création de groupes de paramètres de cluster Amazon DocumentDB](cluster_parameter_groups-create.md).
**Création d'un cluster Amazon DocumentDB**
**Note**
Bien qu'il existe d'autres procédures pour créer un cluster Amazon DocumentDB dans ce guide, les étapes de cette section s'appliquent spécifiquement à la tâche de migration de grandes quantités de données vers un nouveau cluster.
1. [Connectez-vous à la AWS Management Console console Amazon DocumentDB et ouvrez-la à https://console.aws.amazon.com l'adresse /docdb.](https://console.aws.amazon.com/docdb)
1. Dans le panneau de navigation, choisissez **Clusters**.
**Astuce**
Si vous ne voyez pas le volet de navigation sur le côté gauche de votre écran, choisissez l'icône de menu (![\[Hamburger menu icon with three horizontal lines.\]](http://docs.aws.amazon.com/fr_fr/documentdb/latest/developerguide/images/docdb-menu-icon.png)) dans le coin supérieur gauche de la page.
1. **Sur la console de gestion Amazon DocumentDB, sous **Clusters**, choisissez Create.**
1. Sur la page **Créer un cluster Amazon DocumentDB**, dans la section **Type de cluster**, sélectionnez Cluster **basé sur une instance** (il s'agit de l'option par défaut).
1. Dans la section Configuration du cluster :
+ Dans le **champ Identifiant du cluster**, entrez un nom unique, tel que**mydocdbcluster**. Notez que la console remplacera tous les noms de cluster en minuscules, quelle que soit la manière dont ils sont saisis.
+ Pour la **version Engine**, choisissez 5.0.0.
1. Dans la section **Configuration du stockage en cluster**, laissez le paramètre **Amazon DocumentDB Standard** tel quel (il s'agit de l'option par défaut).
1. Dans la section **Configuration de l'instance** :
+ Pour la **classe d'instance de** base de données, choisissez **Classes optimisées pour la mémoire (inclure les classes r)** (par défaut).
+ Pour **Classe d'instance**, choisissez une classe d'instance en fonction de la charge de travail. Par exemple :
+ db.r6g.large : pour les petites charges de travail
+ db.r6g.4xlarge : pour les charges de travail plus importantes
Il est recommandé de choisir une instance aussi grande que possible pour un débit de chargement complet optimal, et de la réduire une fois la migration terminée.
+ Pour **Nombre d'instances**, sélectionnez 1 instance. Le choix d'une instance permet de minimiser les coûts. Nous vous recommandons de passer à trois instances pour une haute disponibilité une fois la migration à chargement complet terminée.
1. Dans la section **Authentification**, entrez un nom d'utilisateur pour l'utilisateur principal, puis choisissez **Autogéré**. Saisissez un mot de passe, puis confirmez-le.
1. Dans la section **Paramètres réseau**, choisissez un VPC et un groupe de sous-réseaux, puis configurez le groupe de sécurité VPC. Assurez-vous que votre groupe de sécurité Amazon DocumentDB autorise les connexions entrantes depuis le groupe de sécurité de l'instance DMS en mettant à jour les règles entrantes.
1. Dans la ncryption-at-rest section **E**, activez le chiffrement (recommandé) et choisissez ou entrez une clé KMS.
1. Dans la section **Backup**, définissez la période de conservation des sauvegardes (1 à 35 jours).
1. Passez en revue votre configuration et choisissez **Create cluster**.
Le temps de déploiement prend généralement entre 10 et 15 minutes,
#### Configuration de la source
MongoDB et Amazon DocumentDB peuvent tous deux servir de sources de migration, selon votre scénario :
+ **MongoDB en tant que source** : courant lors de la migration d'une base de données MongoDB sur site ou autogérée vers Amazon DocumentDB ou d'autres services de base de données. AWS Nécessite une exécution en mode Replica Set avec un journal journal de taille adéquate (assurez-vous qu'il est dimensionné pour contenir toutes les opérations pendant le chargement complet) pour prendre en charge la capture des données de modification pendant la migration.
+ **Amazon DocumentDB en tant que source** : généralement utilisé pour la réplication entre régions, les mises à niveau de version ou la migration vers d'autres services de base de données tels que MongoDB Atlas. Nécessite [Activer les flux de changement](change_streams.md#change_streams-enabling) de définir le `change_stream_log_retention_duration` paramètre dans le groupe de paramètres du cluster pour capturer les modifications en cours pendant la migration. Assurez-vous que votre `change_stream_log_retention_duration` réglage est suffisamment grand pour couvrir le temps nécessaire au chargement complet.
Avant de commencer la migration, configurez votre source pour autoriser AWS DMS l'accès.
Créez un utilisateur MongoDB avec les autorisations appropriées :
```
db.createUser({
user: "dmsUser",
pwd: "yourSecurePassword",
roles: [{ role: "readAnyDatabase", db: "admin" }]
})
```
Configurez le réseau et l'authentification.
Lors de la configuration de la connectivité réseau pour la migration de MongoDB vers DMS :
**Source MongoDB hébergée par EC2**
+ Modifiez le groupe de sécurité EC2 pour autoriser le trafic entrant en provenance du groupe de sécurité de l'instance de réplication DMS.
+ Ajoutez une règle pour le port TCP 27017 (ou votre port MongoDB personnalisé).
+ Utilisez l'ID du groupe de sécurité de l'instance de réplication DMS comme source pour un contrôle d'accès précis.
+ Assurez-vous que le sous-réseau de l'instance EC2 dispose d'une route vers le sous-réseau de l'instance de réplication DMS.
**Source MongoDB sur site**
+ Configurez votre pare-feu pour autoriser les connexions entrantes depuis les adresses IP publiques de l'instance de réplication DMS.
+ Si vous utilisez Direct Connect un VPN, assurez-vous que le routage entre votre réseau et le VPC contenant l'instance DMS est correct.
+ Testez la connectivité à l'aide de commandes telnet ou nc depuis le sous-réseau DMS vers votre serveur MongoDB.
**Source de l'Atlas MongoDB**
+ Ajoutez les adresses IP d'une instance de réplication DMS à la liste d'adresses IP autorisées de MongoDB Atlas.
+ Configurez le peering VPC entre VPC et AWS MongoDB Atlas VPC si Atlas est exécuté sur. AWS
+ Configurez AWS PrivateLink la connectivité privée (niveau Enterprise), si vous utilisez un autre fournisseur de cloud.
+ Créez un utilisateur dédié doté des read/write autorisations appropriées.
+ Utilisez une chaîne de connexion MongoDB Atlas avec le mode SSL défini sur « verify-full ».
+ Assurez-vous que la taille du journal est suffisante pour la durée de la migration.
**Source Amazon DocumentDB**
Configurez votre groupe de sécurité Amazon DocumentDB source pour autoriser le trafic entrant en provenance du groupe de sécurité des instances de réplication DMS.
#### Création d'une instance de réplication DMS
Nous vous recommandons d'utiliser [DMS Buddy](https://github.com/awslabs/amazon-documentdb-tools/tree/master/migration/dms_buddy) pour approvisionner votre infrastructure DMS, car il crée une infrastructure de migration optimale avec des paramètres DMS et des tailles d'instance optimaux.
Si vous préférez effectuer la configuration manuellement, procédez comme suit :
1. Ouvrez la console AWS DMS et choisissez **Créer une instance de réplication**.
1. Entrez les détails de l'instance de réplication :
+ **Nom de l'instance** : choisissez un nom unique.
+ **Classe d'instance** : sélectionnez en fonction de la charge de travail. Exemple : dms.r5.large (petites charges de travail), dms.r5.4xlarge (charges de travail importantes).
+ **Version du moteur** : 3.5.4
+ **Stockage alloué** : la valeur par défaut est de 100 Go (augmentez si nécessaire). Cela dépend de la taille du document updates/second et de la durée du chargement complet.
+ **Déploiement multi-AZ** : activez la haute disponibilité, si nécessaire.
+ Choisissez le même VPC qu'Amazon DocumentDB.
+ Assurez-vous que **les groupes de sécurité** autorisent le trafic entrant depuis la source et Amazon DocumentDB.
1. Cliquez sur **Créer une instance de réplication** et attendez que le statut soit disponible.
#### Création de points de terminaison DMS
##### Création d'un point de terminaison source
**Pour une source MongoDB**
1. **Dans le volet de navigation de la console DMS, choisissez **Migrer ou répliquer**, puis Endpoints.**
1. Choisissez **Créer un point de terminaison**.
1. Sur la page **Créer un point de terminaison**, choisissez Point de **terminaison source**.
1. Dans la section **Configuration du point de terminaison** :
+ Entrez un **identifiant de point de terminaison** unique et significatif (par exemple, « mongodb-source »).
+ Choisissez **MongoDB** comme moteur **source**.
+ Pour **Accès à la base de données du point de terminaison**, choisissez **Renseignez les informations d’accès manuellement**.
+ Dans **Nom du serveur**, entrez votre*MongoDB server DNS name/IP address*.
+ Pour **Port**, entrez **27017** (port MongoDB par défaut).
+ Pour le **mode d'authentification**, choisissez le mode approprié pour votre application (mot de passe/SSL) (le gestionnaire de secrets est par défaut).
+ Si le **mode d'authentification** est un **mot de passe**, fournissez :
+ **Nom d'utilisateur** et **mot de passe** : entrez les informations d'identification MongoDB.
+ **Nom de la base de données : nom** de votre base de données source.
+ **Mécanisme d'authentification** : SCRAM-SHA-1 (par défaut) ou mécanisme approprié
1. Pour le **mode métadonnées**, conservez le paramètre par défaut du **document**.
1. Attributs de connexion supplémentaires :
+ AuthSource=admin (si la base de données d'authentification est différente)
+ ReplicaSet=< your-replica-set-name > (obligatoire pour le CDC)
**Pour une source Amazon DocumentDB**
1. **Dans le volet de navigation de la console DMS, choisissez **Migrer ou répliquer**, puis Endpoints.**
1. Choisissez **Créer un point de terminaison**.
1. Sur la page **Créer un point de terminaison**, choisissez Point de **terminaison source**.
1. Dans la section **Configuration du point de terminaison** :
+ Entrez un **identifiant de point de terminaison** unique et significatif (par exemple, « docdb-source »).
+ Choisissez **Amazon DocumentDB** comme moteur **source**.
+ Pour **Accès à la base de données du point de terminaison**, choisissez **Renseignez les informations d’accès manuellement**.
+ Dans **Nom du serveur**, entrez votre*source Amazon DocumentDB cluster endpoint*.
+ Pour **Port**, entrez **27017** (port Amazon DocumentDB par défaut).
+ Pour le **mode SSL**, choisissez **verify-full** (recommandé pour Amazon DocumentDB).
+ Pour le **certificat CA**, choisissez le certificat CA racine Amazon RDS.
+ Pour le **mode d'authentification**, choisissez le mode approprié pour votre application (mot de passe/SSL) (le gestionnaire de secrets est par défaut).
+ Si le **mode d'authentification** est un **mot de passe**, fournissez :
+ **Nom d'utilisateur** et **mot de passe** : entrez les informations d'identification Amazon DocumentDB.
+ **Nom de la base de données : nom** de votre base de données source.
+ **Mécanisme d'authentification** : SCRAM-SHA-1 (par défaut) ou mécanisme approprié
1. Pour le **mode métadonnées**, conservez le paramètre par défaut du **document**.
##### Création d'un point de terminaison cible (Amazon DocumentDB)
1. **Dans le volet de navigation de la console DMS, choisissez **Migrer ou répliquer**, puis Endpoints.**
1. Choisissez **Créer un point de terminaison**.
1. Sur la page **Créer un point de terminaison**, choisissez un point de **terminaison cible**.
1. Dans la section **Configuration du point de terminaison** :
+ Entrez un **identifiant de point de terminaison** unique et significatif (par exemple, « docdb-target »).
+ Choisissez **Amazon DocumentDB** comme moteur **cible**.
+ Pour **l'accès à la base de données des terminaux**, choisissez la méthode que vous souhaitez utiliser pour authentifier l'accès à la base de données :
+ Si vous choisissez **AWS Secrets Manager**, choisissez le secret dans lequel vous stockez vos informations d'identification Amazon DocumentDB dans le champ **Secret**.
+ Si vous choisissez **Fournir les informations d'accès manuellement** :
+ Dans **Nom du serveur**, entrez votre*target Amazon DocumentDB cluster endpoint*.
+ Pour **Port**, entrez **27017** (port Amazon DocumentDB par défaut).
+ Pour le **mode SSL**, choisissez **verify-full** (recommandé pour Amazon DocumentDB).
+ Pour le **certificat CA**, téléchargez et spécifiez le bundle de certificats CA pour la vérification SSL.
+ Pour le **mode d'authentification**, choisissez le mode approprié pour votre application (mot de passe/SSL) (le gestionnaire de secrets est par défaut).
+ Si le **mode d'authentification** est un **mot de passe**, fournissez :
+ **Nom d'utilisateur** et **mot de passe** : entrez les informations d'identification Amazon DocumentDB.
+ **Nom de la base de données : nom** de votre base de données source.
+ **Mécanisme d'authentification** : SCRAM-SHA-1 (par défaut) ou mécanisme approprié
1. Pour le **mode métadonnées**, conservez le paramètre par défaut du **document**.
#### Création d'une tâche de réplication
1. **Dans le volet de navigation de la console DMS, choisissez **Migrer ou répliquer**, puis Tâches.**
1. Choisissez **Créer tâche**.
1. Sur la page **Créer une tâche**, dans la section **Configuration des tâches** :
+ Entrez un **identifiant de tâche** unique et significatif (par exemple, mongodb-docdb-replication « »).
+ Choisissez le point de terminaison source que vous avez créé précédemment dans le menu déroulant **point de terminaison de la base de données source**.
+ Choisissez le point de terminaison cible que vous avez créé précédemment dans le menu déroulant **Point de terminaison de la base de données cible**.
+ Pour **Type de tâche**, choisissez **Migrer et répliquer**.
1. Dans la section **Paramètres** :
+ Pour le **mode de préparation de la table Target**, conservez le paramètre par défaut.
+ Pour **Arrêter la tâche une fois le chargement complet terminé**, conservez le paramètre par défaut.
+ Pour les **paramètres de colonne LOB**, laissez le paramètre du **mode LOB limité** tel quel.
+ Pour la **validation des données**, laissez le paramètre par défaut **Désactivé**.
+ Pour les **journaux des tâches**, cochez la case **Activer CloudWatch** les journaux.
+ Pour une **application optimisée par lots**, laissez le paramètre par défaut non coché (désactivé).
1. En haut de la section **Paramètres des tâches**, en **mode édition**, choisissez l'**éditeur JSON** et définissez les attributs suivants :
```
{
"TargetMetadata": {
"ParallelApplyThreads": 5
},
"FullLoadSettings": {
"MaxFullLoadSubTasks": 16
}
}
```
1. Dans la section **Mappages de tables**, ajoutez une nouvelle règle de sélection :
+ Pour **le nom du schéma**, ajoutez la base de données source à migrer. Utilisez % pour spécifier plusieurs bases de données.
+ Pour **le nom de la table de schéma**, ajoutez la collection source à migrer. Utilisez % pour spécifier plusieurs collections.
+ Pour **Action**, laissez le paramètre par défaut **Inclure**
1. Pour les collections volumineuses (plus de 100 Go), ajoutez la **règle des paramètres de table** :
+ Pour **le nom du schéma**, ajoutez la base de données source à migrer. Utilisez % pour spécifier plusieurs bases de données.
+ Pour **le nom de la table de schéma**, ajoutez la collection source à migrer. Utilisez % pour spécifier plusieurs collections.
+ Dans **le champ Nombre de partitions**, entrez 16 (doit être inférieur à`MaxFullLoadSubTask`).
1. Dans la section **d'évaluation de la prémigration**, assurez-vous qu'elle est désactivée.
### Migration hors ligne
Cette section décrit le processus de migration hors ligne d'une instance MongoDB autogérée vers Amazon DocumentDB à l'aide des outils MongoDB natifs : et. `mongodump` `mongorestore`
### Conditions préalables
**Exigences relatives à la source MongoDB**
+ Accès à l'instance MongoDB source avec les autorisations appropriées.
+ Installer`mongodump`. Si nécessaire (il est installé lors d'une installation de MongoDB).
+ Assurez-vous qu'il y a suffisamment d'espace disque pour les fichiers de vidage.
**Cibler les exigences d'Amazon DocumentDB**
+ Assurez-vous qu'un cluster Amazon DocumentDB est provisionné.
+ Assurez-vous qu'il existe une instance EC2 dans le même VPC qu'Amazon DocumentDB pour faciliter la migration.
+ La connectivité réseau doit être disponible entre votre environnement source et Amazon DocumentDB.
+ **mongorestore** doit être installé sur l'instance de migration EC2.
+ Les autorisations IAM appropriées doivent être configurées pour accéder à Amazon DocumentDB,
**Prescriptions générales**
+ AWS CLI doit être configuré (si vous utilisez AWS des services pour le stockage intermédiaire)
+ Une bande passante suffisante doit être disponible pour le transfert de données.
+ La fenêtre d'indisponibilité doit être approuvée (si vous effectuez une migration en direct, envisagez d'autres approches)
### Préparation d'un cluster Amazon DocumentDB
Créez un cluster Amazon DocumentDB dans : AWS
+ Adaptez une taille d'instance en fonction de votre charge de travail.
+ Configurez un VPC, des sous-réseaux et des groupes de sécurité.
+ Activez les paramètres nécessaires via des groupes de paramètres.
### Effectuer le vidage des données (mongodump)
Choisissez l'une des options suivantes pour créer un fichier de vidage :
+ **Option 1 : Basique**
```
mongodump --
uri="mongodb://:@:/" --
out=/path/to/dump
```
+ **Option 2 : amélioration du contrôle et des performances**
```
mongodump \
--uri="mongodb://:@:" \
--out=/path/to/dump \
--gzip \# Compress output
--numParallelCollections=4 \# Parallel collections dump
--ssl \# If using SSL
--authenticationDatabase=admin \ # If auth is required
--readPreference=secondaryPreferred # If replica set
```
+ **Option 3 : bases de données volumineuses**
```
mongodump \
--host= \
--port= \
--username= \
--password= \
--db= \# Only dump specific DB
--collection= \ # Only dump specific collection
--query='{ "date": { "$gt": "2020-01-01" } }' \ # Filter documents
--archive=/path/to/archive.gz \# Single archive output
--gzip \
--ssl
```
### Transférer les fichiers de vidage vers l'environnement de restauration
Choisissez une méthode appropriée en fonction de la taille de votre fichier de vidage :
+ **Petit** — Copiez directement sur votre machine de migration (instance EC2 que vous avez créée précédemment) :
```
scp -r /path/to/dump user@migration-machine:/path/to/restore
```
+ **Moyen** — Utilisez Amazon S3 comme stockage intermédiaire :
```
aws s3 cp --recursive /path/to/dump s3://your-bucket/mongodb-dump/
```
+ **Grande taille** : pour les bases de données très volumineuses, envisagez AWS DataSync un transfert physique.
### Restaurer les données sur Amazon DocumentDB (mongorestore)
Avant de démarrer le processus de restauration, créez les index dans Amazon DocumentDB. Vous pouvez utiliser l'[outil Amazon DocumentDB Index](https://github.com/awslabs/amazon-documentdb-tools/tree/master/index-tool) pour exporter et importer des index.
Choisissez l'une des options suivantes pour restaurer les données :
+ **Option 1 : restauration de base**
```
mongorestore --uri="mongodb://:@:27017"
/path/to/dump
```
+ **Option 2 : amélioration du contrôle et des performances**
```
mongorestore \
--uri="mongodb://:@:27017" \
--ssl \
--sslCAFile=/path/to/rds-combined-ca-bundle.pem \ # DocumentDB CA cert
--gzip \# If dumped with gzip
--numParallelCollections=4 \# Parallel restoration
--numInsertionWorkersPerCollection=4 \# Parallel documents insertion
--noIndexRestore \# skip indexes as they are pre-created
/path/to/dump
```
+ **Option 3 : bases de données volumineuses ou contrôles spécifiques**
```
mongorestore \
--host= \
--port=27017 \
--username= \
--password= \
--ssl \
--sslCAFile=/path/to/rds-combined-ca-bundle.pem \
--archive=/path/to/archive.gz \# If using archive format
--gzip \
--nsInclude="db1.*" \# Only restore specific namespaces
--nsExclude="db1.sensitive_data" \ # Exclude specific collections if needed
--noIndexRestore \# skip indexes as they are pre-created
--writeConcern="{w: 'majority'}" # Ensure write durability
```
## Contrôle
Cette section fournit un processus de surveillance détaillé permettant de suivre la progression, les performances et l'état d'une migration en cours à partir de :
****MongoDB vers Amazon DocumentDB****
or
****Amazon DocumentDB vers Amazon DocumentDB****
Les étapes de surveillance s'appliquent quelle que soit la méthode de migration (AWS DMS mongodump/mongorestore ou autres outils).
### AWS DMS Surveillance de la migration (le cas échéant)
Surveillez les CloudWatch indicateurs clés suivants :
**Métriques de la phase de chargement complet**
+ **FullLoadThroughputBandwidthTarget**— Bande passante réseau (Kb/seconde) pendant le chargement complet
+ **FullLoadThroughputRowsTarget**— Nombre de rows/documents chargements par seconde
+ **FullLoadThroughputTablesTarget**— Nombre de tables/collections travaux terminés par minute
+ **FullLoadProgressPercent**— Pourcentage de chargement complet terminé
+ **TablesLoaded**— Nombre de fichiers chargés tables/collections avec succès
+ **TablesLoading**— Nombre de chargements tables/collections en cours
+ **TablesQueued**— Nombre de tables/collections personnes en attente de chargement
+ **TablesErrored**— Numéro de ceux tables/collections qui n'ont pas pu être chargés
**Métriques de phase du CDC**
+ **CDCLatencyCible** : délai (secondes) entre le changement de source et l'application cible
+ **CDCLatencySource** — Délai (secondes) entre le changement de source et sa lecture par le DMS
+ **CDCThroughputRowsTarget**— Nombre de lignes par seconde appliquées pendant la réplication en cours
+ **CDCThroughputBandwidthTarget**— Bande passante réseau (Kb/seconde) pendant le CDC
+ **CDCIncomingModifications** : nombre d'événements de modification reçus de la source
+ **CDCChangesMemoryTarget**— Mémoire utilisée (Mo) pour stocker les modifications du côté cible
**Métriques relatives aux ressources**
+ **CPUUtilization**— Utilisation du processeur par l'instance de réplication
+ **FreeableMemory**— Mémoire disponible sur l'instance de réplication
+ **FreeStorageSpace**— Stockage disponible sur l'instance de réplication
+ **NetworkTransmitThroughput**— Débit réseau pour l'instance de réplication
+ **NetworkReceiveThroughput**— Débit réseau pour l'instance de réplication
**Métriques d'erreur**
+ **ErrorsCount**— Nombre total d'erreurs lors de la migration
+ **TableErrorsCount**— Nombre d'erreurs spécifiques à la table
+ **RecordsErrorsCount**— Nombre d'erreurs spécifiques à un enregistrement
Créez des CloudWatch alarmes pour les indicateurs critiques, tels que `CDCLatencyTarget` et `CPUUtilization` pour recevoir des notifications si les performances de migration se dégradent.
#### Journaux DMS (CloudWatch journaux)
1. Accédez à la console Amazon CloudWatch Logs.
1. Recherchez votre groupe de logs et choisissez-le. Cela ressemblera à « dms-tasks — ».
1. Recherchez les flux de journaux susceptibles de contenir des informations d'erreur :
+ Streams dont le nom contient le mot « error »
+ Streams avec noms de tâches IDs ou de points de terminaison
+ Les flux de journaux les plus récents au moment de votre migration
1. Dans ces flux, recherchez des mots clés tels que :
+ « erreur »
+ « exception »
+ « échec »
+ « avertissement »
#### État de la tâche DMS (en utilisant AWS CLI)
```
aws dms describe-replication-tasks --filters Name=replication-task id,Values= --query
"ReplicationTasks[0].Status"
```
Flux de statut attendu :
création → prêt → exécution → arrêt → arrêté (ou échec)
#### Surveiller en utilisant `docdb-dashboarder`
L'`docdb-dashboarder`outil fournit une surveillance complète des clusters Amazon DocumentDB en générant automatiquement des CloudWatch tableaux de bord contenant des indicateurs de performance essentiels. Ces tableaux de bord affichent des métriques critiques au niveau du cluster (délai de réplication, compteurs d'opérations), des métriques au niveau de l'instance (processeur, mémoire, connexions) et des métriques de stockage (utilisation du volume, stockage de sauvegarde). Pour les scénarios de migration, l'outil propose des tableaux de bord spécialisés qui suivent la progression de la migration à l'aide de mesures telles que le délai de réplication CDC et les taux d'exploitation. Les tableaux de bord peuvent surveiller plusieurs clusters simultanément et incluent la prise en charge des NVMe instances soutenues. En visualisant ces indicateurs, les équipes peuvent identifier de manière proactive les obstacles aux performances, optimiser l'allocation des ressources et garantir le bon fonctionnement de leurs déploiements Amazon DocumentDB. L'outil élimine le besoin de créer manuellement un tableau de bord tout en fournissant une surveillance cohérente dans tous les environnements. Pour les instructions de configuration et les options de configuration avancées, consultez le référentiel [Amazon DocumentDB Dashboarder](https://github.com/awslabs/amazon-documentdb-tools/tree/master/monitoring/docdb-dashboarder) Tool. GitHub
## Validation
**Topics**
+ [Liste de contrôle pour la validation](#w2aac23b9c25c15)
+ [Validation du schéma et de l'index](#w2aac23b9c25c17)
+ [Échantillonnage des données et validation sur le terrain](#w2aac23b9c25c19)
+ [Validation par DataDiffer outil](#w2aac23b9c25c21)
Cette section fournit un processus de validation détaillé pour garantir la cohérence, l'intégrité et la compatibilité des applications des données après la migration depuis :
****MongoDB vers Amazon DocumentDB****
or
****Amazon DocumentDB vers Amazon DocumentDB****
Les étapes de validation s'appliquent quelle que soit la méthode de migration (AWS DMS mongodump/mongorestore ou autres outils).
### Liste de contrôle pour la validation
Vérifiez que le nombre de documents de chaque collection correspond à la source et à la cible :
**Source de MongoDB**
```
mongo --host --port --username -- password --eval
"db..count()"
```
**Cible Amazon DocumentDB**
```
mongo --host --port --username -- password --eval
"db..count()"
```
### Validation du schéma et de l'index
Assurez-vous que :
+ toutes les collections existent dans la cible.
+ les index sont correctement répliqués.
+ les définitions de schéma (si elles sont appliquées) sont identiques.
**Vérifier les collections (source ou cible)**
```
mongo --host --eval "show collections"
mongo --host --ssl --eval "show collections"
```
**vérifier les index (source ou cible)**
```
mongo --host --eval" db..getIndexes()"
mongo --host --ssl –eval" db..getIndexes()"
```
Comparez la liste des collections pour vous assurer qu'il n'y a aucune collection manquante ou supplémentaire.
Vérifiez les index en vérifiant les noms d'index, les définitions de clés, les contraintes uniques et les index TTL (le cas échéant).
**Vérifiez les règles de validation du schéma (si vous utilisez la validation du schéma dans MongoDB)**
```
mongo --host --eval" db.getCollectionInfos({name: ''})
[0].options.validator"
mongo --host --ssl –eval" db.getCollectionInfos({name: ''})[0].options.validator"
```
### Échantillonnage des données et validation sur le terrain
Vous pouvez échantillonner des documents de manière aléatoire et comparer les champs entre la source et la cible.
**Échantillonnage manuel**
Récupérez cinq documents aléatoires (source) :
```
mongo --host --eval "db..aggregate([{ \$sample: { size: 5 } }])"
```
Récupérez le même document IDs (cible) :
```
mongo --host --ssl –eval "db..find({ _id: { \$in: [] } })"
```
**Échantillonnage automatique**
```
import pymongo
# Connect to source and target
source_client = pymongo.MongoClient("")
target_client = pymongo.MongoClient("", ssl=True)
source_db = source_client[""]
target_db = target_client[""]
# Compare 100 random documents
for doc in source_db..aggregate([{ "$sample":
{ "size": 100 } }]):
target_doc = target_db..find_one({ "_id":
doc["_id"] })
if target_doc != doc:
print(f"❌ Mismatch in _id: {doc['_id']}")
else:
print(f"✅ Match: {doc['_id']}")
```
### Validation par DataDiffer outil
L'[DataDiffer outil](https://github.com/awslabs/amazon-documentdb-tools/tree/master/migration/data-differ) fournit un moyen fiable de comparer les données entre les bases de données source et cible.
#### Conditions préalables
Les conditions préalables suivantes doivent être remplies avant d'installer l' DataDiffer outil :
+ Python 3.7\$1
+ PyMongo bibliothèque
+ Connectivité réseau à la fois aux clusters source MongoDB et aux clusters Amazon DocumentDB cibles
#### Configuration et installation
**Clonez le dépôt et naviguez jusqu'au DataDiffer répertoire**
```
git clone https://github.com/awslabs/amazon-documentdb-tools.git
cd amazon-documentdb-tools/migration/data-differ
```
**Installer les dépendances requises**
```
pip install -r requirements.txt
```
#### Validation des données en cours
**Créez un fichier de configuration (par exemple, config.json) avec les détails de connexion**
```
{
"source": {
"uri": "mongodb://username:password@source-mongodb-
host:27017/?replicaSet=rs0",
"db": "your_database",
"collection": "your_collection"
},
"target": {
"uri": "mongodb://username:password@target-docdb-
cluster.region.docdb.amazonaws.com:27017/?tls=true&tlsCAFile=global-
bundle.pem&replicaSet=rs0",
"db": "your_database",
"collection": "your_collection"
},
"options": {
"batch_size": 1000,
"threads": 4,
"sample_size": 0,
"verbose": true
}
}
```
**Exécutez l' DataDiffer outil**
```
python differ.py --config config.json
```
**Pour les grandes collections, utilisez l'échantillonnage pour valider un sous-ensemble de données**
```
python differ.py --config config.json --sample-size 10000
```
**Pour valider plusieurs collections, créez des fichiers de configuration distincts ou utilisez le mode batch**
```
python differ.py --batch-config batch_config.json
```
#### Interprétation des résultats
L'outil produira :
+ Nombre total de documents dans la source et dans la cible
+ Nombre de documents correspondants
+ Nombre de documents manquants
+ Nombre de documents présentant des différences
+ Rapport détaillé des différences (le cas échéant)
#### Bonnes pratiques
Les meilleures pratiques relatives à l'utilisation de l' DataDiffer outil sont les suivantes :
+ **Exécution par étapes** : validez d'abord le nombre de documents, puis échantillonnez les documents clés, puis effectuez une comparaison complète, si nécessaire.
+ **Vérifiez les différences de schéma** : Amazon DocumentDB présente certaines limites par rapport à MongoDB. L'outil mettra en évidence les types de données ou les structures incompatibles.
+ **Valider pendant les périodes calmes** : exécutez la validation lorsque les opérations d'écriture sont minimales pour garantir la cohérence.
+ **Surveiller l'utilisation des ressources** — Le processus de comparaison peut être gourmand en ressources. Ajustez la taille du lot et le nombre de fils en conséquence.
+ **Valider les index** : après la validation des données, assurez-vous que tous les index requis ont été créés sur le cluster Amazon DocumentDB cible.
+ **Résultats de validation des documents** — Conservez un enregistrement des résultats de validation pour chaque collection dans le cadre de votre documentation de migration.
# Migration depuis Couchbase Server
**Topics**
+ [Introduction](#introduction)
+ [Comparaison avec Amazon DocumentDB](#comparison-to-amazon-documentdb)
+ [Découverte](#discovery)
+ [Planification](#planning)
+ [Migration](#migration)
+ [Validation](#validation)
## Introduction
Ce guide présente les points clés à prendre en compte lors de la migration de Couchbase Server vers Amazon DocumentDB. Il explique les considérations relatives aux phases de découverte, de planification, d'exécution et de validation de votre migration. Il explique également comment effectuer des migrations hors ligne et en ligne.
## Comparaison avec Amazon DocumentDB
| | **Serveur Couchbase** | **Amazon DocumentDB** |
| --- | --- | --- |
| Organisation des données | Dans les versions 7.0 et ultérieures, les données sont organisées en compartiments, étendues et collections. Dans les versions antérieures, les données étaient organisées en compartiments. | Les données sont organisées en bases de données et en collections. |
| Compatibilité | Il existe des services distincts APIs (par exemple, données, index, recherche, etc.). Les recherches secondaires utilisent SQL\$1\$1 (anciennement connu sous le nom de N1QL), un langage de requête basé sur le SQL standard ANSI, qui est donc familier à de nombreux développeurs. | Amazon DocumentDB est [compatible avec l'API MongoDB.](compatibility.html) |
| Architecture | Le stockage est attaché à chaque instance de cluster. Vous ne pouvez pas dimensionner le calcul indépendamment du stockage. | Amazon DocumentDB est conçu pour le cloud et pour éviter les limites des architectures de base de données traditionnelles. Les [couches de calcul et de stockage sont séparées](db-clusters-understanding.html) dans Amazon DocumentDB et la couche de calcul peut être [mise à l'échelle indépendamment](how-it-works.html) du stockage. |
| Ajoutez de la capacité de lecture à la demande | Les clusters peuvent être étendus en ajoutant des instances. Le stockage étant rattaché à l'instance sur laquelle le service est exécuté, le temps nécessaire pour le faire évoluer dépend de la quantité de données à déplacer vers la nouvelle instance ou à rééquilibrer. | Vous pouvez obtenir un dimensionnement de lecture pour votre cluster Amazon DocumentDB en [créant jusqu'à 15 répliques Amazon DocumentDB](db-cluster-manage-performance.html#db-cluster-manage-scaling-reads) dans le cluster. Il n'y a aucun impact sur la couche de stockage. |
| Restauration rapide en cas de défaillance d'un nœud | Les clusters sont dotés de fonctionnalités de basculement automatique, mais le temps nécessaire pour rétablir leur pleine capacité dépend de la quantité de données à déplacer vers la nouvelle instance. | Amazon DocumentDB peut généralement [basculer le cluster principal](failover.html) en 30 secondes et rétablir la pleine puissance du cluster en 8 à 10 minutes, quelle que soit la quantité de données qu'il contient. |
| Faites évoluer le stockage à mesure que les données augmentent | Pour le stockage en clusters autogéré, ne IOs procédez pas à une mise à l'échelle automatique. | [Stockage et mise à l' IOs échelle](db-cluster-manage-performance.html#db-cluster-manage-scaling-storage) d'Amazon DocumentDB automatiquement. |
| Backup des données sans affecter les performances | Les sauvegardes sont effectuées par le service de sauvegarde et ne sont pas activées par défaut. Comme le stockage et le calcul ne sont pas séparés, cela peut avoir un impact sur les performances. | Les sauvegardes Amazon DocumentDB sont activées par défaut et ne peuvent pas être désactivées. Les sauvegardes sont gérées par la couche de stockage, elles n'ont donc aucun impact sur la couche de calcul. Amazon DocumentDB prend en charge [la restauration à partir d'un instantané de cluster](backup_restore-restore_from_snapshot.html) et [la restauration à un point précis dans le temps](backup_restore-point_in_time_recovery.html). |
| Durabilité des données | Il peut y avoir un maximum de 3 répliques de données dans un cluster, pour un total de 4 copies. Chaque instance sur laquelle le service de données est exécuté comportera des copies actives et une, deux ou trois répliques des données. | Amazon DocumentDB conserve 6 copies de données, quel que soit le nombre d'instances de calcul, avec un quorum d'écriture de 4 et un résultat toujours vrai. Les clients reçoivent un accusé de réception une fois que la couche de stockage a conservé 4 copies des données. |
| Cohérence | La cohérence immédiate des K/V opérations est prise en charge. Le SDK Couchbase achemine les K/V demandes vers l'instance spécifique qui contient la copie active des données. Ainsi, une fois la mise à jour confirmée, le client est assuré de lire cette mise à jour. La réplication des mises à jour vers d'autres services (index, recherche, analyse, événements) est finalement cohérente. | Les répliques Amazon DocumentDB sont finalement cohérentes. Si des lectures cohérentes immédiates sont requises, le client peut lire à partir de l'instance principale. |
| Réplication | La réplication entre centres de données (XDCR) permet une réplication filtrée, active-passive/active-active des données dans de nombreuses topologies. | Les [clusters globaux Amazon DocumentDB](global-clusters.html) fournissent une réplication active-passive dans des topologies 1:many (jusqu'à 10). |
## Découverte
La migration vers Amazon DocumentDB nécessite une connaissance approfondie de la charge de travail de base de données existante. La découverte de la charge de travail consiste à analyser la configuration et les caractéristiques opérationnelles de votre cluster Couchbase (ensemble de données, index et charge de travail) afin de garantir une transition fluide avec un minimum de perturbations.
### Configuration du cluster
Couchbase utilise une architecture centrée sur les services où chaque fonctionnalité correspond à un service. Exécutez la commande suivante sur votre cluster Couchbase pour déterminer quels services sont utilisés (voir [Obtenir des informations sur les nœuds](https://docs.couchbase.com/server/current/rest-api/rest-node-get-info.html)) :
```
curl -v -u : \
http://:/pools/nodes | \
jq '[.nodes[].services[]] | unique'
```
Exemple de sortie :
```
[
"backup",
"cbas",
"eventing",
"fts",
"index",
"kv",
"n1ql"
]
```
Les services de Couchbase incluent les suivants :
#### Service de données (kv)
Le service de données permet read/write d'accéder aux données en mémoire et sur disque.
[Amazon DocumentDB prend en charge les K/V opérations sur les données JSON via l'API MongoDB.](java-crud-operations.html)
#### Service de requêtes (n1ql)
Le service de requêtes prend en charge l'interrogation de données JSON via SQL\$1\$1.
Amazon DocumentDB prend en charge l'interrogation de données JSON via l'API MongoDB.
#### Service d'indexation (index)
Le service d'index crée et gère des index sur les données, ce qui permet d'accélérer les requêtes.
Amazon DocumentDB prend en charge un index principal par défaut et la création d'index secondaires sur les données JSON via l'API MongoDB.
#### Service de recherche (fts)
Le service de recherche prend en charge la création d'index pour la recherche en texte intégral.
La fonctionnalité native de recherche en texte intégral d'Amazon DocumentDB vous permet d'[effectuer une recherche de texte sur de grands ensembles de données textuels à l'aide d'index de texte spécifiques via l'API](text-search.html) MongoDB. Pour les cas d'utilisation de la recherche avancée, l'intégration d'[Amazon DocumentDB Zero-ETL à Amazon OpenSearch Service](https://aws.amazon.com/blogs/big-data/amazon-documentdb-zero-etl-integration-with-amazon-opensearch-service-is-now-available/) fournit des fonctionnalités de recherche avancées, telles que la recherche floue, la recherche entre collections et la recherche multilingue, sur les données Amazon DocumentDB.
#### Service d'analyse (cbas)
Le service d'analyse prend en charge l'analyse des données JSON en temps quasi réel.
Amazon DocumentDB prend en charge les requêtes ad hoc sur les données JSON via l'API MongoDB. Vous pouvez également [exécuter des requêtes complexes sur vos données JSON dans Amazon DocumentDB à l'aide d'Apache Spark exécuté sur Amazon EMR](https://aws.amazon.com/blogs/database/run-complex-queries-on-massive-amounts-of-data-stored-on-your-amazon-documentdb-clusters-using-apache-spark-running-on-amazon-emr/).
#### Service de concours complet (concours complet)
Le service d'événements exécute une logique métier définie par l'utilisateur en réponse aux modifications des données.
Amazon DocumentDB automatise les charges de travail basées sur les événements en [invoquant des AWS Lambda fonctions chaque fois que les données changent avec](https://docs.aws.amazon.com/lambda/latest/dg/with-documentdb-tutorial.html) votre cluster Amazon DocumentDB.
#### Service de sauvegarde (sauvegarde)
Le service de sauvegarde planifie des sauvegardes de données complètes et incrémentielles et des fusions de sauvegardes de données précédentes.
Amazon DocumentDB sauvegarde en permanence vos données sur Amazon S3 avec une période de conservation de 1 à 35 jours afin que vous puissiez les restaurer rapidement à tout moment pendant la période de conservation des sauvegardes. Amazon DocumentDB prend également des instantanés automatiques de vos données dans le cadre de ce processus de sauvegarde continue. Vous pouvez également [gérer la sauvegarde et la restauration d'Amazon DocumentDB](https://aws.amazon.com/blogs/storage/manage-backup-and-restore-of-amazon-documentdb-with-aws-backup/) avec. AWS Backup.
### Caractéristiques opérationnelles
Utilisez l'[outil de découverte pour Couchbase](https://github.com/awslabs/amazon-documentdb-tools/tree/master/migration/discovery-tool-for-couchbase) pour obtenir les informations suivantes sur votre ensemble de données, vos index et votre charge de travail. Ces informations vous aideront à dimensionner votre cluster Amazon DocumentDB.
#### Jeu de données
L'outil récupère les informations suivantes relatives au compartiment, à l'étendue et à la collection :
1. nom de compartiment
1. type de compartiment
1. nom de la portée
1. nom de collection
1. taille totale (octets)
1. nombre total d'articles
1. taille de l'élément (octets)
#### Index
L'outil récupère les statistiques d'index suivantes et toutes les définitions d'index pour tous les compartiments. Notez que les index principaux sont exclus car Amazon DocumentDB crée automatiquement un index principal pour chaque collection.
1. nom de compartiment
1. nom de la portée
1. nom de collection
1. nom de l'index
1. taille de l'index (octets)
#### Charge de travail
L'outil récupère les métriques K/V des requêtes N1QL. K/V les valeurs métriques sont collectées au niveau du bucket et les métriques SQL\$1\$1 sont collectées au niveau du cluster.
Les options de ligne de commande de l'outil sont les suivantes :
```
python3 discovery.py \
--username \
--password \
--data_node \
--admin_port \
--kv_zoom \
--tools_path \
--index_metrics \
--indexer_port \
--n1ql_start \
--n1ql_step
```
Voici un exemple de commande :
```
python3 discovery.py \
--username username \
--password ******** \
--data_node "http://10.0.0.1" \
--admin_port 8091 \
--kv_zoom week \
--tools_path "/opt/couchbase/bin" \
--index_metrics true \
--indexer_port 9102 \
--n1ql_start -60000 \
--n1ql_step 1000
```
Les valeurs métriques K/V seront basées sur des échantillons prélevés toutes les 10 minutes au cours de la semaine écoulée (voir [méthode HTTP et URI](https://docs.couchbase.com/server/current/rest-api/rest-bucket-stats.html#http-method-and-uri)). Les valeurs métriques SQL\$1\$1 seront basées sur des échantillons prélevés toutes les 1 seconde au cours des 60 dernières secondes (voir [Étiquettes générales](https://docs.couchbase.com/server/current/rest-api/rest-statistics-single.html#general-labels)). La sortie de la commande se trouvera dans les fichiers suivants :
**collection-stats.csv** : informations sur le bucket, le champ d'application et la collection
```
bucket,bucket_type,scope_name,collection_name,total_size,total_items,document_size
beer-sample,membase,_default,_default,2796956,7303,383
gamesim-sample,membase,_default,_default,114275,586,196
pillowfight,membase,_default,_default,1901907769,1000006,1902
travel-sample,membase,inventory,airport,547914,1968,279
travel-sample,membase,inventory,airline,117261,187,628
travel-sample,membase,inventory,route,13402503,24024,558
travel-sample,membase,inventory,landmark,3072746,4495,684
travel-sample,membase,inventory,hotel,4086989,917,4457
...
```
**index-stats.csv** — noms et tailles d'index
```
bucket,scope,collection,index-name,index-size
beer-sample,_default,_default,beer_primary,468144
gamesim-sample,_default,_default,gamesim_primary,87081
travel-sample,inventory,airline,def_inventory_airline_primary,198290
travel-sample,inventory,airport,def_inventory_airport_airportname,513805
travel-sample,inventory,airport,def_inventory_airport_city,487289
travel-sample,inventory,airport,def_inventory_airport_faa,526343
travel-sample,inventory,airport,def_inventory_airport_primary,287475
travel-sample,inventory,hotel,def_inventory_hotel_city,497125
...
```
**kv-stats.csv** — obtenir, définir et supprimer des métriques pour tous les buckets
```
bucket,gets,sets,deletes
beer-sample,0,0,0
gamesim-sample,0,0,0
pillowfight,369,521,194
travel-sample,0,0,0
```
**n1ql-stats.csv** — SQL\$1\$1 sélectionne, supprime et insère des métriques pour le cluster
```
selects,deletes,inserts
0,132,87
```
**indexes- .txt** : définitions d'index de tous les index du compartiment. Notez que les index principaux sont exclus car Amazon DocumentDB crée automatiquement un index principal pour chaque collection.
```
CREATE INDEX `def_airportname` ON `travel-sample`(`airportname`)
CREATE INDEX `def_city` ON `travel-sample`(`city`)
CREATE INDEX `def_faa` ON `travel-sample`(`faa`)
CREATE INDEX `def_icao` ON `travel-sample`(`icao`)
CREATE INDEX `def_inventory_airport_city` ON `travel-sample`.`inventory`.`airport`(`city`)
CREATE INDEX `def_inventory_airport_faa` ON `travel-sample`.`inventory`.`airport`(`faa`)
CREATE INDEX `def_inventory_hotel_city` ON `travel-sample`.`inventory`.`hotel`(`city`)
CREATE INDEX `def_inventory_landmark_city` ON `travel-sample`.`inventory`.`landmark`(`city`)
CREATE INDEX `def_sourceairport` ON `travel-sample`(`sourceairport`)
...
```
## Planification
Au cours de la phase de planification, vous déterminerez les exigences du cluster Amazon DocumentDB et le mappage des compartiments, des étendues et des collections Couchbase avec les bases de données et les collections Amazon DocumentDB.
### Exigences relatives au cluster Amazon DocumentDB
Utilisez les données collectées lors de la phase de découverte pour dimensionner votre cluster Amazon DocumentDB. Consultez la section [Dimensionnement des instances](best_practices.html#best_practices-instance_sizing) pour plus d'informations sur le dimensionnement de votre cluster Amazon DocumentDB.
### Mappage de compartiments, de portées et de collections avec des bases de données et des collections
Déterminez les bases de données et les collections qui existeront dans votre ou vos clusters Amazon DocumentDB. Envisagez les options suivantes en fonction de la façon dont les données sont organisées dans votre cluster Couchbase. Ce ne sont pas les seules options, mais elles constituent des points de départ à considérer.
#### Couchbase Server 6.x ou version antérieure
##### Buckets Couchbase pour les collections Amazon DocumentDB
Migrez chaque compartiment vers une collection Amazon DocumentDB différente. Dans ce scénario, la valeur du document Couchbase sera utilisée comme `id` valeur Amazon `_id` DocumentDB.
![\[Compartiments Couchbase Server 6.x ou version antérieure pour les collections Amazon DocumentDB\]](http://docs.aws.amazon.com/fr_fr/documentdb/latest/developerguide/images/buckets-to-collections.png)
#### Couchbase Server 7.0 ou version ultérieure
##### Collections Couchbase vers des collections Amazon DocumentDB
Migrez chaque collection vers une collection Amazon DocumentDB différente. Dans ce scénario, la valeur du document Couchbase sera utilisée comme `id` valeur Amazon `_id` DocumentDB.
![\[Collections Couchbase Server 7.0 ou version ultérieure vers des collections Amazon DocumentDB\]](http://docs.aws.amazon.com/fr_fr/documentdb/latest/developerguide/images/collections-to-collections.png)
## Migration
### Migration d'index
La migration vers Amazon DocumentDB implique le transfert non seulement de données, mais également d'index afin de maintenir les performances des requêtes et d'optimiser les opérations de base de données. Cette section décrit le step-by-step processus détaillé de migration des index vers Amazon DocumentDB tout en garantissant la compatibilité et l'efficacité.
Utilisez [Amazon Q](https://docs.aws.amazon.com/amazonq/latest/qdeveloper-ug/chat-with-q.html) pour convertir les `CREATE INDEX` instructions SQL\$1\$1 en commandes Amazon `createIndex()` DocumentDB.
1. Téléchargez le ou les fichiers **.txt d'index** créés par l'outil de découverte pour Couchbase.
1. Entrez le message suivant :
`Convert the Couchbase CREATE INDEX statements to Amazon DocumentDB createIndex commands`
Amazon Q générera des commandes Amazon DocumentDB `createIndex()` équivalentes. Notez que vous devrez peut-être mettre à jour les noms des collections en fonction de la façon dont vous avez [mappé les compartiments, les étendues et les collections Couchbase aux collections Amazon DocumentDB](#mapping-buckets-scopes-and-collections-to-databases-and-collections).
Par exemple :
**indexes-beer-sample.txt**
```
CREATE INDEX `beerType` ON `beer-sample`(`type`)
CREATE INDEX `code` ON `beer-sample`(`code`) WHERE (`type` = "brewery")
```
Exemple de sortie Amazon Q (extrait) :
```
db.beerSample.createIndex(
{ "type": 1 },
{
"name": "beerType",
"background": true
}
)
db.beerSample.createIndex(
{ "code": 1 },
{
"name": "code",
"background": true,
"partialFilterExpression": { "type": "brewery" }
}
)
```
Pour les index qu'Amazon Q n'est pas en mesure de convertir, reportez-vous à la section [Gestion des index et des propriétés d'index Amazon DocumentDB](managing-indexes.html) [pour plus d'informations](mongo-apis.html#mongo-apis-index).
### Code de refactorisation pour utiliser le MongoDB APIs
Les clients utilisent Couchbase SDKs pour se connecter au serveur Couchbase. Les clients Amazon DocumentDB utilisent les pilotes MongoDB pour se connecter à Amazon DocumentDB. Toutes les langues prises en charge par Couchbase SDKs sont également prises en charge par les pilotes MongoDB. Consultez la section [Pilotes MongoDB](https://www.mongodb.com/docs/drivers/) pour plus d'informations sur le pilote adapté à votre langue.
Comme il APIs existe des différences entre Couchbase Server et Amazon DocumentDB, vous devrez refactoriser votre code pour utiliser la MongoDB appropriée. APIs Vous pouvez utiliser [Amazon Q](https://docs.aws.amazon.com/amazonq/latest/qdeveloper-ug/chat-with-q.html) pour convertir les appels d' K/V API et les requêtes SQL\$1\$1 en MongoDB équivalent : APIs
1. Téléchargez le ou les fichiers de code source.
1. Entrez le message suivant :
`Convert the Couchbase API code to Amazon DocumentDB API code`
À l'aide de l'exemple de code [Python Hello Couchbase](https://docs.couchbase.com/python-sdk/current/hello-world/start-using-sdk.html#hello-couchbase), Amazon Q génère ce qui suit (extrait) :
```
from datetime import timedelta
from pymongo import MongoClient
# Connection parameters
database_name = "travel-sample"
# Connect to Amazon DocumentDB cluster
client = MongoClient('')
# Get reference to database and collection
db = client['travel-sample']
airline_collection = db['airline']
# upsert document function
def upsert_document(doc):
print("\nUpsert Result: ")
try:
# key will equal: "airline_8091"
key = doc["type"] + "_" + str(doc["id"])
doc['_id'] = key # Amazon DocumentDB uses _id as primary key
result = airline_collection.update_one(
{'_id': key},
{'$set': doc},
upsert=True
)
print(f"Modified count: {result.modified_count}")
except Exception as e:
print(e)
# get document function
def get_airline_by_key(key):
print("\nGet Result: ")
try:
result = airline_collection.find_one({'_id': key})
print(result)
except Exception as e:
print(e)
# query for document by callsign
def lookup_by_callsign(cs):
print("\nLookup Result: ")
try:
result = airline_collection.find(
{'callsign': cs},
{'name': 1, '_id': 0}
)
for doc in result:
print(doc['name'])
except Exception as e:
print(e)
# Test document
airline = {
"type": "airline",
"id": 8091,
"callsign": "CBS",
"iata": None,
"icao": None,
"name": "Couchbase Airways",
}
upsert_document(airline)
get_airline_by_key("airline_8091")
lookup_by_callsign("CBS")
```
Reportez-vous à la section [Connexion par programmation à Amazon](connect_programmatically.html) DocumentDB pour des exemples de connexion à Amazon DocumentDB en Python, Node.js, PHP, Go, Java, C\$1/.NET, R et Ruby.
### Sélectionnez l'approche de migration
Lors de la migration de données vers Amazon DocumentDB, deux options s'offrent à vous :
1. [migration hors ligne](#offline-migration)
1. [migration en ligne](#online-migration)
#### Migration hors ligne
Envisagez une migration hors ligne lorsque :
+ **Les temps d'arrêt sont acceptables :** la migration hors ligne implique l'arrêt des opérations d'écriture dans la base de données source, l'exportation des données, puis leur importation dans Amazon DocumentDB. Ce processus entraîne une interruption de service de votre application. Si votre application ou votre charge de travail peut tolérer cette période d'indisponibilité, la migration hors ligne est une option viable.
+ **Migration de petits ensembles de données ou réalisation de preuves de concept :** pour les petits ensembles de données, le temps nécessaire au processus d'exportation et d'importation est relativement court, ce qui fait de la migration hors ligne une méthode simple et rapide. Il est également parfaitement adapté au développement, aux tests et aux proof-of-concept environnements où les temps d'arrêt sont moins critiques.
+ **La simplicité est une priorité :** la méthode hors ligne, utilisant cbexport et mongoimport, est généralement l'approche la plus simple pour migrer des données. Il permet d'éviter les complexités liées à la saisie des données de modification (CDC) associées aux méthodes de migration en ligne.
+ **Aucune modification en cours ne doit être répliquée :** si la base de données source ne reçoit pas activement les modifications pendant la migration, ou si ces modifications ne sont pas essentielles pour être capturées et appliquées à la cible pendant le processus de migration, une approche hors ligne est appropriée.
**Topics**
+ [Couchbase Server 6.x ou version antérieure](#couchbase-6x-or-earlier-offline)
+ [Couchbase Server 7.0 ou version ultérieure](#couchbase-70-or-later-offline)
##### Couchbase Server 6.x ou version antérieure
##### Compartiment Couchbase pour la collection Amazon DocumentDB
Exportez les données à l'aide de [cbexport json](https://docs-archive.couchbase.com/server/6.6/tools/cbexport-json.html) pour créer un dump JSON de toutes les données du bucket. Pour l'`--format`option, vous pouvez utiliser `lines` ou`list`.
```
cbexport json \
--cluster \
--bucket \
--format \
--username \
--password \
--output export.json \
--include-key _id
```
Importez les données dans une collection Amazon DocumentDB à l'aide de [mongoimport](backup_restore-dump_restore_import_export_data.html#backup_restore-dump_restore_import_export_data-mongoimport) avec l'option appropriée pour importer les lignes ou la liste :
lignes :
```
mongoimport \
--db \
--collection \
--uri "" \
--file export.json
```
liste :
```
mongoimport \
--db \
--collection \
--uri "" \
--jsonArray \
--file export.json
```
##### Couchbase Server 7.0 ou version ultérieure
Pour effectuer une migration hors ligne, utilisez les outils cbexport et mongoimport :
##### Bucket Couchbase avec étendue et collection par défaut
Exportez les données à l'aide de [cbexport json](https://docs.couchbase.com/server/current/tools/cbexport-json.html) pour créer un dump JSON de toutes les collections du bucket. Pour l'`--format`option, vous pouvez utiliser `lines` ou`list`.
```
cbexport json \
--cluster \
--bucket \
--format \
--username \
--password \
--output export.json \
--include-key _id
```
Importez les données dans une collection Amazon DocumentDB à l'aide de [mongoimport](backup_restore-dump_restore_import_export_data.html#backup_restore-dump_restore_import_export_data-mongoimport) avec l'option appropriée pour importer les lignes ou la liste :
lignes :
```
mongoimport \
--db \
--collection \
--uri "" \
--file export.json
```
liste :
```
mongoimport \
--db \
--collection \
--uri "" \
--jsonArray \
--file export.json
```
##### Collections Couchbase vers des collections Amazon DocumentDB
Exportez les données à l'aide de [cbexport json](https://docs.couchbase.com/server/current/tools/cbexport-json.html) pour créer un dump JSON de chaque collection. Utilisez l'`--include-data`option pour exporter chaque collection. Pour l'`--format`option, vous pouvez utiliser `lines` ou`list`. Utilisez les `--collection-field` options `--scope-field` et pour enregistrer le nom de la portée et de la collection dans les champs spécifiés de chaque document JSON.
```
cbexport json \
--cluster \
--bucket \
--include-data . \
--format \
--username \
--password \
--output export.json \
--include-key _id \
--scope-field "_scope" \
--collection-field "_collection"
```
Puisque cbexport a ajouté les `_collection` champs `_scope` et à chaque document exporté, vous pouvez les supprimer de tous les documents du fichier d'exportation par recherche et remplacement`sed`, ou par la méthode de votre choix.
Importez les données de chaque collection dans une collection Amazon DocumentDB à l'aide de [mongoimport](backup_restore-dump_restore_import_export_data.html#backup_restore-dump_restore_import_export_data-mongoimport) avec l'option appropriée pour importer les lignes ou la liste :
lignes :
```
mongoimport \
--db \
--collection \
--uri "" \
--file export.json
```
liste :
```
mongoimport \
--db \
--collection \
--uri "" \
--jsonArray \
--file export.json
```
#### Migration en ligne
Envisagez une migration en ligne lorsque vous devez minimiser les temps d'arrêt et que les modifications en cours doivent être répliquées sur Amazon DocumentDB en temps quasi réel.
Consultez [Comment effectuer une migration en direct de Couchbase vers Amazon DocumentDB pour](https://github.com/awslabs/amazon-documentdb-tools/tree/master/migration/migration-utility-for-couchbase) savoir comment effectuer une migration en direct vers Amazon DocumentDB. La documentation explique comment déployer la solution et effectuer une migration en direct d'un bucket vers un cluster Amazon DocumentDB.
**Topics**
+ [Couchbase Server 6.x ou version antérieure](#couchbase-6x-or-earlier-online)
+ [Couchbase Server 7.0 ou version ultérieure](#couchbase-70-or-later-online)
##### Couchbase Server 6.x ou version antérieure
##### Compartiment Couchbase pour la collection Amazon DocumentDB
L'[utilitaire de migration pour Couchbase](https://github.com/awslabs/amazon-documentdb-tools/tree/master/migration/migration-utility-for-couchbase) est préconfiguré pour effectuer une migration en ligne d'un bucket Couchbase vers une collection Amazon DocumentDB. Si l'on examine la configuration du [connecteur récepteur](https://github.com/awslabs/amazon-documentdb-tools/blob/master/migration/migration-utility-for-couchbase/migration-utility-connectors.yaml), le `document.id.strategy` paramètre est configuré pour utiliser la valeur de la clé du message comme valeur de `_id` champ (voir [Propriétés de la stratégie de l'identifiant du connecteur récepteur](https://www.mongodb.com/docs/kafka-connector/current/sink-connector/configuration-properties/id-strategy/#std-label-sink-configuration-id-strategy)) :
```
ConnectorConfiguration:
document.id.strategy: 'com.mongodb.kafka.connect.sink.processor.id.strategy.ProvidedInKeyStrategy'
```
##### Couchbase Server 7.0 ou version ultérieure
##### Bucket Couchbase avec étendue et collection par défaut
L'[utilitaire de migration pour Couchbase](https://github.com/awslabs/amazon-documentdb-tools/tree/master/migration/migration-utility-for-couchbase) est préconfiguré pour effectuer une migration en ligne d'un bucket Couchbase vers une collection Amazon DocumentDB. Si l'on examine la configuration du [connecteur récepteur](https://github.com/awslabs/amazon-documentdb-tools/blob/master/migration/migration-utility-for-couchbase/migration-utility-connectors.yaml), le `document.id.strategy` paramètre est configuré pour utiliser la valeur de la clé du message comme valeur de `_id` champ (voir [Propriétés de la stratégie de l'identifiant du connecteur récepteur](https://www.mongodb.com/docs/kafka-connector/current/sink-connector/configuration-properties/id-strategy/#std-label-sink-configuration-id-strategy)) :
```
ConnectorConfiguration:
document.id.strategy: 'com.mongodb.kafka.connect.sink.processor.id.strategy.ProvidedInKeyStrategy'
```
##### Collections Couchbase vers des collections Amazon DocumentDB
Configurez le [connecteur source](https://github.com/awslabs/amazon-documentdb-tools/blob/master/migration/migration-utility-for-couchbase/migration-utility-connectors.yaml) pour diffuser chaque collection Couchbase de chaque étendue vers une rubrique distincte (voir [Options de configuration de la source](https://docs.couchbase.com/kafka-connector/current/source-configuration-options.html#couchbase.collections)). Par exemple :
```
ConnectorConfiguration:
# add couchbase.collections configuration
couchbase.collections: '., ., ...'
```
Configurez le [connecteur récepteur](https://github.com/awslabs/amazon-documentdb-tools/blob/master/migration/migration-utility-for-couchbase/migration-utility-connectors.yaml) pour qu'il diffuse depuis chaque rubrique vers une collection Amazon DocumentDB distincte (voir [Propriétés de configuration du connecteur récepteur](https://github.com/mongodb-labs/mongo-kafka/blob/master/docs/sink.md#sink-connector-configuration-properties)). Par exemple :
```
ConnectorConfiguration:
# remove collection configuration
#collection: 'test'
# modify topics configuration
topics: '.., .., ...'
# add topic.override.%s.%s configurations for each topic
topic.override....collection: ''
topic.override....collection: ''
```
## Validation
Cette section fournit un processus de validation détaillé pour vérifier la cohérence et l'intégrité des données après la migration vers Amazon DocumentDB. Les étapes de validation s'appliquent quelle que soit la méthode de migration.
**Topics**
+ [Vérifiez que toutes les collections existent dans la cible](#validation-checklist-step-1)
+ [Vérifiez le nombre de documents entre les clusters source et cible](#validation-checklist-step-2)
+ [Comparez les documents entre les clusters source et cible](#validation-checklist-step-3)
### Vérifiez que toutes les collections existent dans la cible
#### Source de Couchbase
option 1 : banc de requêtes
```
SELECT RAW `path`
FROM system:keyspaces
WHERE `bucket` = ''
```
option 2 : outil [cbq](https://docs.couchbase.com/server/current/cli/cbq-tool.html)
```
cbq \
-e \
-u \
-p \
-q "SELECT RAW `path`
FROM system:keyspaces
WHERE `bucket` = ''"
```
#### Cible Amazon DocumentDB
mongosh (voir [Connect to your Amazon DocumentDB cluster](connect-ec2-manual.html#manual-connect-ec2.connect-use)) :
```
db.getSiblingDB('')
db.getCollectionNames()
```
### Vérifiez le nombre de documents entre les clusters source et cible
#### Source de Couchbase
##### Couchbase Server 6.x ou version antérieure
option 1 : banc de requêtes
```
SELECT COUNT(*)
FROM ``
```
option 2 : [cbq](https://docs.couchbase.com/server/current/cli/cbq-tool.html)
```
cbq \
-e \
-u \
-p \
-q "SELECT COUNT(*)
FROM ``"
```
##### Couchbase Server 7.0 ou version ultérieure
option 1 : banc de requêtes
```
SELECT COUNT(*)
FROM ``.``.``
```
option 2 : [cbq](https://docs.couchbase.com/server/current/cli/cbq-tool.html)
```
cbq \
-e \
-u \
-p \
-q "SELECT COUNT(*)
FROM ``.``.``"
```
#### Cible Amazon DocumentDB
mongosh (voir [Connect to your Amazon DocumentDB cluster](connect-ec2-manual.html#manual-connect-ec2.connect-use)) :
```
db = db.getSiblingDB('')
db.getCollection('').countDocuments()
```
### Comparez les documents entre les clusters source et cible
#### Source de Couchbase
##### Couchbase Server 6.x ou version antérieure
option 1 : banc de requêtes
```
SELECT META().id as _id, *
FROM ``
LIMIT 5
```
option 2 : [cbq](https://docs.couchbase.com/server/current/cli/cbq-tool.html)
```
cbq \
-e
-u \
-p \
-q "SELECT META().id as _id, *
FROM `` \
LIMIT 5"
```
##### Couchbase Server 7.0 ou version ultérieure
option 1 : banc de requêtes
```
SELECT COUNT(*)
FROM ``.``.``
```
option 2 : [cbq](https://docs.couchbase.com/server/current/cli/cbq-tool.html)
```
cbq \
-e \
-u \
-p \
-q "SELECT COUNT(*)
FROM ``.``.``"
```
#### Cible Amazon DocumentDB
mongosh (voir [Connect to your Amazon DocumentDB cluster](connect-ec2-manual.html#manual-connect-ec2.connect-use)) :
```
db = db.getSiblingDB('')
db.getCollection('').find({
_id: {
$in: [
<_id 1>, <_id 2>, <_id 3>, <_id 4>, <_id 5>
]
}
})
```