Exceções do automongobackup, mas o script é concluído

Question

Estou usando o automongobackup para, bem, automatizar os backups do mongodb.

saída do script (para STDERR) tem as seguintes exceções (mas o backup é concluído e os arquivos de despejo são criados)

###### WARNING ######
STDERR written to during mongodump execution. 
The backup probably succeeded, as mongodump sometimes writes to STDERR, but you may wish to scan the error log below:
exception: connect failed
exception: connect failed
exception: connect failed
exception: connect failed
exception: HostAndPort: bad port #
exception: connect failed
exception: connect failed
exception: connect failed
exception: connect failed
exception: connect failed
exception: connect failed

Eu sei que o Host & Porta estão corretas.

Se eu executar mongodump --host=127.0.0.1:27017 --journal (que é o comando efetivo de automongobackup com base nas opções definidas e minha leitura do código src), tudo será executado sem nenhum relatório de erros e os arquivos de despejo serão criados conforme o esperado.

Por que automongobackup reporta erros de conexão, mesmo que crie arquivos de despejo, mas uma chamada direta para mongodump não?

• Debian 6.0 Lenny (da imagem Linode: Latest 3.2 (3.2.1-x86_64-linode23))
• AutoMongoBackup VER 0,9
• mongodb v 2.0.2

Answer 1

Eu tenho mergulhado no código de automongobackup e enquanto shell scripts não são o meu strong:

A resposta curta

Defina o seguinte na seção de configuração:

# Choose other Server if is Replica-Set Master
REPLICAONSLAVE="no"

Eu defini isso como 'yes' (já que espero mudar para uma réplica antes) - e recebi exatamente os erros que o OP fornece por e-mail, com outro e-mail contendo o registro bem-sucedido do script, ou seja, o mesmo problema .

A resposta longa

O texto nessa opção de configuração implica que a configuração só terá efeito se estiver em um conjunto de réplicas. Mas mais tarde no código, você vê que ter essa variável de configuração definida como 'yes' faz com que ela seja executada

mongo --quiet --eval       'rs.conf().members.forEach(function(x){ print(x.host) })'

i.e. ele pergunta ao mongo quais são os membros do conjunto de réplicas. No entanto, se você não estiver em , um replicaset, que retorna:

TypeError: rs.conf() has no properties

De lá, uma coisa leva a outra dentro do script e os erros são, presumivelmente, o resultado. Das mensagens de erro, acredito que tente em algum lugar para conectar a um servidor secundário que

• não existe ..
• porque não está configurado ..
• porque não há configuração.

Eu decidi não usar o script do gWaldo porque acho que o automongobackup tem mais chances de ser mantido e melhorado no futuro.

Em resumo, o código que detecta se você está em um conjunto de réplicas e como lidar com isso, caso não precise melhorar. Definir essa opção como 'no' consertará isso até que o script melhore - o que infelizmente estou qualificado para fazer.

    

Answer 2

Sem mergulhar em seu código, não posso dizer por que ele está jogando erros.

O que posso dizer é que você já investiu mais esforço em encontrar essa ferramenta (aparentemente quebrada) do que se tivesse acabado de escrever um script de shell rápido para chamar mongodump (mesmo com rotações) e adicioná-lo ao seu crontab.

Veja um exemplo do que você pode fazer se quiser fazer backups diários durante uma semana, mas manter os domingos perpetuamente:

#!/bin/bash

## Determine day of week. If Sunday, do an archival backup.
## Otherwise, do by day of week.

DOW='/bin/date +%a'
REPLSET="mlg0"

if [ $DOW == "Sun" ]; then
  DSTRING='/bin/date +%Y-%m-%d'
  ARCHSTRING="$REPLSET.$DOW.$DSTRING.tgz"
else
  ARCHSTRING="$REPLSET.$DOW"

fi

BACKUP_DIR="/var/shared/backup/mongodb/$ARCHSTRING"

CRON="backup.$ARCHSTRING"
LOCKFILE="/tmp/cron.$CRON.lock"

if [ -f "$LOCKFILE" ]; then
    /usr/bin/logger -t mongodb_backup "$ARCHSTRING locked; skipping"
    exit 0
fi

touch "$LOCKFILE"
/usr/bin/logger -t mongodb_backup "$ARCHSTRING started"
rm -f $BACKUP_DIR
mkdir $BACKUP_DIR
/opt/mongodb-2.0.1/bin/mongodump --host server.domain --out $BACKUP_DIR
rm -f "$LOCKFILE"
/usr/bin/logger -t mongodb_backup "$ARCHSTRING finished"

Agora, um repositório do git: link

    

Answer 3

Então, você quer ter o benefício de ter Conjuntos de Réplicas, mas ainda não o faz, já que na verdade não é executado nesse modo no momento. Então, novamente, você reclama de erros?

O que você esperava que acontecesse? :)

Obviamente, se você colocar "yes" em "REPLICAONSLAVE", então o código assumirá que o que você deseja é encontrar o primeiro escravo disponível para fazer o backup.

De qualquer forma, adicionarei código de detecção de conjuntos de réplicas relevantes em algum momento (se o tempo livre permitir) conforme o problema que alguém abriu por meio do github: -)

KW