Mongodb - différence entre un jeu de répliques autonome et 1 nœud
J'avais besoin d'utiliser des transactions Mongo DB, et récemment j'ai compris que les transactions ne fonctionnent pas pour le mode autonome Mongo, mais uniquement pour les jeux de répliques ( Mongo DB avec C # - document ajouté quelle que soit la transaction ).
J'ai également lu que le mode autonome n'est pas recommandé pour la production.
J'ai donc découvert que la simple définition d'un nom de jeu de réplicas dans mongod.cfg est suffisante pour exécuter Mongo DB en tant que jeu de réplicas au lieu d'être autonome.
Après avoir changé cela, les transactions Mongo ont commencé à fonctionner.
Cependant, il semble un peu étrange de l'utiliser en tant que jeu de réplicas bien que je n'utilise pas vraiment la fonctionnalité de réplication, et je veux m'assurer que j'utilise une configuration valide.
Mes questions sont donc:
- Existe-t-il un problème/un inconvénient à exécuter Mongo en tant que jeu de réplicas à 1 nœud, en supposant que je n'ai pas vraiment besoin de la réplication, de l'équilibrage de charge ou de toute autre fonctionnalité évolutive? (comme je l'ai dit, j'en ai besoin pour autoriser les transactions)
- Quelles sont les différences de fonctionnalités et de performances, le cas échéant, entre l'exécution en tant qu'exécution autonome et l'exécution en tant que jeu de réplicas à 1 nœud?
- J'ai lu que le mode autonome n'est pas recommandé pour la production, bien qu'il semble que ce soit la configuration la plus basique. Je comprends que cette configuration n'est pas utilisée dans la plupart des scénarios, mais parfois vous souhaiterez peut-être l'utiliser comme base de données standard sur une machine locale. Alors pourquoi le mode autonome n'est-il pas recommandé? N'est-ce pas assez stable, ou pour d'autres raisons?
Existe-t-il un problème/un inconvénient à exécuter Mongo en tant que jeu de réplicas à 1 nœud, en supposant que je n'ai pas vraiment besoin de la réplication, de l'équilibrage de charge ou de toute autre fonctionnalité évolutive?
Vous n'avez pas une haute disponibilité offerte par un jeu de répliques approprié. Il n'est donc pas recommandé pour un déploiement en production. C'est bien pour le développement.
Notez que la fonction d'un jeu de réplicas concerne principalement la haute disponibilité au lieu de la mise à l'échelle.
Quelles sont les différences de fonctionnalités et de performances, le cas échéant, entre l'exécution en tant qu'exécution autonome et l'exécution en tant que jeu de réplicas à 1 nœud?
Un jeu de réplicas à nœud unique aurait l'oplog. Cela signifie que vous utiliserez plus d'espace disque pour stocker l'oplog, et que toute opération d'insertion/mise à jour serait également écrite dans l'oplog (amplification d'écriture).
Alors pourquoi le mode autonome n'est-il pas recommandé? N'est-ce pas assez stable, ou pour d'autres raisons?
MongoDB en production a été conçu avec un déploiement de jeu de répliques à l'esprit, pour:
- Haute disponibilité face aux pannes de nœuds
- Maintenance/mises à niveau continues sans interruption
- Possibilité de mettre à l'échelle les lectures
- Possibilité d'avoir une réplique de données dans un nœud spécial qui ne fait pas partie des nœuds haute disponibilité
En bref, MongoDB a été conçu pour être une base de données distribuée tolérante aux pannes (évolue horizontalement) au lieu de la base de données monolithique SQL typique (évolue verticalement). L'idée est que si vous perdez un nœud de votre jeu de répliques, les autres prendront immédiatement le relais. La plupart du temps, votre application ne sait même pas qu'il y a une défaillance côté base de données. En revanche, une défaillance d'un serveur de base de données monolithique perturberait immédiatement votre application.
Je pense que kevinadi a bien répondu, mais je veux quand même l'ajouter.
Un autonome est une instance de mongod qui s'exécute sur un seul serveur mais ne fait pas partie d'un jeu de réplicas. Instances autonomes utilisées pour les tests et le développement, mais toujours recommandées pour utiliser des jeux de réplicas en production.
Un jeu de réplicas à nœud unique aurait l'oplog qui enregistre toutes les modifications apportées à ses jeux de données. Cela signifie que vous utiliserez plus d'espace disque pour stocker l'oplog, et que toute opération d'insertion/mise à jour serait également écrite dans l'oplog (amplification d'écriture). Il prend également en charge la récupération ponctuelle.
Veuillez suivre Convertir un autonome en jeu de répliques si vous souhaitez convertir la base de données autonome en jeu de réplicas.
Les transactions ont été introduites dans MongoDB version 4.0. À partir de la version 4.0, pour les situations qui nécessitent une atomicité pour les mises à jour de plusieurs documents ou une cohérence entre les lectures de plusieurs documents, MongoDB fournit des transactions multi-documents pour les jeux de réplicas. La transaction n'est pas disponible en mode autonome car elle nécessite oplog pour maintenir une forte cohérence au sein d'un cluster.