web-dev-qa-db-fra.com

Comment puis-je m'assurer de toujours me connecter au nœud principal / secondaire dans un ReplicaSet MongoDB?

J'ai un jeu de répliques à 3 nœuds fonctionnant sur 3 serveurs différents. J'ai fini de le configurer et tout fonctionne très bien. Maintenant, je veux donner à mes utilisateurs deux chaînes de connexion:

  1. Connectez-vous à ce "xyz" pour écrire

  2. Connectez-vous à cet "abc" pour le trafic en lecture seule

J'essaie également de mettre en place un CNAME pour chacune des connexions, afin de pouvoir avoir la flexibilité de changer à l'avenir.

Merci et appréciez votre temps à l'avance.

mongodb
5
Mallik

Réf: https://docs.mongodb.com/manual/reference/connection-string/

Si vous utilisez un jeu de réplicas, vous n'utilisez pas votre nom d'hôte mongod dans votre chaîne de connexion. Utilisez plutôt tous les noms d'hôte mongos et le nom du jeu de réplicas.

Par exemple:

Pour décrire une connexion à un jeu de réplicas nommé test, avec les hôtes mongod suivants:

db1.example.net sur le port 27017 et db2.example.net sur le port 2500. Vous utiliseriez une chaîne de connexion semblable à la suivante:

mongodb: //db1.example.net,db2.example.net: 2500 /? replicaSet = test

Les écritures iront toujours au primaire et vous n'avez rien à faire. Config et mongos communiqueront entre eux et redirigeront vers le primaire.

Vous pouvez configurer Write concern qui décrit le type d'assurance que le mongod et le pilote fournissent à l'application concernant le succès et la durabilité de l'opération d'écriture. Pour une explication complète du problème d'écriture et des opérations d'écriture en général, voir Write Concern .

Lire les options de préférence

Les préférences de lecture décrivent le comportement des opérations de lecture en ce qui concerne les jeux de réplicas. Ces paramètres vous permettent de spécifier les préférences de lecture par connexion dans la chaîne de connexion. La valeur par défaut est primary, qui envoie toutes les opérations de lecture au primaire du jeu de réplicas.

Les valeurs de préférence de lecture sont les suivantes:

  • primaire
  • primaryPreferred
  • secondaire
  • secondairePréféré
  • la plus proche

Pour les descriptions de chaque valeur, voir Lire les modes de préférence .

9
SqlWorldWide

Selon MongoDB BOL Ici Pour vérifier l'état du jeu de réplicas et afficher l'état actuel du jeu de réplicas et l'état actuel de chaque membre, exécutez la méthode rs.status () dans un mongo Shell connecté au jeu de réplicas primaire .

REMARQUE: La méthode rs.status () est un wrapper qui exécute la commande de base de données replSetGetStatus.

Par exemple 

Given a replica set with three members running on three separate hosts:

m1.example.net
m2.example.net
m3.example.net
All three use the default port 27017.

Tester les connexions entre tous les membres 

Test the connection from m1.example.net to the other hosts with the following operation set m1.example.net:

mongo --Host m2.example.net --port 27017

mongo --Host m3.example.net --port 27017
Test the connection from m2.example.net to the other two hosts with the following operation set from m2.example.net, as in:

mongo --Host m1.example.net --port 27017

mongo --Host m3.example.net --port 27017
You have now tested the connection between m2.example.net and m1.example.net in both directions.

Test the connection from m3.example.net to the other two hosts with the following operation set from the m3.example.net Host, as in:

mongo --Host m1.example.net --port 27017

mongo --Host m2.example.net --port 27017
If any connection, in any direction fails, check your networking and firewall configuration and reconfigure your environment to allow these connections.

As MongoDB BOL Here La commande replSetGetStatus renvoie l'état du jeu de répliques du point de vue du serveur qui a traité la commande. replSetGetStatus doit être exécuté contre le administrateur database. La commande a la forme prototype suivante:

{ replSetGetStatus: 1 }

L'exemple suivant exécute la commande replSetGetStatus sur la base de données d'administration du jeu de réplicas primary:

db.adminCommand( { replSetGetStatus : 1 } )

Considérez l'exemple de sortie suivant: 

{
   "set" : "replset",
   "date" : ISODate("2016-11-02T20:02:16.543Z"),
   "myState" : 1,
   "term" : NumberLong(1),
   "heartbeatIntervalMillis" : NumberLong(2000),
   "optimes" : {
         "lastCommittedOpTime" : {
            "ts" : Timestamp(1478116934, 1),
            "t" : NumberLong(1)
         },
         "readConcernMajorityOpTime" : {
            "ts" : Timestamp(1478116934, 1),
            "t" : NumberLong(1)
         },
         "appliedOpTime" : {
            "ts" : Timestamp(1478116934, 1),
            "t" : NumberLong(1)
         },
         "durableOpTime" : {
            "ts" : Timestamp(1478116934, 1),
            "t" : NumberLong(1)
         }
      },

   "members" : [
      {
            "_id" : 0,
            "name" : "m1.example.net:27017",
            "health" : 1,
            "state" : 1,
            "stateStr" : "PRIMARY",
            "uptime" : 269,
            "optime" : {
                        "ts" : Timestamp(1478116934, 1),
                        "t" : NumberLong(1)
            },
            "optimeDate" : ISODate("2016-11-02T20:02:14Z"),
            "infoMessage" : "could not find member to sync from",
            "electionTime" : Timestamp(1478116933, 1),
            "electionDate" : ISODate("2016-11-02T20:02:13Z"),
            "configVersion" : 1,
            "self" : true
      },
      {
            "_id" : 1,
            "name" : "m2.example.net:27017",
            "health" : 1,
            "state" : 2,
            "stateStr" : "SECONDARY",
            "uptime" : 14,
            "optime" : {
               "ts" : Timestamp(1478116934, 1),
               "t" : NumberLong(1)
            },
            "optimeDurable" : {
               "ts" : Timestamp(1478116934, 1),
               "t" : NumberLong(1)
            },
            "optimeDate" : ISODate("2016-11-02T20:02:14Z"),
            "optimeDurableDate" : ISODate("2016-11-02T20:02:14Z"),
            "lastHeartbeat" : ISODate("2016-11-02T20:02:15.618Z"),
            "lastHeartbeatRecv" : ISODate("2016-11-02T20:02:14.866Z"),
            "pingMs" : NumberLong(0),
            "syncingTo" : "m3.example.net:27017",
            "configVersion" : 1
      },
      {
            "_id" : 2,
            "name" : "m3.example.net:27017",
            "health" : 1,
            "state" : 2,
            "stateStr" : "SECONDARY",
            "uptime" : 14,
            "optime" : {
               "ts" : Timestamp(1478116934, 1),
               "t" : NumberLong(1)
            },
            "optimeDurable" : {
               "ts" : Timestamp(1478116934, 1),
               "t" : NumberLong(1)
            },
            "optimeDate" : ISODate("2016-11-02T20:02:14Z"),
            "optimeDurableDate" : ISODate("2016-11-02T20:02:14Z"),
            "lastHeartbeat" : ISODate("2016-11-02T20:02:15.619Z"),
            "lastHeartbeatRecv" : ISODate("2016-11-02T20:02:14.787Z"),
            "pingMs" : NumberLong(0),
            "syncingTo" : "m1.example.net:27018",
            "configVersion" : 1
      }
   ],
   "ok" : 1,
   "$clusterTime" : {
      "clusterTime" : Timestamp(1510716515, 1),
      "signature" : {
         "hash" : BinData(0,"B2ViX7XLzFLS5Fl9XEuFXbwKIM4="),
         "keyId" : NumberLong("6488045157173166092")
      }
   },
   "operationTime" : Timestamp(1510716515, 1)
}
4
Md Haidar Ali Khan