Pourquoi Mongo est coincé dans STARTUP2?
J'ai un réplica Mongo 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'instance secondaire Mongo et maintenant elle est bloquée dans STARTUP2 pendant plus de 12 heures. Est-ce que ça fait du sens ? Les documents indiquent que Mongo devrait ê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)?
La réponse de l'eoinbrazil est partiellement incorrecte. Un nouveau Node peut être dans STARTUP2 pendant longtemps. Le lien que le posté dit:
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 supérieur à 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 ....)
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 interne mais il n'a pas encore changé d'état en Récupération et en passant de celui-ci à Secondaire (voir [é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).
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.
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.