Conseils pour la mise à niveau vers la dernière version de MongoDB

Les dernières versions de MongoDB sont conçues pour intégrer des fonctionnalités nouvelles ou améliorées des versions précédentes. Pour cette raison, il est recommandé d'exécuter la dernière version pour des performances maximales et des fonctionnalités supplémentaires. De plus, les dernières versions peuvent être le résultat de bogues corrigés en fonction de la version de MongoDB.

Gestion des versions de MongoDB

Les versions de MongoDB sont au format X.Y.Z.

Lorsque Y est pair, c'est-à-dire 4.0 ou 4.2, cela fait référence à une série de versions qui est stable et donc recommandée pour la production. Dans ce cas, de nouvelles fonctionnalités sont intégrées, ce qui peut entraîner une incompatibilité descendante.
Si Y est impair, c'est-à-dire 4,1 ou 4,3, il s'agit d'une série de développement qui n'est pas stable et donc recommandée uniquement pour les tests.
Z fait référence à un numéro de révision/correctif. Implique la correction de bogues et des modifications rétrocompatibles.

Il est également important de tenir compte des versions du pilote MongoDB pour garantir une base de données performante.

Considérations avant la mise à niveau

Sauvegarde :À mi-chemin de la mise à niveau, un plantage peut se produire et, à la fin, compromettre l'intégrité des données que la base de données contenait. Par conséquent, il est recommandé de toujours faire une sauvegarde des données avant de passer à une certaine version.
Fenêtre de maintenance :Il peut y avoir une certaine complexité qui peut survenir lors de la mise à niveau vers une version si des jeux de réplicas sont impliqués. Il faut prévoir suffisamment de temps pour ce processus afin de ne pas rencontrer de temps d'arrêt élevés.
Compatibilité des versions :Assurez-vous de parcourir les notes de version et vérifiez si la configuration de votre système sera compatible avec la version vers laquelle vous souhaitez effectuer la mise à niveau. Consultez également la documentation sur la compatibilité des pilotes sur la page de compatibilité des pilotes s'ils peuvent aller de pair avec la version de MongoDB vers laquelle vous souhaitez effectuer la mise à niveau. Par exemple, à partir de MongoDB 4.2, le système Ubuntu 16.04 PPCLE n'est pas pris en charge.
Modifier les flux :Les flux de modifications sont conçus pour que les applications accèdent aux modifications de données en temps réel sans nécessairement suivre l'oplog. Pour les versions de MongoDB antérieures à la 4.0.7, le flux de modifications utilise un jeton de reprise version 0 v0 alors que cette version et les successeurs utilisent un jeton de reprise version 1 v1. Il est recommandé aux clients d'attendre la fin de la mise à niveau avant de reprendre les flux de modifications lors de la mise à niveau vers la version 4.0.7.
Vérification de l'environnement de mise en scène :Assurez-vous que toutes les configurations sont bien configurées avant de mettre à niveau l'environnement de production et qu'elles seront compatibles avec la nouvelle version vers laquelle vous souhaitez effectuer la mise à niveau.
Primaire -Secondaire -Architecture d'arbitrage (PSA) :MongoDB version 3.6 et supérieure active la prise en charge de la préoccupation de lecture « majoritaire » par défaut. Cependant, cette configuration peut entraîner une pression sur le cache de stockage et la seule façon d'éviter cela est de désactiver ce paramètre. Néanmoins, la désactivation de ce paramètre peut soulever plus de problèmes, c'est-à-dire :
1. La prise en charge des transactions sur un cluster fragmenté sera affectée dans les cas suivants :
  1. si une partition a la lecture concernant la "majorité" désactivée, elle générera une erreur pour une transaction qui écrit sur plusieurs partitions.
  2. L'« instantané » de la préoccupation de lecture ne peut pas être utilisé pour une transaction impliquant une partition avec la préoccupation de lecture « majorité » désactivée
2. les commandes collMod responsables de la modification d'un index à partir d'une annulation ne fonctionneront pas. Cela signifie que si une opération doit être annulée, il faut utiliser le nœud principal pour resynchroniser les nœuds concernés.
3. La prise en charge de Change Streams pour MongoDB 4.0 et les versions antérieures sera également désactivée.
4. Les transactions de jeux de réplicas ne sont pas affectées par la désactivation de ce paramètre.

Procédures de mise à niveau

Effectuez une sauvegarde de vos données.
Mettre à niveau le binaire mongod/mongos séparément à l'aide de l'outil de gestion des packages système aux côtés des packages MongoDB officiels. Vous pouvez également mettre à niveau les mongos en remplaçant les fichiers binaires existants par de nouveaux fichiers binaires à l'aide de ces procédures :
1. Téléchargez les fichiers binaires MongoDB pour la révision vers laquelle vous souhaitez mettre à niveau et stockez le fichier compressé téléchargé dans un emplacement temporaire.
2. Arrêtez l'instance.
3. Utilisez les binaires téléchargés pour remplacer les binaires MongoDB existants.
4. Redémarrez l'instance.
Si vous mettez à niveau un jeu de répliques, mettez à niveau chaque membre séparément en commençant par les secondaires et le primaire en dernier. Pour mettre à niveau les secondaires :
1. Mettre à jour le binaire mongod
2. Attendez que le secondaire revienne à l'état SECONDAIRE et, une fois terminé, mettez à niveau l'instance suivante. rs.status() est utilisé pour vérifier l'état du membre dans un shell mongo. Les états RÉCUPÉRATION et DÉMARRAGE peuvent apparaître, mais vous devrez attendre qu'ils reviennent à SECONDAIRE.
Lors de la mise à niveau du principal :
1. Dans un shell mongo, utilisez rs.stepDown() pour réduire le primaire afin de lancer un basculement normal. Étant donné qu'aucune écriture ne sera acceptée pendant cette période, il est conseillé d'effectuer la mise à niveau dans les plus brefs délais.
2. Jusqu'à ce que vous voyiez qu'un autre membre a été élu comme principal, mettez à niveau les fichiers binaires du principal d'arrêt.
3. Redémarrez le primaire une fois la mise à niveau terminée, mais si vous vérifiez son état, rs.status(), il peut être étiqueté secondaire.
Pour mettre à niveau pour un cluster partagé MongoDB 4.4 :
1. Assurez-vous que l'équilibreur a été désactivé.
2. Mettre à niveau les serveurs de configuration de la même manière que vous avez mis à niveau le jeu de répliques.
3. Mettre à niveau le fragment à l'aide de la procédure correspondante, c'est-à-dire un jeu de réplicas ou un autonome.
4. Mettre à niveau chaque instance mongos dans l'ordre.
5. Réactivez l'équilibreur.

Conclusion

Avec le temps, les données deviennent plus complexes, ce qui nécessite des fonctionnalités de base de données avancées qui peuvent répondre aux spécifications des administrateurs de base de données. MongoDB ne se rabat pas sur cela car il publie toujours des versions de base de données avec des bogues corrigés ou des fonctionnalités nouvellement intégrées. Il est recommandé de toujours mettre à niveau vers la dernière version de MongoDB pour des performances maximales. Néanmoins, avant d'effectuer une mise à niveau, vous devez vérifier les notes de version de la version vers laquelle vous souhaitez effectuer la mise à niveau si elle est compatible avec votre système. La mise à niveau des pilotes MongoDB correspondants est également conseillée.