Назад | Перейти на главную страницу

Mongodb в стратегии резервного копирования AWS EC2

Я запускаю Mongodb на экземпляре AWS EC2. Данные / журнал / и журнал хранятся в отдельном томе в формате xfs. В настоящее время мы останавливаем экземпляр mongodb, чтобы сделать снимок, но читаем следующее: https://docs.mongodb.com/ecosystem/tutorial/backup-and-restore-mongodb-on-amazon-ec2/ очевидно, нет необходимости останавливать службу во время создания снимка, поскольку журнал включен. Я прав? Могу ли я создать согласованный моментальный снимок, даже если служба работает?

В общем, не доверяйте никаким процедурам резервного копирования, пока не подтвердите целостность восстановления с долговременного носителя.


У вас уже есть возможность сделать резервную копию уровня системы хранения в режиме онлайн. В данном случае с томами EBS или Linux LVM. Проблема в том, чтобы привести базу данных в согласованное состояние.

Оперативное резервное копирование возможно с журналом или без него. В любом случае способ приостановить запись в базу данных mongo - это fsync и lock, как описано в этом руководстве.

Без журнала трудно сказать, какие данные надежно хранятся на диске, а какие находятся в буфере и еще не зафиксированы. fsync и lock устанавливают момент времени и останавливают все выполняющиеся записи до тех пор, пока не будет выполнено резервное копирование.

Блокировка также необходима для нескольких дисков, где (в этой системе хранения) моментальные снимки не согласуются друг с другом. Приостановка записи на время резервного копирования означает, что диск /dev/sdf не будет в несколько другой момент времени по сравнению с /dev/sdg.

Монго утверждает, что если у вас есть только не замужем диск и иметь журнал, вам не нужно использовать fsync и блокировку. Предположительно, моментальный снимок EBS - достаточно хороший момент времени с устойчивостью к сбоям, и восстановление журнала вперед может исправить любые неполные записи.