Mise à jour produit hebdomadaire : mise à niveau vers MongoDB 2.4.1

Publié initialement le 12 avril 2013.

Cette semaine, nous nous sommes concentrés sur l’amélioration du backend pour rendre Mailgun plus performant, fiable et évolutif. Beaucoup de choses ennuyeuses, mais nous espérons que vous remarquerez la différence.

L’une de nos actions principales a été de mettre à niveau MongoDB de la version 2.2 à la version 2.4.1. Chez Mailgun, nous sommes de grands fans de MongoDB. L’article détaillé sur « Pourquoi MongoDB » se fait attendre, mais en attendant, voici un aperçu de notre expérience de mise à niveau vers la dernière version de MongoDB. Nous avons également effectué la mise à niveau vers la dernière version de pymongo : le pilote Python de MongoDB.

Nous recommandons vivement cette montée de version à toutes les personnes qui utilisent MongoDB en production. Bien que vous puissiez consulter la liste complète des nouveautés de la version 2.4.1 sur le site Web de 10Gen, voici la liste des fonctionnalités et améliorations que nous avons trouvées particulièrement utiles lors de notre évaluation dans notre environnement de préproduction :

• Nouvelles classes MongoClient et MongoReplicaSet. Elles introduisent le nouveau comportement par défaut sécurisé : l’attente des accusés de réception d’écriture.
• Corrections de bugs survenues après l’introduction de la version 2.4.

Notre équipe d’ingénierie d’infrastructure a effectué la mise à niveau sur un système en direct à forte charge sans aucun problème.

Par défaut, les tests ne passeront pas.  Vous devrez corriger certaines erreurs d’importation. Par exemple, objectidmodule est passé du package pymongo au package bson. Autrement, la mise à niveau est plutôt sûre car le nouveau comportement par défaut n’est présent que dans les nouvelles classes de connexion.

Il y a une mise en garde importante à prendre en compte : dans cette version, 10Gen a introduit le concept de requêtes. Les objets de connexion que vous obtenez de pymongo sont désormais liés à leur thread d’appel par défaut. Nos tests ont montré une dégradation des performances d’un facteur 3 ! Vos résultats peuvent varier, mais dans tous les cas, il s’agit d’un changement de comportement par défaut très important. Nous aurions aimé que 10Gen soit plus explicite à ce sujet.

Vous ne devriez pas utiliser MongoDB sans jeux de répliques. Cela vous permet non seulement de résister aux pannes matérielles, mais aussi d’effectuer des mises à niveau de la version de la base de données à la volée. Voici les étapes que nous suivons :

• Évidemment, assurez-vous de disposer d’une sauvegarde récente de vos données. Nous effectuons des sauvegardes en arrêtant l’un des nœuds secondaires, en compactant sa base de données et en envoyant l’archive tar du répertoire de la base de données vers Rackspace Cloud Files.
• Mettez à niveau un nœud secondaire à la fois, tout en surveillant l’état du jeu de répliques.
• Enfin, rétrogradez le nœud principal.
• Mettez à niveau le nœud principal.

Dans l’ensemble, c’est une procédure très ennuyeuse et sans incident. Exactement comme nous l’aimons lorsqu’il s’agit de bases de données.

À la semaine prochaine.

Bons envois d’emails,
L’équipe Mailgun

Auteur·trice: The Sinch Mailgun team The Sinch Mailgun team shares news, best practices, and strategies to take your products and apps to the next level using email. Subscribe to our newsletter to get all the articles in your inbox!