Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Make by tools (01.00.01) - action=clean_macro_parameter
Scroll Ignore
scroll-viewporttrue
scroll-pdftrue
scroll-officetrue
scroll-chmtrue
scroll-htmlfalse
scroll-docbooktrue
scroll-eclipsehelptrue
scroll-epubtrue
scroll-htmlfalse
Panel
titleSommaire

Table of Contents
stylenone

Introduction

La haute disponibilité de la base MongoDB passe par la mise en place d'un cluster de plusieurs instances de mongod ( pour dupliquer les données en plusieurs endroits ).

Un cluster mongo doit forcément être composé d'au moins trois instances ( nœud ) pour fonctionner, principalement pour la notion d'élection ( être capable de choisir le mongo primaire ).

  • Il est cependant possible de n'avoir que 2 nœuds de stockage :

Selon le nombre de fois que sont répliquées les données, l'architecture du cluster sera différente : 

  • Si les données sont répliquées que deux fois,

Comment choisir l'une des

Pourquoi

deux architectures ?

Un cluster mongo doit forcément être composé de trois instances ( nœud ) pour fonctionner. Pour répliquer les données que deux fois, on ajoute un "Arbiter".

C'est une question de sécurité opposée au coût d'avoir plusieurs serveurs de redondance :

  • Plus les données sont répliquées sur chaque élément du cluster, moins vous avez de risque d'être impacté par le crash, incendie,... de plusieurs serveurs à la fois.
  • Mais, comme les quantités de données stockées nécessitent de l'espace disque et de la RAM ( dépendant du volume de donnée et de traitement fait ), mettre plusieurs serveurs peut devenir un problème de coût
Cet Arbiter, ne contient aucune donnée, il permet simplement de voter lorsqu'il y a une élection ( l'élection est le choix d'un nouveau nœud primaire pour prendre le relais du traitement des requêtes )
  • .