Mongodb перенести базу на другой жесткий диск
Обновлено: 06.07.2024
Резервное копирование и восстановление в MongoDB является важной частью для обработки базы данных. Эта утилита важна, потому что ваши ценные данные могут быть удалены или повреждены или повреждены с вашего сервера, локального компьютера случайно или по любой ошибке, какой бы она ни была. В этот жизненно важный момент вы можете быть в безопасности, восстанавливая свои данные, если у вас есть резервная копия ваших ценных данных. Резервное копирование может быть сделано в различном формате. Здесь, в этой статье, мы опишем процесс создания резервных копий и восстановления данных с использованием утилит, поставляемых с MongoDB
MongoDB Backup
Резервное копирование базы данных с mongodump
Утилита резервного копирования MongoDB может создать резервную копию для всего сервера, базы данных или коллекции, или вы можете использовать запрос для резервного копирования части коллекции.
Когда mongodump работает только без каких-либо аргументов, команда подключается к экземпляру MongoDB в локальной системе (например, localhost) через порт 27017 и создает резервную копию базы данных с именем dump / в текущем каталоге.
Вот команда для резервного копирования данных с экземпляра mongod или mongos, работающего на той же машине и с портом по умолчанию 27017.
Чтобы сделать резервную копию, вы должны ввести каталог bin в папку mongodb на вашем компьютере. Здесь наш путь D: / mongodb / bin, и вы должны выполнить команду отсюда.
Для резервного копирования базы данных с помощью mongodump укажите --host и --port
Здесь, в приведенном ниже примере, хост - это mypc-PC, а порт - это порт по умолчанию 27017.
NB. Команда mongodump перезаписывает выходные файлы, если они уже существуют в папке данных резервного копирования. Таким образом, лучше убедиться, что вам больше не нужны файлы в выходной папке или вы взяли копию предыдущей резервной папки, прежде чем запускать команду mongodump несколько раз.
Резервное копирование базы данных с mongodump указать другой выходной каталог
Вы можете сделать резервную копию в определенном каталоге, используя опцию --out или -o. Здесь в приведенном ниже примере мы упоминаем каталог в D: это backup_data / backup / folder.
NB. Команда mongodump перезаписывает выходные файлы, если они уже существуют в папке данных резервного копирования. Таким образом, лучше убедиться, что вам больше не нужны файлы в выходной папке или вы взяли копию предыдущей резервной папки, прежде чем запускать команду mongodump несколько раз.
Резервное копирование определенной коллекции и конкретной базы данных с помощью mongodump
Если вы хотите сделать резервную копию определенной базы данных и определенной коллекции с помощью команды mongodump, вы можете указать --db и --collection в качестве параметров для mongodump.
Здесь, в приведенном ниже примере, наша база данных - myinfo, а collection - userdetails.
Приведенная выше операция создаст дамп коллекции с именем userdetails из базы данных myinfo в подкаталоге dump / текущего рабочего каталога. Вот вывод
NB. Команда mongodump перезаписывает выходные файлы, если они уже существуют в папке данных резервного копирования. Таким образом, лучше убедиться, что вам больше не нужны файлы в выходной папке или вы взяли копию предыдущей резервной папки, прежде чем запускать команду mongodump несколько раз.
Создание резервных копий из нелокальных экземпляров mongod
В этом типе резервного копирования параметры --host и --port для mongodump позволяют пользователю подключаться и выполнять резервное копирование с удаленного хоста. Вот такая команда:
Резервное копирование базы данных и коллекции MongoDB с использованием экспорта в формате CSV
Данные MongoDB можно экспортировать с помощью команды mongoexport. Команда mongoexport подключается к экземпляру mongod, который работает на локальном порту с номером 27017.
Здесь в приведенном ниже примере экспортируются данные из коллекции userdetails, которая находится в базе данных myinfo в формате CSV, в файл D: /backup_data/backup/userdetails.csv.
Когда вы экспортируете в формате CSV, вы должны указать поля в документах для экспорта, а в приведенном ниже примере конкретными полями являются user_id, образование и интерес.
Вы можете открыть этот файл в Excel. Вот файл, отображаемый в каталоге упоминаний, и данные, экспортированные в формате .csv.
Экспорт в формате CSV с использованием файла, содержащего список полей
Вы также можете указать поля в файле, содержащем список полей, разделенных строками, для экспорта и использовать этот файл .txt вместе с параметром --fieldFile в команде mongoexport.
Вот файл myfields.txt, как показано ниже. Откройте редактор блокнота и напишите следующий текст, только одно поле в одной строке, затем сохраните файл под нужным именем в папке / mondodb / bin / и используйте это имя в команде. Здесь наше имя файла myfields.txt, и мы использовали это имя.
Экспорт в формате JSON
В приведенном ниже примере экспортируются пользовательские детали коллекции из экземпляра MongoDB, запущенного на локальном порту с номером 27017, с явным включением ведения журнала. Эта команда записывает экспортированные данные в файл newuserdetails.json в формате JSON.
Экспорт с удаленного хоста, запущенного с аутентификацией
Имя нашей коллекции - userdetails, а db - myinfo, а расположение и имя файла резервной копии - D: /backup_data/backup/newuserdetails.json.
Экспорт результатов запроса
Только результаты запроса также можно экспортировать с помощью параметра --query, и ограничить результаты одной базой данных с помощью параметра --db.
Здесь, в приведенном ниже примере, эта команда возвращает все документы из коллекции userdetails в базе данных myinfo, которые содержат поле с именем интереса и значением которого является MUSIC.
MongoDB Restore
Восстановление из дампа с помощью mongorestore
Утилита восстановления с помощью команды mongorestore восстанавливает двоичную резервную копию, созданную mongodump. Mongorestore может восстановить либо целую резервную копию базы данных, либо ее часть.
Следующая команда импортирует резервную копию базы данных в папке дампа в экземпляр mongod, работающий на интерфейсе localhost. Вот команда. Здесь мы не упомянули имя папки, поэтому по умолчанию резервная копия базы данных в папке дампа будет импортирована.
Следующая команда импортирует резервную копию базы данных в папке myinfo в папке dump в экземпляр mongod, работающий на интерфейсе localhost. Вот команда. Здесь мы упоминаем имя папки, поэтому резервная копия базы данных из упомянутой папки будет импортирована.
Восстановление резервных копий в нелокальные экземпляры mongod
Команда mongorestore по умолчанию подключается к экземпляру MongoDB, работающему на интерфейсе localhost с портом по умолчанию (27017). Мы также можем восстановить резервную копию на другой хост или порт, используя опции --host и --port.
Импорт коллекции с использованием mongoimport
Команда mongoimport восстанавливает базу данных из резервной копии, созданной с помощью mongoexport.
Здесь в примере предположим, что наше имя файла резервной копии - newuserdetails.JSON, имя базы данных - myinfo, а имя коллекции - userdetails. В следующем примере mongoimport импортирует данные в данных JSON из файла newuserdetails.json в пользовательские детали коллекции в базе данных myinfo.
Импорт JSON на удаленный хост, работающий с аутентификацией
Команду mongoimport также можно использовать для импорта данных в удаленную базу данных MongoDB с включенной аутентификацией. Здесь в приведенном ниже примере mongoimport импортирует данные из файла /backup_data/backup/newuserdetails.json в коллекцию userdetails в базе данных myinfo в удаленной базе данных MongoDB.
CSV Import
Mongoimport может импортировать данные в формате CSV в коллекцию. Опция --headerline используется, чтобы дать команду mongoimport определить имена полей, используя первую строку в файле CSV.
Здесь в примере предположим, что наше имя файла резервной копии - userdetails.csv, расположенное в папке / backup_data / backup /, имя БД - myinfo, а имя коллекции - userdetails.
Здесь, в приведенном ниже примере, имя коллекции не указано, и была указана опция --ignoreBlanks, которая будет игнорировать пустые столбцы.
MongoDB — одна из самых популярных систем управления базами данных NoSQL. Она отличается масштабируемостью, отказоустойчивостью, надежностью и удобством в использовании. В этом учебном модуле вы создадите резервную копию, восстановите и перенесете образец базы данных MongoDB.
Импортирование и экспорт базы данных подразумевают работу с данными в формате, приемлемом для чтения, который также совместим с другими программными продуктами. Операции резервного копирования и восстановления MongoDB создают или используют специальные двоичные данные MongoDB, в результате чего не только обеспечиваются согласованность и целостность данных, но и сохраняются специальные атрибуты MongoDB. Таким образом, для переноса данных предпочтительнее использовать процесс резервного копирования и восстановления, если исходные и целевые системы совместимы друг с другом.
Предварительные требования
Перед выполнением этого учебного модуля необходимо следующее:
-
, настроенный в соответствии с руководством по начальной настройке сервера Ubuntu 20.04, в том числе пользователь без привилегий root с привилегиями sudo и брандмауэр.
- СУБД MongoDB, установленная и настроенная согласно указаниям статьи Установка MongoDB в Ubuntu 20.04.
- Пример базы данных MongoDB, импортированной в соответствии с инструкциями учебного модуля Импорт и экспорт базы данных MongoDB.
Если не указано иное, все команды в этом учебном модуле, для которых требуются привилегии root, должны выполняться пользователем без привилегий root с привилегиями sudo.
Шаг 1 — Использование JSON и BSON в MongoDB
Прежде чем продолжить прохождение этого учебного модуля, важно понять некоторые базовые моменты. Если у вас есть опыт работы с другими системами баз данных NoSQL, такими как Redis, вы можете найти некоторое сходство с ними при работе с MongoDB.
MongoDB использует для хранения информации форматы JSON и BSON (двоичный JSON). JSON - это удобный для прочтения человеком формат, идеально подходящий для экспорта и импорта данных. Вы сможете управлять экспортированными данными в этом формате с помощью любого инструмента, поддерживающего JSON, включая простой текстовый редактор.
Пример документа JSON:
С JSON удобно работать, но этот формат поддерживает не все типы данных, доступные в BSON. Это означает, что при использовании JSON возможна так называемая потеря корректности информации. Для создания резервных копий и восстановления, лучше использовать двоичный формат BSON.
Во-вторых, вам не нужно беспокоиться о явном создании базы данных MongoDB. Если база данных, которую вы указываете для импорта, еще не существует, она создается автоматически. Еще лучше обстоят дела со структурой коллекций (таблицы базы данных). В отличие от других СУБД, в MongoDB структура создается автоматически при вставке первого документа (строка базы данных).
В-третьих, в MongoDB операции чтения или вставки больших объемов данных, таких как в задачах этого учебного модуля, могут потреблять много ресурсов процессора, памяти и дискового пространства. Это крайне важно, поскольку MongoDB часто используется для крупных баз данных и больших данных. Самое простое решение этой проблемы — выполнять экспорт и создавать резервные копии в ночное время или в периоды низкой нагрузки.
В-четвертых, согласованность информации может представлять проблему, если у вас загруженный сервер MongoDB, где информация может изменяться при экспорте или резервном копировании базы данных. Одно из возможных решений этой проблемы — репликация, и вы можете использовать его, когда лучше освоитесь с MongoDB.
Хотя вы можете использовать функции импорта и экспорта для резервного копирования и восстановления данных, существуют и лучшие способы обеспечения полной целостности данных в базах данных MongoDB. Чтобы создать резервную копию данных, вам следует использовать команду mongodump . Для восстановления используйте команду mongorestore . Давайте посмотрим, как они работают.
Шаг 2 — Использование mongodump для резервного копирования базы данных MongoDB
Вначале поговорим о резервном копировании базы данных MongoDB.
Одним из самых важных аргументов команды mongodump является аргумент --db , указывающий имя базы данных, резервную копию которой вы хотите создать. Если вы не укажете имя базы данных, mongodump создаст резервные копии всех ваших баз данных. Второй важный аргумент — это аргумент --out , определяющий каталог, в котором будут сохранены данные. Давайте создадим резервную копию базы данных newdb и сохраним ее в каталоге /var/backups/mongobackups . В идеальной ситуации все наши резервные копии будут содержаться в каталоге с текущей датой /var/backups/mongobackups/10-29-20 .
Вначале создайте каталог /var/backups/mongobackups :
Затем запустите команду mongodump :
Результат должен будет выглядеть следующим образом:
Обратите внимание, что в вышеуказанном пути каталога мы использовали формат date +"%m-%d-%y" , который автоматически получает текущую дату. Это позволяет нам размещать резервные копии в каталогах вида /var/backups/ 10-29-20 / . Это особенно удобно для автоматизации резервного копирования.
Теперь у вас имеется полная резервная копия базы данных newdb в каталоге /var/backups/mongobackups/ 10-29-20 /newdb/ . В этой резервной копии есть все необходимое для правильного восстановления newdb и сохранения так называемой «корректности».
Как правило, резервное копирование выполняется регулярно, и обычно это делается в периоды наименьшей нагрузки на сервер. Вы можете задать команду mongodump как задачу планировщика (cron), чтобы она выполнялась регулярно, например, каждый день в 03:03.
Для этого откройте редактор crontab:
Обратите внимание, что при запуске sudo crontab вы будете редактировать кроны пользователя root. Рекомендуется сделать именно это, потому что если вы настроите кроны для своего пользователя, они могут выполняться неправильно, особенно если для вашего профиля sudo требуется проверка пароля.
Вставьте в командную строку crontab следующую команду mongodump :
В приведенной выше команде мы целенаправленно опускаем аргумент --db , потому что обычно мы хотим создать резервные копии всех наших баз данных.
Если резервных копий будет слишком много, а базы данных MongoDB будут слишком большими, у вас быстро закончится место на диске. В связи с этим, также рекомендуется регулярно удалять старые резервные копии или сжимать их.
Например, вы можете использовать следующую команду bash для удаления всех резервных копий старше семи дней:
Аналогично предыдущей команде mongodump , вы можете добавить эту команду как задание cron. Его следует запускать непосредственно перед началом следующего резервного копирования, например, в 03:01. Для этого снова откройте crontab:
Вставьте следующую строку:
Сохраните и закройте файл.
Выполнение всех задач, описанных на этом шаге, обеспечит надлежащее решение резервного копирования для ваших баз данных MongoDB.
Шаг 3 — Использование mongorestore для восстановления и переноса базы данных MongoDB
При восстановлении базы данных MongoDB из предыдущей резервной копии вы получите точную копию информации MongoDB на определенный момент времени, включая все индексы и типы данных. Это особенно полезно, если вы хотите выполнить миграцию ваших баз данных MongoDB. Для восстановления MongoDB мы будем использовать команду mongorestore , которая работает с двоичными резервными копиями, которые производятся mongodump .
Давайте продолжим наши примеры с базой данных newdb и посмотрим, как мы можем восстановить ее с предыдущей резервной копии. Вначале мы укажем имя базы данных с аргументом --nsInclude . Если использовать newdb.* , мы восстановим все коллекции. Для восстановления отдельной коллекции, например restaurants , следует использовать newdb.restaurants .
Используя аргумент --drop мы обеспечим предварительное отбрасывание целевой базы данных так, чтобы резервная копия была восстановлена в чистой базе данных. Как последний аргумент мы зададим каталог последней резервной копии, который будет выглядеть примерно так: /var/backups/mongobackups/ 10-29-20 /newdb/ .
Когда вы создадите резервную копию с временной меткой, вы можете восстановить ее с помощью следующей команды:
Результат должен будет выглядеть следующим образом:
В примере выше мы восстанавливаем данные на том же сервере, на котором создали резервную копию. Если вы хотите перенести данные на другой сервер, используя эту же методику, вам следует скопировать на другой сервер каталог резервной копии, в нашем случае это /var/backups/mongobackups/ 10-29-20 /newdb/ .
Заключение
Вы выполнили ряд важных задач по резервному копированию, восстановлению и миграции баз данных MongoDB. Производственный сервер MongoDB нельзя использовать без надежной стратегии резервного копирования, такой как описана здесь.
Вышеуказанные два набора команд используются для резервного копирования и восстановления.
1.1.1 Инструмент экспорта монгоэкспорта
Инструмент mongoexport в Mongodb может экспортировать коллекцию в файл в формате JSON или CSV. Вы можете указать экспортируемые элементы данных через параметры или экспортировать данные в соответствии с указанными условиями.
Параметры этой команды следующие:
параметр
Описание параметра
-h
Укажите IP хоста базы данных
-u
Укажите имя пользователя базы данных
-p
Укажите пароль базы данных
-d
Укажите название базы данных
-c
Укажите название коллекции
-f
Укажите, какие столбцы экспортировать
-o
Укажите имя файла для экспорта
-q
Укажите условия фильтрации для экспортируемых данных
--type
Укажите тип файла
--authenticationDatabase
Наименование проверочных данных
mongoexportРезервное копирование
Резервное копирование огромной коллекции в библиотеке приложений
Примечание. Имя файла резервной копии можно настроить, а данные в формате JSON экспортируются по умолчанию.
Экспорт данных в формате CSV
1.1.2 Импорт инструмента mongoimport
Инструмент mongoimport в Mongodb может импортировать содержимое файла определенного формата в указанную коллекцию. Инструмент может импортировать данные в формате JSON или CSV.
Параметры этой команды следующие:
параметр
Описание параметра
-h
Укажите IP хоста базы данных
-u
Укажите имя пользователя базы данных
-p
Укажите пароль базы данных
-d
Укажите название базы данных
-c
Укажите название коллекции
-f
Укажите, какие столбцы экспортировать
-o
Укажите имя файла для экспорта
-q
Укажите условия фильтрации для экспортируемых данных
--drop
Удалить оригинал перед вставкой
--headerline
Укажите, что первая строка является именем столбца и не нуждается в импорте.
-j
Количество операций вставки, запущенных одновременно (по умолчанию 1), параллельно
--authenticationDatabase
Наименование проверочных данных
mongoimportВосстановительная практика
Импортировать ранее восстановленные данные
Импортировать ранее восстановленные данные формата CSV
1.1.3 [Эксперимент] Перенос данных mysql в базу данных mongodb
Экспортируйте пользовательскую таблицу под mysql в базе данных mysql.
Просмотр экспортированного контента
Импорт данных в mongodb
Просмотр импортированного контента
Миграция данных завершена.
1.2 Mongodump / Mongorestore практика
1.2.1 mongodump средство резервного копирования
Параметры mongodump в основном совпадают с параметрами mongoexport
параметр
Описание параметра
-h
Укажите IP хоста базы данных
-u
Укажите имя пользователя базы данных
-p
Укажите пароль базы данных
-d
Укажите название базы данных
-c
Укажите название коллекции
-o
Укажите имя файла для экспорта
-q
Укажите условия фильтрации для экспортируемых данных
--authenticationDatabase
Наименование проверочных данных
--gzip
Сжатый во время резервного копирования
--oplog
use oplog for taking a point-in-time snapshot
mongodumpПараметр практики
Полная резервная копия базы данных
Резервная тестовая библиотека
Сделайте резервную копию огромной коллекции под тестовой библиотекой
Библиотека сжатых резервных копий
Сжатая резервная копия одной таблицы
1.2.2 Практика восстановления Mongorestore
Mongorestore похож на параметры моноимпорта
параметр
Описание параметра
-h
Укажите IP хоста базы данных
-u
Укажите имя пользователя базы данных
-p
Укажите пароль базы данных
-d
Укажите название базы данных
-c
Укажите название коллекции
-o
Укажите имя файла для экспорта
-q
Укажите условия фильтрации для экспортируемых данных
--authenticationDatabase
Наименование проверочных данных
--gzip
Сжатый во время резервного копирования
--oplog
use oplog for taking a point-in-time snapshot
--drop
Удалить предыдущую коллекцию при восстановлении
Восстановление отдельной библиотеки в полной резервной копии библиотеки (на основе предыдущей полной резервной копии библиотеки)
Восстановить тестовую библиотеку
Восстановите обширную коллекцию под тестовой библиотекой
--drop параметр практика восстановления
1.2.3 Сравнение mongoexport / mongoimport и mongodump / mongorestore
- Импорт / экспорт mongoexport / mongoimport осуществляется в формате JSON, а импорт / экспорт mongodump / mongorestore - в формате BSON.
- JSON читается, но имеет большой размер, а BSON - это двоичный файл, который является небольшим, но почти нечитаемым для людей.
- В некоторых версиях mongodb формат BSON может отличаться в разных версиях, поэтому использование mongodump / mongorestore между различными версиями может оказаться невозможным, в зависимости от совместимости между версиями. Когда невозможно использовать BSON для миграции данных между версиями, можно использовать формат JSON, mongoexport / mongoimport. Кросс-версия mongodump / mongorestore не рекомендуется. Если вы хотите это сделать, проверьте документацию, чтобы убедиться, что две версии совместимы (большую часть времени).
- Хотя JSON обладает хорошей универсальностью, он сохраняет только часть данных и не сохраняет другую основную информацию, такую как индексы и учетные записи. Будьте осторожны при использовании.
1.3 Оплог в MongoDB
1.3.1 Что такое оплог
MongoDB Replication использует журнал для хранения операций записи, который называется oplog.
По умолчанию oplog выделяет 5% свободного дискового пространства. Вообще говоря, это разумная настройка. Размер журнала oplog можно изменить с помощью mongod --oplogSize.
oplogЭто ограниченная коллекция, из-за характеристик оплог (не может заполнить диск слишком много, фиксированный размер), MongoDB изобрела ограниченную коллекцию (этот журнал на самом деле является причиной создания ограниченных коллекций). Набор фиксированного размера, oplogSizeMB: 2048, оплог является идемпотентом и не будет выполняться повторно после выполнения.
Стоит отметить, что оплогНабор для репликиИли хозяин / рабЗависит от режима (автономныйРежим для запуска mongodbНе рекомендуется).
Оплог есть в местной библиотеке: местный. oplog
Под архитектурой master / slave: local.oplog. $ Main;
Под репликой задается архитектура: local.oplog.rs
Основная функция этого параметра заключается в создании файла oplog.bson при экспорте и сохранении всех оплогов между моментом запуска дампа и его окончанием.
Проще говоря, oplog - это ограниченная коллекция в наборе реплик, размер по умолчанию составляет 5% дискового пространства (может быть изменен параметром --oplogSizeMB) и находится в db.oplog.rs в локальной библиотеке. Интерес может посмотреть на то, что в нем.
Он записывает все операции изменения (вставки / обновления / удаления) базы данных во всем экземпляре mongod за определенный период времени. Когда пространство исчерпано, новая запись автоматически перезаписывает самую старую запись.
Таким образом, по оси времени охват оплога, вероятно, выглядит следующим образом:
Его покрытие называется временным окном оплога. Следует отметить, что, поскольку oplog является постоянным набором громкости, диапазон, который может охватывать временное окно, будет варьироваться в зависимости от количества обновлений в единицу времени. Хотите просмотреть текущее оценочное значение временного окна оплога.
Оплог имеет очень важную особенность -Идемпотентность (idempotent）, То есть, когда набор данных воспроизводится с использованием операции, записанной в oplog, независимо от того, сколько раз он воспроизводится, результат будет одинаковым.
Например, если в oplog записана операция вставки, иВы не получите две идентичные записи в базе данных, потому что вы проиграли дважды, Это важная особенность.
1.3.2 Роль oplog.bson
Параметры, связанные с оплогом
параметр
Описание параметра
--oplogReplay
Воспроизведите содержимое операции в oplog.bson
--oplogLimit
При использовании с --oplogReplay вы можете ограничить время воспроизведения
Первое, что нужно понять, это то, что данные зависят друг от друга, например, заказ хранится в наборе A, а все детали заказа хранятся в наборе B. Тогда только один заказ имеет полные данные - это правильное состояние.
Предположим, что в любой момент времени данные наборов A и B полностью соответствуют и значимы (это нелегко для нереляционных баз данных, и такая структура данных неприемлема для MongoDB. Но это Мы предполагаем, что это условие выполняется), тогда, если A находится в момент времени x, а B находится в момент времени y после x, можно представить, что данные в A и B, скорее всего, не соответствуют и теряют смысл.
Процесс mongodump не блокирует базу данных, чтобы гарантировать, что вся библиотека заморожена в фиксированный момент времени, что часто недопустимо в бизнесе. Следовательно, в конечном результате дампа набор A находится в 10 часов, а набор B - в 10 часов.
Даже если такая резервная копия будет восстановлена, мыслимые результаты могут иметь ограниченное значение.
Тогда значение вышеописанного oplog.bson отражено здесь. Если на основе данных дампа повторить все операции, записанные в журнале операций, данные в это время могут представлять состояние базы данных на определенный момент времени в конце дампа.
1.3.3 [Симуляция] Использование mongodump
Во-первых, мы моделируем набор foo, который непрерывно выполняет операции вставки,
Затем смоделируйте mongodump один раз во время процесса вставки и укажите --oplog.
нота: Опция --oplog действительна только для всего экспорта библиотеки, поэтому вы не можете указать опцию -d.
Поскольку вся операция изменения экземпляра будет сосредоточена в коллекции oplog.rs в локальной библиотеке.
Согласно вышесказанному, система времени из дампа будет записывать все оплоги в oplog.bson, поэтому мы получаем эти файлы:
Посмотреть первый и последний контент в oplog.bson
Окончательные сброшенные данные не являются ни начальным состоянием, ни конечным состоянием, а случайным состоянием в середине. Это именно потому, что коллекция постоянно меняется.
Используйте Mongorestore для восстановления
Обратите внимание на желтый шрифт.В первом предложении указано, что в коллекции clsn.clsn1 было восстановлено 3165 документов, а во втором - все операции в оплоге были воспроизведены. Таким образом, теоретически clsn1 должен иметь 16857 документов (3165 от clsn.bson, остальные от oplog.bson). Проверьте это:
Это настоящая роль mongodump с оплогом.
1.3.4 Оплог из других мест
Есть два источника оплога:
1. Добавьте параметр --oplog, когда mongodump, автоматически генерируемый оплог, таким образом, оплог напрямую --oplogReplay может восстановить
2. Из других мест, кроме --oplog, оплог получен искусственно
Поскольку данные из дампа могут быть использованы для восстановления базы данных до определенного состояния с помощью oplog, есть ли у вас копия данных дампа, скопированная с определенного момента времени, плюс оплог после запуска дампа, если этот журнал достаточно длинный, да Разве невозможно восстановить базу данных до какого-либо последующего состояния?Да!
Фактически, набор реплик - это точно механизм работы на основе оплогов. Когда вторичное соединение присоединяется к реплике, установленной в первый раз, начальная синхронизация эквивалентна выполнению mongodump, после чего ему нужно только непрерывно синхронизировать и воспроизводить данные в oplog.rs для достижения цели синхронизации вторичного и первичного.
Поскольку oplog всегда существовал в oplog.rs, зачем нам указывать --oplog при mongodump? Не может ли он быть взят из oplog.rs при необходимости? Ответ - да, вы можете просто сбросить данные без оплога.
Он может быть взят из oplog.rs при необходимости. Но предпосылка состоит в том, что временное окно оплога должно покрывать время начала дампа.
Своевременное моделирование сценария восстановления
Имитация производственной среды
Резервное копирование при вставке данных
После завершения резервного копирования выполните неправильную операцию
Резервное копирование файла oplog.rs
Восстановите данные, сохраненные до
Перехватить оплог и найти момент случайного удаления
Скопируйте оплог в резервную папку
Восстановите и добавьте ошибочно удаленные точки (лимит), найденные ранее
На этом этапе восстановление завершено
1.3.5 Руководство по резервному копированию mongodb
MongoDB может выполнять операции восстановления на определенный момент времени только для реплики или главного / подчиненного, если выполнены следующие критерии:
- Интервал между любыми двумя резервными копиями данных (от первой резервной копии до второй резервной копии) не может превышать охват временного окна оплога.
- На основе последнего резервного копирования данных выполняется полное резервное копирование оплога до того, как временное окно оплога не выскользнет из момента времени, когда заканчивается последнее резервное копирование. Полностью учтите время, необходимое для резервного копирования оплога, взвесьте пространство на сервере, чтобы определить интервал резервного копирования оплога.
Вопросы, требующие внимания при практическом применении:
- Учитывая, что временное окно оплога является изменяющимся значением, обратите внимание на конкретное время временного окна оплога.
- Должно быть достаточно времени, чтобы выгрузить требуемые файлы oplog.rs, прежде чем выдвинуть действительное время рядом с временным окном oplog. Пожалуйста, зарезервируйте достаточно времени и не выполняйте резервное копирование после заполнения временного окна.
- Когда происходит авария, первым делом нужно остановить операцию записи в базу данных, в прошлом оплог выпал из временного окна. В частности, операция удаления (<>), подобная описанной выше, мгновенно вставит большое количество d записей, что приведет к быстрому выходу оплога из временного окна.
Рекомендации по резервному копированию сегментированных кластеров
1. Что сделать резервную копию?
（1）configserver
(2) Каждый осколок
2. На что следует обратить внимание во время резервного копирования?
(1) Метаданные и реальные данные должны иметь эквивалентность (проблемы миграции blancer приведут к несовместимому резервному копированию конфигурации и сегментов)
(2) Различные части конечного момента времени резервного копирования отличаются, восстановленные данные проблематичны.
1.4 МонгоБД мониторинг
Отслеживайте и своевременно получайте информацию о состоянии приложения и обнаруживайте ее вовремя, когда возникнет проблема.
Процессор, память, дисковый ввод-вывод, приложение (MongoDB), мониторинг процесса (ps -aux), мониторинг журнала ошибок
1.4.1 Метод мониторинга кластера MongoDB
Просмотр текущего состояния экземпляра (использование памяти, блокировка, подключение пользователя и т. Д.)
Выполнить анализ производительности, сравнивая снимки до и после
Показать описание информации:
1.4.2 mongostat
Состояние базы данных в режиме реального времени, чтение и запись, блокировка, попадание в индекс, прерывание сбоя страницы, очередь ожидания чтения и записи и т. Д.
Обновляйте значение состояния раз в секунду и можете обеспечить хорошую читаемость, благодаря этим параметрам можно наблюдать общую производительность системы MongoDB.
параметр
Описание параметра
insert
Вставок в секунду
query
Запросов в секунду
update
Обновлений в секунду
delete
Удаляет в секунду
conn
qr|qw
Длина очереди клиентских запросов (чтение | запись) предпочтительно равна 0, если происходит накопление, обработка базы данных идет медленно.
ar|aw
Количество активных клиентов (читай | пиши)
time
mongotopОписание команды:
1.4.3 команды уровня дБ
Проверьте, какую операцию выполняет база данных.
Используется для просмотра длительных процессов.
Фильтровать по (продолжительности выполнения, операции, блокировке, длительности блокировки ожидания) и другим условиям.
Если обнаружено, что операция слишком длинная и база данных застряла, вы можете использовать эту команду, чтобы убить его:> db.killOp (608605)
Установить медленный журнал на уровне сервера
0: не сохранять
1: Сохранить журнал медленных запросов
2: Сохранить все журналы запросов
Примечание. Уровень соответствует текущей базе данных, а пороговое значение является глобальным.
Просмотр статуса профилирования
Просмотр медленного запроса: system.profile
Закрыть профилирование
1.5 Схема оптимизации производительности кластера MongoDB
1.5.1 Направление оптимизации
Аппаратное обеспечение (память, SSD)
Сжатие данных
Добавить новые машины, новые наборы реплик
Выбор ключа осколка кластера
настройка размера куска
Предварительная обработка (предварительно выделенное пространство для хранения)
1.5.2 Механизм хранения
WiredTiger - это стандартное ядро хранилища после 3.0. Мелкозернистое управление параллелизмом и сжатие данных обеспечивают более высокую производительность и эффективность хранения. MMAPv1 по умолчанию до 3.0 также повышает производительность.
Несколько наборов тактовых запоминающих устройств могут быть объединены в наборе репликации MongoDB, и каждый экземпляр реализует различные требования приложения.
1.5.3 Другие предложения по оптимизации
Сжатие данных
Pre-Sharding
Добавить новые машины, новые наборы реплик
Выбор ключа осколка кластера
настройка размера куска
Если журнал и файл данных находятся на одном и том же блочном устройстве, файлы данных и журнал могут претендовать на конечное число доступных ресурсов ввода-вывода. Перемещение журнала на отдельное устройство может увеличить емкость операций записи.
Таким образом, похоже, что каталог журнала жестко закодирован как подкаталог каталога базы данных. Я мог бы использовать символическую ссылку, чтобы поместить его на другой диск, но мне кажется, что я делаю что-то не так.
1 ответ
я пытаюсь записать содержимое очень большого массива символов на жесткий диск. У меня есть следующий массив (на самом деле его размер будет очень большим) Я использую массив как битовый массив, и после вставки в него заданного количества битов я должен скопировать его содержимое в другой массив и.
У меня есть mongodb v2.4.6, работающий на ubuntu 13.04. Известно, что mongodb хранит все данные в /var/lib/mongodb. Теперь mongodb заканчивается на жестком диске. К счастью, я получил новый жесткий диск, который установлен, fdisked, formated и получил имя /dev/sda3. к сожалению, я не знаю, как.
Вы бы mount другой том в жестко закодированном месте.
Похожие вопросы:
Мне любопытно узнать, как переместить электронные письма из определенной подпапки на мой жесткий диск. В основном мой почтовый ящик содержит около 20 подпапок. Я хочу иметь возможность перемещать.
Виртуальный контроллер хранения Box SAS позволяет работать быстрее IO, чем SATA: SAS-это то же самое, что SATA-это то же самое, что IDE: он обеспечивает более надежные и быстрые соединения. из.
Этот вопрос касается двоичных журналов MySQL. Нам нужно переместить двоичный журнал на другой жесткий диск. Какое изменение конфигурации требуется в MySQL? В настоящее время двоичные журналы идут в.
я пытаюсь записать содержимое очень большого массива символов на жесткий диск. У меня есть следующий массив (на самом деле его размер будет очень большим) Я использую массив как битовый массив, и.
У меня есть mongodb v2.4.6, работающий на ubuntu 13.04. Известно, что mongodb хранит все данные в /var/lib/mongodb. Теперь mongodb заканчивается на жестком диске. К счастью, я получил новый жесткий.
У меня есть узел и npm с существующими пакетами, установленными в настоящее время на диск C на Windows. Мой диск C - это диск SSD с небольшим количеством места. Как я могу переместить установку узла.
У меня есть mongodb, работающий на windows azure linux vm, База данных находится на системном диске, и я хочу переместить ее на другой жесткий диск, так как там недостаточно места. Я узнал об этом.
Как я могу припарковать жесткий диск с помощью C? Парк: чтобы переместить головку жесткого диска с жесткого диска в безопасное место. Это было сделано для того, чтобы убедиться, что головка не.
Я только что обновил Windows 10 в своем ноутбуке до Redstone 1. Поэтому я провел тест подсистемы Linux (она же WSL, LXSS или Bash на Windows). В принципе, все в порядке, но есть проблема, что RootFS.
Я перепробовал множество учебников, которые нашел в интернете, о том, как изменить местоположение моего JENKINS_HOME. Я все еще сталкивался с этими ошибками: В приложении jenkins - не удалось.
Читайте также: