One place for hosting & domains

      Миграция

      Создание резервных копий, восстановление и миграция базы данных MongoDB в Ubuntu 20.04


      Автор выбрал COVID-19 Relief Fund для получения пожертвования в рамках программы Write for DOnations.

      Введение

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

      Импортирование и экспорт базы данных подразумевают работу с данными в формате, приемлемом для чтения, который также совместим с другими программными продуктами. Операции резервного копирования и восстановления MongoDB создают или используют специальные двоичные данные MongoDB, в результате чего не только обеспечиваются согласованность и целостность данных, но и сохраняются специальные атрибуты MongoDB. Таким образом, для переноса данных предпочтительнее использовать процесс резервного копирования и восстановления, если исходные и целевые системы совместимы друг с другом.

      Предварительные требования

      Перед выполнением этого учебного модуля необходимо следующее:

      Если не указано иное, все команды в этом учебном модуле, для которых требуются привилегии root, должны выполняться пользователем без привилегий root с привилегиями sudo.

      Шаг 1 — Использование JSON и BSON в MongoDB

      Прежде чем продолжить прохождение этого учебного модуля, важно понять некоторые базовые моменты. Если у вас есть опыт работы с другими системами баз данных NoSQL, такими как Redis, вы можете найти некоторое сходство с ними при работе с MongoDB.

      MongoDB использует для хранения информации форматы JSON и BSON (двоичный JSON). JSON – это удобный для прочтения человеком формат, идеально подходящий для экспорта и импорта данных. Вы сможете управлять экспортированными данными в этом формате с помощью любого инструмента, поддерживающего JSON, включая простой текстовый редактор.

      Пример документа JSON:

      Example of JSON Format

      {"address":[
          {"building":"1007", "street":"Park Ave"},
          {"building":"1008", "street":"New Ave"},
      ]}
      

      С 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:

      • sudo mkdir /var/backups/mongobackups

      Затем запустите команду mongodump:

      • sudo mongodump --db newdb --out /var/backups/mongobackups/`date +"%m-%d-%y"`

      Результат должен будет выглядеть следующим образом:

      Output

      2020-10-29T19:22:36.886+0000 writing newdb.restaurants to 2020-10-29T19:22:36.969+0000 done dumping newdb.restaurants (25359 documents)

      Обратите внимание, что в вышеуказанном пути каталога мы использовали формат 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:

      crontab

      3 3 * * * mongodump --out /var/backups/mongobackups/`date +"%m-%d-%y"`
      

      В приведенной выше команде мы целенаправленно опускаем аргумент --db, потому что обычно мы хотим создать резервные копии всех наших баз данных.

      Если резервных копий будет слишком много, а базы данных MongoDB будут слишком большими, у вас быстро закончится место на диске. В связи с этим, также рекомендуется регулярно удалять старые резервные копии или сжимать их.

      Например, вы можете использовать следующую команду bash для удаления всех резервных копий старше семи дней:

      • find /var/backups/mongobackups/ -mtime +7 -exec rm -rf {} ;

      Аналогично предыдущей команде mongodump, вы можете добавить эту команду как задание cron. Его следует запускать непосредственно перед началом следующего резервного копирования, например, в 03:01. Для этого снова откройте crontab:

      Вставьте следующую строку:

      crontab

      1 3 * * * find /var/backups/mongobackups/ -mtime +7 -exec rm -rf {} ;
      

      Сохраните и закройте файл.

      Выполнение всех задач, описанных на этом шаге, обеспечит надлежащее решение резервного копирования для ваших баз данных MongoDB.

      Шаг 3 — Использование mongorestore для восстановления и переноса базы данных MongoDB

      При восстановлении базы данных MongoDB из предыдущей резервной копии вы получите точную копию информации MongoDB на определенный момент времени, включая все индексы и типы данных. Это особенно полезно, если вы хотите выполнить миграцию ваших баз данных MongoDB. Для восстановления MongoDB мы будем использовать команду mongorestore, которая работает с двоичными резервными копиями, которые производятся mongodump.

      Давайте продолжим наши примеры с базой данных newdb и посмотрим, как мы можем восстановить ее с предыдущей резервной копии. Вначале мы укажем имя базы данных с аргументом --nsInclude. Если использовать newdb.*, мы восстановим все коллекции. Для восстановления отдельной коллекции, например restaurants, следует использовать newdb.restaurants.

      Используя аргумент --drop мы обеспечим предварительное отбрасывание целевой базы данных так, чтобы резервная копия была восстановлена в чистой базе данных. Как последний аргумент мы зададим каталог последней резервной копии, который будет выглядеть примерно так: /var/backups/mongobackups/10-29-20/newdb/.

      Когда вы создадите резервную копию с временной меткой, вы можете восстановить ее с помощью следующей команды:

      • sudo mongorestore --db newdb --drop /var/backups/mongobackups/10-29-20/newdb/

      Результат должен будет выглядеть следующим образом:

      Output

      2020-10-29T19:25:45.825+0000 the --db and --collection args should only be used when restoring from a BSON file. Other uses are deprecated and will not exist in the future; use --nsInclude instead 2020-10-29T19:25:45.826+0000 building a list of collections to restore from /var/backups/mongobackups/10-29-20/newdb dir 2020-10-29T19:25:45.829+0000 reading metadata for newdb.restaurants from /var/backups/mongobackups/10-29-20/newdb/restaurants.metadata.json 2020-10-29T19:25:45.834+0000 restoring newdb.restaurants from /var/backups/mongobackups/10-29-20/newdb/restaurants.bson 2020-10-29T19:25:46.130+0000 no indexes to restore 2020-10-29T19:25:46.130+0000 finished restoring newdb.restaurants (25359 documents) 2020-10-29T19:25:46.130+0000 done

      В примере выше мы восстанавливаем данные на том же сервере, на котором создали резервную копию. Если вы хотите перенести данные на другой сервер, используя эту же методику, вам следует скопировать на другой сервер каталог резервной копии, в нашем случае это /var/backups/mongobackups/10-29-20/newdb/.

      Заключение

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



      Source link

      Миграция данных Redis с помощью репликации в Ubuntu 18.04


      Введение

      Redis — это хранилище данных типа ключ – значение в памяти, известное своей гибкостью, производительностью, широким набором поддерживаемых языков и встроенными функциями, включая репликацию. Репликация — это практика регулярного копирования данных из одной базы в другую для создания копии, которая всегда остается точным дубликатом основной версии. Одним из стандартных вариантов использования репликации в Redis является миграция существующего хранилища данных на новый сервер в случае масштабирования инфраструктуры для повышения производительности.

      В этом обучающем руководстве описан процесс использования встроенных в Redis функций репликации для миграции данных с одного сервера Ubuntu 18.04 («источник») на другой («цель»). Этот процесс подразумевает внесение нескольких изменений в конфигурацию для каждого сервера, настройку целевого сервера для работы в виде копии источника, а затем возврат копии к начальному серверу после завершения миграции.

      Предварительные требования

      Для данного обучающего руководства вам потребуется следующее:

      • Два сервера под управлением Ubuntu 18.04. Каждый сервер должен иметь пользователя с административными привилегиями и брандмауэр, настроенный с помощью ufw. Для настройки этого окружения необходимо следовать указаниям обучающего руководства по начальной настройке сервера Ubuntu 18.04 для обоих серверов.
      • Последняя версия Redis, установленная на каждом сервере. Для настройки воспользуйтесь нашим руководством Установка Redis из источника в Ubuntu 18.04.

      Шаг 1 — (опциональный) Загрузка в экземпляр источника Redis образца данных

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

      Для начала подключитесь к серверу Ubuntu, который вы будете использовать в качестве экземпляр источника Redis, работая с вашим пользователем без прав root: Для начала подключитесь к серверу Ubuntu, который вы будете использовать в качестве исходного экземпляра Redis, который используется на вашем компьютере без прав root:

      • ssh sammy@source_server_ip

      Затем выполните следующую команду для доступа к вашему серверу Redis: Затем выполните следующую команду для доступа к вашему серверу Redis:

      Если вы настроили для вашего сервера аутентификацию по паролю, запустите команду auth, за которой следует ваш пароль Redis:

      • auth source_redis_password

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

      • mset string1 "Redis" string2 "is" string3 "fun!"
      • hmset hash1 field1 "Redis" field2 "is" field3 "fast!"
      • rpush list1 "Redis" "is" "feature-rich!"
      • sadd set1 "Redis" "is" "free!"

      Кроме того, запустите следующие команды expire, чтобы предоставить несколько из этих ключей с задержкой. В результате они станут волатильными, то есть Redis будет удалять их по истечении указанного времени (в данном случае 7500 секунд).

      • expire string2 7500
      • expire hash1 7500
      • expire set1 7500

      Теперь у нас есть несколько примеров данных, которые мы можем экспортировать в целевой экземпляр Redis. Оставьте запрос redis-cli открытым на время, пока мы будем запускать несколько команд из него на следующем шаге, чтобы создать резервную копию этих данных.

      Шаг 2 — Создание резервной копии экземпляра источника Redis

      Каждый раз, когда вы планируете перенести данные с одного сервера на другой, существует риск того, что что-то может пойти не так, а вы в результате потеряете данные. Хотя этот риск невелик, мы будем использовать команду Redis bgsave для создания резервной копии вашей базы данных источника Redis на случай возникновения ошибки в процессе репликации.

      Откройте интерфейс командной строки Redis, если вы этого еще не сделали:

      Если вы настроили для вашего сервера аутентификацию по паролю, запустите команду auth, за которой следует ваш пароль Redis:

      Далее запустите команду bgsave. В результате будет создан снимок текущего набора данных, после чего этот снимок будет экспортирован в файл дампа, хранящийся в рабочем каталоге Redis:

      Примечание: вы можете сделать снимок вашей базы данных Redis с помощью команд save или bgsave. Мы используем команду bgsave, так как команда save запускается синхронно, а значит будет блокировать действия других клиентов, подключенных к базе данных. По этой причине документация команды save рекомендует не запускать ее в производственной среде практически ни при каких условиях.

      Вместо этого предлагается использовать команду bgsave, которая запускается асинхронно. Это приведет к тому, что Redis будет делить работу с базой данных на два процесса: родительский процесс будет продолжать обслуживать клиентов, а дочерний процесс сохранит эту базу перед выходом:

      Обратите внимание, что если клиенты добавляют или изменяют данные во время работы команды bgsave, эти изменения не отражаются в нашем снимке.

      После этого вы можете закрыть подключение к вашему экземпляру Redis, запустив команду exit:

      Если вам потребуется эти данные в будущем, вы сможете найти их в файле дампа данных в рабочем каталоге вашего экземпляра Redis. Вспомните, как согласно предварительным требованиям по установке Redis вы настроили использование /var/lib/redis в качестве рабочего каталога.

      Выведите список содержимого рабочего каталога Redis, чтобы подтвердить, что в нем содержится файл дампа данных:

      Если дамп файл был экспортирован корректно, вы увидите его в выводе этой команды. По умолчанию этот файл имеет имя dump.rdb:

      Output

      dump.rdb

      После подтверждения корректного резервного копирования данных следует настроить сервер источника Redis для приема внешних подключений и возможности выполнения репликации.

      Шаг 3 — Настройка экземпляра источника Redis

      По умолчанию Redis не настроен на прослушивание внешних подключений, то есть любые настроенные вами реплики не смогут синхронизироваться с вашим экземпляром источника, пока вы не обновите конфигурацию. Сейчас мы обновим файл конфигурации экземпляра источника, чтобы разрешить внешние подключения, а также установим пароль, который будет использоваться целевым экземпляром для аутентификации после запуска репликации. Затем мы добавим правило для брандмауэра, чтобы разрешить подключение к порту, на котором запущен Redis.

      Откройте файл конфигурации экземпляра источника Redis в предпочитаемом вами текстовом редакторе. Мы будем использовать nano:

      • sudo nano /etc/redis/redis.conf

      Перейдите в строку, которая начинается с директивы bind. По умолчанию она будет выглядеть следующим образом:

      /etc/redis/redis.conf

      . . .
      bind 127.0.0.1
      . . .
      

      Эта директива привязывает Redis к 127.0.0.1, кольцевому IPv4-адресу, представляющему localhost. Это означает, что этот экземпляр Redis настроен только для прослушивания подключений, поступающих с того же сервера, где он установлен. Чтобы разрешить вашему экземпляру принимать любое подключение, которое поступает на его публичный IP-адрес, например, подключение из целевого экземпляра, добавьте IP-адрес сервера вашего источника Redis после 127.0.0.1​​​. Обратите внимание, что вам не нужно добавлять запятые после 127.0.0.1​​​:

      /etc/redis/redis.conf

      . . .
      bind 127.0.0.1 source_server_IP
      . . .
      

      Далее, если вы еще не сделали этого, воспользуйтесь директивой requirepass для настройки пароля, который должен вводить пользователь, прежде чем он сможет взаимодействовать с данными экземпляра источника. Разкомментируйте директиву и установите сложный пароль или фразу-пароль:

      /etc/redis/redis.conf

      . . .
      requirepass source_redis_password
      . . .
      

      Обязательно запишите пароль, потому что он потребуется вам при настройке целевого сервера.

      После этого вы можете сохранить и закрыть файл конфигурации Redis. Если вы использовали nano, нажмите CTRL+X, Y, затем ENTER.

      Затем перезапустите службу Redis, чтобы эти изменения вступили в силу:

      • sudo systemctl restart redis

      Это все, что вам требуется сделать для настройки Redis, но если вы настроили брандмауэр на вашем сервере, он будет продолжать блокировать любые попытки подключения вашего целевого сервера к источнику. Если вы настроили брандмауэр с помощью ufw, вы можете обновить его, чтобы разрешить подключение к порту, на котором запущен Redis с помощью следующей команды. Обратите внимание, что Redis настроен для использования порта 6379 по умолчанию:

      После внесения этого последнего изменения настройку вашего сервера источника Redis можно считать выполненной. Теперь вы можете перейти к настройке целевого экземпляра Redis, который будет использоваться в качестве копии источника.

      Шаг 4 — Настройка экземпляра цели Redis

      К этому вы настроили экземпляр источника Redis для принятия внешних подключений. Однако, поскольку вы закрыли доступ к источнику, разкомментировав директиву requirepass, ваш целевой экземпляр не сможет копировать данные, хранящиеся в источнике. Теперь вы должны настроить целевой экземпляр Redis, чтобы он мог выполнять аутентификацию при подключении к источнику для осуществления репликации.

      Начнем с подключения к серверу цели Redis с помощью вашего пользователя без прав root:

      • ssh sammy@target_server_ip

      Затем откройте файл конфигурации Redis вашего целевого сервера:

      • sudo nano /etc/redis/redis.conf

      Если вы еще не сделали этого, вам нужно настроить пароль для экземпляра цели Redis с помощью директивы requirepass:

      /etc/redis/redis.conf

      . . .
      requirepass target_redis_password
      . . .
      

      Затем разкомментируйте директиву masterauth и настройте для нее пароль аутентификации экземпляра источника Redis. С помощью этого ваш целевой сервер сможет выполнять аутентификацию в экземпляре источника после обеспечения возможности репликации.

      /etc/redis/redis.conf

      . . .
      masterauth source_redis_password
      . . .
      

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

      Для этого вам потребуется изменить директиву replica-read-only. По умолчанию для нее установлено значение yes, что означает, что она настроена для создания копии “только для чтения”, в которую клиенты не смогут добавлять данные. Установите для этой директивы значение no, чтобы у клиентов появилась возможность записывать данные:

      /etc/redis/redis.conf

      . . .
      replica-read-only no
      . . .
      

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

      Затем перезапустите службу Redis, чтобы эти изменения вступили в силу:

      • sudo systemctl restart redis

      После перезагрузки службы Redis ваш целевой сервер будет готов к тому, чтобы стать копией источника. Чтобы сделать это, вам нужно будет запустить всего одну команду, что мы сделаем в ближайшее время.

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

      Шаг 5 — Запуск и подтверждение репликации

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

      Начнем с открытия интерфейса командной строки Redis на целевом сервере Redis:

      Запустите команду auth для аутентификации подключения:

      Затем превратите целевой экземпляр в копию источника с помощью команды replicaof. Обязательно замените source_server_ip на публичный IP-адрес вашего экземпляра источника, а source_port​​​ на порт, используемый Redis в вашем экземпляре источника:

      • replicaof source_server_ip source_port

      Из запроса запустите следующую команду scan. Она возвращает все ключи, которые хранятся в копии:

      Если репликация работает ожидаемым образом, вы увидите все ключи из экземпляра источника, хранящиеся в копии. Если вы загрузили в источник данные из примера в шаге 1, вывод команды scan будет выглядеть примерно следующим образом:

      Output

      1) "0" 2) 1) "string3" 2) "string1" 3) "set1" 4) "string2" 5) "hash1" 6) "list1"

      Примечание: необходимо помнить, что эта команда может возвращать ключи в другом порядке, отличном от представленного в примере.

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

      Пока ваше подключение открыто, вы можете также подтвердить, что ключи, для которых вы задали истекший срок действия, остаются волатильными. Чтобы сделать это, запустив команду ttl с одним из этих ключей в качестве аргумента:

      Она возвращает количество секунд до того, как ключ будет удален:

      Output

      5430

      Убедившись, что данные в вашем экземпляре источника были корректно синхронизированы с целью, вы можете сделать цель основным экземпляром, запустив команду replicaof еще раз. На этот раз вместо того, чтобы добавлять к replicaof IP-адрес и порт, добавьте no one​​​. Это приведет к тому, что целевой экземпляр остановит синхронизацию с источником немедленно:

      Чтобы подтвердить, что данные, скопированные из источника, сохраняются в цели, перезапустите команду scan, которую вы запускали ранее:

      scan 0
      

      Вы должны увидеть те же самые ключи в выводе этой команде, которые вы видели после запуска scan, когда цель выполняла репликацию источника:

      Output

      1) "0" 2) 1) "string3" 2) "string1" 3) "set1" 4) "string2" 5) "hash1" 6) "list1"

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

      Заключение

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

      Если вы хотите узнать больше о работе с Redis, мы рекомендуем ознакомиться с серией Управление базой данных Redis. Также, если вы хотите переместить ваши данные Redis в экземпляр Redis, управляемый DigitalOcean, воспользуйтесь указаниями нашего руководства.



      Source link