> For the complete documentation index, see [llms.txt](https://navixy.com/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://navixy.com/docs/on-premise/ru/on-premise/how-to-guide/maintenance/migration/entire-platform-migration.md).

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

Перенесите всю платформу Navixy On-Premise на новый сервер. Описаны предварительные требования, стратегии миграции базы данных, перенос служб, управление IP-адресами и процедуры запуска.

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

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

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

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

В общем случае при расчете параметров нового сервера можно ориентироваться на [требованиях к оборудованию](/docs/on-premise/ru/on-premise/how-to-guide/requirements/server-hardware.md) рекомендации, приведенные в соответствующем разделе нашего сайта.

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

* комплект разработки Java SE (JDK) 17
* MySQL Server 8.0
* NGINX 1.2 или новее

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

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

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

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

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

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

Репликация не является стандартной функцией MySQL, поэтому для этих целей требуется использование стороннего программного обеспечения. Существуют разные решения, и у каждого системного администратора свои предпочтения в инструментах. Наш предпочитаемый инструмент — [XtraBackup](https://www.percona.com/software/mysql-database/percona-xtrabackup) приложение от Percona, которое позволяет делать горячие резервные копии и репликацию работающей базы данных.

{% hint style="danger" %}
При копировании базы данных лицензионный ключ повреждается, потому что его можно использовать только на одном сервере. Возможно, вам потребуется отдельно сохранить резервную копию лицензионного ключа перед переходом на базу данных на новом сервере. Это символьная строка в `fingerprint` строке `google.variables` таблицы. Нужно сохранить это значение и подставить его в то же место перед запуском новой базы данных. Если ключ не был сохранен и оказался поврежден, техподдержка Navixy бесплатно перевыпустит его.
{% endhint %}

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

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

В Linux это:

* /home/java/
* /var/www
* /etc/nginx/ (all configurations and SSL certificates)

В Windows это:

* C:\\\java
* C:\nginx

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

{% hint style="info" %}
Если операционные системы на старом и новом серверах различаются (например, если вы выполняете миграцию с Windows на Linux), конфигурации Java-сервисов будут полностью разными, как и конфигурация веб-сервера Nginx. За подробностями по настройке сервисов обратитесь в поддержку Navixy.
{% endhint %}

## Шаг 4 - изменение IP-адреса

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

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

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

{% hint style="info" %}
Если IP-адрес изменится, все устройства, настроенные на работу по IP, перестанут передавать данные на сервер и потребуют перенастройки. Все устройства, настроенные на использование домена, будут работать как и раньше.
{% endhint %}

## Завершающие шаги

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

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

{% hint style="danger" %}
Если во время миграции или после нее у вас возникнут какие-либо проблемы, вы можете обратиться в техподдержку Navixy по адресу <support@navixy.com> за дополнительной консультацией.
{% endhint %}


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://navixy.com/docs/on-premise/ru/on-premise/how-to-guide/maintenance/migration/entire-platform-migration.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.