Pourquoi Mongo est coincé dans STARTUP2?

13

J'ai une Mongoréplique avec quelques secondaires. Une boîte, qui héberge une instance secondaire, s'est écrasée et a perdu la base de données.

J'ai redémarré l' Mongoinstance secondaire et maintenant elle est bloquée dans STARTUP2 pendant plus de 12 heures. Est-ce que ça fait du sens ? Les documents indiquent qu'ils Mongodevraient être dans STARTUP2 pendant une courte période avant d'entrer dans l'état RECOVERING

Que signifie exactement STARTUP2? Copie-t-il la base de données du primaire? Comment puis-je le vérifier (en supposant que Mongo fonctionne sous Linux)?

mongodb recovery

— Michael
source

12

La réponse de l'eoinbrazil est partiellement incorrecte. Un nouveau nœud peut être dans STARTUP2 pendant longtemps. Le lien affiché indique:

Chaque membre d'un jeu de réplicas entre dans l'état STARTUP2 dès que mongod a fini de charger la configuration de ce membre, auquel cas il devient un membre actif du jeu de réplicas. Le membre décide ensuite de procéder ou non à une synchronisation initiale. Si un membre commence une synchronisation initiale, le membre reste dans STARTUP2 jusqu'à ce que toutes les données soient copiées et que tous les index soient créés. Par la suite, le membre passe à RECOVERING.

J'administre une collection de 700 Go et, lorsque j'ajoute un nouveau nœud, l'état STARTUP2 reste bien plus de 24 heures. Mais vous pouvez toujours voir s'il se passe quelque chose, en regardant si la base de données se développe. Vous pouvez voir la taille de la base de données sur le nouveau nœud avec

show databases

ou vous pouvez également observer le répertoire de données, pour voir s'il est toujours en croissance. (sous linux avec les commandes ls, df, du, iotop, etc ....)

— Kenyakorn Ketsombut
source

1

show databaseséchoue avecnot master and slaveOk=false

— JDPeckham

En regardant les journaux, vous pouvez voir la progression. Par exemple, il affichera quelque chose comme: [rsSync] Index Build: 2538000/22982417 11%

— Daniel Benedykt

4

L'état STARTUP2 signifie que le nœud ne peut pas voter. Un membre d'un RS entre dans cet état une fois que le processus MongoD a terminé de charger sa configuration. Dans cet état, le membre a créé des threads pour gérer les opérations de réplication internes, mais il n'a pas encore changé d'état en Récupération et ensuite celui en Secondaire (voir [l'état et leurs détails dans les documents]) .

Si votre nœud est dans cet état depuis plus d'une brève période, vous rencontrez un comportement étrange. C'est à peu près impossible à analyser sans les journaux pour déterminer pourquoi il est bloqué. L'exécution de rs.status () et db.printSlaveReplicationInfo () vous donnera quelques détails sur l'image locale sur le nœud.

L'approche normale pour résoudre ce problème serait d'arrêter le nœud, d'essuyer ses fichiers de données (ces fichiers dans le dbpath) et de le redémarrer. Cela redémarrera le processus de synchronisation initial et devrait passer au SECONDAIRE. S'il se bloque à nouveau dans STARTUP2, vous devrez consulter les journaux pour collecter plus d'informations sur les raisons - il existe un éventail de causes, mais l'une d'entre elles peut être un réseau instable ou une contention de ressources locales.

Un point à noter est que pendant qu'une synchronisation initiale est en cours, le nœud restera dans STARTUP2, donc en fonction de la quantité de données synchronisées, cela pourrait prendre un temps considérable (potentiellement des jours).

— eoinbrazil
source

Merci. Nous avons supprimé les données et redémarré le Mongo. Il est toujours dans STARTUP2. Il semble que le Mongo fonctionne. Il consomme du CPU et comme je le vois dans db.statsla base de données, il grandit. Le journal indique que certains objets cloned. Je cherche toujours les causes possibles de ce problème.

— Michael

1

Si c'est toujours un problème, vous pouvez simplement faire une copie à partir d'un autre nœud (voir cette procédure - docs.mongodb.org/manual/tutorial/resync-replica-set-member/… ). Si vous pouvez joindre les faits saillants et les détails des journaux sur la version que vous utilisez, cela peut indiquer une cause, mais il s'agit également d'un comportement inhabituel. Avez-vous essayé de faire un ping entre les nœuds pour voir à quoi ressemble la latence du réseau?

— eoinbrazil

Mongo 2.4.6 pingentre les hôtes est OK.

— Michael

À quoi ressemblent les temps de ping car il peut s'agir de problèmes de réseau intermittents? Dans ce cas, il est beaucoup plus facile d'ajouter des sorties de journal car il s'agit d'un comportement non standard et les journaux sont la principale source de vérité lorsque vous essayez de déterminer ce qui se passe exactement.

— eoinbrazil

J'ai peur de ne pas pouvoir afficher les journaux ici. Cependant, j'ai remarqué qu'il essaie de se connecter à un autre membre secondaire, qui est en panne. Cela peut-il être la cause du problème?

— Michael

1

Une cause possible est que votre secondaire devient "périmé" comme indiqué ici .

Lorsque vous resynchronisez un membre, assurez-vous que le RS n'est pas sous une lourde charge.

— user2829759
source

0

L'état STARTUP2 peut être dû à un espace disque insuffisant. Eh bien, puisqu'il n'y a pas où synchroniser, il ne peut que rester à l'état @ STARTUP2.

— Aesop Lee
source