Compartilhar via

Tutorial: Migrar online de uma VM do Azure ou de um servidor PostgreSQL local para o Banco de Dados do Azure para PostgreSQL com o serviço de migração, Versão prévia

  • Artigo

APLICA-SE A: Banco de Dados do Azure para PostgreSQL – Servidor Flexível

Este artigo orienta você na migração de uma instância do PostgreSQL de suas VMs (máquinas virtuais) locais ou do Azure para o servidor flexível do Banco de Dados do Azure para PostgreSQL usando o portal do Azure e a CLI do Azure.

O serviço de migração no Banco de Dados do Azure para PostgreSQL é um serviço totalmente gerenciado integrado ao portal do Azure e à CLI do Azure. Ele foi projetado para simplificar o seu percurso de migração para o servidor flexível do Banco de Dados do Azure para PostgreSQL.

  • Configurar seu Servidor Flexível de Banco de Dados do Azure para PostgreSQL
  • Configurar a tarefa de migração
  • Monitorar a migração
  • Verificar a migração quando concluída

Pré-requisitos

Para iniciar a migração, você precisa dos seguintes pré-requisitos:

Antes de iniciar a migração com o serviço de migração do Banco de Dados do Azure para PostgreSQL, é importante atender aos seguintes pré-requisitos, especificamente projetados para cenários de migração online.

Verificar a versão de origem

A versão do servidor PostgreSQL de origem deve ser 9.5 ou posterior.

Se a versão PostgreSQL de origem for menor que 9.5, atualize-a para 9.5 ou superior antes de iniciar a migração.

Instalar test_decoding – Instalação de origem

  • test_decoding recebe WAL por meio do mecanismo de decodificação lógica e o decodifica em representações de texto das operações executadas.

  • Para obter mais informações sobre o plug-in de decodificação de teste, consulte a documentação do PostgreSQL

Definir a configuração de destino

  • Antes de migrar, o Banco de Dados do Azure para PostgreSQL – Servidor flexível precisa ser criado.
  • O SKU provisionado para o Banco de Dados do Azure para PostgreSQL – servidor flexível deve corresponder à origem.
  • Para criar um novo Banco de Dados do Azure para PostgreSQL, visite Criar uma instância do Banco de Dados do Azure para PostgreSQL – Servidor Flexível
  • Ao migrar entre versões do PostgreSQL (principais ou secundárias), certifique-de que haja compatibilidade entre seu banco de dados e o aplicativo lendo as notas de versão para detectar possíveis alterações interruptivas.

Habilitar CDC como uma origem

  • O plug-in de decodificação lógica test_decoding captura os registros alterados da origem.
  • Na instância postgreSQL de origem, defina os seguintes parâmetros e valores no arquivo de configuração postgresql.conf:
    • Set wal_level = logical
    • Set max_replication_slots como um valor maior que 1; o valor deve ser maior que o número de bancos de dados selecionados para migração.
    • Set max_wal_senders para um valor maior que 1, deve ser definido como pelo menos o mesmo que max_replication_slots, além do número de remetentes já usados por sua instância.
    • O parâmetro wal_sender_timeout termina conexões de replicação que estão inativas por mais tempo do que o número especificado de milissegundos. O padrão para um banco de dados PostgreSQL local é 60000 milissegundos (60 segundos). Definir o valor como 0 (zero) desabilita o mecanismo de tempo limite e é uma configuração válida para migração.

Para impedir que a migração online fique sem espaço, verifique se você tem espaço suficiente no espaço de tabela usando um disco gerenciado provisionado. Para isso, desabilite o parâmetro do servidor azure.enable_temp_tablespaces_on_local_ssdno Servidor flexível durante a migração e restaure-o para o estado original após a migração.

Configurar a instalação da rede

A configuração da rede é crucial para que o serviço de migração funcione corretamente. Verifique se o servidor PostgreSQL de origem consegue se comunicar com o servidor de destino do Banco de Dados do Azure para PostgreSQL. As configurações de rede a seguir são fundamentais para uma migração bem-sucedida.

Para obter informações sobre a configuração de rede, visite Guia de rede para o serviço de migração.

  • Considerações adicionais de rede:

Configuração do pg_hba.conf: para facilitar a conectividade entre as instâncias do PostgreSQL de origem e de destino, é essencial verificar e potencialmente modificar o arquivo pg_hba.conf. Esse arquivo inclui a autenticação do cliente e deve ser configurado para permitir que o PostgreSQL de destino se conecte à origem. As alterações no arquivo pg_hba.conf normalmente exigem uma reinicialização da instância do PostgreSQL de origem para entrar em vigor.

O arquivo pg_hba.conf está localizado no diretório de dados da instalação do PostgreSQL. Esse arquivo deve ser verificado e configurado se o banco de dados de origem é um servidor PostgreSQL local ou um servidor PostgreSQL hospedado em uma VM do Azure.

Habilitar extensões

Para garantir uma migração bem-sucedida usando o serviço de migração no Banco de Dados do Azure para PostgreSQL, talvez seja necessário verificar as extensões da sua instância de origem do PostgreSQL. As extensões oferecem funcionalidades e recursos que podem ser necessários para seu aplicativo. Certifique-se de verificar as extensões na instância de origem do PostgreSQL antes de iniciar o processo de migração.

Na instância de destino do Banco de Dados do Azure para PostgreSQL – Servidor Flexível, habilite as extensões com suporte identificadas na instância de origem do PostgreSQL.

Para obter mais informações, confira Extensões no Banco de Dados do Azure para PostgreSQL.

Observação

É necessário reiniciar o computador sempre que você fizer alterações no parâmetro shared_preload_libraries.

Verificar parâmetros do servidor

  • Você precisa configurar manualmente os valores de parâmetro do servidor no servidor flexível do Banco de Dados do Azure para PostgreSQL – com base nos valores de parâmetro do servidor configurados na origem.

Verificar usuários e funções

  • Os usuários e funções diferentes devem ser migrados manualmente para o Banco de Dados do Azure para PostgreSQL – Servidor flexível. Para migrar usuários e funções, você pode usar pg_dumpall --globals-only -U <<username> -f <<filename>>.sql.
  • Banco de Dados do Azure para PostgreSQL – O servidor flexível não dá suporte a nenhum superusuário; os usuários que têm funções de superusuário precisam ser removidos antes da migração.

Realizar a migração

Você pode migrar usando o portal do Azure ou a CLI do Azure.

Este artigo orienta você a usar o portal do Azure para migrar o seu banco de dados PostgreSQL de uma VM do Azure ou de um servidor PostgreSQL local para um Banco de Dados do Azure para PostgreSQL. O portal do Azure permite que você execute várias tarefas, incluindo a migração de banco de dados. Seguindo as etapas descritas neste tutorial, você pode transferir o seu banco de dados diretamente para o Azure e aproveitar seus recursos avançados e escalabilidade.

Configurar a tarefa de migração

O serviço de migração vem com uma experiência simples e baseada em assistente no portal do Azure. Veja como começar:

  1. Abra o navegador da Web e acesse o portal. Insira suas credenciais para entrar. A exibição padrão é o painel de serviço.

  2. Acesse seu destino de Banco de Dados do Azure para PostgreSQL servidor flexível.

  3. Na guia Visão geral do Servidor Flexível, no menu à esquerda, role para baixo até Migração e selecione-a.

    Captura de tela da página de seleção de Migração no portal do Azure.

  4. Selecione o botão Criar para migrar de uma VM (Máquina virtual) do Azure ou de um servidor PostgreSQL local para o Servidor Flexível. Se esta for a primeira vez que você usa o serviço de migração, uma grade vazia aparecerá com uma solicitação para iniciar sua primeira migração.

    Captura de tela de Criar migração.

    Se você já tiver criado migrações para o destino do Servidor Flexível, a grade conterá informações sobre as tentativas de migração.

  5. Selecione o botão Criar. Em seguida, você passa por uma série de guias baseada em assistente para criar uma migração para esse destino de Servidor Flexível do Servidor de origem postgreSQL.

Instalação

A primeira guia é a guia de configuração, em que o usuário inicia as migrações fornecendo detalhes de migração, como nome de migração e tipo de origem.

Captura de tela da migração de instalação.

  • O Nome da migração é o identificador exclusivo de cada migração para esse destino de servidor flexível. Esse campo aceita apenas caracteres alfanuméricos e não aceita nenhum caractere especial, exceto um hífen (-). O nome não pode começar com um hífen e deve ser exclusivo de um servidor de destino. Nenhuma migração para o mesmo destino de servidor flexível pode ter o mesmo nome de outra.

  • Tipo de Servidor de origem — Dependendo da origem do PostgreSQL, você pode selecionar de VM do Azure ou local.

  • A opção de migração permite realizar validações antes de acionar uma migração. Você pode escolher uma das seguintes opções:

    • Validar – verifica se o seu servidor e seu banco de dados estão preparados para migrar para o destino.
    • Migrar – ignora as validações e inicia as migrações.
    • Validar e Migrar – executa a validação antes de disparar uma migração. A migração será disparada somente se não houver falhas de validação.

Escolher a opção Validar ou Validar e Migrar é sempre uma boa prática ao executar validações de pré-imigração antes de executar a migração. Para saber mais sobre a validação de pré-migração, consulte esta documentação.

O Modo de migração permite escolher o modo para a migração. Offline é a opção padrão.

Selecione o botão Avançar: Conectar à Origem.

Servidor de Runtime

O Servidor de Runtime de Migração é uma funcionalidade especializada dentro do serviço de migração no Banco de Dados do Azure para PostgreSQL, desenvolvida para atuar como um servidor intermediário durante a migração. É uma instância separada do Banco de Dados do Azure para PostgreSQL – Servidor Flexível que não é o servidor de destino, mas é usada para facilitar a migração de bancos de dados de um ambiente de origem que só é acessível por meio de uma rede privada.

Captura de tela da página Servidor do Runtime de Migração.

Para obter mais informações sobre o Servidor de Runtime, acesse o artigo: Servidor de Runtime de Migração.

Conectar à origem

A guia Conectar à Origem solicita que você forneça detalhes relacionados à origem selecionada na Guia de Instalação, que é a origem dos bancos de dados.

Captura de tela do Connectsourcemigration.

  • Nome do Servidor - Fornece o nome do host ou o endereço IP da instância do PostgreSQL de origem
  • Porta – Número da porta do servidor de origem
  • ID de logon do administrador do servidor – Nome de usuário do servidor PostgreSQL de origem
  • Senha – Senha do servidor PostgreSQL de origem
  • Modo SSL – Os valores com suporte são preferenciais e obrigatórios. Quando o SSL no servidor PostgreSQL de origem estiver OFF, use o SSLMODE=prefer. Se o SSL no servidor de origem estiver ON, use o SSLMODE=require. Os valores SSL podem ser determinados no arquivo postgresql.conf.
  • Testar Conexão – executa o teste de conectividade entre o destino e a origem. Depois que a conexão for bem-sucedida, os usuários poderão prosseguir com a próxima etapa. Caso contrário, você precisa identificar os problemas de rede entre o destino e a origem e verificar o nome de usuário/senha da origem. A conexão de teste leva alguns minutos para estabelecer uma conexão entre o destino e a origem

Após a conexão de teste bem-sucedida, selecione o botão Avançar: Selecionar Destino de Migração

Selecionar destino de migração

A guia selecionar destino de migração exibe metadados para o destino do Servidor Flexível, como o nome da assinatura, o grupo de recursos, o nome do servidor, o local e a versão do PostgreSQL.

Captura de tela do Connecttargetmigration.

  • Nome de usuário do administrador – nome de usuário administrador do servidor PostgreSQL de destino
  • Senha – Senha do servidor PostgreSQL de destino
  • FQDN/IP personalizado (opcional): o campo FQDN/IP personalizado é opcional e pode ser usado quando o destino está por trás de um servidor DNS personalizado ou tem namespaces DNS personalizados, tornando-o acessível apenas por meio de FQDNs específicos ou endereços IP. Por exemplo, isso pode incluir entradas como flexibleserver.example.com, 198.1.0.2 ou um FQDN do PostgreSQL, como flexibleserver.postgres.database.azure.com, se o servidor DNS personalizado contiver a zona DNS postgres.database.azure.com ou encaminhar consultas para essa zona para 168.63.129.16, na qual o FQDN é resolvido na zona DNS pública ou privada do Azure.
  • Testar Conexão – executa o teste de conectividade entre o destino e a origem. Depois que a conexão for bem-sucedida, os usuários poderão prosseguir com a próxima etapa. Caso contrário, precisamos identificar os problemas de rede entre o destino e a origem e verificar o nome de usuário/senha do destino. A conexão de teste leva alguns minutos para estabelecer uma conexão entre o destino e a origem.

Após a conexão de teste bem-sucedida, selecione o Próximo: Selecionar Bancos de Dados para Migração

Selecionar bancos de dados para migração

Nessa guia, uma lista de bancos de dados de usuário está dentro do servidor de origem selecionado na guia de configuração. Você pode selecionar e migrar até oito bancos de dados em uma única tentativa de migração. Se houver mais de oito bancos de dados de usuários, o processo de migração será repetido entre os servidores de origem e de destino no próximo conjunto de bancos de dados.

Captura de tela de FetchDBmigration.

Depois de selecionar os bancos de dados, selecione Avançar:Resumo

Resumo

A guia Resumo resume todos os detalhes da origem e do destino para criar a validação ou a migração. Revise os detalhes e selecione no botão Iniciar.

Captura de tela da migração de Resumo.

Monitorar a migração

Depois de selecionar o botão Iniciar, uma notificação aparecerá em alguns segundos informando que a validação ou criação da migração foi bem-sucedida. Você será redirecionado automaticamente para a folha Migração do Servidor Flexível, que tem uma nova entrada para a validação ou migração criada recentemente.

Captura de tela da migração do monitor no portal do Azure.

A grade que exibe as migrações tem estas colunas: Nome, Status, Modo de migração, Tipo de migração, Servidor de origem, Tipo de servidor de origem, Bancos de dados, **Duração e Hora de início. As entradas são exibidas na ordem decrescente da hora de início, com a entrada mais recente na parte superior. Você pode usar o botão de atualização para atualizar o status da validação ou migração. Selecione o nome da migração na grade para ver os detalhes associados.

Quando a validação ou migração é criada, ela passa para o estado InProgress e para o subestado PerformingPreRequisiteSteps. O fluxo de trabalho leva de 2 a 3 minutos para configurar a infraestrutura de migração e as conexões de rede.

Detalhes da migração

Na guia Instalação, selecionamos a opção de migração como Migrar e Validar. Nesse cenário, as validações são executadas primeiro antes do início da migração. Após a conclusão do substrato PerformingPreRequisiteSteps, o fluxo de trabalho passa para o subestado de Validação em andamento.

  • Se a validação tiver erros, a migração passa para um estado de Falha.
  • Se a validação é concluída sem nenhum erro, a migração é iniciada e o fluxo de trabalho passa para o subestado de Migrando Dados.

Os resultados da validação são exibidos na guia Validação e a migração é monitorada na guia Migração.

Captura de tela da migração de Detalhes.

Alguns possíveis estados da migração incluem:

Estados de migração

Estadual Descrição
InProgress A instalação da infraestrutura de migração está em andamento ou a migração de dados real está em andamento.
Cancelada A migração foi cancelada ou excluída.
Com falha A migração falhou.
Falha na Validação A validação falhou.
Êxito A migração foi bem-sucedida e está concluída.
WaitingForUserAction Aplicável somente para migração online. Aguardando a ação do usuário para executar a substituição.

Subestados de migração

Subestado Descrição
PerformingPreRequisiteSteps A configuração da infraestrutura está em andamento para migração de dados.
Validação em andamento Validação em andamento.
MigratingData Migração de dados em andamento.
CompletingMigration A migração está nos estágios finais da conclusão.
Concluído A migração foi concluída.
Com falha A migração falhou.

Substratos de validação

Subestado Descrição
Com falha A validação falhou.
Êxito A validação foi bem-sucedida.
Aviso A validação está com um aviso.

Substituição

Se houver Migrar e Validar e Migrar, a conclusão da migração online exigirá outra etapa – o usuário precisará realizar uma ação de substituição. Após a conclusão da cópia/clone dos dados base, a migração passa para o estado WaitingForUserAction e o substrato WaitingForCutoverTrigger. Nesse estado, o usuário pode disparar a substituição do portal selecionando a migração.

Antes de iniciar a substituição, é importante garantir que:

  • As gravações na origem são interrompidas – Latency o valor é 0 ou próximo a 0. As informações Latency podem ser obtidas na tela de detalhes da migração, conforme mostrado abaixo:
  • O valor de latency diminui para 0 ou perto de 0
  • O valor de latency indica quando o destino foi sincronizado pela última vez com a origem. Neste ponto, as gravações na origem podem ser interrompidas e a substituição iniciada. Caso haja tráfego intenso na origem, é recomendável interromper as gravações primeiro para que Latency possa chegar perto de 0 e, em seguida, uma transição seja iniciada.

A operação de substituição aplica todas as alterações pendentes da Origem para o Destino e conclui a migração. Se você acionar uma "Substituição" mesmo com um Latency, diferente de zero, a replicação será interrompida até esse momento. Todos os dados na origem até o ponto de transição são então aplicados ao destino. Se você tiver uma latência de 15 minutos no ponto de substituição, todos os dados alterados nos últimos 15 minutos serão aplicados ao destino. O tempo gasto depende da lista de pendências das alterações ocorridas nos últimos 15 minutos. Portanto, é recomendável que a latência atinja zero ou perto de zero, antes de disparar a substituição.

  • A migração passa para o estado Succeeded quando o subestado Migrating Data ou a substituição (na migração online) é concluído com êxito. Se houver um problema no subestado Migrating Data, a migração passará para o estado Failed.

Cancelar a migração

Você pode cancelar as validações ou migrações em andamento. O fluxo de trabalho deve estar no estado InProgress para ser cancelado. Você não pode cancelar uma validação ou migração no estado Bem-sucedido ou Com falha.

O cancelamento de uma validação interrompe qualquer atividade de validação adicional e a validação passa para um estado Cancelado.

O cancelamento de uma migração interrompe qualquer atividade de migração adicional no servidor de destino e passa para um estado Cancelado. Ele não descarta nem reverte nenhuma alteração no servidor de destino. Certifique-se de remover os bancos de dados em seu servidor de destino que está envolvido em uma migração cancelada.

Verificar a migração quando concluída

Depois de concluir os bancos de dados, você precisa validar manualmente os dados entre a origem e o destino e verificar se todos os objetos no banco de dados de destino foram criados com êxito.

Após a migração, você pode executar as seguintes tarefas:

  • Verifique os dados em seu servidor flexível e verifique se é uma cópia exata da instância de origem.
  • Após a verificação, habilite a opção de alta disponibilidade em seu servidor flexível conforme necessário.
  • Altere o SKU do servidor flexível para que ele corresponda às necessidades do aplicativo. Essa alteração exige uma reinicialização do servidor de banco de dados.
  • Se você alterar os parâmetros de servidor de seus valores padrão na instância de origem, copie esses valores de parâmetro de servidor no servidor flexível. Copie outras configurações do servidor, como marcas, alertas e regras de firewall (se aplicável) da instância de origem para o servidor flexível.
  • Faça alterações em seu aplicativo para apontar as cadeias de conexão para um servidor flexível.
  • Monitore o desempenho do banco de dados de perto para ver se ele exige um ajuste de desempenho.

Conteúdo relacionado