Falha de segmentação Mongodump ao despejar todos os dbs

Question

Eu estou executando um replicaset mongodb (2.0.4) com um mestre e dois escravos, onde um é escravo oculto para backup. Estou usando o link

Quando eu corro mongodump --oplog -h rsuat/10.0.3.163 --out /tmp/lala

Eu recebo:

Fri Dec 13 09:05:53 starting new replica set monitor for replica set rsuat with seed of 10.0.3.163
Fri Dec 13 09:05:53 successfully connected to seed 10.0.3.163 for replica set rsuat
Fri Dec 13 09:05:53 changing hosts to { 0: "10.0.2.234:27017", 1: "10.0.4.96:27017" } from rsuat/
Fri Dec 13 09:05:53 trying to add new host 10.0.2.234:27017 to replica set rsuat
Fri Dec 13 09:05:53 successfully connected to new host 10.0.2.234:27017 in replica set rsuat
Fri Dec 13 09:05:53 trying to add new host 10.0.4.96:27017 to replica set rsuat
Fri Dec 13 09:05:53 successfully connected to new host 10.0.4.96:27017 in replica set rsuat
Fri Dec 13 09:05:53 replica set monitor for replica set rsuat started, address is rsuat/10.0.2.234:27017,10.0.4.96:27017
Fri Dec 13 09:05:53 [ReplicaSetMonitorWatcher] starting
connected to: rsuat/10.0.3.163
all dbs
DATABASE: connect_log,mongodb:   to     /tmp/lala/connect_log,mongodb:
    connect_log,mongodb:.log to /tmp/lala/connect_log,mongodb:/log.bson
        131600/142621   92%
         142621 objects
    connect_log,mongodb:.system.indexes to /tmp/lala/connect_log,mongodb:/system.indexes.bson
         1 objects
Segmentation fault (core dumped)

Funciona sem o sinalizador oplog. Alguém tem uma pista do que poderia estar errado?

EDIT: falha de segmentação parece acontecer mesmo se eu não usar o sinalizador oplog, então o erro é ao fazer um despejo completo.

EDIT2: Esta é uma linha do syslog causada pelo processo se for de alguma ajuda:

 ip-10-0-3-163 kernel: [23126212.267385] mongodump[26858]: segfault at 0 ip 00007f234ca776c4 sp 00007fff2b9d5f00 error 4 in libc-2.15.so[7f234ca09000+1b5000]

    

Answer 1

Deve-se observar que usar --oplog não constitui um "despejo completo", que sinaliza quaisquer operações que foram aplicadas ao oplog entre o início do dump e o final do dump. Ou seja, ele fornecerá uma parte do oplog para que seu dump quando restaurado (com --oplogReplay ) represente os dados como estavam no final do dump.

No entanto, ele não despeja o oplog em si, portanto, se você não estiver inserindo / atualizando durante o despejo, ele não será necessário. Na verdade, acho que havia alguns bugs de coleções vazias com mongodump , então, se não houver ops no oplog entre o início e o final do dump, isso pode ser um problema seu.

Como outra maneira possível de contornar isso - você tentou usar versões mais recentes das ferramentas (2.4.x etc.) contra a instância 2.0.4. A versão 2.0.4 é bem antiga neste ponto, houve até mesmo mais lançamentos 2.0.x depois disso, sem mencionar dois lançamentos principais e outro em breve. Você não precisa ter uma versão 2.4 do servidor para usar suas ferramentas, o que pode fazer com que você encontre alguns dos antigos mongodump bugs.