Bonjour,
Tout d'abord, j'avoue honteusement ne jamais avoir joué en détail avec
mongodb.
Nous avons un client qui utilise un 'cluster' (pas sûr du terme exact)
mongodb dans du kubernetes.
C'est un replicaset entre deux containers, un secondary et un primary.
Il y a quelques jours, le primary a été redémarré (je ne me souviens
plus exactement pourquoi) et depuis son socket n'est pas ouvert et il
loggue des tonnes de réplications depuis le secondary (qui est passé
master du coup).
Des lignes de ce style là :
2019-07-08T14:25:54.190+0000 I REPL [repl writer worker 14] applied
op: CRUD { ts: Timestamp(1557594480, 163), t: 30, h:
9159662043010515962, v: 2, op: "u", ns: "config.system.sessions", ui:
UUID("d70a82fb-4fb1-477c-8d4b-81fd4e85252b"), o2: { _id: { id:
UUID("918a45b7-977d-4ccc-b9e9-1374827a8487"), uid: BinData(0,
E3B0C44298FC1C159AFBF4C8996FB92428AE41E4649B934CA495991B7852B855) } },
wall: new Date(1557594480500), o: { $v: 1, $set: { lastUse: new
Date(1557594480505) } } }, took 205ms
(j'ai volontairement remplacé quelques octets aléatoirement pour que ça
reste inexploitable)
A première vue, je dirais qu'il est en train d'appliquer une série
opérations CRUD qui lui manquent depuis le dernier bon jeu de données
qu'il a pu trouver.
Ce qui me choque, c'est que le timestamp (qui s'incrémente
tranquillement) est ici au 11/05 et c'est parti de plus loin encore. Ce
qui signifierait qu'en cas de reboot, la dernière version des données
'utilisable' est vraiment très ancienne. C'est juste flippant, notamment
si on perd le secondary avant la fin de l'opération.
De plus, il était master, pourquoi est-il obligé de récupérer des
données depuis le secondary ?
Et ça prend des plombes (ça tourne depuis plusieurs jours déjà). A
priori, on parle d'un moteur WiredTiger.
Un doué en mongodb saurait m'expliquer rapidement un tel retour dans le
passé ? Et tant qu'à faire, si on peut accélérer le mouvement, au moins
pour les prochaines fois ?
Merci !
Julien