У нас есть набор реплик MongoDB, установленный на серверах Windows, с запланированным заданием резервного копирования. MongoDB настроен на использование журналирования.
Работа выполняется db.fsyncLock() через скрипт на MongoDB (первичный сервер), затем выполняет моментальный снимок файловой системы Kaminario, а затем запускает db.syncUnlock() через скрипт.
Блокировка / разблокировка осуществляется отдельно, поэтому не используется одно и то же соединение.
Проблема в том, что db.fsyncUnlock() не всегда работает, оставляя базу данных заблокированной для записи, пока она не будет разблокирована вручную через оболочку.
Мы попытались сделать снимки без использования fsyncLock()Однако наши тесты показали, что:
Восстановление только одной базы данных, в результате чего данные имеют «дыры» в ней (некоторые из записывающих потоков имели незафиксированные изменения, за которыми следовали зафиксированные изменения)
При восстановлении всего экземпляра базы данных восстановление не удалось из-за блокировки и отсутствия журнала, несмотря на то, что журнал включен и присутствует.
В то время как с fsyncLock() тесты прошли. Испытания проводились с writeConcernзнак равно2, так как мы хотим обеспечить постоянство в случае сбоя MongoDB.
Мои вопросы:
а. Как гарантировать успех fsyncUnlock() после выполнения снимка?
б. Есть ли способ гарантировать последовательное резервное копирование без использования fsyncLock()?
Крест отправлен на DBA.SE.
Редактировать:
После дальнейшего расследования выяснилось, что проблема заключалась в зависании снимка, а не в разблокировке. Однако это все еще не объясняет, что fsync требует блокировки.