Qu'est-ce que la réplication en chaîne ?
Lorsque nous parlons de réplication, nous faisons référence au processus de création de copies redondantes de données afin de répondre aux critères de conception sur la disponibilité des données. La réplication en chaîne fait donc référence à l'ordre linéaire des serveurs MongoDB pour former une chaîne synchronisée. La chaîne contient un nœud principal, suivi de serveurs secondaires disposés linéairement. Comme le suggère la chaîne de mots, le serveur le plus proche du serveur principal se réplique à partir de celui-ci tandis que tous les autres serveurs secondaires suivants se répliquent à partir du serveur MongoDB secondaire précédent. C'est la principale différence entre la réplication en chaîne et la réplication normale. La réplication en chaîne se produit lorsqu'un nœud secondaire sélectionne sa cible à l'aide du temps de ping ou lorsque le nœud le plus proche est un nœud secondaire. Bien que la réplication en chaîne telle qu'elle apparaît réduise la charge sur le nœud principal, elle peut entraîner un retard de réplication.
Pourquoi utiliser la réplication en chaîne ?
Les infrastructures système subissent parfois des pannes imprévisibles entraînant la perte d'un serveur et donc affectant la disponibilité. La réplication garantit que les pannes imprévisibles n'affectent pas la disponibilité. La réplication permet en outre la récupération après une panne matérielle et une interruption de service. La réplication chaînée et non chaînée sert à assurer la disponibilité malgré les défaillances du système. Après avoir établi que la réplication est importante, vous pouvez vous demander pourquoi utiliser la réplication en chaîne en particulier. Il n'y a pas de différence de performances entre la réplication chaînée et non chaînée dans MongoDb. Dans les deux cas, lorsque le nœud principal tombe en panne, les serveurs secondaires votent pour un nouveau nœud principal actif et, par conséquent, l'écriture et la lecture des données ne sont pas affectées dans les deux cas. La réplication chaînée est cependant le type de réplication par défaut dans MongoDb.
Comment configurer une réplique en chaîne
Par défaut, la réplication chaînée est activée dans MongoDB. Nous allons donc détailler le processus de désactivation de la réplication en chaîne. La principale raison pour laquelle la réplication en chaîne peut être désactivée est si elle provoque un décalage. Le mérite de la réplication en chaîne est cependant supérieur au démérite du décalage et donc dans la plupart des cas, la désactiver n'est pas nécessaire. Juste au cas où la réplication en chaîne ne serait pas active par défaut, les commandes suivantes vous aideront à l'activer.
cfg = rs.config()
cfg.settings.chainingAllowed = true
rs.reconfig(cfg)Ce processus est réversible. Lorsqu'il est forcé de désactiver la réplication en chaîne, le processus suivant est suivi religieusement.
cfg = rs.config()
cfg.settings.chainingAllowed = false
rs.reconfig(cfg)Conseils et astuces pour la réplication en chaîne
Les limites les plus redoutables de la réplication en chaîne sont le décalage de réplication. Le décalage de réplication fait référence au délai qui se produit entre le moment où une opération est effectuée sur le primaire et le moment où la même opération est répliquée sur le secondaire. Bien que cela soit naturellement impossible, on souhaite toujours que la vitesse de réplication soit très élevée dans ce délai de réplication égal à zéro. Pour éviter ou minimiser le retard de réplication pour qu'il soit proche de zéro, il est prudent d'utiliser des hôtes principaux et secondaires ayant les mêmes spécifications en termes de CPU, de RAM, d'E/S et de spécifications liées au réseau.
Bien que la réplication en chaîne assure la disponibilité des données, la réplication en chaîne peut être utilisée avec la journalisation. La journalisation assure la sécurité des données en écrivant dans un journal qui est régulièrement vidé sur le disque. Lorsque les deux sont combinés, trois serveurs sont écrits par demande d'écriture, contrairement à la réplication en chaîne seule où seuls deux serveurs sont écrits par demande d'écriture.
Une autre astuce importante consiste à utiliser w avec la réplication. Le paramètre w contrôle le nombre de serveurs sur lesquels une réponse doit être écrite avant de renvoyer un succès. Lorsque le paramètre w est défini, getlasterror vérifie l'oplog des serveurs et attend que l'opération soit appliquée au nombre donné de serveurs "w".
L'utilisation d'un outil de surveillance comme MongoDB Monitoring Service (MMS) ou ClusterControl vous permet d'obtenir l'état de vos nœuds répliqués et de visualiser les changements au fil du temps. Par exemple, dans MMS, vous pouvez trouver des graphiques de décalage de réplique des nœuds secondaires montrant la variation du temps de latence de réplication.
Mesurer les performances de réplication de la chaîne
Vous savez maintenant que le paramètre de performance le plus important de la réplication en chaîne est le délai de réplication. Nous verrons donc comment tester la période de latence de réplication. Ce test peut être effectué via le script shell MongoDb. Pour effectuer un test de décalage de réplication, nous comparons l'oplog du dernier événement sur le nœud principal et l'oplog du dernier événement sur le nœud secondaire.
Pour vérifier les informations du nœud principal, nous exécutons le code suivant.
db.printSlaveReplicationInfo()La commande ci-dessus fournira des informations sur toutes les opérations récentes sur le nœud principal. Les résultats devraient apparaître comme ci-dessous.
rs-ds046297:PRIMARY db.printSlaveReplicationInfo()
source: ds046297-a1.mongolab.com:46297
synced To: Tue Mar 05 2013 07:48:19 GMT-0800 (PST)
= 7475 secs ago (2.08hrs)
source: ds046297-a2.mongolab.com:46297
synced To: Tue Mar 05 2013 07:48:19 GMT-0800 (PST)
= 7475 secs ago (2.08hrs)Après avoir obtenu l'oplog du nœud primaire, nous nous intéressons maintenant à l'oplog du nœud secondaire. La commande suivante nous aidera à obtenir l'oplog.
db.printReplicationInfo()Cette commande fournira une sortie avec des détails sur la taille de l'oplog, la longueur du journal, l'heure du premier événement de l'oplog, l'heure du dernier événement de l'oplog et l'heure actuelle. Les résultats apparaissent comme ci-dessous.
rs-ds046297:PRIMARY db.printReplicationInfo()
configured oplog size: 1024MB
log length start to end: 5589 secs (1.55hrs)
oplog first event time: Tue Mar 05 2013 06:15:19 GMT-0800 (PST)
oplog last event time: Tue Mar 05 2013 07:48:19 GMT-0800 (PST)
now: Tue Mar 05 2013 09:53:07 GMT-0800 (PST)À partir de l'oplog du serveur principal, la dernière synchronisation s'est produite le Tue Mar 05 2013 07:48:19 GMT-0800 (PST). À partir de l'oplog du serveur secondaire, la dernière opération s'est produite le Tue Mar 05 2013 07:48:19 GMT-0800 (PST). Le décalage de réplication était nul et donc notre système répliqué en chaîne fonctionne correctement. Le délai de réplication peut cependant varier en fonction de la quantité de modifications à répliquer.
