Миграция всей платформы

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

Описанные ниже шаги одинаково применимы к установкам на Linux и Windows. Более того, их можно использовать для миграции с Windows на Linux или наоборот.

Шаг 1 — предварительные требования

Прежде всего необходимо подготовить сервер (или серверы) для работы платформы. В общем случае производительность в продакшене не должна быть ниже существующей, т.е. необходимо убедиться, что сервер имеет такое же или большее количество ядер CPU, объём ОЗУ и дискового пространства. Сетевая инфраструктура должна обеспечивать достаточную скорость интернета, а те же порты должны быть открыты для работы платформы, что и на предыдущем сервере.

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

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

• Java SE Development Kit (JDK) 17

• MySQL Server 8.0

• NGINX 1.2 или новее

Здесь важны только основные версии; различие в минорных версиях не влияет на функциональность.

Шаг 2 — миграция базы данных

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

Основная стратегия — сделать резервную копию существующей базы данных, затем перенести её на новый сервер и восстановить базу данных из резервной копии там. Это простой, надёжный и проверенный способ, но его недостаток — длительный простой, который увеличивается с ростом размера базы данных.

Если на старом сервере есть отдельный диск для размещения базы данных, вы можете просто отмонтировать его и затем примонтировать на новом сервере. Таким образом база данных переместится практически мгновенно. К сожалению, этот метод работает только при виртуализации в рамках одного дата-центра или у одного облачного провайдера (AWS, Azure и т.д.). При смене дата-центров этот метод неприменим.

Для больших баз данных и в случаях, когда минимизация простоя критична, следует использовать продвинутый метод, известный как репликация базы данных. В этом случае на целевом сервере создаётся реплика базы данных, которая постепенно заполняется данными и работает как slave. Эта процедура медленная, но позволяет главной базе данных продолжать работу без простоев. Когда slave догоняет master по объёму данных, остаётся лишь переключить master-slave, и таким образом база данных полностью мигрирует на новый сервер со всеми актуальными данными.

Репликация не является стандартной функцией MySQL, поэтому для этой цели требуется использование стороннего программного обеспечения. Существуют различные решения, и у каждого системного администратора есть свои предпочтения в инструментах. Наш предпочтительный инструмент — XtraBackup приложение от Percona, которое позволяет выполнять «горячие» резервные копии и репликацию рабочей базы данных.

При копировании базы данных лицензионный ключ повреждается, поскольку он применим только на одном сервере. Возможно, потребуется отдельно сохранить резервную копию лицензионного ключа перед переключением на базу данных на новом сервере. Это строка-символ в поле fingerprint строке таблицы google.variables Необходимо сохранить это значение и подставить его в том же месте перед запуском новой базы данных. Если ключ не был сохранён и был повреждён, техническая поддержка Navixy перевыпустит его бесплатно.

Шаг 3 — миграция сервисов

Единственное постоянно меняющееся место платформы — это база данных. В то же время сервисы платформы и веб-сайт остаются статичными, и изменения происходят только при обновлениях платформы. Поэтому всё, что потребуется — скопировать необходимые директории вместе с их содержимым в те же пути.

В Linux это:

• /home/java/

• /var/www

• /etc/nginx/ (все конфигурации и SSL-сертификаты)

В Windows это:

• C:\java

• C:\nginx

После этого необходимо настроить запуск сервисов Navixy. В Linux это делается с помощью systemd, в Windows с помощью Java Wrapper. Конфигурации на старом и новом сервере должны быть одинаковыми. Если вы не знаете, как настроить эти сервисы, свяжитесь с технической поддержкой Navixy.

Если операционные системы на старом и новом серверах различаются (например, при миграции с Windows на Linux), то конфигурации Java-сервисов будут полностью отличаться, как и конфигурация веб-сервера Nginx. Обратитесь в поддержку Navixy за деталями настройки сервисов.

Шаг 4 — смена IP-адреса

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

Для этого нужно перенести публичный IP-адрес со старого сервера на новый.

Если перенос IP-адреса невозможен (что может иметь место при смене дата-центров), необходимо внести изменения в конфигурацию DNS, привязав ваш домен к новому публичному IP-адресу сервера.

Если IP-адрес изменится, все устройства, настроенные на работу по IP, перестанут передавать данные на сервер и потребуют перенастройки. Все устройства, настроенные на использование домена, будут продолжать работать как прежде.

Заключительные шаги

После смены IP-адреса необходимо остановить работающие java-сервисы на старом сервере.

Затем можно запустить все сервисы на новом сервере. На этом миграция завершена, и вы можете проверить доступность перенесённой платформы.

Если в ходе или после миграции вы столкнулись с какими-либо проблемами, вы можете обратиться в техническую поддержку Navixy по адресу [email protected] за дальнейшими консультациями.