Не углубляясь в их код, я не могу сказать вам, почему он выдает ошибки.

Что я могу сказать, так это то, что вы уже приложили больше усилий для поиска этого (очевидно, сломанного) инструмента, чем если бы вы просто написали сценарий быстрой оболочки для вызова mongodump (даже с ротациями) и добавления его в свой crontab.

Вот пример того, что вы можете сделать, если хотите иметь ежедневное резервное копирование в течение одной недели, но оставлять воскресенья вечными:

#!/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"

Теперь репозиторий git: https://github.com/gwaldo/mongoBackup

я иметь погрузился в код automongobackup и пока сценарии оболочки не моя сильная сторона:

Краткий ответ

В разделе конфигурации задайте следующее:

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

У меня было установлено «да» (так как я надеюсь вскоре перейти к набору реплик) - и мне по электронной почте отправлялись именно те ошибки, которые предоставляет OP, с другим электронным письмом, содержащим успешный журнал из сценария, то есть ту же проблему.

Длинный ответ

Формулировка этого параметра конфигурации подразумевает, что параметр будет иметь только эффект если это в наборе реплик. Но позже в коде вы увидите, что если для этой переменной конфигурации установлено значение «да», она будет выполняться

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

то есть он спрашивает mongo, что такое члены набора реплик. Однако, если вы не в набор реплик, который возвращает:

TypeError: rs.conf() has no properties

Оттуда одно ведет к другому внутри сценария, и, по-видимому, результатом являются ошибки. Из сообщений об ошибках я предполагаю, что он пытается где-то подключиться на вторичный сервер, который

• не существует ..
• потому что он не настроен ..
• потому что конфигурации нет.

Я решил не использовать скрипт gWaldo, потому что думаю, что в будущем автобэкап с большей вероятностью будет поддерживаться и улучшаться.

Таким образом, код, который определяет, находитесь ли вы в наборе реплик, и как с ним справиться, если вы не нуждаетесь в улучшении. Установка для этой опции значения «нет» будет исправлять это до тех пор, пока сценарий не улучшится, что, к сожалению, у меня недостаточно.

Итак, вы хотите иметь преимущество наличия наборов реплик, но еще не совсем так, поскольку в данный момент вы действительно не работаете в таком режиме. Опять же, вы жалуетесь на там ошибки?

Чего вы ожидали? :)

Очевидно, что если вы поставите «да» в «REPLICAONSLAVE», тогда код будет предполагать, что вы хотите найти первое доступное подчиненное устройство, с которого можно сделать резервную копию.

В любом случае, я добавлю соответствующий код обнаружения Replica Sets в какой-то момент (если позволит свободное время) в соответствии с проблемой, которую кто-то открыл через github :-)

КВт