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