Восстановление устаревшей конфигурации сервера

Question

У нас есть 1 тест MongoDB кластер, который включает в себя

• 1 mongos серверы

• 3 конфигурации сервера

• 6 Осколки

Q1 , Мы попытались восстановить устаревшую резервную копию резервного сервера. Мы можем найти только, что у config.chunks меньше записей, чем раньше, но мы можем запрашивать и вставлять/обновлять данные в mongodb. Какой будет худший результат, если мы воспользуемся устаревшей резервной копией резервного сервера?

Q2. Есть ли какие-либо инструменты, которые могут воссоздать записи потерь в конфигурационном сервере с существующими данными в каждом осколке?

Answer 1

Ответ на Q1

с устаревшим содержимым конфигурации сервера, IIRC, может быть незамеченной гигантская потеря данных. Вот почему:

Sharding in MongoDB основан на ключевых диапазонах. То есть каждому осколку присваивается диапазон ключей, которые он отвечает.

Для иллюстрации предположим, что у вас есть ключ осколка целых чисел, начиная с 1 до бесконечности. Таким образом, основные диапазоны могут выглядеть следующим образом (эксклюзивные границы)

shard0001: -infinity to 100 
shard0002: 101 - 200 
shard0003: 201 - 300 
shard0004: 301 - 400 
shard0005: 401 - 500 
shard0006: 501 - 600 

Так как же вы Монго знает об этом распределении? Он хранится на серверах конфигурации. Теперь предположим, что ваши метаданные были изменены, и ваш shard0002 фактически хранит данные от 100-500. Предположим, вы хотите получить документ с помощью ключа осколка 450. Согласно старым метаданным, этот документ должен быть на shard0005, если он существует. Таким образом, запрос направляется в shard0005. Будет выполнен поиск индекса, и осколок выяснит, что у него нет документа. Поэтому, пока документ существует (на shard0002), из-за устаревших метаданных он будет проверяться на shard0005, где его не существует.

Ответ на Q2

Нет, насколько я знаю. Однако вы можете использовать следующую процедуру для MongoDB < 3.0.0.

Отказ

Я не проверял эту процедуру. Перед очисткой каталогов данных убедитесь, что у вас есть резервные копии, и не опускайте флажки --repair и --objcheck. Для обеспечения максимальной безопасности создайте моментальные снимки файловой системы перед использованием. Если вы этого не сделаете, пожалуйста, не обвиняйте меня в каких-либо потерях данных.

1. Выключите весь кластер изящно

2. Используйте mongodump против каталога данных

   mongodump --repair --dbpath /path/to/your/datafiles -o /path/for/backups/mongo 
   

   Сделайте это один раз для каждого осколка.

3. Протрите все каталоги данных и восстановить свой sharded кластер

4. Подключение к mongos

   sh.enableSharding({"database":yourDb}) 
   sh.shardCollection("yourdDb.yourShardedCollection",{"yourShardKey":1}) 
   

5. От каждого осколка, используйте mongorestore для записи резервных копий к mongos

   mongorestore -h mongosHost:mongosPort --db yourDb --dir /path/for/backups/ \ 
   --objcheck --write-concern "{w:1}" 
   

Обратите внимание, что вы должны NOT выполнять восстановление параллельно, так как это может привести к перегрузке балансировочного устройства.

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

Следите за процессом очень осторожно и абсолютно уверены, что вы не перегружаете балансир, иначе вы можете вырваться из дискового пространства на осколке, если у вас нет оптимального ключа осколка.

Конечно, вы можете воссоздать другие защищенные базы данных из резервной копии, используя соответственно mongorestore. Чтобы восстановить незащищенные базы данных, просто подключитесь к репликации, которую вы хотите сохранить, вместо того, чтобы подключаться к монго.

Примечание стороны:

Если вам нужно восстановить сервер конфигурации, просто сбросить один из двух других и восстановить базу данных конфигурации для этого сервера.

Причина этого в том, что метаданные не могут быть обновлены, если все серверы конфигурации не работают, не работают и не синхронизируются.