> 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/pt-br/on-premise/how-to-guide/maintenance/migration/entire-platform-migration.md). # Migração da plataforma inteira Migre a plataforma completa Navixy On-Premise para um novo servidor. Abrange pré-requisitos, estratégias de migração do banco de dados, transferência de serviços, gerenciamento de IP e procedimentos de inicialização. A migração da plataforma consiste essencialmente na migração do banco de dados e na migração dos serviços. Nesse caso, você precisa instalar todo o software auxiliar no novo servidor e, em seguida, mover o banco de dados e copiar os serviços. As etapas descritas abaixo se aplicam igualmente a instalações em Linux e Windows. Além disso, elas podem ser usadas para migração do Windows para o Linux, ou vice-versa. ## Etapa 1 - pré-requisitos Antes de mais nada, você precisa preparar o(s) servidor(es) para executar a plataforma. Em geral, a capacidade de produção não deve ser inferior à existente, ou seja, você precisa garantir que o servidor tenha a mesma quantidade ou uma quantidade superior de núcleos de CPU, RAM e espaço em disco. A infraestrutura de rede deve ter velocidade de internet suficiente, e as mesmas portas devem estar abertas para a plataforma funcionar, assim como no servidor anterior. Em geral, ao calcular os parâmetros do novo servidor, você pode se basear nos [requisitos de hardware](/docs/on-premise/pt-br/on-premise/how-to-guide/requirements/server-hardware.md) informados na seção correspondente do nosso site. Do ponto de vista do software, o mesmo software de terceiros deve ser instalado, assim como no servidor de origem. Isso inclui: * Java SE Development Kit (JDK) 17 * MySQL Server 8.0 * NGINX 1.2 ou mais recente Aqui, apenas as versões principais importam, e a diferença nas versões secundárias não terá efeito na funcionalidade. ## Etapa 2 - migração do banco de dados Esta é a etapa mais longa e que mais consome recursos, porque o banco de dados cresce ao longo do tempo e pode atingir um tamanho significativo. A estratégia básica aqui é fazer um backup do banco de dados existente, depois movê-lo para um novo servidor e restaurar o banco de dados a partir do backup lá. Este é um método simples, confiável e comprovadamente funcional, mas a desvantagem é o longo tempo de inatividade, que fica ainda maior quanto maior for o banco de dados. Se você tiver um disco separado no servidor antigo para hospedar o banco de dados, pode simplesmente desmontá-lo e montá-lo no novo servidor. Dessa forma, o banco de dados será movido quase instantaneamente. Infelizmente, esse método só funciona ao virtualizar dentro do mesmo data center ou provedor de nuvem (AWS, Azure etc.). Se você mudar de data center, esse método não se aplica. Para bancos de dados grandes e em casos em que minimizar o tempo de inatividade é crucial, deve ser usado um método avançado conhecido como replicação de banco de dados. Nesse caso, uma réplica do banco de dados é criada no servidor de destino, e ela é preenchida gradualmente com dados e executa como escrava. Esse procedimento é lento, mas permite que o banco de dados mestre continue a funcionar normalmente, sem tempo de inatividade. Quando a escrava alcançar o mestre em termos de preenchimento, tudo o que resta é trocar mestre e escrava e, assim, o banco de dados será completamente migrado para o novo servidor com todos os dados reais. A replicação não é um recurso padrão do MySQL, portanto requer o uso de software de terceiros para esse fim. Existem diferentes soluções, e cada administrador de sistema tem suas próprias preferências em ferramentas. Nossa ferramenta preferida é [XtraBackup](https://www.percona.com/software/mysql-database/percona-xtrabackup) aplicativo da Percona que permite fazer backups a quente e replicação de um banco de dados em funcionamento. {% hint style="danger" %} Ao copiar o banco de dados, a chave de licença é corrompida porque só pode ser usada em um servidor. Talvez você precise fazer backup da chave de licença separadamente antes de mudar para o banco de dados no novo servidor. Esta é a sequência de símbolos na linha `fingerprint` da `google.variables` da tabela. Você precisa salvar esse valor e substituí-lo no mesmo local antes de iniciar o novo banco de dados. Se a chave não tiver sido copiada em backup e tiver sido corrompida, o suporte técnico da Navixy a reemitirá gratuitamente. {% endhint %} ## Etapa 3 - migração dos serviços O único local da plataforma que muda constantemente é o banco de dados. Ao mesmo tempo, os serviços da plataforma e o site permanecem estáticos, e as alterações ocorrem apenas durante as atualizações da plataforma. Portanto, tudo o que você precisa fazer é copiar os diretórios necessários, incluindo seu conteúdo, para os mesmos caminhos. No Linux, estes são: * /home/java/ * /var/www * /etc/nginx/ (todas as configurações e certificados SSL) No Windows, estes são: * C:\java * C:\nginx Depois disso, você precisa configurar os serviços da Navixy para serem executados. No Linux, isso é feito com *systemd*, no Windows com *Java Wrapper*. As configurações no servidor antigo e no novo devem ser as mesmas. Se você não souber como configurar esses serviços, entre em contato com o suporte técnico da Navixy. {% hint style="info" %} Se os sistemas operacionais nos servidores antigo e novo não forem os mesmos (por exemplo, se você estiver migrando do Windows para o Linux), então as configurações do serviço Java serão completamente diferentes, assim como a configuração do servidor web Nginx. Entre em contato com o suporte da Navixy para obter detalhes sobre como configurar os serviços. {% endhint %} ## Etapa 4 - mudança de endereço IP Depois de mover o banco de dados e todos os serviços para o novo servidor, você precisa tornar esse servidor o principal e disponibilizá-lo para os clientes e seus dispositivos de rastreamento. Para isso, você precisa transferir o endereço IP público do servidor antigo para o novo. Se a transferência do endereço IP for impossível (o que pode ocorrer ao trocar de data center), você precisa fazer alterações na configuração de DNS, vinculando seu domínio ao novo endereço IP público do servidor. {% hint style="info" %} Se o endereço IP mudar, todos os dispositivos configurados para operar por IP deixarão de enviar dados para o servidor e precisarão ser reconfigurados. Todos os dispositivos configurados para usar domínio continuarão funcionando como antes. {% endhint %} ## Etapas finais Depois de mudar o endereço IP, você precisa parar os serviços Java em execução no servidor antigo. Depois, você pode iniciar todos os serviços no novo servidor. Isso conclui a migração e você pode verificar a disponibilidade da plataforma migrada. {% hint style="danger" %} Se você tiver algum problema durante ou após a migração, entre em contato com o suporte técnico da Navixy pelo e-mail para obter mais orientações. {% 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 dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://navixy.com/docs/on-premise/pt-br/on-premise/how-to-guide/maintenance/migration/entire-platform-migration.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. 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.