Une liste de contrôle du développement et des opérations pour MongoDB

Les listes de contrôle de fonctionnement et de développement de MongoDB sont destinées à aider les administrateurs de bases de données à éviter de rencontrer des problèmes dans l'environnement de production MongoDB. Une liste de contrôle de développement doit traiter des problèmes tels que...

1. Conception de schéma
2. Durabilité des données
3. Réplication
4. Drive 
5. Partagement 

Une liste de contrôle des opérations, d'autre part, traite...

1. Réplication
2. Système de fichiers 
3. Sharding
4. Matériel
5. Journalisation (moteur de stockage WiredTiger) 
6. Configurations du système d'exploitation 
7. Déploiement sur du matériel cloud 
8. Surveillance
9. Sauvegardes et équilibrage de charge

Avant de lancer un projet, il est conseillé de travailler sur la liste de contrôle d'exploitation et de développement pour permettre le bon fonctionnement de MongoDB en production. Cet article explique la liste de contrôle de fonctionnement et de développement avant de déployer MongoDB.

Liste de contrôle des opérations MongoDB

Réplication

Tous les ensembles de membres dupliqués qui ne sont pas masqués doivent être provisionnés de la même manière en ce qui concerne le disque, la RAM, la configuration réseau et le processeur.

La taille d'Oplog doit être configurée correctement pour répondre aux besoins opérationnels tels que :

• Pour éviter la nécessité d'une resynchronisation complète, la fenêtre de l'application oplog de réplique doit couvrir la période d'arrêt et la fenêtre de maintenance habituelles.
• Pour restaurer un membre du jeu de réplication, la fenêtre oplog du réplica doit toujours couvrir le temps nécessaire.

L'ensemble de production doit au minimum intégrer trois nœuds porteurs de données qui s'exécutent avec la journalisation activée. En outre, les écritures doivent être émises avec w :préoccupation d'écriture "majoritaire" dans le but d'assurer la disponibilité et la durabilité des données.

Le déploiement doit contenir un nombre impair de membres votants pour faciliter le processus de vote en cas de défaillance du nœud principal du cluster.

Plutôt que d'utiliser des adresses IP qui peuvent nécessiter de modifier les configurations en raison du changement d'adresse IP, l'utilisation de noms d'hôte DNS logiques est recommandée.

Assurez-vous que les instances mongod ont 0 ou 1 vote.

Toutes les instances Mongod doivent être entièrement et bidirectionnellement connectées de manière à faciliter la communication des données entre les nœuds impliqués.

Journalisation

Il s'agit d'une stratégie de journalisation sur disque à écriture anticipée utilisée pour assurer la durabilité des données en cas de panne. Toutes les instances doivent avoir la journalisation activée pour cette raison, en particulier lorsqu'il s'agit de charges de travail intensives en écriture.

Cependant, tenez compte du fait que cela affecte les renforcements de type instantané, car les enregistrements constituant l'état de la base de données résideront sur des volumes partitionnés.

Système de fichiers

N'utilisez pas de lecteurs NFS (News File System) pour dbPath. Les lecteurs NFS peuvent éventuellement entraîner une performance déstabilisée. Les lecteurs virtuels VMware sont recommandés pour les utilisateurs VMware.

Assurez-vous que vos partitions de disque sont alignées avec vos configurations RAIDON.

Pour les utilisateurs Linux/Unix, l'utilisation de XFS est recommandée. XFS est connu pour être plus performant avec MongoDB.

Pour les utilisateurs du système d'exploitation Windows, le système de fichiers NTFS est recommandé. Vous devez éviter d'utiliser un système de fichiers FAT.

Déploiement sur du matériel cloud

Windows Azure :modifiez le TCP keepalive (tcp_keepalive_time) sur 100-120. Le délai d'expiration du délai d'attente TCP sur l'équilibreur de pile Azure est également modéré pour le comportement de regroupement d'associations de MongoDB

Utilisez MongoDB 2.6.4 ou des versions plus récentes sur des frameworks avec un stockage à latence élevée, tels que Windows Azure, car ces versions intègrent des améliorations d'exécution pour ces frameworks.

Partage

Placez vos serveurs de configuration sur du matériel dédié pour une exécution idéale dans des clusters étendus.

Assurez-vous que le matériel dispose de suffisamment de RAM pour contenir entièrement les enregistrements d'informations en mémoire et dispose d'un espace de stockage dédié.

Déployez les routeurs mongos conformément aux directives de configuration de génération.

Synchronisez les horloges de tous les composants de votre cluster partitionné à l'aide de NTP.

Assurez-vous d'un réseau bidirectionnel complet entre les serveurs mongos, mongod et de configuration.

Utilisez des CNAME pour reconnaître vos serveurs de configuration dans le cluster afin de pouvoir renommer et renuméroter vos serveurs de configuration sans temps d'arrêt.

Surveillance

Vous pouvez utiliser des outils tels que MongoDB Cloud Manager, ClusterControl ou un autre cadre de surveillance pour filtrer les métriques clés de la base de données et configurer des alarmes. Incorporer des alertes pour les métriques :

• Files d'attente
• Fenêtre oplog de réplication
• Assertions
• Défauts de page
• Délai de réplication

Surveillez les métriques matérielles de vos serveurs. Faites particulièrement attention à l'espace disque disponible, à l'utilisation du disque, au CPU

Matériel

Utilisez des disques RAID10 et SSD pour des performances idéales.

SAN et virtualisation :

Assurez-vous que chacune des instances mongod a provisionné des IOPS pour son dbPath, ou a son disque physique ou LUN de revendication.

Évitez les points forts de la mémoire dynamique, tels que le gonflement de la mémoire, lors de l'exécution dans des environnements virtuels.

Évitez de configurer tous les individus de l'ensemble de copies sur le même SAN, car le SAN peut être un seul point de déception.

Équilibrage de charge

Concevez des équilibreurs de charge pour activer les "sessions persistantes" ou "l'affinité client" avec un délai d'expiration adéquat pour les connexions existantes.

Évitez de placer des équilibreurs de charge entre le cluster MongoDB ou les composants du jeu de répliques.

Sauvegardes

Planifiez des tests intermittents de votre processus de sauvegarde et de restauration pour avoir des jauges de temps à portée de main et confirmer son utilité.

Configuration du système d'exploitation

Windows

Envisagez de désactiver les mises à niveau NTFS "dernier accès".

Formater les disques NTFS en utilisant la taille d'unité d'allocation par défaut de 4096 octets.

Linux

Désactivez les énormes pages transparentes.

Apportez des ajustements aux paramètres de tête de lecture des dés où vos fichiers de base de données sont stockés. La lecture anticipée du moteur de stockage WiredTiger doit être définie entre 8 et 32.

Si vous utilisez tuned sur RHEL / CentOS, vous devez personnaliser votre profil ajusté. De nombreux profils optimisés fournis avec RHEL / CentOS peuvent nuire à l'exécution avec leurs paramètres par défaut. Personnalisez le profil que vous avez choisi pour :

Désactiver les pages énormes simples.

Définir la lecture anticipée entre 8 et 32 ​​dans tous les cas de tri de média de capacité.

Utilisez les planificateurs de disque noop ou d'échéance pour les disques SSD.

Utilisez le planificateur de disque noop pour les lecteurs virtualisés dans les machines virtuelles invitées.

Désactivez NUMA ou définissez vm.zone_reclaim_mode sur 0 et exécutez les occurrences mongod avec l'entrelacement des nœuds.

Ajustez les valeurs ulimit sur votre matériel en fonction de votre cas d'utilisation. Dans le cas où différentes occurrences mongod ou mongos s'exécutent sous le même client, mettez à l'échelle les valeurs ulimit de la même manière.

Concevez des descripteurs d'enregistrement adéquats (fs.file-max), une contrainte de pid de partie (kernel.pid_max), un nombre maximal de threads par processus (kernel.threads-max) et un nombre maximal de zones de contour de mémoire par processus (vm.max_map_count) pour votre envoi. Pour les cadres étendus, les valeurs suivantes constituent un excellent point de départ :

fs.file-max value of 98000,

kernel.pid_max value of 64000,

kernel.threads-max value of 64000, and vm.max_map_count value of 128000

Assurez-vous que votre framework dispose d'un espace d'échange configuré.

Faites allusion à la documentation de votre système d'exploitation pour les points d'intérêt sur le dimensionnement correct.

 Assurez-vous que le keepalive TCP par défaut du système est correctement défini. Une valeur de 300 donne souvent des performances supérieures pour les jeux de réplicas et les clusters partitionnés.

Liste de contrôle du développement MongoDB

Réplication

Utiliser un nombre impair de personnes votantes pour garantir que les élections se poursuivent efficacement. Vous aurez jusqu'à 7 personnes votantes. Si vous avez un nombre pair de personnes votantes et que des contraintes, telles que le coût, interdisent d'inclure un autre secondaire comme membre votant, vous pourrez inclure un arbitre pour garantir un nombre impair de votes.

Garantissez que vos secondaires restent à jour en utilisant des outils de surveillance et en indiquant les problèmes d'écriture appropriés.

N'utilisez pas de lectures auxiliaires pour mettre à l'échelle le débit de lecture global.

Conception de schéma

Les données dans MongoDB contiennent un modèle dynamique. Les collections ne respectent pas la structure du rapport. Cela encourage l'amélioration itérative et le polymorphisme. Dans tous les cas, les collections contiennent souvent des documents aux structures extrêmement homogènes.

Décidez de l'ensemble de collections dont vous aurez besoin et des index nécessaires pour sauvegarder vos requêtes. Avec le cas particulier de l'index _id, vous devez faire tous les index expressément :MongoDB ne fait naturellement aucun index autre que _id.

Garantissez que votre plan de schéma prend en charge votre type de déploiement :si vous envisagez d'utiliser des clusters partitionnés pour la mise à l'échelle horizontale, planifiez votre schéma pour incorporer une clé de partition forte. La clé de partition influence l'exécution de la lecture et de l'écriture en décidant de la façon dont MongoDB segmente les données. Vous ne pouvez pas modifier la clé de partition une fois qu'elle est définie.

Assurez-vous que votre plan de schéma ne dépend pas de clusters indexés dont la longueur augmente sans limite. Normalement, la meilleure exécution peut être obtenue lorsque ces clusters indexés ont moins de 1000 composants.

Tenez compte des limites d'estimation du document lors de la conception de votre schéma. La limite d'estimation de document BSON est de 16 Mo par document. Si vous avez besoin de rapports plus volumineux, utilisez GridFS.

Pilotes

Utilisez le regroupement d'associations. La plupart des pilotes MongoDB prennent en charge le regroupement d'associations. Modifiez la taille du pool d'associations en fonction de votre cas d'utilisation, en commençant par 110 à 115 % du nombre normal de demandes de base de données simultanées.

Assurez-vous que vos applications gèrent les erreurs d'écriture et de lecture temporelles lors des élections d'ensembles de répliques.

Assurez-vous que vos applications gèrent les requêtes ayant échoué et réessayez si nécessaire. Les conducteurs ne le font pas

réessayer naturellement les requêtes ayant échoué.

Utiliser une logique d'attente exponentielle pour les nouvelles tentatives de demande de base de données.

Utilisez cursor.maxTimeMS() pour les lectures et wtimeout pour les écritures au cas où vous souhaiteriez limiter la période d'exécution des opérations de base de données.

Durabilité des données

Assurez-vous que votre jeu de réplicas intègre au moins trois hubs porteurs de données avec w:majority compose concern. Trois hubs porteurs de données sont nécessaires pour la solidité des données à l'échelle de l'ensemble de réplicas.

Garantissez que toutes les instances utilisent la journalisation.

Partage

Garantissez que votre clé de partition transmet la charge de manière égale sur vos partitions.

Utilisez des opérations ciblées pour les charges de travail qui évoluent avec le nombre de partitions.

Pour MongoDB 3.6 et versions ultérieures, les secondaires ne renvoient plus de données orphelines à moins d'utiliser la préoccupation de lecture "disponible" (qui est la préoccupation de lecture par défaut pour les lectures sur les secondaires lorsqu'elles ne sont pas liées à des sessions causalement fiables).

À partir de MongoDB 3.6, tous les membres de l'ensemble de réplicas de fragments conservent les métadonnées des blocs, ce qui leur permet de filtrer les orphelins lorsqu'ils n'utilisent pas "disponible". Ainsi, les requêtes non ciblées ou diffusées qui n'utilisent pas "disponible" peuvent être exécutées en toute sécurité sur n'importe quel membre et ne renverront pas d'informations orphelines.

Le problème de lecture "accessible" peut renvoyer des documents orphelins à partir de membres auxiliaires car il ne vérifie pas les métadonnées de bloc révisées. Dans tous les cas, dans le cas où le retour de documents orphelins est insignifiant pour une application, la préoccupation de lecture "disponible" donne le moins de lectures d'inactivité possible parmi les différentes préoccupations de lecture.

Pré-divisez et ajustez manuellement les blocs lors de l'intégration de vastes ensembles de données dans une nouvelle collection fragmentée non hachée. Le pré-fractionnement et l'ajustement physique permettent à la pile d'intégration d'être dispersée parmi les fragments, ce qui étend l'exécution pour la charge de départ.

Conclusion 

La gestion des listes de contrôle d'exploitation et de développement est une étape cruciale que les développeurs doivent intégrer lors de l'utilisation de MongoDB en production. Ce sont des considérations essentielles car elles améliorent le flux de tâches pour un projet en production. L'environnement de production MongoDB nécessite des fonctionnalités de base de données stables et fiables, car la base de données en production stocke des données de travail réelles. L'intégrité des données dépend de la stabilité de la base de données qui est activée en s'assurant que tous les éléments de la liste de contrôle d'exploitation et de développement sont travaillés avant la production.