MongoDB
 sql >> Base de données >  >> NoSQL >> MongoDB

Guide du développeur pour les ensembles de répliques MongoDB

MongoDB implique souvent de travailler avec un grand ensemble de données, y compris des tableaux intégrés et des objets de tableau. Par conséquent, il est toujours important de s'assurer que le taux de traitement de votre base de données est aussi rapide que possible pour améliorer les opérations de lecture et d'écriture. En outre, pour éviter les anomalies de données pouvant survenir en raison d'une incohérence des données, vous devez vous assurer que vos données sont en disponibilité accrue au cas où vous souhaiteriez une récupération après une défaillance matérielle ou des interruptions de service. MongoDB fournit 2 concepts à cet effet - ReplicaSets et Sharding.

Réplication dans MongoDB

Réplication maître-esclave

Il s'agit de l'une des techniques les plus anciennes utilisées pour garantir que les données sont toujours disponibles pour les utilisateurs, même en cas de défaillance d'un système. Cependant, la réplication Maître-Esclave est obsolète dans les dernières versions de MongoDB à partir de la 3.2 et a donc été remplacée par des ensembles de répliques.

Pour faire cette configuration, on démarre 2 instances mongod en considérant que l'une est en mode maître et l'autre en mode esclave.

Pour démarrer une instance en mode maître, exécutez :

mongod --master --port portNumber

Les options --master demandent à mongod de créer une collection local.oplog.$main avec laquelle une liste d'opérations est mise en file d'attente pour que les esclaves s'appliquent à répliquer les données.

Pour démarrer une instance mongod en mode esclave, exécutez simplement :

mongod --slave --source <masterhostname><:<port>>

Ici, vous devez spécifier le nom d'hôte et le port de l'instance maître à l'argument --source. Il s'agit d'un aperçu résumé de l'utilisation de la réplication maître-esclave et puisqu'elle est obsolète, notre intérêt portera sur les ensembles de répliques.

Ensembles de répliques

Il s'agit d'un groupe de processus MongoDB appelés instances mongod qui hébergent essentiellement le même ensemble de données. Il est caractérisé par un nœud principal et plusieurs nœuds secondaires pour les données de support. Le nœud principal reçoit toutes les opérations d'écriture et enregistre toutes les autres modifications apportées à son ensemble de données dans son journal des opérations. Les nœuds secondaires, à l'autre extrémité, répliquent le journal des opérations du primaire et appliquent les opérations à leur ensemble de données de sorte que leurs ensembles de données reflètent l'ensemble de données du primaire. En termes simples, nous pouvons dire que nous avons la machine A comme nœud principal et les machines B et C comme nœuds secondaires. La machine A reçoit une opération d'écriture et apporte des modifications à ses données, puis établit une liste des modifications qui ont été apportées. Les machines B et C copieront alors les opérations de la liste fournie, dans ce cas l'oplog, et les exécuteront de sorte que les données résultantes soient les mêmes que sur la machine A.

Comme mentionné précédemment, il est toujours important d'assurer une haute disponibilité des données, en particulier dans le cadre de la production. La réplication vient en aide en fournissant une redondance des données dans différentes instances de Mongod. En cas de perte de données, étant donné que des copies des mêmes données sont stockées dans différentes bases de données à plusieurs endroits, il est facile de les récupérer dans la base existante.

Avec de nombreuses instances en cours d'exécution, les opérations de lecture et d'écriture des clients sont envoyées à différents serveurs et, par conséquent, le taux de traitement augmente. La structure de base du processus de réplication est illustrée ci-dessous.

Parfois, le principal peut ne pas être disponible, par exemple en raison d'une déconnexion Internet ou d'une interruption de service. Dans ce cas, le jeu de réplicas désignera un nœud secondaire comme nœud principal. Autant que les demandes de lecture sont essentiellement adressées au primaire, certaines occasions, les demandes de lecture peuvent être envoyées aux secondaires, mais soyez prudent car les données renvoyées peuvent ne pas refléter ce qui se trouve dans le primaire ou plutôt les données peuvent ne pas être à jour.

Arbitres

Dans le cas de l'élection d'une primaire, vous aurez besoin d'une instance mongod supplémentaire au jeu de répliques pour ajouter un vote dans le processus d'élection. Cette instance est appelée arbitre et ses principales caractéristiques sont :

  1. Il n'a pas de copie de l'ensemble de données et ne nécessite donc pas de matériel aussi puissant que les nœuds porteurs de données.
  2. Ne peut pas être promu pour devenir le principal.
  3. Ils ont toujours 1 vote électoral afin de permettre à l'ensemble de répliques d'avoir un nombre impair de membres votants sans la surcharge d'un membre supplémentaire qui réplique les données. Son rôle crucial est donc de sélectionner un nœud principal lorsqu'il n'est pas disponible.
  4. Il reste inchangé.

Contrairement à l'arbitre, d'autres jeux de réplicas peuvent être convertis en primaires à partir de secondaires et vice-versa.

Réplication asynchrone

Le processus de réplication se déroule sous deux formes de synchronisation des données. Tout d'abord, les membres de l'ensemble sont renseignés avec des données complètes lors de la synchronisation initiale. La réplication ultérieure a lieu pour appliquer les modifications avancées à l'ensemble de données complet.

Lors de la synchronisation initiale, les données sont copiées d'un membre du jeu de réplicas vers un autre. Lorsque le processus est terminé, le membre passe au nœud secondaire.

Basculement automatique MongoDB

Il peut y avoir une interruption de service comme une déconnexion du réseau qui a pour conséquence de mettre fin à la communication entre le primaire et les secondaires. Si la déconnexion dure plus de 10 secondes ou échoue complètement, le jeu de réplicas restant votera pour qu'un membre devienne le nouveau principal. Le nœud secondaire qui obtient la majorité des votes devient le nouveau nœud principal.

Dans la version 3.0 de MongoDB, un jeu de réplicas peut avoir jusqu'à 50 membres avec 7 membres votants.

Membres de l'ensemble de réplicas de priorité zéro

Ce sont des membres secondaires qui ne peuvent ni transiter pour devenir des nœuds primaires ni déclencher une élection. Leurs rôles cruciaux dans l'ensemble de données sont les suivants :conserver les copies de l'ensemble de données, élire un nœud principal et effectuer des opérations de lecture. Ils agissent comme une sauvegarde où un nouveau membre peut ne pas s'ajouter immédiatement. Il stockera ainsi les données mises à jour et pourra immédiatement remplacer un membre indisponible.

Membres de l'ensemble de répliques masquées MongoDB

Il s'agit de membres sans connexion aux applications clientes. Ils sont utilisés pour les charges de travail avec des exigences d'utilisation différentes de celles des autres membres secondaires. Ils ne reçoivent que le trafic de réplication de base lors de la synchronisation initiale.

Membres de l'ensemble de répliques retardées MongoDB

Ceux-ci copient les données du fichier oplog du nœud principal dans un délai spécifié. Ils reflètent toujours l'état retardé ou une forme antérieure de l'ensemble. Ils sont donc importants pour détecter les erreurs et donnent une indication sur la façon dont on peut récupérer de ces erreurs, par exemple s'il y a une base de données qui a été abandonnée. Lors du choix du délai, cela doit être pris en compte :

  1. La durée doit être inférieure à la capacité du journal des opérations, qui pour les moteurs de stockage WiredTiger, MMAPv1 et In-Memory est de 50 Go. Sinon, le membre retardé ne peut pas répliquer avec succès les opérations.
  2. La durée du retard doit être égale ou légèrement supérieure à la durée prévue de votre fenêtre de maintenance.

Configuration

Il s'agit d'un membre prioritaire zéro, il est masqué donc non visible pour les candidatures et peut enfin participer au processus d'élection. Par conséquent, pour configurer une priorité, disons que vous avez 10 membres dans votre jeu de répliques, vous pouvez sélectionner un membre à la position n en tant que membre[n] et définir ses propriétés comme :

{
    “_id”: <num>, 
    “Host”: <hostname: port>,
    “Priority”: 0,
    “slaveDelay”: <seconds>,
    “Hidden”: true
}

Ou en utilisant le shell mongo connecté au primaire, vous pouvez exécuter ces commandes pour définir le premier membre du jeu de réplicas comme retardé :

cfg = rs.conf()
cfg.members[0].priority = 0
cfg.members[0].hidden = true
cfg.members[0].slaveDelay = 3600
rs.reconfig(cfg)

Après avoir défini ces configurations, le secondaire retardé ne peut pas devenir un primaire et donc caché des applications. Le Membre sera retardé de 1 heure (3600 secondes) à partir des opérations oplog.

Plusieursnines Devenez un administrateur de base de données MongoDB – Amener MongoDB en productionDécouvrez ce que vous devez savoir pour déployer, surveiller, gérer et faire évoluer MongoDBDélécharger gratuitement

Comment démarrer un jeu de répliques

Dans ce guide, nous verrons étape par étape comment configurer un jeu de répliques dans MongoDB.

  1. Supposons que vous vouliez répliquer 3 mongodb et qu'ils soient configurés comme suit :
    1. Mongod1.conf exécuté sur le port 27017
    2. Mongod2.conf exécuté sur le port 27018
    3. Mongod3.conf exécuté sur le port 27019

    Assurez-vous d'ajouter le nom du jeu de répliques qui ne changera pas dans chaque fichier. Vous pouvez le faire en ajoutant ou en modifiant la valeur de l'option replSet par un nom de votre choix.

  2. Nous pouvons démarrer la première instance en exécutant

    sudo mongod --config /etc/mongo/mongod1.conf

    C'est si vous n'avez pas d'instance en cours d'exécution mongod. Faites ensuite de même pour les autres instances. Pour vérifier les instances en cours d'exécution sur votre ordinateur, exécutez

    ps -ax | grep mongo

    Vous obtiendrez une liste comme celle-ci :

    4328 ttys000    0:06.15 mongod
4950 ttys001    0:00.00 grep mongo
    Cela signifie que la première instance de MongoDB s'exécute par défaut sur le port 27017, nous l'avons donc comme la première de la liste. Si vous avez démarré les autres, ils seront également indiqués dans la liste avec leurs URL de chemin correspondantes. Pour vous connecter à une instance dans le shell mongo, exécutez cette commande :
    mongo  --port port_number i.e mongo  --port 27017.
    Cependant, dans notre cas, nous devons nous connecter avec un nom de jeu de répliques, nous devons donc ajouter le nom à la commande :
    mongod --replSet replicaSetName --dbpath /usr/local/var/mongo/mongod --port 27017
    Dans ce cas, notre replicaSetName ="testrep"

  3. Vérifions s'il existe un jeu de réplicas activé en exécutant rs.status()

    Si vous obtenez un résultat comme :

    {
    "ok" : 0,
    "errmsg" : "not running with --replSet",
    "code" : 76,
    "codeName" : "NoReplicationEnabled"
}

    Ensuite, cela signifie qu'aucun jeu de répliques n'est activé. Sinon, si vous obtenez le résultat comme

    {
    "operationTime" : Timestamp(0, 0),
    "ok" : 0,
    "errmsg" : "no replset config has been received",
    "code" : 94,
    "codeName" : "NotYetInitialized",
    "$clusterTime" : {
        "clusterTime" : Timestamp(0, 0),
        "signature" : {
            "hash" : BinData(0,"AAAAAAAAAAAAAAAAAAAAAAAAAAA="),
            "keyId" : NumberLong(0)
        }
    }
}

    cela signifie que la réplique n'est pas encore lancée.

  4. La méthode rs.initiate() nous aidera à démarrer un nouvel ensemble de réplicas et l'instance dans laquelle il est initié devient notre nœud principal. Nous pouvons donc en lancer un dans notre instance en exécutant la méthode initiate. rs.initiate().

  5. Vérifiez à nouveau l'état du jeu de répliques en exécutant rs.status().members. Vous devriez maintenant voir quelque chose comme

    "members" : [
        {
            "_id" : 0,
            "name" : "localhost:27018",
            "health" : 1,
            "state" : 1,
            "stateStr" : "PRIMARY",
            "uptime" : 577,
            "optime" : {
                "ts" : Timestamp(1535301271, 1),
                "t" : NumberLong(1)
            },
            "optimeDate" : ISODate("2018-08-26T16:34:31Z"),
            "syncingTo" : "",
            "syncSourceHost" : "",
            "syncSourceId" : -1,
            "infoMessage" : "could not find member to sync from",
            "electionTime" : Timestamp(1535301265, 1),
            "electionDate" : ISODate("2018-08-26T16:34:25Z"),
            "configVersion" : 1,
            "self" : true,
            "lastHeartbeatMessage" : ""
        }
    ]

    Eh bien, c'est bon d'y aller. Notre intérêt sera l'option des membres, car nous pouvons voir qu'il s'agit d'un tableau n avec 1 membre. En vérifiant l'option stateStr du premier membre, dans ce cas, il est défini sur Primary, ce qui signifie qu'il agira comme notre nœud principal.

  6. Ajoutez un nouveau membre au jeu de répliques à l'aide de son nom d'hôte. Pour vérifier le nom d'hôte de l'instance connectée que vous souhaitez ajouter, exécutez

    db.serverStatus().host

    Vous obtiendrez quelque chose comme

    ervername.local:27019

    Ainsi, à partir du PRIMARY, vous pouvez ajouter un autre membre en exécutant cette commande dans le shell mongo :

    rs.add("servername.local:27019");

  7. Exécutez la commande d'état

    rs.status().members

    Pour vérifier si les modifications ont été apportées.

    Vous devriez maintenant avoir quelque chose qui ressemble à ceci :

    [
    {
        "_id" : 0,
        "name" : "localhost:27018",
        "health" : 1,
        "state" : 1,
        "stateStr" : "PRIMARY",
        "uptime" : 11479,
        "optime" : {
            "ts" : Timestamp(1535312183, 1),
            "t" : NumberLong(1)
        },
        "optimeDate" : ISODate("2018-08-26T19:36:23Z"),
        "syncingTo" : "",
        "syncSourceHost" : "",
        "syncSourceId" : -1,
        "infoMessage" : "",
        "electionTime" : Timestamp(1535301265, 1),
        "electionDate" : ISODate("2018-08-26T16:34:25Z"),
        "configVersion" : 2,
        "self" : true,
        "lastHeartbeatMessage" : ""
    },
    {
        "_id" : 1,
        "name" : "127.0.0.1:27019",
        "health" : 1,
        "state" : 2,
        "stateStr" : "SECONDARY",
        "uptime" : 15,
        "optime" : {
            "ts" : Timestamp(1535312183, 1),
            "t" : NumberLong(1)
        },
        "optimeDurable" : {
            "ts" : Timestamp(1535312183, 1),
            "t" : NumberLong(1)
        },
        "optimeDate" : ISODate("2018-08-26T19:36:23Z"),
        "optimeDurableDate" : ISODate("2018-08-26T19:36:23Z"),
        "lastHeartbeat" : ISODate("2018-08-26T19:36:26.302Z"),
        "lastHeartbeatRecv" : ISODate("2018-08-26T19:36:27.936Z"),
        "pingMs" : NumberLong(0),
        "lastHeartbeatMessage" : "",
        "syncingTo" : "localhost:27018",
        "syncSourceHost" : "localhost:27018",
        "syncSourceId" : 0,
        "infoMessage" : "",
        "configVersion" : 2
    }
]

    Nous avons maintenant 2 membres, l'un est un nœud PRIMAIRE et l'autre est un nœud SECONDAIRE. Vous pouvez ajouter plus de membres mais pas plus de 50. Maintenant, créons une base de données dans l'instance au port 27018 comme primaire.

    Si nous déconnectons le primaire, un basculement se produira et puisque nous n'avons qu'un seul primaire, il passera automatiquement en secondaire. Maintenant, si nous nous connectons à celui sur le port 27019, vous devriez obtenir les mêmes bases de données et collections avec leurs documents.

    Désormais, si le nœud principal déconnecté est reconnecté, il sera ajouté en tant que nœud secondaire car il copie les opérations de l'oplog du nœud principal existant.

Problème d'écriture de l'ensemble de répliques MongoDB

Si MongoDB renvoie une préoccupation d'écriture journalisée réussie, les données seront stockées sur le disque et deviendront donc disponibles après le redémarrage de mongod. Cependant, pour les opérations d'écriture, les données ne sont durables qu'après avoir été répliquées et validées dans le journal en faveur de la majorité des membres votants du jeu de répliques.

Certaines données peuvent être trop volumineuses pour être mises à jour ou insérées, ce qui peut prendre plus de temps que prévu pour que les données soient répliquées dans d'autres membres. Pour cette raison, il est conseillé de modifier les configurations de writeConcern pour tenir compte de la durée pendant laquelle une opération doit être exécutée. Les configurations par défaut de writeConcern stipulent que le jeu de réplicas nécessite un accusé de réception uniquement de la part du membre principal. Une préoccupation d'écriture par défaut confirme les opérations d'écriture pour le primaire uniquement, mais peut être remplacée pour vérifier les opérations d'écriture sur certains membres du jeu de répliques en spécifiant la préoccupation d'écriture pour une opération d'écriture spécifique. Par exemple :

db.books.insert({name: “James”,place: “Beijing”},{writeConcern: {w: 3, wtimeout: 3600}})

L'option d'écriture dans ce cas indique que l'opération doit renvoyer une réponse uniquement après qu'elle a été propagée au primaire et au moins 2 secondaires ou si elle expire après 3,6 secondes.

Configuration du problème d'écriture pour MongoDB

L'option MongoDB getLastErrorDefaults nous donne les paramètres pour modifier les paramètres par défaut de préoccupation d'écriture dans la configuration du jeu de répliques. Cela implique que l'opération doit être terminée dans la plupart des membres votants avant de renvoyer le résultat.

cfg = rs.conf()
cfg.settings = {},
cfg.settings.getLastErrorDefaults = {w: “majority”, wtimeout: 3600}
rs.reconfig(cfg)

La valeur du délai d'attente empêchera le blocage des opérations d'écriture, c'est-à-dire que s'il y a 5 membres censés accuser réception du problème d'écriture mais qu'il y a malheureusement 4 membres ou moins dans le jeu de répliques, l'opération se bloquera jusqu'à ce que tous les membres soient disponibles. En ajoutant le seuil de temporisation, le blocage de l'opération sera annulé après cette durée.

Blocage de la réplication

Le blocage d'une opération, en particulier lorsque tous les membres ont été répliqués, garantit qu'il n'y aura plus de temps perdu à attendre qu'un autre membre du jeu de répliques soit disponible pour renvoyer une réponse. L'option de commande MongoDB getLastError dicte comment la mise à jour de la réplication est effectuée à l'aide de l'attribut facultatif "w".

Par exemple, cette requête

db.runCommand({getLastError: 1, w: N, “wtimeout”: 5000});

exige que le blocage se produise jusqu'à ce qu'un nombre N de membres aient répliqué la dernière opération d'écriture. Si N est disponible ou est inférieur à 2, la requête sera renvoyée. Sinon, si la valeur de N est égale à 2, le maître équivalent au primaire ne répondra qu'après la réplication de 1 de ses esclaves à la dernière opération.

Le wtimeout Le paramètre consiste essentiellement à définir le temps en millisecondes après lequel la commande getLastError expirera et renverra une erreur avant que la dernière option n'ait été répliquée.

Même si le blocage est en quelque sorte avantageux, il a parfois une limitation. Cela ralentit considérablement les opérations de lecture, surtout si vous définissez la valeur « w » sur une valeur trop élevée. Je vous recommande de définir la valeur « w » sur 2 ou 3 pour améliorer la sécurité et l'efficacité.

Lire la préférence dans MongoDB

Il s'agit essentiellement de la route adjacente avec laquelle les opérations de lecture du client sont effectuées sur le jeu de réplicas. La configuration par défaut de MongoDB configure les opérations de lecture sur le primaire car c'est celui avec la dernière version du document que vous récupérez. Comme mentionné précédemment, l'avantage suprême de l'exploitation du jeu de répliques est d'améliorer les performances de notre système de base de données. Ainsi, il convient de répartir les opérations de lecture sur de nombreux membres secondaires afin de réduire la latence pour les applications qui ne nécessitent pas forcément des données à jour. Cependant, il existe des raisons plus cruciales pour lesquelles vous devriez également utiliser le primaire comme préférence de base :

  1. Maintenir la disponibilité des données pendant le basculement.
  2. Pour les applications réparties géographiquement, le principal fournira des lectures locales pour les clients du même centre de données.
  3. Ne pas affecter les applications frontales, en particulier celles qui exécutent les opérations système.

Mongo.setReadPref() Méthode

Cette méthode consiste essentiellement à définir comment le client acheminera toutes les requêtes vers les membres du jeu de répliques. Il prend 2 arguments, mode et tagSet.

L'argument mode spécifie la préférence de lecture qui peut être primaire, primairePréférée, secondaire, secondairePréférée ou la plus proche.

Le mode tagSet spécifie la préférence de lecture personnalisée. Vous pouvez également les spécifier sous forme de tableau d'objets. Un exemple de configuration sera :

db.getMongo().setReadPref('primaryPreferred',
                          [ { "dc": "east", "use": "production" },
                            { "dc": "east", "use": "reporting" },
                            { "dc": "east" },
                            {}
                          ] )

Ce qui se passe ici, c'est que si le client essaie d'accéder à la première balise et que la demande échoue, il sera opté pour la deuxième préférence de lecture.

Lire les modes de préférence

  • Principal :cela définit que toutes les opérations de lecture lues à partir d'un jeu de réplicas donné sont primaires et est le mode de lecture de préférence par défaut.
  • PrimaryPreferred :si seul le primaire n'est pas disponible, alors les opérations de lecture peuvent être effectuées à partir des secondaires.
  • Secondaire :toutes les opérations de lecture sont effectuées à partir des membres secondaires du jeu de répliques.
  • SecondaryPreferred :si seulement il n'y a pas de secondaire disponible, les opérations de lecture peuvent être effectuées à partir du primaire.
  • Le plus proche :le membre avec la plus faible latence réseau est sélectionné pour l'opération de lecture, quel que soit son type.

Ensembles de balises et leur configuration

Ce sont des options qui vous permettent de modéliser la façon dont vous voulez que votre préoccupation d'écriture et vos préférences de lecture ressemblent. Ils sont stockés dans l'objet de configuration du jeu de répliques. Si vous exécutez rs.conf().members, vous obtiendrez cet objet renvoyé :

[
    {
        "_id" : 0,
        "host" : "localhost:27018",
        "arbiterOnly" : false,
        "buildIndexes" : true,
        "hidden" : false,
        "priority" : 1,
        "tags" : {
            
        },
        "slaveDelay" : NumberLong(0),
        "votes" : 1
    },
    {
        "_id" : 1,
        "host" : "127.0.0.1:27019",
        "arbiterOnly" : false,
        "buildIndexes" : true,
        "hidden" : false,
        "priority" : 1,
        "tags" : {
            
        },
        "slaveDelay" : NumberLong(0),
        "votes" : 1
    }
]

Comme vous pouvez le voir, chaque membre a un attribut tags.

La principale différence entre les préférences de lecture et la préoccupation d'écriture est que la première considère la valeur d'une balise lors de la sélection d'un membre à lire, tandis que la seconde ne le fait pas.

Supposons qu'un ensemble de balises pour une opération de lecture est défini sur :

{ "disk": "ssd", "use": "reporting" }

Un membre du jeu de répliques doit remplir ces balises pour que l'opération de lecture soit effectuée. Donc dire, une configuration comme celle-ci

{ "disk": "ssd", "use": "reporting", "rack": "a" }

satisfera la requête alors que celle-ci

{ "disk": "ssd", "use": "production", "rack": "k" }

ne satisfera pas la requête.

Ajout de balises à une réplique d'ensemble

Pour votre membre sélectionné dans un jeu de répliques, vous pouvez ajouter des jeux de balises à l'aide de la méthode rs.conf() dans MongoDB.

Supposons que vous ayez sélectionné un membre en position 1 de votre tableau de jeux de répliques, vous pouvez ajouter des jeux de balises comme suit.

conf = rs.conf()
conf.members[0].tags = { "dc": "NYK", "use": "production"  }
conf.members[1].tags = { "dc": "LON", "use": "reporting"  }
conf.members[2].tags = { "use": "production"  }
rs.reconfig(conf)

Modèles de déploiement pour l'ensemble de répliques MongoDB

  1. Ensemble d'instances dupliquées distribuées géographiquement :améliore la redondance des données en plus de protéger les données contre les pannes telles que les coupures de courant. Les instances en cours d'exécution sont situées à plusieurs endroits.
  2. Ensemble de réplicas à trois membres :architecture standard de base pour un ensemble de réplicas.
  3. Ensemble de répliques à quatre membres ou plus :permet une plus grande redondance des données et prend également en charge une distribution plus large des opérations de lecture dans l'ensemble de répliques.

Techniques de réglage du déploiement de l'ensemble de répliques MongoDB

Un jeu de répliques idéal nécessitera une architecture bien conçue avec au moins 3 membres pour un système de production. Ces stratégies de déploiement vous aideront à activer un excellent jeu de réplicas.

  1. Utilisez des membres différés et masqués pour prendre en charge des fonctions dédiées telles que la création de rapports et la sauvegarde.
  2. Rendez toujours impair le nombre de membres déployés. Comme nous l'avons discuté ci-dessus, un nombre impair de membres sera nécessaire pour élire une primaire. Assurez-vous donc d'avoir un nombre impair et sinon, vous pouvez toujours ajouter un arbitre.
  3. Pour les déploiements gourmands en lecture, vous devrez équilibrer la charge. Il vous sera donc demandé de distribuer les lectures au secondaire afin d'améliorer les performances de lecture. De plus, lorsque les données augmentent avec le temps, vous pouvez ajouter plus de membres et les distribuer, mais gardez à l'esprit que vous devez le configurer de telle sorte que la conception primordiale soit d'élire le principal.
  4. Considérez toujours la tolérance aux pannes. Il s'agit essentiellement de déterminer combien de membres peuvent être indisponibles à un moment donné et combien resteront pour soutenir le processus électoral d'une primaire. Si vous n'avez pas de primaire, le jeu de répliques n'acceptera malheureusement aucune opération d'écriture.
  5. Ajoutez de nouveaux membres à l'ensemble de répliques existant avant que la demande n'apparaisse.
  6. Utilisez des ensembles de balises d'ensemble de répliques pour vous assurer que toutes les opérations sont répliquées dans des centres de données spécifiques. Vous pouvez également utiliser ces balises dans le routage des opérations de lecture pour des machines de déploiement spécifiques.
  7. Déployez la plupart de vos membres au même endroit pour éviter les revers qui résulteront du partitionnement du réseau. Le partitionnement du réseau peut être le résultat d'une communication déconnectée entre les centres de données, ce qui entrave le processus de réplication et le processus d'élection d'un serveur principal.
  8. Pour des raisons de sécurité, répartissez vos membres géographiquement en plus d'en cacher certains. Vous pouvez définir la priorité d'au moins 2 ou 3 membres sur zéro afin d'éviter qu'ils ne deviennent principaux.
  9. Utilisez la journalisation pour protéger les pertes de données pouvant résulter d'une panne de courant, par exemple. Cela garantit que les données sont écrites sur le disque en cas d'arrêt soudain.

Le journal des opérations (Oplog)

L'oplog conserve un enregistrement des opérations du maître qui doivent être appliquées aux esclaves. Il est stocké dans une base de données appelée local dans la collection oplog.$main. Il est créé lorsque vous démarrez un membre du jeu de répliques pour la première fois. Sur la limite supérieure, l'oplog est limité à une taille de 50 Go pour tous les moteurs de stockage. La taille de l'oplog peut être modifiée à partir d'un paramètre par défaut. Si cette taille est atteinte par exemple en 24 heures de fonctionnement, les secondaires ne pourront pas copier confortablement pendant cette durée et risquent de ne plus copier du tout. Vous pouvez modifier la taille de l'oplog en utilisant l'option replSetResizeOplog c'est-à-dire

db.database({replSetResizeOplog:1, size: 16384})

Si vous devez réduire la taille de cet oplog, certaines données seront supprimées. L'impact principal de cela dans le jeu de réplicas est que les membres synchronisés avec ce nœud deviennent obsolètes. Ainsi, vous devrez resynchroniser ces membres.

Modèles de charge de travail qui nécessiteraient une grande taille d'oplog

  1. Mettez à jour plusieurs documents à la fois. Les multiples opérations de mise à jour doivent être traduites en une opération individuelle pour améliorer les résultats sur les nœuds. Cette opération utilisera un vaste espace de l'espace oplog.
  2. Nombre important de mises à jour sur place. Cela se produit généralement lors de la mise à jour des données de documents n'augmentant pas nécessairement la taille de ce document. La base de données enregistrera un grand nombre d'opérations dans l'oplog, augmentant ainsi sa taille.
  3. Les suppressions correspondent à la même quantité de données que les insertions. Cela se produit lorsque vous essayez de supprimer une quantité de données (presque) égale à la quantité de données que vous insérez. Cette opération aura tendance à augmenter la taille de l'oplog.

Conclusion

La réplication est un aspect important des bases de données que les développeurs doivent comprendre. Il assure une disponibilité accrue des données. Votre serveur MongoDB peut tomber en panne, par exemple, en raison d'une panne de courant, mais vous souhaitez toujours que vos clients accèdent à ses données. Si vous avez répliqué des données sur un autre serveur, vos clients pourront continuer à y accéder en cas de défaillance du serveur principal. En outre, l'équilibrage de charge est accru, de sorte qu'au lieu que tous les utilisateurs accèdent à un seul serveur, nous avons constaté les inconvénients de la diffusion du trafic à partir de réplicas secondaires.