serveurs de configuration mongodb non synchronisés

9

J'ai installé avec 2 fragments, avec 2 serveurs de réplique et 3 serveurs de configuration, et 2 mongos. J'ai les problèmes suivants:

1) Les serveurs de configuration Mongo ne sont pas synchronisés:

Aug 14 09:46:48 server mongos.27017[10143]: Sun Aug 11 09:46:48.987 [CheckConfigServers] ERROR: config servers not in sync! config servers mongocfg1.testing.com:27000 and mongocfg3.testing.com:27000 differ#012chunks: "d2c08c5f1ee6048e5f6fab30e37a70f0"#011chunks: "7e643e9402ba90567ddc9388c2abdb8a"#012databases: "6f35ec52b536eee608d5bc706a72ec1e"#011databases: "6f35ec52b536eee608d5bc706a72ec1e"

2) J'utilise ce document pour synchroniser les serveurs: http://docs.mongodb.org/manual/tutorial/replace-config-server/ 3) Après la synchronisation, je redémarre un serveur mongos et je le vois dans les journaux:

Thu Aug 15 09:56:05.376 [mongosMain] MongoS version 2.4.4 starting: pid=1575 port=27111 64-bit host=web-inno.innologica.com (--help for usage)
Thu Aug 15 09:56:05.376 [mongosMain] git version: 4ec1fb96702c9d4c57b1e06dd34eb73a16e407d2
Thu Aug 15 09:56:05.376 [mongosMain] build info: Linux ip-10-2-29-40 2.6.21.7-2.ec2.v1.2.fc8xen #1 SMP Fri Nov 20 17:48:28 EST 2009 x86_64 BOOST_LIB_VERSION=1_49
Thu Aug 15 09:56:05.376 [mongosMain] options: { configdb: "mongocfg1.testing.com:27000,mongocfg2.testing.com:27000,mongocfg3.testing.com:27000", keyFile: "/mongo_database/pass.key", port: 27111 }
Thu Aug 15 09:56:05.582 [mongosMain] SyncClusterConnection connecting to [mongocfg1.testing.com:27000]
Thu Aug 15 09:56:05.583 [mongosMain] SyncClusterConnection connecting to [mongocfg2.testing.com:27000]
Thu Aug 15 09:56:05.583 [mongosMain] SyncClusterConnection connecting to [mongocfg3.testing.com:27000]
Thu Aug 15 09:56:05.585 [mongosMain] SyncClusterConnection connecting to [mongocfg1.testing.com:27000]
Thu Aug 15 09:56:05.586 [mongosMain] SyncClusterConnection connecting to [mongocfg2.testing.com:27000]
Thu Aug 15 09:56:05.586 [mongosMain] SyncClusterConnection connecting to [mongocfg3.testing.com:27000]
Thu Aug 15 09:56:07.213 [Balancer] about to contact config servers and shards
Thu Aug 15 09:56:07.213 [websvr] admin web console waiting for connections on port 28111
Thu Aug 15 09:56:07.213 [Balancer] starting new replica set monitor for replica set replica01 with seed of mongo1.testing.com:27020,mongo2.testing.com:27020,mongo3.testing.com:27017
Thu Aug 15 09:56:07.214 [Balancer] successfully connected to seed mongo1.testing.com:27020 for replica set replica01
Thu Aug 15 09:56:07.214 [Balancer] changing hosts to { 0: "mongo1.testing.com:27020", 1: "mongo2.testing.com:27020" } from replica01/
Thu Aug 15 09:56:07.214 [Balancer] trying to add new host mongo1.testing.com:27020 to replica set replica01
Thu Aug 15 09:56:07.215 [Balancer] successfully connected to new host mongo1.testing.com:27020 in replica set replica01
Thu Aug 15 09:56:07.215 [Balancer] trying to add new host mongo2.testing.com:27020 to replica set replica01
Thu Aug 15 09:56:07.215 [Balancer] successfully connected to new host mongo2.testing.com:27020 in replica set replica01
Thu Aug 15 09:56:07.215 [mongosMain] waiting for connections on port 27111
Thu Aug 15 09:56:07.427 [Balancer] Primary for replica set replica01 changed to mongo1.testing.com:27020
Thu Aug 15 09:56:07.429 [Balancer] replica set monitor for replica set replica01 started, address is replica01/mongo1.testing.com:27020,mongo2.testing.com:27020
Thu Aug 15 09:56:07.429 [ReplicaSetMonitorWatcher] starting
Thu Aug 15 09:56:07.430 [Balancer] starting new replica set monitor for replica set replica02 with seed of mongo5.testing.com:27020,mongo6.testing.com:27020
Thu Aug 15 09:56:07.431 [Balancer] successfully connected to seed mongo5.testing.com:27020 for replica set replica02
Thu Aug 15 09:56:07.432 [Balancer] changing hosts to { 0: "mongo5.testing.com:27020", 1: "mongo6.testing.com:27020" } from replica02/
Thu Aug 15 09:56:07.432 [Balancer] trying to add new host mongo5.testing.com:27020 to replica set replica02
Thu Aug 15 09:56:07.432 [Balancer] successfully connected to new host mongo5.testing.com:27020 in replica set replica02
Thu Aug 15 09:56:07.432 [Balancer] trying to add new host mongo6.testing.com:27020 to replica set replica02
Thu Aug 15 09:56:07.433 [Balancer] successfully connected to new host mongo6.testing.com:27020 in replica set replica02
Thu Aug 15 09:56:07.712 [Balancer] Primary for replica set replica02 changed to mongo5.testing.com:27020
Thu Aug 15 09:56:07.714 [Balancer] replica set monitor for replica set replica02 started, address is replica02/mongo5.testing.com:27020,mongo6.testing.com:27020
Thu Aug 15 09:56:07.715 [Balancer] config servers and shards contacted successfully
Thu Aug 15 09:56:07.715 [Balancer] balancer id: web-inno.innologica.com:27111 started at Aug 15 09:56:07
Thu Aug 15 09:56:07.715 [Balancer] SyncClusterConnection connecting to [mongocfg1.testing.com:27000]
Thu Aug 15 09:56:07.716 [Balancer] SyncClusterConnection connecting to [mongocfg2.testing.com:27000]
Thu Aug 15 09:56:24.438 [mongosMain] connection accepted from 127.0.0.1:55303 #1 (1 connection now open)
Thu Aug 15 09:56:24.443 [conn1]  authenticate db: admin { authenticate: 1, nonce: "6cc9a76b79656179", user: "admin", key: "xxxxxxxxxxxxxxxxxxx" }
Thu Aug 15 09:56:26.676 [conn1] creating WriteBackListener for: mongo1.testing.com:27020 serverID: 520c7b87e4a4c3afa569b21a
Thu Aug 15 09:56:26.676 [conn1] creating WriteBackListener for: mongo2.testing.com:27020 serverID: 520c7b87e4a4c3afa569b21a
Thu Aug 15 09:56:26.678 [conn1] creating WriteBackListener for: mongo5.testing.com:27020 serverID: 520c7b87e4a4c3afa569b21a
Thu Aug 15 09:56:26.678 [conn1] creating WriteBackListener for: mongo6.testing.com:27020 serverID: 520c7b87e4a4c3afa569b21a
Thu Aug 15 09:56:26.679 [conn1] SyncClusterConnection connecting to [mongocfg1.testing.com:27000]
Thu Aug 15 09:56:26.679 [conn1] SyncClusterConnection connecting to [mongocfg2.testing.com:27000]
Thu Aug 15 09:56:26.680 [conn1] SyncClusterConnection connecting to [mongocfg3.testing.com:27000]
Thu Aug 15 09:57:33.704 [conn1] warning: inconsistent chunks found when reloading collection.documents, previous version was 8651|7||51b5c7a96b2903a0b3fac106, this should be rare
Thu Aug 15 09:57:33.714 [conn1] warning: ChunkManager loaded an invalid config for collection.documents, trying again
Thu Aug 15 09:57:34.065 [conn1] warning: inconsistent chunks found when reloading collection.documents, previous version was 8651|7||51b5c7a96b2903a0b3fac106, this should be rare
Thu Aug 15 09:57:34.076 [conn1] warning: ChunkManager loaded an invalid config for collection.documents, trying again
Thu Aug 15 09:57:34.491 [conn1] warning: inconsistent chunks found when reloading collection.documents, previous version was 8651|7||51b5c7a96b2903a0b3fac106, this should be rare
Thu Aug 15 09:57:34.503 [conn1] warning: ChunkManager loaded an invalid config for collection.documents, trying again
Thu Aug 15 09:57:34.533 [conn1] Assertion: 13282:Couldn't load a valid config for collection.documents after 3 attempts. Please try again.
0xa82161 0xa46e8b 0xa473cc 0x8b857e 0x93cb52 0x93f329 0x93ff18 0x94311f 0x9740e0 0x991865 0x669887 0xa6e8ce 0x7f4456361851 0x7f445570790d
 /usr/bin/mongos(_ZN5mongo15printStackTraceERSo+0x21) [0xa82161]
 /usr/bin/mongos(_ZN5mongo11msgassertedEiPKc+0x9b) [0xa46e8b]
 /usr/bin/mongos() [0xa473cc]
 /usr/bin/mongos(_ZN5mongo12ChunkManager18loadExistingRangesERKSs+0x24e) [0x8b857e]
 /usr/bin/mongos(_ZN5mongo8DBConfig14CollectionInfo5shardEPNS_12ChunkManagerE+0x52) [0x93cb52]
 /usr/bin/mongos(_ZN5mongo8DBConfig14CollectionInfoC1ERKNS_7BSONObjE+0x149) [0x93f329]
 /usr/bin/mongos(_ZN5mongo8DBConfig5_loadEv+0xa48) [0x93ff18]
 /usr/bin/mongos(_ZN5mongo8DBConfig4loadEv+0x1f) [0x94311f]
 /usr/bin/mongos(_ZN5mongo4Grid11getDBConfigESsbRKSs+0x480) [0x9740e0]
 /usr/bin/mongos(_ZN5mongo7Request5resetEv+0x1d5) [0x991865]
 /usr/bin/mongos(_ZN5mongo21ShardedMessageHandler7processERNS_7MessageEPNS_21AbstractMessagingPortEPNS_9LastErrorE+0x67) [0x669887]
 /usr/bin/mongos(_ZN5mongo17PortMessageServer17handleIncomingMsgEPv+0x42e) [0xa6e8ce]
 /lib64/libpthread.so.0(+0x7851) [0x7f4456361851]
 /lib64/libc.so.6(clone+0x6d) [0x7f445570790d]
Thu Aug 15 09:57:34.549 [conn1] scoped connection to mongocfg1.testing.com:27000,mongocfg2.testing.com:27000,mongocfg3.testing.com:27000 not being returned to the pool
Thu Aug 15 09:57:34.549 [conn1] warning: error loading initial database config information :: caused by :: Couldn't load a valid config for collection.documents after 3 attempts. Please try again.
Thu Aug 15 09:57:34.549 [conn1] AssertionException while processing op type : 2004 to : collection.system.namespaces :: caused by :: 13282 error loading initial database config information :: caused by :: Couldn't load a valid config for collection.documents after 3 attempts. Please try again.
Thu Aug 15 09:57:37.722 [Balancer] SyncClusterConnection connecting to [mongocfg1.testing.com:27000]
Thu Aug 15 09:57:37.723 [Balancer] SyncClusterConnection connecting to [mongocfg2.testing.com:27000]
Thu Aug 15 09:57:37.723 [Balancer] SyncClusterConnection connecting to [mongocfg3.testing.com:27000]

Les premiers mongos ont également cette erreur "avertissement: erreur lors du chargement des informations de configuration initiale de la base de données :: causée par :: Impossible de charger une configuration valide pour collection.documents après 3 tentatives. Veuillez réessayer."

mais travaillez pour l'instant.

Les seconds mongos après le redémarrage ne fonctionnent pas;

mongos> show collections
Thu Aug 15 09:57:34.550 JavaScript execution failed: error: {
    "$err" : "error loading initial database config information :: caused by :: Couldn't load a valid config for collection.documents after 3 attempts. Please try again.",
    "code" : 13282
} at src/mongo/shell/query.js:L128
mongos>

Quelles sont les prochaines étapes pour récupérer des serveurs de configuration?

Tous les conseils sont les bienvenus.

user2688866
la source

Réponses:

11

La restauration des serveurs de configuration, en particulier si vous avez eu une sorte d'événement catastrophique, est délicate, mais pas impossible. Mais, avant d'aller plus loin, une grosse mise en garde audacieuse:

SAUVEGARDER TOUT

Cela signifie prendre une sauvegarde des trois serveurs de configuration. Je vais vous donner quelques conseils, et c'est généralement correct, mais s'il vous plaît, veuillez prendre une copie de sauvegarde de chaque instance de serveur de configuration actuelle avant de remplacer / remplacer quoi que ce soit

Comme explication rapide, les serveurs de configuration ne sont pas configurés comme un jeu de réplicas - chaque instance de serveur de configuration est censée être identique (au moins pour toutes les collections importantes) aux autres. Par conséquent, tout serveur de configuration sain peut être utilisé pour remplacer un serveur de configuration non sain et vous pouvez ensuite suivre le didacticiel que vous avez mentionné pour revenir à une bonne configuration.

La clé de la récupération consiste à identifier le serveur de configuration sain et à l'utiliser pour remplacer les autres - vous vous retrouvez alors avec 3 serveurs de configuration identiques.

Il y a plus d'une façon de le faire, ils se répartissent essentiellement en trois catégories:

1) Utilisez le message d'erreur

Le message d'erreur qui est imprimé vous permet en fait de savoir quel serveur de configuration il pense être sain, bien que cela ne soit pas évident à partir de la messagerie. Voici comment le lire de manière générique:

ERROR: config servers not in sync! config servers <healthy-server> and <out-of-sync-server> differ

Fondamentalement, le premier de la liste est le plus sain, dans votre cas, ce serait le cas mongocfg1.testing.com:27000. C'est notre premier candidat pour une base de données de configuration saine.

2) Utilisez dbhashpour comparer les trois et choisissez ceux qui conviennent

Sur chaque serveur de configuration, basculez vers la base de données de configuration à l'aide use config, exécutez db.runCommand("dbhash")et comparez les hachages pour les collections ci-dessous:

  • morceaux
  • bases de données
  • réglages
  • fragments
  • version

Vous recherchez deux serveurs qui sont d'accord, et en vous servant de la base pour déterminer que la version de la base de données de configuration sur ces hôtes est fondamentalement fiable et doit être utilisée pour amorcer le reste.

3. Inspectez manuellement les collections dans la base de données de configuration

Enfin, jetez un œil à la base de données de configuration et faites attention aux collections répertoriées dans la deuxième option ci-dessus. Il s'agit d'un simple jugement fondé sur votre connaissance de vos données.

Espérons que les trois méthodes vous dirigent vers le même hôte (ou les hôtes). Ce serveur de configuration doit être utilisé pour amorcer les deux autres (après avoir effectué des sauvegardes afin de pouvoir revenir en arrière). C'est fondamentalement votre meilleur pari. Si cela échoue, vous voudrez peut-être essayer l'une des autres versions (à partir des sauvegardes) - en vous assurant toujours que lorsque vous les démarrez, les trois sont identiques.

Enfin, assurez-vous toujours que tous les mongosprocessus utilisent la même chaîne de serveur de configuration et que les 3 serveurs sont toujours répertoriés dans le même ordre sur chaque processus - ne pas le faire sur tous les mongosprocessus peut conduire à des résultats (très) étranges.

Adam C
la source
Pour la deuxième catégorie, je ne vois pas de collection "bases de données". À quel point est-ce important si d'autres choses comme des «morceaux» sont synchronisées? Peut-on le trouver ailleurs?
snetch
J'ai suivi ce que vous avez dit, je ne vois que le "md5": "d41d8cd98f00b204e9800998ecf8429e" de 3 serveurs de configuration identiques. Comment corriger l'erreur?
Amit Tripathi
salut AdamC, j'ai actuellement le même problème et il est très urgent pour moi de le faire dès que possible. J'ai une petite question. Dois-je arrêter tous les mongos et mongod avant d'arrêter la configdb?
rendybjunior
Si vous avez un problème urgent, je recommanderais d'obtenir des conseils professionnels à ce sujet - contactez MongoDB et demandez-leur de l'aide. Je ne travaille plus pour MongoDB et je ne voudrais pas vous parler de ce type de procédure, en particulier pour les versions plus récentes de la base de données où ce type de problème a considérablement changé (cette réponse a été écrite il y a presque 4 ans)
Adam C