Maison > base de données > MongoDB > Parlons de plusieurs problèmes concernant les jeux de réplicas MongoDB

Parlons de plusieurs problèmes concernant les jeux de réplicas MongoDB

coldplay.xixi
Libérer: 2020-12-21 18:01:13
avant
3467 Les gens l'ont consulté

Tutoriel MongoDBPrésentation des raisons d'utiliser des jeux de réplicas

Parlons de plusieurs problèmes concernant les jeux de réplicas MongoDB

Recommandé (gratuit ): Tutoriel MongoDB

Pourquoi utiliser des jeux de réplicas

1. Sauvegarder les données
via le construit- dans mongo_dump/mongo_restore Les outils peuvent également implémenter la sauvegarde, mais après tout, ils ne sont pas aussi pratiques que la sauvegarde par synchronisation automatique des jeux de réplicas.

2. Basculement automatique
Un jeu de réplicas est déployé Lorsque le nœud maître échoue, le cluster votera automatiquement pour élire un nouveau nœud maître parmi les nœuds pour continuer à fournir des services. Et tout cela se fait automatiquement et de manière transparente pour les opérations et les développeurs. Bien sûr, si une panne se produit, vous devez toujours la gérer manuellement et en temps opportun. Ne comptez pas trop sur le jeu de répliques. En cas de panne, vous n'aurez même pas le temps de respirer.

3. Améliorer les performances de lecture dans certains scénarios spécifiques
Par défaut, la lecture et l'écriture ne peuvent être effectuées que sur le nœud maître.
Voici les cinq options de lecture du jeu de réplication prises en charge par le client MongoDB :

  • primaire : mode par défaut, toutes les opérations de lecture sont effectuées sur le nœud principal du jeu de réplicas.
  • primaryPreferred : Dans la plupart des cas, les opérations de lecture sont effectuées sur le nœud principal, mais si le nœud principal n'est pas disponible, les opérations de lecture seront transférées vers le nœud esclave pour exécution.
  • Secondaire : Toutes les opérations de lecture sont effectuées sur le nœud esclave du jeu de réplicas.
  • secondaryPreferred : Dans la plupart des cas, les opérations de lecture sont effectuées sur le nœud esclave, mais lorsque le nœud esclave est indisponible, l'opération de lecture sera transférée au nœud principal.
  • le plus proche : l'opération de lecture sera effectuée sur le nœud avec le plus petit retard réseau dans le jeu de réplicas, quel que soit le type de nœud.

Source : http://docs.mongoing.com/manual-zh/core/re...

Les opérations de lecture sur les nœuds esclaves ne sont pas recommandées, car les données sur le nœud esclave peuvent ne pas être les dernières données (la raison principale).
Les scénarios pour les opérations de lecture sur les nœuds esclaves sont très limités. Le manuel officiel indique les scénarios applicables et plusieurs raisons pour lesquelles les opérations de lecture sur les nœuds esclaves ne sont pas recommandées : http://docs.mongoing.com/manual-zh/ core. /re...

Laissez-moi parler de ma propre opinion : les jeux de réplicas n'existent pas pour améliorer les performances de lecture. À l'exception de quelques scénarios, il n'est pas recommandé d'effectuer des opérations de lecture sur des nœuds esclaves. Si vous souhaitez améliorer les performances de lecture, utilisez les index et le partitionnement. À propos, si la taille des données n’est pas importante, il n’est pas nécessaire d’utiliser le partitionnement. Il y a près de 200 millions d'enregistrements de collection unique dans notre base de données en ligne, et les performances sont relativement bonnes (bien sûr, la configuration de la machine n'est pas mauvaise, et un seul Redis et un MongoDB fonctionnent dessus).

Comment déployer un jeu de répliques

Veuillez consulter le manuel : http://docs.mongoing.com/manual-zh/tutoria...

Comment utiliser la fonction de basculement automatique du jeu de répliques MongoDB dans un programme

Prenons le pilote PHP mongo comme exemple.

$client = new MongoClient('mongodb://192.168.1.2:27018,192.168.1.3:27019,192.168.1.4:27020', array('replicaSet' => 'rs0'));
Copier après la connexion

Après cette configuration, si un seul des services MongoDB raccroche, les nœuds restants éliront automatiquement un nouveau nœud maître et le programme pourra continuer à fonctionner normalement. Pendant le processus électoral, le programme lancera toujours des exceptions. Bien que le processus électoral soit rapide, la gestion des exceptions doit être prise en compte pour la robustesse du programme. Bien entendu, si un nouveau nœud maître ne peut pas être élu, l'intégralité de MongoDB deviendra indisponible. (D'après ce qui a été dit ci-dessus, si l'option de lecture du jeu de réplicas est configurée primaryPreferred. S'il n'y a pas de nœud maître, mais que le nœud esclave est toujours disponible, alors l'opération de lecture sera transférée au nœud esclave, donc que l'ensemble du jeu de réplicas MongoDB peut toujours fournir un service d'opération de lecture)

En fait, si le nom du jeu de réplicas 'replicaSet' => 'rs0' est spécifié, alors même si toutes les adresses de nœud ne sont pas répertoriées et qu'une seule adresse de nœud valide est écrite , le pilote mongo obtiendra automatiquement tous les nœuds valides, $client->getHosts() Méthode pour afficher les adresses de tous les nœuds valides.

Mais si vous n'écrivez qu'une seule adresse de nœud et que ce nœud est en panne, vous ne pourrez pas vous connecter. Tout ce que je recommande, c'est de configurer une liste complète d'adresses de nœuds .

Quel est le principe de la synchronisation ?

Après avoir ouvert le jeu de répliques, un ensemble appelé local sera généré sous la bibliothèque oplog.rs. ensemble limité. C'est juste que la taille est fixe. Chaque opération d'écriture dans la base de données sera enregistrée dans cette collection. Les nœuds de l'ensemble de réplication réalisent la synchronisation des données en lisant l'oplog sur d'autres nœuds.

举个例子:
用客户端向主节点添加了 100 条记录,那么 oplog 中也会有这 100 条的 insert 记录。从节点通过获取主节点的 oplog,也执行这 100 条 oplog 记录。这样,从节点也就复制了主节点的数据,实现了同步。

需要说明的是:并不是从节点只能获取主节点的 oplog。

为了提高复制的效率,复制集中所有节点之间会互相进行心跳检测(通过ping)。每个节点都可以从任何其他节点上获取oplog。

还有,用一条语句批量删除 50 条记录,并不是在 oplog 中只记录一条数据,而是记录 50 条单条删除的记录。

oplog中的每一条操作,无论是执行一次还是多次执行,对数据集的影响结果是一样的,i.e 每条oplog中的操作都是幂等的。

什么情况下需要重新同步

在上一个问题中得知:oplog 大小是固定的,而且 oplog 里面的记录数不一定和节点中的数据量成正比。那么,新记录肯定会将前面的老记录给覆盖。

如果,有天一个从节点挂了,其他节点还在正常运行,继续有写操作,oplog 继续增长。而这个挂掉的节点一直不能从其他节点那里同步最新的 oplog 记录,当其他节点的 oplog 已经发生的覆盖。即使这个从节点后来恢复了正常,也不会和其他节点保持数据一致了。因为,覆盖的就永远回不来了。

那么,这个时候就得重新同步了。恩,回不去的就永远回不去了,再找个新的重新开始吧。(逃

如何重新同步

参见:复制集成员的重新同步

什么时候应该使用投票节点

当复制集中有偶数个节点时,应该再加一个投票节点,用于打破投票僵局。

比如:我线上共有3台服务器,其中1台是作为 Web 服务器;其余2台作为 DB 服务器,各部署了1个MongoDB节点,构成了2个节点的复制集。这个时候,我并没有多余的机器了。在这个情况下,如果任意一台 DB 服务器上的 MongoDB 挂了,那么另外一台的 MongoDB 必然变为 SECONDARY 节点,那么就意味着 MongoDB 是不可用的了。为了避免这种情况,提高服务的可用性,可以在 Web 服务器上部署一个投票节点。投票节点并不存储数据,因此不能升职为 PRIMARY 节点,它对于硬件资源要求很低,并不会对 Web 服务器上的其他程序产生太大影响。这种情况下,如果任意一台 DB 服务器挂了,另外一台服务器上的 MongoDB 将成为 PRIMARY 节点,此时 MongoDB 还是依旧对外提供服务的。乘此时机,赶紧排查出故障的那台服务器的原因,尽快恢复服务。

为了让投票节点可以占用更少的资源,可以在配置文件中添加以下几个配置项:

journal = false
smallfiles = true
noprealloc = true
Copier après la connexion

主从复制

master-slave 复制架构已经不推荐使用了,建议使用 replica sets 复制集架构。
参见:http://docs.mongoing.com/manual-zh/core/ma...

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!

Étiquettes associées:
source:learnku.com
Déclaration de ce site Web
Le contenu de cet article est volontairement contribué par les internautes et les droits d'auteur appartiennent à l'auteur original. Ce site n'assume aucune responsabilité légale correspondante. Si vous trouvez un contenu suspecté de plagiat ou de contrefaçon, veuillez contacter admin@php.cn
Tutoriels populaires
Plus>
Derniers téléchargements
Plus>
effets Web
Code source du site Web
Matériel du site Web
Modèle frontal