Compartilhar via

Tutorial: Migrar online do Amazon RDS para PostgreSQL para o Banco de Dados do Azure para PostgreSQL usando a versão prévia do serviço de migração

  • Artigo

Este artigo explora como migrar seu banco de dados PostgreSQL do Amazon RDS para PostgreSQL para o Banco de Dados do Azure para PostgreSQL online.

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 seu percurso de migração para o Banco de Dados do Azure para PostgreSQL.

  • Pré-requisitos
  • Realizar a migração
  • Monitorar a migração
  • Substituição
  • Verificar a migração quando concluída

Pré-requisitos

Para concluir a migração, são necessários estes 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 pré-requisitos a seguir, 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.
  • No Amazon RDS para PostgreSQL, o plug-in test_decoding está pré-instalado e pronto para replicação lógica. Isso permite que você configure facilmente slots de replicação lógica e transmita alterações WAL, facilitando casos de uso, como CDC (captura de dados de alteração) ou replicação para sistemas externos.
  • 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 Banco de Dados do Azure para PostgreSQL, visite Criar um Banco de Dados do Azure para PostgreSQL

Habilitar CDC como uma origem

  • O plug-in de decodificação lógica test_decoding captura os registros alterados da origem.
  • Para permitir que o usuário de migração acesse privilégios de replicação, execute o seguinte comando:
GRANT rds_replication TO <<username>>;

  • Na origem, instância do PostgreSQL, modifique os seguintes parâmetros criando um grupo de parâmetros:

    • Defina rds.logical_replication = 1
    • Defina max_replication_slots como um valor maior que um; o valor deve ser maior que o número de bancos de dados selecionados para migração.
    • Defina max_wal_senders como um valor maior que um. Ele deve ser pelo menos o mesmo que max_replication_slots, mais o número de remetentes já usados em sua instância.
    • O parâmetro wal_sender_timeout termina conexões de replicação inativas por mais tempo do que o número especificado de milissegundos. O padrão para uma instância do AWS RDS para PostgreSQL é 30000 milliseconds (30 seconds). Definir o valor como 0 (zero) desabilita o mecanismo de tempo limite e é uma configuração válida para migração.

  • No Servidor Flexível de destino, para impedir que a migração online fique sem armazenamento para armazenar os logs, 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_ssd 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 mais informações sobre a configuração de rede, visite o Guia de rede para o serviço de migração.

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 os parâmetros do servidor

Esses parâmetros não são migrados automaticamente para o ambiente de destino e devem ser configurados manualmente.

  • Corresponda os valores de parâmetro do servidor do banco de dados PostgreSQL de origem ao Banco de Dados do Azure para PostgreSQL acessando a seção "Parâmetros do servidor" no portal do Azure e atualizando manualmente os valores de acordo.

  • Salve as alterações de parâmetro e reinicie o Banco de Dados do Azure para PostgreSQL para aplicar a nova configuração, se necessário.

Verificar usuários e funções

Ao migrar para o Banco de Dados do Azure para PostgreSQL, é essencial abordar a migração de usuários e funções separadamente, pois elas exigem intervenção manual:

  • Migração Manual de Usuários e Funções: os usuários e suas funções associadas devem ser migrados manualmente para o Banco de Dados do Azure para PostgreSQL. Para facilitar esse processo, você pode usar o utilitário pg_dumpall com o sinalizador --globals-only para exportar objetos globais, como funções e contas de usuário. Execute o seguinte comando, substituindo <<username>> pelo nome de usuário real e <<filename>> pelo nome do arquivo de saída desejado:

    pg_dumpall --globals-only -U <<username>> -f <<filename>>.sql

  • Restrição em Funções de Superusuário: o Banco de Dados do Azure para PostgreSQL não dá suporte a funções de superusuário. Portanto, os usuários com privilégios de superusuário devem ter esses privilégios removidos antes da migração. Certifique-se de ajustar as permissões e as funções adequadamente.

Seguindo estas etapas, você pode garantir que contas de usuário e funções sejam migradas corretamente para o Banco de Dados do Azure para PostgreSQL sem encontrar problemas relacionados a restrições de superusuário.

Desabilitar a alta disponibilidade (confiabilidade) e as réplicas de leitura no destino

  • Desabilitar a alta disponibilidade (confiabilidade) e ler réplicas no ambiente de destino é essencial. Esses recursos devem ser habilitados somente após a conclusão da migração.

  • Seguindo essas diretrizes, você pode ajudar a garantir um processo de migração suave sem as variáveis adicionadas introduzidas por HA e réplicas de leitura. Depois que a migração for concluída e o banco de dados estiver estável, você poderá continuar a habilitar esses recursos para aprimorar a disponibilidade e a escalabilidade do seu ambiente de banco de dados no Azure.

Realizar a migração

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

O portal do Azure oferece uma experiência simples e intuitiva baseada em um assistente que orienta você durante a migração. Seguindo as etapas descritas neste tutorial, você pode transferir seu banco de dados diretamente para o Banco de Dados do Azure para PostgreSQL – Servidor Flexível e aproveitar os recursos avançados e escalabilidade dele.

Para migrar com o portal do Azure, primeiro configure a tarefa de migração, conecte-se à origem e ao destino e execute a migração.

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 seleção de Migração.

  4. Selecione o botão Criar para migrar do Amazon RDS para PostgreSQL para o Banco de Dados do Azure para PostgreSQL – 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 da criação de uma migração.

    Se você já tiver criado migrações para o destino do Banco de Dados do Azure para PostgreSQL, a grade conterá informações sobre tentativas de migrações já realizadas.

  5. Selecione o botão Criar. Em seguida, você passa por uma série de guias baseada em assistente para criar uma migração da instância de origem do PostgreSQL para esse destino do Banco de Dados do Azure para PostgreSQL.

Instalação

A primeira é a guia Configuração, em que o usuário precisa fornecer detalhes de migração, como o tipo de origem do nome da migração, para iniciar as migrações.

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

  • 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 o tipo de origem correspondente, como um serviço PostgreSQL baseado em nuvem, uma configuração local ou uma máquina virtual.

  • 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.

Selecione Servidor de Runtime

O Servidor de Runtime de migração é um recurso especializado dentro do serviço de migração, projetado para atuar como um servidor intermediário durante a migração. Trata-se de uma instância separada do Banco de Dados do Azure para PostgreSQL - Servidor Flexível que não é o servidor de destino, mas é usado para facilitar a migração de bancos de dados de um ambiente de origem que só é acessível por meio de uma rede privada.

Para obter mais informações sobre o Runtime Server, visite o Servidor de Rede de Migração.

Captura de tela da página Servidor do 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 definido como OFF, use SSLMODE=prefer. Se o SSL no servidor de origem estiver definido como ON, use 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, precisamos identificar os problemas de rede entre o destino e a origem e verificar o nome de usuário/senha da origem. Estabelecer uma conexão de teste leva alguns minutos.

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 os metadados do destino de servidor flexível, como nome da assinatura, grupo de recursos, nome do servidor, localização e versão do PostgreSQL.

Captura de tela da tela de migração do destino da conexão.

  • 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 dessa zona para 168.63.129.16, onde 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. Em seguida, você será redirecionado automaticamente para a página 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.

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.

Você pode ver os resultados da validação e migração no nível da instância e do banco de dados.

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

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

  • 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 momento, 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 substituição são então aplicados ao destino. Digamos que uma latência foi de 15 minutos no ponto de substituição, portanto todos os dados alterados nos últimos 15 minutos sã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.

    Captura de tela de Confirmcutovermigration.

  • 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.

    Captura de tela da migração bem-sucedida.

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