Cette semaine, j’ai eu l’occasion de commencer à étudier le fonctionnement de la réplication et du sharding avec MongoDB. Voici diverses informations provenant du guide sur la réplication.

Réplication

La réplication consiste à écrire la donnée sur plusieurs serveurs et répond ainsi au problématique de haute disponibilité et de redondance des données. Elle permet, dans certains cas, d’augmenter les capacités en lecture. Un replica set peut avoir jusqu’à 12 membres dont 7 voteront à la fois. Pour disposer de plus de 12 instances, il est nécessaire de passer à la réplication maître-esclave.

L’architecture standard pour un replica set en production se compose de trois membres. Si l’application se connecte à plusieurs replica set, chacun doit avoir un nom différent. Les membres s’envoient des ping toutes les 2 secondes.

Replica Set: Groupe de mongod disposant des mêmes (~~) données.

Membres

On distingue deux types principaux de mongod dans un replica set: les primaires et les secondaires.

Primaire (Primary)

Il est unique et reçoit toutes les opérations d’écriture. Tous les changements sont conservés dans son oplog. Une élection d’un nouveau mongod primaire à lieux, si l’actuel ne communique avec aucun membre du replica set pendant 10s.

Secondaire (Secondary)

Récupère le oplog et applique les opérations sur son jeu de données. En cas d’indisponibilité du primaire, un mongod secondaire sera élu à sa place.

Membre à priorité 0

Mongod secondaire qui ne peut pas devenir primaire et ne peut déclencher d’élections. Permet de s’assurer que seul les membres qui en ont les capacités deviendront primaire (distribution géographique, hardware). Il est conseillé de s’assurer que le datacenter principal contient les votants et les membres éligibles.

Membre caché

Invisible pour les applications clientes. Sont toujours des membres à priorité 0, ne peuvent devenir primaire mais peuvent voter. En cluster, mongos n’interagit pas avec les membres cachés.

Membre retardé

Reflète un état retardé de l’état du groupe.
Requis:
* Doit être un membre à priorité 0
* Devrait être un membre caché
Le délai doit être plus petit que la capacité de oplog. Cette fonctionnalité est utile pour pouvoir appliquer un rollback (retour en arrière) en cas d’erreur humaine.

Arbitre (Arbiter)

Sa fonction est de voter en cas d’élection d’un mongod primaire et permet d’obtenir une majorité en cas d’un nombre pair de membres.
Important: Ne pas ajouter d’arbitre sur les machines hébergeant déjà un primaire ou un secondaire.

Stratégies

Déployer un nombre impair de membres pour s’assurer qu’un primaire pourra toujours être élu. Ajouter un arbitre si besoin.
Tolérance aux fautes: Correspond au nombre de membres auquel on soustrait la majorité requise pour élire un nouveau mongod primaire.
Au moins un membre à priorité 0 dans un autre datacenter. Garder une majorité de membre au même endroit.

Le sharding est souvent une meilleur stratégie pour augmenter les capacités en lecture et en écriture.

Read Preference Mode

* primary
* primaryPreferred
* secondary
* secondaryPreferred
* nearest
Seul primary permet d’être sûr d’avoir des données totalement à jour.
Utiliser readPref() dans mongo shell pour accéder aux préférences.