Начальная синхронизация MongoDB в большой базе данных

Question

Мы используем набор реплик MongoDB с тремя узлами. База данных имеет довольно большой размер в 2+ миллиарда записей и занимает 700 ГБ на диске (ядро WiredTiger MongoDB). В основном на документах выполняются вкладыши (несколько миллионов в день), после чего читаются и обновляются.

После замены диска на дополнительном элементе папка с данными была пуста и началась первоначальная синхронизация. Изучив журналы, потребовалось около 7 часов для копирования записей, а затем 30 часов для построения индексов, но это было слишком много для оплога, чтобы содержать все записи, которые были вставлены / обновлены за это время:

2016-11-16T23:32:03.503+0100 E REPL     [rsBackgroundSync] too stale to catch up -- entering maintenance mode
2016-11-16T23:32:03.503+0100 I REPL     [rsBackgroundSync] our last optime : (term: 46, timestamp: Nov 15 10:03:15:8c)
2016-11-16T23:32:03.503+0100 I REPL     [rsBackgroundSync] oldest available is (term: 46, timestamp: Nov 15 17:37:57:30)
2016-11-16T23:32:03.503+0100 I REPL     [rsBackgroundSync] See http://dochub.mongodb.org/core/resyncingaverystalereplicasetmember

Сначала мы перезапустили этот элемент, и началась повторная синхронизация:

2016-11-16T23:47:22.974+0100 I REPL     [rsSync] initial sync pending
2016-11-16T23:47:22.974+0100 I REPL     [ReplicationExecutor] syncing from: x3:27017
2016-11-16T23:47:23.219+0100 I REPL     [rsSync] initial sync drop all databases
2016-11-16T23:47:23.219+0100 I STORAGE  [rsSync] dropAllDatabasesExceptLocal 5
2016-11-16T23:53:09.014+0100 I REPL     [rsSync] initial sync clone all databases

При просмотре папки с данными все файлы были стерты, и они начали расти. Но примерно через 8 часов он едва ресинсировал 5% базы данных.

Какой подход использовать для таких больших синхронизаций?

Мы думали увеличить размер оплога, но для этого потребуется время простоя всего набора реплик. Какие подходы мы можем использовать без простоя?

Answer 1

Лучшее решение - использовать снимок файловой системы, если это возможно.

Вы можете сделать снимок узла mongod напрямую, если файлы оплогов находятся на том же дисковом пространстве, что и остальные файлы данных. Не нужно "отключать" или делать что-то еще проактивное.

как сделать восстановление со снимком

Затем вы просто копируете эти файлы в каталог данных новых узлов и запускаете mongod.

Если моментальный снимок файловой системы невозможен, тогда можно взять другой способ скопировать рабочий каталог данных mongod, что легко, если у вас может быть время простоя. Если у вас не может быть простоев, вы всегда можете добавить несколько (два) арбитров и на мгновение остановить этот другой вторичный объект (чтобы получить копию каталога данных), конечно, в течение этого времени ваш набор реплик в основном является "одним узлом RS".