MongoDB
 sql >> Base de données >  >> NoSQL >> MongoDB

Pourquoi démarrer une instance MongoDB solo en tant que jeu de répliques n'est pas recommandé en production ?

La fonction principale d'un jeu de répliques est de fournir une redondance des données et une haute disponibilité pour votre déploiement MongoDB. Autrement dit, si le nœud principal d'un jeu de répliques tombait en panne pour une raison quelconque, un nœud secondaire prendrait immédiatement le relais en tant que nouveau nœud principal (en moyenne dans les 10 secondes environ). Voir Réplication pour plus de détails sur ce sujet.

Les pilotes MongoDB officiels sont conscients de cet événement d'élection d'ensemble de répliques et fourniraient une reconnexion automatique et des tentatives d'opération au nouveau primaire. Du point de vue de l'application, rien ne s'est passé du côté de la base de données.

Un autre avantage de l'utilisation d'un jeu de réplicas avec plusieurs secondaires est la possibilité d'une mise à niveau/maintenance sans temps d'arrêt de manière continue. Cela peut être fait en mettant un secondaire hors ligne, en effectuant la maintenance dessus, puis en effectuant la maintenance sur les autres secondaires, et enfin en arrêtant le primaire et en effectuant la maintenance. Encore une fois, puisque les pilotes MongoDB officiels sont au courant de ces événements, vous pouvez techniquement effectuer la maintenance sur une base de données en direct avec un impact très minimal et sans temps d'arrêt de l'application.

C'est une philosophie différente par rapport à un serveur de base de données monolithique, où il n'y a qu'un seul vrai gros serveur. Bien qu'il y ait certains mérites dans un déploiement monolithique (ce qui est encore une fois une discussion différente :) ), MongoDB a été conçu comme une base de données distribuée tolérante aux pannes. Un inconvénient immédiat d'un serveur unique est que le serveur doit être à 100% à tout moment, sinon l'application est interrompue. Un jeu de réplicas a été conçu pour que votre application puisse avoir une disponibilité de 100 % sans exercer de pression sur les serveurs individuels devant avoir une disponibilité de 100 %.

En prime, un jeu de répliques peut être en mesure de fournir une évolutivité en lecture en configurant le pilote pour qu'il lise à partir des secondaires (les écritures doivent toujours aller au primaire). Notez qu'il doit y avoir une conception soignée si vous souhaitez effectuer des lectures secondaires, car cela peut potentiellement interférer avec l'aspect haute disponibilité en cas d'abus.

En résumé, un jeu de répliques peut fournir :

  • Haute disponibilité et tolérance aux pannes
  • Pas de temps d'arrêt de maintenance
  • Redondance des données pour adapter les lectures

sans exiger que le matériel soit fiable à 100 %. C'est pourquoi un jeu de répliques est fortement recommandé dans un déploiement de prod.

Voir Architectures de déploiement d'ensembles de réplicas pour des considérations plus détaillées sur le déploiement d'ensembles de répliques.