Migrar online, de um servidor do Amazon RDS para PostgreSQL para o Azure Database para PostgreSQL, com o serviço de migração.

Este artigo orienta você a usar o portal do Azure para migrar seu banco de dados PostgreSQL de um servidor Do Amazon RDS para PostgreSQL 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 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 é fornecido com uma experiência simples e baseada em assistente no portal do Azure.

Usando o portal do Azure:

1. Selecione seu servidor flexível do Azure Database for PostgreSQL.

2. No menu de recursos, selecione Migração.

   

3. Selecione Criar para percorrer uma série de guias baseada em assistente para executar uma migração para um servidor flexível do local ou da VM do Azure.

   Observação

   Na primeira vez que você usa o serviço de migração, uma grade vazia aparece com um prompt para iniciar sua primeira migração.

   Se as migrações para o destino do servidor flexível já tiverem sido criadas, a grade agora conterá informações sobre tentativas de migrações.

   

Configuração

Você precisa fornecer vários detalhes relacionados à migração, como o nome da migração, o tipo de servidor de origem, a opção e o modo.

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

• Tipo de servidor de origem – dependendo da origem do PostgreSQL, você pode selecionar a Máquina Virtual do Azure ou o servidor local.

• Opção de migração – permite que você execute validações antes de disparar uma migração. Você pode escolher qualquer uma das seguintes opções:

  • Validar – verifica a preparação do servidor e do banco de dados para migração para o destino.
  • Validar e migrar — executa a validação antes de disparar uma migração. Se não houver falhas de validação, a migração será iniciada.

Escolher a opção Validar ou Validar e migrar é sempre uma boa prática para executar validações de pré-imigração antes de executar a migração.

Para saber mais sobre a validação de premigração, visite premigração.

• O modo de migração permite que você escolha o modo para a migração. Offline é a opção padrão. Nesse caso, vamos alterá-lo para Online.

Selecione Avançar: servidor de runtime.

Servidor de execução

O servidor de runtime de migração é um recurso especializado dentro do serviço de migração no Banco de Dados do Azure para PostgreSQL, projetado para atuar como um servidor intermediário durante a migração. É uma instância de servidor flexível do Banco de Dados do Azure para PostgreSQL separada 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.

Para obter mais informações sobre o servidor de runtime, visite o servidor de runtime de migração.

Servidor de origem

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

• Nome do servidor – forneça o nome do host ou o endereço IP do servidor PostgreSQL de origem.
• Porta – Número da porta do servidor de origem.
• Logon do administrador – nome do usuário administrador do servidor PostgreSQL de origem.
• Senha – senha do logon do administrador fornecida para se conectar ao servidor PostgreSQL de origem.
• Modo SSL – os valores com suporte são preferred e required. Quando o SSL no servidor PostgreSQL de origem estiver OFF, use prefer. Se o SSL no servidor de origem estiver ON, use o require. Os valores SSL podem ser determinados no arquivo postgresql.conf do servidor de origem.
• Testar a conexão – executa o teste de conectividade entre o destino e a origem. Depois que a conexão for bem-sucedida, você poderá prosseguir para a próxima guia. Esses testes visam identificar quaisquer problemas de conectividade que possam existir entre os servidores de destino e de origem, incluindo a verificação da autenticação usando as credenciais fornecidas. Estabelecer uma conexão de teste leva alguns segundos.

Após a conexão de teste bem-sucedida, selecione Avançar: Servidor de destino.

Servidor de destino

A guia Servidor de destino 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.

• Logon do administrador – nome do usuário administrador do servidor PostgreSQL de destino.
• Senha – senha do logon do administrador fornecida para se conectar ao servidor PostgreSQL de destino.
• Endereço IP ou FQDN personalizado: o campo de endereço IP ou FQDN 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 production-flexible-server.example.com, 198.1.0.2, ou um FQDN do PostgreSQL, como production-flexible-server.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, em que o FQDN é resolvido na zona DNS pública ou privada do Azure.
• Testar a conexão – executa o teste de conectividade entre a origem e o destino. Depois que a conexão for bem-sucedida, você poderá prosseguir para a próxima guia. Esses testes visam identificar quaisquer problemas de conectividade que possam existir entre os servidores de origem e de destino, incluindo a verificação da autenticação usando as credenciais fornecidas. Estabelecer uma conexão de teste leva alguns segundos.

Após a conexão de teste bem-sucedida, selecione o Próximo: Bancos de dados para validar ou migrar

Bancos de dados para validar ou migrar

Na guia Bancos de Dados para validar ou migrar , você pode escolher uma lista de bancos de dados de usuário para migrar do servidor PostgreSQL de origem.

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

Resumo

A guia Resumo apresenta todos os detalhes de origem e destino para criar a validação ou a migração. Examine os detalhes e selecione Iniciar validação e migração.

Cancelar a validação ou a migração

Você pode cancelar as validações ou migrações em andamento. O fluxo de trabalho deve estar no status Em andamento para ser cancelado. Você não pode cancelar uma validação ou migração no status bem-sucedido ou com falha .

Cancelar uma validação interrompe qualquer atividade de validação adicional e a validação passa para um status Cancelado .

O cancelamento de uma migração interrompe a atividade de migração adicional no servidor de destino e passa para um status Cancelado . Ele não descarta nem reverte nenhuma alteração no servidor de destino. Certifique-se de remover os bancos de dados no servidor de destino envolvidos em uma migração cancelada.

Este artigo explora o uso da CLI do Azure para migrar seu banco de dados PostgreSQL de uma máquina virtual do Azure ou uma instância local do PostgreSQL para um Banco de Dados do Azure para PostgreSQL. A CLI do Azure fornece uma interface de linha de comando poderosa e flexível que permite executar várias tarefas, incluindo a migração de banco de dados. Seguindo as etapas descritas neste artigo, você pode transferir seu banco de dados diretamente para o Azure e aproveitar seus recursos avançados e escalabilidade.

Para saber mais sobre a CLI do Azure com o serviço de migração, visite Como configurar a CLI do Azure para o serviço de migração.

Depois que a CLI estiver instalada, abra o prompt de comando e faça logon em sua conta do Azure usando o comando abaixo.

az login

Configurar a tarefa de migração

Para iniciar a migração, crie um arquivo JSON com os detalhes da migração. O arquivo JSON contém as seguintes informações:

• Edite os placeholders abaixo das linhas JSON << >> e armazene-os no computador local como <<filename>>.json, onde a CLI está sendo invocada. Neste tutorial, salvamos o arquivo em c:/migration-CLI/migration_body.json

{
"properties": {
"SourceDBServerResourceId": "<<source-server-hostname-or-IP-address>>:<<port>>@<<username>>",
        "SecretParameters": {
            "AdminCredentials": {
                "SourceServerPassword": "<<source-server-administrator-password>>",
                "TargetServerPassword": "<<target-server-administrator-password>>"
            },
            "targetServerUserName": "<<target-server-administrator-login>>"
        },
        "DBsToMigrate": "<<comma-separated-list-of-databases-in-array-like-["ticketdb","timedb","inventorydb"]>>",
        "OverwriteDBsInTarget": "true",
        "sourceType": "OnPremises",
        "sslMode": "Prefer"
    }
}

• Execute o comando a seguir para verificar se alguma migração está em execução. O nome da migração é exclusivo entre as migrações no destino do servidor flexível do Banco de Dados do Azure para PostgreSQL.

  az postgres flexible-server migration list --subscription <subscription_id> --resource-group <resource_group> --name <target_server> --filter all
  

• Nas etapas acima, não há migrações executadas, portanto, começamos com a nova migração executando o comando a seguir.

  az postgres flexible-server migration create --subscription <subscription_id> --resource-group <resource_group> --name <target_server> --migration-name <migration> --migration-mode offline --migration-option ValidateAndMigrate --properties "c:/migration-cli/migration_body.json"
  

• Execute o comando a seguir para ver o status da migração iniciada na etapa anterior. Você pode verificar o status da migração fornecendo o nome da migração.

  az postgres flexible-server migration show --subscription <subscription_id> --resource-group <resource_group> --name <target_server> --migration-name <migration>
  

• O progresso e o status da migração são mostrados na CLI do Azure.

• Você também pode ver o progresso e o status no portal do Azure.

• Você pode cancelar todas as tentativas de migração em andamento usando o cancel comando. Esse comando interrompe a tentativa de migração específica e reverte todas as alterações que ele poderia ter feito no servidor de destino. A seguir está o comando da CLI para cancelar a migração que tem um status "Em andamento".

  az postgres flexible-server migration update cancel --subscription <subscription_id> --resource-group <resource_group> --name <target_server> --migration-name <migration>
  

Para a opção Validar e migrar, a conclusão da migração online exige que o usuário complete uma etapa adicional, que é acionar a ação de transição. Depois que a cópia ou clonagem dos dados base for concluída, a migração passará para o Waiting for user action status e o Waiting for cutover trigger substatus. Neste status, 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 quando o valor latency é 0 ou próximo a 0. As latency informações podem ser obtidas na tela de detalhes da migração, conforme mostrado abaixo:
• latency o valor diminui para 0 ou perto de 0
• O latency valor 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 do servidor de origem ao servidor de destino e conclui a migração. Se você disparar uma substituição, mesmo com um latency diferente de zero, a replicação será interrompida até esse momento. Todos os dados da origem até o ponto de corte são então aplicados ao alvo. Se você experimentar uma latência de 15 minutos no momento de transição, todas as alterações feitas nos dados nos últimos 15 minutos serão aplicadas ao destino.

O tempo depende do acúmulo de mudanças 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 status Succeeded quando o substatus Migrating data ou a substituição (na migração online) é concluído com sucesso. Se houver um problema no Migrating data substatus, a migração passará para um Failed status.

Para a opção Validar e migrar, a conclusão da migração online exige que o usuário complete uma etapa adicional, que é acionar a ação de transição. Depois que a cópia ou clonagem dos dados base for concluída, a migração passará para o Waiting for user action status e o Waiting for cutover trigger substatus. Nesse estado, o usuário pode iniciar a migração por meio da CLI usando o comando abaixo. A substituição também pode ser disparada no portal selecionando o nome da migração na grade de migrações.

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

• As gravações na origem são interrompidas quando o valor latency é 0 ou próximo a 0. As latency informações podem ser obtidas na tela de detalhes da migração, conforme mostrado abaixo:
• latency o valor diminui para 0 ou perto de 0
• O latency valor 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 do servidor de origem ao servidor de destino e conclui a migração. Se você disparar uma substituição, mesmo com um latency diferente de zero, a replicação será interrompida até esse momento. Todos os dados da origem até o ponto de corte são então aplicados ao alvo. Se você experimentar uma latência de 15 minutos no momento de transição, todas as alterações feitas nos dados nos últimos 15 minutos serão aplicadas ao destino.

O tempo depende do acúmulo de mudanças 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 status Succeeded quando o substatus Migrating data ou a substituição (na migração online) é concluído com sucesso. Se houver um problema no Migrating data substatus, a migração passará para um Failed status.

Para disparar a substituição, use o seguinte comando:

az postgres flexible-server migration update --subscription <subscription_id> --resource-group <resource_group> --name <server> --migration-name <migration> --cutover