Migration vers Amazon DocumentDB

• Utilisation de MongoDB comme source pour AWS DMS

• Utilisation d'Amazon DocumentDB comme cible pour AWS Database Migration Service

• Procédure pas à pas : migration de MongoDB vers Amazon DocumentDB

Détails d'architecture

• Nom

  Choisissez un nom unique pour le suivi de ce déploiement.

   

• Version

  Enregistrez la version de MongoDB que votre déploiement exécute. Pour rechercher la version, connectez-vous à un membre du jeu de réplicas avec le shell Mongo et exécutez l'opération db.version().

   

• Type

  Enregistrez si votre déploiement est une instance mongo autonome, un jeu de réplicas ou un cluster partitionné.

   

• Membres

  Enregistrez les noms d'hôte, les adresses, et les ports de chaque cluster, jeu de réplicas ou membre autonome.

   

  Pour un déploiement en cluster, vous pouvez trouver les membres de partition mongo en vous connectant à un hôte avec le shell Mongo et en exécutant l'opération sh.status().

   

  Pour un jeu de réplicas, vous pouvez obtenir les membres en vous connectant à un membre de l'ensemble de réplicas avec le shell Mongo et en exécutant l'opération rs.status().

   

• Tailles oplog

  Pour les jeux de réplicas ou les clusters partitionnés, enregistrez la taille de l'oplog pour chaque membre de l'ensemble de réplicas. Pour rechercher la taille oplog d'un membre, connectez-vous à un membre de l'ensemble de réplicas avec le shell mongo et exécutez l'opération ps.printReplicationInfo().

   

• Priorités des membres de l'ensemble de réplicas

  Pour les jeux de réplicas ou les clusters partitionnés, enregistrez la priorité de chaque membre du jeu de réplicas. Pour rechercher les priorités des membres du jeu de réplicas, connectez-vous à un membre du jeu de réplicas avec le shell Mongo et exécutez l'opération rs.conf(). La priorité est affichée en tant que valeur de la clé priority.

   

• TLS/SSLutilisation

  Enregistrez si Transport Layer Security (TLS) /Secure Sockets Layer (SSL) est utilisé sur chaque nœud pour le chiffrement en transit.

Caractéristiques d'exploitation

• Statistiques de base de données

  Pour chaque collection, enregistrez les informations suivantes :

  • Nom

  • La taille des données

  • Nombre de collections

   

  Pour rechercher les statistiques de la base de données, connectez-vous à cette dernière avec le shell Mongo et exécutez la commande db.runCommand({dbstats: 1}).

   

• Statistiques de collection

  Pour chaque collection, enregistrez les informations suivantes :

  • Espace de noms

  • La taille des données

  • Nombre d'index

  • Si la collection est limitée

   

• Statistiques d'index

  Pour chaque collection, enregistrez les informations d'index suivantes :

  • Espace de noms

  • ID

  • Size

  • Clés

  • TTL

  • Fragmentée

  • Contexte

   

  Pour rechercher les informations d'index, connectez-vous à la base de données avec le shell Mongo et exécutez la commande db.collection.getIndexes().

   

• Compteurs d'opérations

  Ces informations vous permettent de comprendre vos modèles de charge de travail MongoDB actuels (beaucoup de lectures, beaucoup d'écritures ou équilibre). Il fournit également des conseils sur votre sélection initiale d'instance Amazon DocumentDB.

   

  Voici les informations à collecter au cours de la période de surveillance (en nombre/sec) :

  • Requêtes

  • Insertions

  • Mises à jour

  • Suppressions

   

  Vous pouvez obtenir ces informations en représentant dans un graphique le résultat de la commande db.serverStatus() au fil du temps. Vous pouvez également utiliser l'outil mongostat pour obtenir des valeurs instantanées pour ces statistiques. Toutefois, avec cette option, vous risquez de planifier votre migration sur des périodes d'utilisation autres que vos pics de charge.

   

• Statistiques réseau

  Ces informations vous permettent de comprendre vos modèles de charge de travail MongoDB actuels (beaucoup de lectures, beaucoup d'écritures ou équilibre). Il fournit également des conseils sur votre sélection initiale d'instance Amazon DocumentDB.

   

  Voici les informations à collecter au cours de la période de surveillance (en nombre/sec) :

  • Connexions

  • Octets réseau entrants

  • Octets réseau sortants

   

  Vous pouvez obtenir ces informations en représentant dans un graphique le résultat de la commande db.serverStatus() au fil du temps. Vous pouvez également utiliser l'outil mongostat pour obtenir des valeurs instantanées pour ces statistiques. Toutefois, avec cette option, vous risquez de planifier votre migration sur des périodes d'utilisation autres que vos pics de charge.

• Disponibilité

  Amazon DocumentDB fournit une haute disponibilité grâce au déploiement d'instances de réplication, qui peuvent être promues au rang d'instance principale dans le cadre d'un processus appelé failover. En déployant des instances de réplica dans différentes zones de disponibilité, vous pouvez atteindre des niveaux de disponibilité plus élevés.

   

  Le tableau suivant fournit des directives relatives aux configurations de déploiement d'Amazon DocumentDB afin de répondre à des objectifs de disponibilité spécifiques.

   

  Objectif de disponibilité	Total des instances	Réplicas	Zones de disponibilité
  99 %	1	0	1
  99,9 %	2	1	2
  99,99 %	3	2	3

   

  La fiabilité globale du système doit prendre en compte tous les composants, pas seulement la base de données. Pour connaître les meilleures pratiques et les recommandations visant à répondre aux besoins globaux de fiabilité du système, consultez le livre blanc AWS Well-Architected Reliability Pillar.

   

• Performances

  Les instances Amazon DocumentDB vous permettent de lire et d'écrire sur le volume de stockage de votre cluster. Les instances de cluster sont de plusieurs types, avec des quantités de mémoire et de v variablesCPU, ce qui affecte les performances de lecture et d'écriture de votre cluster. À l'aide des informations que vous avez collectées lors de la phase de détection, choisissez un type d'instance capable de prendre en charge vos exigences de performances pour la charge de travail. Pour obtenir la liste des types d’instances, consultez Gestion des classes d'instances.

   

  Lorsque vous choisissez un type d'instance pour votre cluster Amazon DocumentDB, tenez compte des aspects suivants des exigences de performance de votre charge de travail :

  • vCPUs—Les architectures qui nécessitent un nombre de connexions plus élevé peuvent bénéficier d'instances avec plus de v. CPUS

     

  • Mémoire : lorsque cela est possible, le fait de conserver votre ensemble de données de travail en mémoire garantit des performances optimales. Une règle de départ consiste à réserver un tiers de la mémoire de votre instance pour le moteur Amazon DocumentDB, en laissant les deux tiers pour votre ensemble de données de travail.

     

  • Connexions — Le nombre de connexions optimal minimum est de huit connexions par instance Amazon DocumentDB v. CPU Bien que la limite de connexion aux instances Amazon DocumentDB soit beaucoup plus élevée, les avantages en termes de performances liés aux connexions supplémentaires diminuent au-delà de huit connexions par v. CPU

     

  • Réseau : les charges de travail comportant un grand nombre de clients ou de connexions doivent tenir compte des performances réseau agrégées requises pour les données insérées et extraites. Les opérations en bloc peuvent utiliser plus efficacement les ressources réseau.

     

  • Performances d'insertion : les insertions de documents uniques constituent généralement le moyen le plus lent d'insérer des données dans Amazon DocumentDB. Les opérations d'insertion en bloc peuvent être nettement plus rapides que les insertions uniques.

     

  • Performances de lecture : les lectures depuis la mémoire de travail sont toujours plus rapides que les lectures renvoyées depuis le volume de stockage. Par conséquent, l'optimisation de la taille de la mémoire d'instance afin de conserver votre jeu de travail en mémoire est idéale.

     

  En plus de servir les lectures depuis votre instance principale, les clusters Amazon DocumentDB sont automatiquement configurés en tant que jeux de répliques. Vous pouvez alors acheminer les requêtes en lecture seule vers les réplicas en lecture en définissant la préférence de lecture dans votre pilote MongoDB. Vous pouvez dimensionner le trafic en lecture en ajoutant des réplicas, ce qui réduit la charge globale sur l'instance principale.

   

  Il est possible de déployer des répliques Amazon DocumentDB de différents types d'instances dans le même cluster. Un exemple de cas d'utilisation peut être le maintien d'un réplica avec un type d'instance plus important pour servir le trafic d'analyses temporaire. Si vous déployez un ensemble de types d'instance varié, assurez-vous de configurer la priorité de basculement pour chaque instance. Vous vous assurerez ainsi qu'un événement de basculement promeut toujours un réplica d'une taille suffisante pour gérer votre charge d'écriture.

   

• Récupération

  Amazon DocumentDB sauvegarde en permanence vos données au fur et à mesure qu'elles sont écrites. Il fournit des fonctionnalités de point-in-time restauration (PITR) sur une période configurable de 1 à 35 jours, connue sous le nom de période de conservation des sauvegardes. La durée de conservation des sauvegardes par défaut est d'un jour. Amazon DocumentDB crée également automatiquement des instantanés quotidiens de votre volume de stockage, qui sont également conservés pendant la période de conservation des sauvegardes configurée.

   

  Si vous souhaitez conserver les instantanés au-delà de la période de conservation des sauvegardes, vous pouvez également lancer des instantanés manuels à tout moment à l'aide du bouton AWS Management Console et AWS Command Line Interface ()AWS CLI. Pour de plus amples informations, veuillez consulter Sauvegarde et restauration dans Amazon DocumentDB.

   

  Tenez compte des éléments suivants lorsque vous planifiez votre migration :

  • Choisissez une période de conservation des sauvegardes de 1 à 35 jours qui répond à votre objectif de point de restauration (RPO).

  • Déterminez si vous avez besoin que les instantanés soient créés manuellement et, le cas échéant, à quel intervalle.

• Vérifiez que l'approche choisie donne le résultat de migration souhaité.

• Vérifiez que vos choix de type d'instance et préférences de lecture respectent les exigences en matière de performances de votre application.

• Vérifiez le comportement de votre application lors du basculement.

• Avant d'exécuter mongodump ou de démarrer une tâche de migration AWS DMS , vous devez désactiver l'équilibreur de cluster partitionné et attendre la fin de toutes les migrations en cours. Pour de plus amples informations, veuillez consulter Désactiver l'équilibreur dans la documentation MongoDB.

• Si vous utilisez AWS DMS pour répliquer des données, exécutez la cleanupOrphaned commande sur chaque partition avant d'exécuter les tâches de migration. Si vous n'exécutez pas cette commande, les tâches risquent d'échouer en raison d'un document dupliquéIDs. Notez que cette commande peut avoir un impact sur les performances. Pour plus d'informations, consultez cleanupOrphanedla documentation de MongoDB.

• Si vous utilisez l'outil mongodump pour vider les données, vous devez exécuter un processus mongodump par partition. L'approche la plus efficace en terme de durée peut nécessiter plusieurs serveurs de migration pour optimiser vos performances de vidage.

• Si vous utilisez AWS Database Migration Service pour répliquer des données, vous devez créer un point de terminaison source pour chaque partition. Exécutez également au moins une tâche de migration pour chaque partition que vous migrez. L'approche la plus efficace en terme de durée peut nécessiter plusieurs instances de réplication pour optimiser vos performances de migration.

• Débit réseau

• Write throughput

• Read throughput

• Replica lag

Consultez les rubriques suivantes dans le Guide de l'utilisateur AWS Database Migration Service  :

• Utilisation d'Amazon DocumentDB comme cible pour AWS Database Migration Service

• Procédure : Migration de MongoDB vers Amazon DocumentDB