Tutorial: Migrar do Banco de Dados do Azure para PostgreSQL - Servidor Único para Servidor Flexível com o serviço de migração

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

Usando o portal do Azure, você pode migrar uma instância do Banco de Dados do Azure para PostgreSQL – Servidor Único para o Banco de Dados do Azure para PostgreSQL – Servidor Flexível. Neste tutorial, executamos a migração de um banco de dados de exemplo de um banco de dados do Azure para servidor único PostgreSQL para um servidor flexível PostgreSQL usando o portal do Azure.

• Configurar seu Banco de Dados do Azure para o Servidor Flexível PostgreSQL
• Configurar a tarefa de migração
• Monitorize a migração
• Cancelar a migração
• Pós-migração

Portal

Você pode migrar usando o portal do Azure.

Offline

Pré-requisitos (offline)

Antes de iniciar a migração com o serviço de migração no Banco de Dados do Azure para PostgreSQL, você deve cumprir os seguintes pré-requisitos, que se aplicam a cenários de migração offline.

Verifique a versão de origem

A versão do PostgreSQL de origem deve ser >= 9.5. Se a versão de origem do PostgreSQL for menor que 9.5, atualize a versão de origem do PostgreSQL para 9.5 ou superior antes da migração.

Configuração de destino

• O servidor flexível do Banco de Dados do Azure para PostgreSQL deve ser implantado e configurado corretamente no Azure antes de iniciar o processo de migração.

• A SKU escolhida para o Banco de Dados do Azure para PostgreSQL deve corresponder às especificações do banco de dados de origem para garantir compatibilidade e desempenho adequado.

• Para obter instruções detalhadas sobre como criar um novo Banco de Dados do Azure para PostgreSQL, consulte o seguinte link: Guia de início rápido: criar servidor.

• Ao migrar entre versões do PostgreSQL (principais ou secundárias), garanta a compatibilidade entre seu banco de dados e o aplicativo revisando as notas de versão para verificar possíveis alterações de rutura.

Configuração da rede

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

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

Ativar 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 para sua instância do PostgreSQL de origem. As extensões fornecem funcionalidades e recursos que podem ser necessários para seu aplicativo. Certifique-se de verificar as extensões na instância PostgreSQL de origem 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 do PostgreSQL de origem.

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

Nota

Uma reinicialização é necessária quando você faz alterações no shared_preload_libraries parâmetro.

Verifique os parâmetros do servidor

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

• Coracione os valores dos parâmetros 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, se necessário, reinicie o Banco de Dados do Azure para servidor flexível PostgreSQL para aplicar a nova configuração.

Importante

Altere o parâmetro password_encryption server em seu servidor flexível de SCRAM-SHA-256 para MD5 antes de iniciar a migração. Isso é essencial para que as credenciais existentes em um único servidor funcionem em seu servidor flexível.

Desative a alta disponibilidade (confiabilidade) e leia réplicas no destino

• Desabilitar a alta disponibilidade (confiabilidade) e as réplicas de leitura 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 adicionais introduzidas pela alta disponibilidade e réplicas de leitura. Quando a migração estiver concluída e o banco de dados estiver estável, você poderá continuar habilitando esses recursos para aprimorar a disponibilidade e a escalabilidade do seu ambiente de banco de dados no Azure.

Configurar seu Banco de Dados do Azure para servidor flexível PostgreSQL

• Crie o servidor flexível de destino. Para obter as etapas guiadas, consulte o guia de início rápido Criar um banco de dados do Azure para servidor flexível PostgreSQL usando o portal.

• Extensões Allowlist cujas bibliotecas devem ser carregadas no início do servidor. É essencial que a extensão esteja na lista de permissões antes de iniciar uma migração.

• Verifique se a distribuição de dados entre as tabelas de um banco de dados está distorcida, com a maioria dos dados presentes em uma única (ou pouca) tabela. Se for enviesada, a velocidade de migração poderá ser mais lenta do que o esperado. Nesse caso, a velocidade de migração pode ser aumentada migrando a tabela grande em paralelo.

Configurar a tarefa de migração

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

1. Abra o browser e aceda ao portal do Azure. Para iniciar sessão, introduza as suas credenciais. A vista predefinida é o dashboard de serviço.

2. Vá para o seu Banco de Dados do Azure para o destino do Servidor Flexível PostgreSQL.

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

   

4. Selecione o botão Criar para iniciar uma migração de um único servidor para um servidor flexível. Se esta for a primeira vez que você usa o serviço de migração, uma grade vazia será exibida com um prompt para iniciar sua primeira migração.

   

   Se você já criou migrações para o destino Servidor Flexível, a grade contém informações sobre migrações que foram tentadas para esse destino a partir do Servidor Único.

5. Você passa por uma série de guias baseadas em assistente para criar uma migração para esse destino de servidor flexível de diferentes fontes possíveis. Por padrão, o tipo de servidor de origem é definido como Banco de Dados do Azure para Servidor Único PostgreSQL, que é o que nos interessa para este cenário.

Como alternativa, você pode iniciar o processo de migração do Banco de Dados do Azure para o Servidor Único PostgreSQL.

1. Abra o browser e aceda ao portal do Azure. Para iniciar sessão, tem de introduzir as suas credenciais. A vista predefinida é o dashboard de serviço.

2. Ao selecionar o Servidor Único, você pode observar um banner relacionado à migração na guia Visão geral. Selecione Migrar agora para começar.

   

3. Você é direcionado para uma página com duas opções. Se você já criou um Servidor Flexível e deseja usá-lo como destino, escolha Selecionar existente e selecione os detalhes correspondentes de Assinatura, Grupo de recursos e Nome do servidor. Depois que as seleções forem feitas, selecione Ir para o assistente de migração e siga as instruções na seção Configuração .

   

4. Se você optar por criar um novo Servidor Flexível, selecione Criar novo e selecione Ir para o assistente de criação. Esta ação o conduz pelo processo de criação do Servidor Flexível e implanta o Servidor Flexível.

   

Depois de implantar o Servidor Flexível, siga as etapas 3 a 5 em Configurar a tarefa de migração.

Configurar

A primeira guia é Configuração. Caso você tenha perdido, permita listar as extensões necessárias, conforme descrito em Configurar seu Banco de Dados do Azure para servidor flexível PostgreSQL, antes de iniciar uma migração.

O nome da migração é o identificador exclusivo de cada migração para esse destino do Servidor Flexível. Este campo aceita apenas caracteres alfanuméricos e não aceita caracteres especiais, exceto sublinhado (_) e hífen (-). O nome deve começar com um caractere alfanumérico. O nome também deve ser exclusivo para um servidor de destino, porque não há duas migrações para o mesmo destino do Servidor Flexível podem ter o mesmo nome.

O tipo de servidor de origem indica a origem. Neste caso, é o Banco de Dados do Azure para PostgreSQL Single Server

A opção de migração permite executar validações antes de acionar 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 a migração para o destino.
• Migrar - Ignora validações e inicia a migração.
• Validar e migrar - Executa a validação antes de acionar uma migração. A migração só é acionada se não houver falhas de validação.

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

O modo de migração permite que você escolha entre uma migração online e offline, neste caso ela deve ser definida como Offline.

Selecione o botão Next: Select Runtime Server (Avançar: Selecionar servidor de tempo de execução).

Servidor de tempo de execução

O Servidor de Tempo de Execução 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. É um Banco de Dados do Azure separado para PostgreSQL - instância do 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 Migration Runtime Server.

Selecione o botão Next: Connect to source (Avançar: Conectar ao código-fonte ).

Ligar à origem

A seção Origem solicita que você forneça detalhes relacionados ao Servidor Único, que é a origem dos bancos de dados.

Depois de fazer as seleções de Assinatura e Grupo de Recursos, a lista suspensa para nomes de servidor mostra Servidores Únicos nesse grupo de recursos entre regiões. Selecione a origem da qual deseja migrar bancos de dados. Você pode migrar bancos de dados de um Servidor Único para um Servidor Flexível de destino na mesma região. As migrações entre regiões são habilitadas apenas para servidores da Índia, China e Emirados Árabes Unidos.

Depois de escolher a origem do Servidor Único, as caixas Localização e Versão do PostgreSQL são preenchidas automaticamente. Certifique-se de fornecer as credenciais de uma função de administrador, pois isso é necessário para que o serviço de migração migre com êxito os bancos de dados.

O campo FQDN/IP personalizado é opcional e pode ser usado quando a fonte está atrás de um servidor DNS personalizado ou tem namespaces DNS personalizados, tornando-o acessível apenas por meio de FQDNs ou endereços IP específicos. Por exemplo, isso pode incluir entradas como singleserver.example.com, 198.1.0.2ou um FQDN do PostgreSQL, como singleserver.postgres.database.azure.com, se o servidor DNS personalizado contiver a zona postgres.database.azure.com DNS ou encaminhar consultas para essa zona para 168.63.129.16, onde o FQDN é resolvido na zona DNS pública ou privada do Azure.

Depois de preencher todos os campos, selecione o link Conectar à fonte . Isso valida se os detalhes do servidor de origem inseridos estão corretos e se o servidor de origem está acessível.

Selecione o botão Next: Select migration target (Avançar: selecionar destino de migração) para continuar.

Selecionar destino de migração

A seção Selecionar destino de migração exibe metadados para o destino Servidor flexível, como Assinatura, Grupo de recursos, Nome do servidor, Local e Versão do PostgreSQL.

O campo FQDN/IP personalizado é opcional e pode ser usado quando o destino está atrás de um servidor DNS personalizado ou tem namespaces DNS personalizados, tornando-o acessível apenas por meio de FQDNs ou endereços IP específicos. Por exemplo, isso pode incluir entradas como flexibleserver.example.com, 198.1.0.2ou um FQDN do PostgreSQL, como flexibleserver.postgres.database.azure.com, se o servidor DNS personalizado contiver a zona postgres.database.azure.com DNS ou encaminhar consultas para essa zona para 168.63.129.16, onde o FQDN é resolvido na zona DNS pública ou privada do Azure.

Escolha os valores apropriados para o método de autenticação e todos os campos relacionados à autenticação. Certifique-se de que a identidade fornecida é a do usuário administrador no servidor de destino. Depois de preencher todas as informações necessárias, selecione o link Conectar ao destino . Isso valida se os detalhes do servidor de destino inseridos estão corretos e se o servidor de destino está acessível.

Selecione o botão Next: Select database(s) for migration para selecionar os bancos de dados a serem migrados.

Selecionar banco(s) de dados para migração

Nesta guia, há uma lista de bancos de dados de usuários dentro do Servidor Único. 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 para o próximo conjunto de bancos de dados. Os bancos de dados selecionados que existem no servidor de destino com os mesmos nomes exatos são substituídos.

Selecione o botão Seguinte: Resumo para rever os detalhes.

Resumo

A guia Resumo resume todos os detalhes para criar a validação ou migração. Reveja os detalhes e selecione o botão Iniciar Validação e Migração .

Monitorar o portal de migração

Depois de iniciar a migração, uma notificação aparece para dizer que a validação ou a criação da migração foi bem-sucedida. Você será redirecionado automaticamente para a página Migração do Servidor flexível. Isso tem uma nova entrada para a validação ou migração criada recentemente.

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, Hora de início e Duração. 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 Atualizar para atualizar o status da validação ou migração.

Você também pode selecionar o nome de uma migração específica na grade para ver os detalhes associados.

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

Vejamos como monitorar as migrações para cada opção de migração.

Validar

Depois que o subestado PerformingPreRequisiteSteps for concluído, a validação será movida para o subestado de Validação em Andamento, onde as verificações são feitas no servidor de origem e de destino para avaliar a prontidão para a migração.

A validação será movida para o estado Bem-sucedido se todas as validações estiverem no estado Êxito ou Aviso .

A grelha de validação contém as seguintes informações:

• Detalhes de validação, por exemplo , e Detalhes de validação para bancos de dados , representando as regras de validação usadas para verificar a prontidão da migração.
• Nome da validação - O nome de cada regra de validação específica.
• Status de validação - Representa o resultado de cada regra e pode ter qualquer um dos três valores:
  • Bem sucedido - Se nenhum erro foi encontrado.
  • Falha - Se houver erros de validação.
  • Aviso - Se houver avisos de validação.
• Duração - Tempo necessário para a operação de validação.
• Hora de início (UTC) e hora de fim (UTC) - Horas de início e fim da operação de validação em UTC.

O status Validação será movido para o estado Falha se houver erros na validação. Selecione o Nome de validação ou a validação do nome do banco de dados que falhou e um painel de distribuição fornece os detalhes e a ação corretiva que você deve tomar para evitar esse erro.

Migrate

Após a conclusão do subestado PerformingPreRequisiteSteps , a migração é movida para o subestado de Migrando dados quando ocorre a clonagem/cópia dos bancos de dados. O tempo para a conclusão da migração depende do tamanho e da forma dos bancos de dados que você está migrando. A migração é rápida se os dados estiverem distribuídos uniformemente em todas as tabelas. Tamanhos de mesa distorcidos levam um tempo relativamente maior.

Quando você seleciona qualquer um dos bancos de dados na migração, um painel de distribuição é exibido. Ele tem todas as contagens de tabelas (copiadas, enfileiradas, copiando e erros) e também o status de migração do banco de dados.

A migração é movida para o estado Bem-sucedido quando o estado Migrando dados é concluído com êxito. Se houver um problema no estado Migrando dados , a migração será movida para um estado Falha .

Depois que a migração for movida para o estado Bem-sucedido, a migração de esquema e dados do Servidor Único para o destino do Servidor Flexível será concluída. Você pode atualizar a página para verificar o progresso.

Validar e migrar

Nessa opção, as validações são executadas primeiro antes do início da migração. Depois que o subestado PerformingPreRequisiteSteps for concluído, o fluxo de trabalho será movido para o subestado de Validação em Andamento.

• Se a validação tiver erros, a migração será movida para um estado Falha .
• Se a validação for concluída sem qualquer erro, a migração será iniciada e o fluxo de trabalho será movido para o subestado de Migrando dados.

Você pode ver os resultados de Validar e Migrar quando a operação for concluída.

Online

Pré-requisitos (online)

Antes de iniciar sua migração com o serviço de migração no Banco de Dados do Azure para PostgreSQL, é essencial cumprir os seguintes pré-requisitos, que se aplicam a cenários de migração offline.

Verifique a versão de origem

A versão do PostgreSQL de origem deve ser >= 9.5. Se a versão de origem do PostgreSQL for menor que 9.5, atualize a versão de origem do PostgreSQL para 9.5 ou superior antes da migração.

Configurar parâmetros de migração online

Para migração online, o suporte à replicação deve ser definido como Lógico nas configurações de replicação do servidor PostgreSQL de origem. Além disso, os parâmetros max_wal_senders e max_replication_slots valores do servidor devem ser maiores do que o número de bancos de dados que precisam ser migrados. Os parâmetros podem ser definidos no portal do Azure em Configurações-Parâmetros> do Servidor ou configurados na linha de comando usando os seguintes comandos:

• ALTER SYSTEM SET wal_level = lógico;
• ALTERAR SISTEMA CONJUNTO max_wal_senders = number of databases to migrate + 1;
• ALTERAR SISTEMA CONJUNTO max_replication_slots = number of databases to migrate + 1;

Certifique-se de que não há transações de longa duração. Transações de longa duração não permitem a criação de slots de replicação. A criação de um slot de replicação será bem-sucedida se todas as transações de longa execução forem confirmadas ou revertidas. Você precisará reiniciar o servidor PostgreSQL de origem depois de concluir todos os pré-requisitos de migração online.

Nota

Para migração online com o Banco de Dados do Azure para servidor único PostgreSQL, o suporte à replicação do Azure é definido como lógico nas configurações de replicação da página de servidor único no portal do Azure.

Para evitar que a migração Online fique sem armazenamento para armazenar os logs, verifique se você tem espaço de tabela suficiente usando um disco gerenciado provisionado. Para conseguir isso, desative o parâmetro azure.enable_temp_tablespaces_on_local_ssd server no servidor flexível durante a migração e restaure-o para o estado original após a migração.

Configurar destino

• O Banco de Dados do Azure para PostgreSQL deve ser configurado no Azure antes da migração.

• A SKU escolhida para o Banco de Dados do Azure para PostgreSQL deve corresponder às especificações do banco de dados de origem para garantir compatibilidade e desempenho adequado.

• Para obter instruções detalhadas sobre como criar um novo Banco de Dados do Azure para PostgreSQL, consulte o seguinte link: Guia de início rápido: criar servidor.

• O parâmetro max_replication_slots server deve ser maior do que o número de bancos de dados que precisam ser migrados. Ele pode ser definido no portal do Azure em Configurações-Parâmetros> do Servidor ou configurado na linha de comando usando o seguinte comando:

• ALTERAR SISTEMA CONJUNTO max_replication_slots = number of databases to migrate + 1;

• Ao migrar entre versões do PostgreSQL (principais ou secundárias), garanta a compatibilidade entre seu banco de dados e o aplicativo revisando as notas de versão para verificar possíveis alterações de rutura.

Importante

Altere o parâmetro password_encryption server em seu servidor flexível de SCRAM-SHA-256 para MD5 antes de iniciar a migração. Isso é essencial para que as credenciais existentes em um único servidor funcionem em seu servidor flexível.

Configurar a rede

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

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

Ativar 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 para sua instância do PostgreSQL de origem. As extensões fornecem funcionalidades e recursos que podem ser necessários para seu aplicativo. Certifique-se de verificar as extensões na instância PostgreSQL de origem 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 do PostgreSQL de origem.

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

Nota

Uma reinicialização é necessária quando você faz alterações no shared_preload_libraries parâmetro.

Parâmetros do servidor

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

• Correlacione os valores dos parâmetros 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.

Desative a alta disponibilidade (confiabilidade) e leia réplicas 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. Quando a migração estiver concluída e o banco de dados estiver estável, você poderá continuar habilitando esses recursos para aprimorar a disponibilidade e a escalabilidade do seu ambiente de banco de dados no Azure.

Nota

Algumas limitações aplicam-se à migração on-line que estão documentadas aqui. Certifique-se de que seu banco de dados esteja em conformidade para executar uma migração online.

Configurar seu Banco de Dados do Azure para servidor flexível PostgreSQL

• Crie o servidor flexível de destino. Para obter as etapas guiadas, consulte o guia de início rápido Criar um banco de dados do Azure para servidor flexível PostgreSQL usando o portal.

• Extensões Allowlist cujas bibliotecas devem ser carregadas no início do servidor. É essencial que a extensão esteja na lista de permissões antes de iniciar uma migração.

• Verifique se a distribuição de dados entre as tabelas de um banco de dados está distorcida, com a maioria dos dados presentes em uma única (ou pouca) tabela. Se for enviesada, a velocidade de migração poderá ser mais lenta do que o esperado. Nesse caso, a velocidade de migração pode ser aumentada migrando a tabela grande em paralelo.

Configurar a tarefa de migração

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

1. Abra o browser e aceda ao portal do Azure. Para iniciar sessão, introduza as suas credenciais. A vista predefinida é o dashboard de serviço.

2. Vá para o seu Banco de Dados do Azure para o destino do Servidor Flexível PostgreSQL.

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

   

4. Selecione o botão Criar para iniciar uma migração de um único servidor para um servidor flexível. Se esta for a primeira vez que você usa o serviço de migração, uma grade vazia será exibida com um prompt para iniciar sua primeira migração.

   

   Se você já criou migrações para o destino Servidor Flexível, a grade contém informações sobre migrações que foram tentadas para esse destino a partir do Servidor Único.

5. Você passa por uma série de guias baseadas em assistente para criar uma migração para esse destino de servidor flexível de diferentes fontes possíveis. Por padrão, o tipo de servidor de origem é definido como Banco de Dados do Azure para Servidor Único PostgreSQL, que é o que nos interessa para este cenário.

Como alternativa, você pode iniciar o processo de migração do Banco de Dados do Azure para o Servidor Único PostgreSQL.

1. Abra o browser e aceda ao portal do Azure. Para iniciar sessão, tem de introduzir as suas credenciais. A vista predefinida é o dashboard de serviço.

2. Ao selecionar o Servidor Único, você pode observar um banner relacionado à migração na guia Visão geral. Selecione Migrar agora para começar.

   

3. Você é direcionado para uma página com duas opções. Se você já criou um Servidor Flexível e deseja usá-lo como destino, escolha Selecionar existente e selecione os detalhes correspondentes de Assinatura, Grupo de recursos e Nome do servidor. Depois que as seleções forem feitas, selecione Ir para o assistente de migração e siga as instruções na seção Configuração .

   

4. Se você optar por criar um novo Servidor Flexível, selecione Criar novo e selecione Ir para o assistente de criação. Esta ação o conduz pelo processo de criação do Servidor Flexível e implanta o Servidor Flexível.

   

Depois de implantar o Servidor Flexível, siga as etapas 3 a 5 em Configurar a tarefa de migração.

Configurar

A primeira guia é Configuração. Caso você tenha perdido, permita listar as extensões necessárias, conforme descrito em Configurar seu Banco de Dados do Azure para servidor flexível PostgreSQL, antes de iniciar uma migração.

O nome da migração é o identificador exclusivo de cada migração para esse destino do Servidor Flexível. Este campo aceita apenas caracteres alfanuméricos e não aceita caracteres especiais, exceto sublinhado (_) e hífen (-). O nome deve começar com um caractere alfanumérico. O nome também deve ser exclusivo para um servidor de destino, porque não há duas migrações para o mesmo destino do Servidor Flexível podem ter o mesmo nome.

O tipo de servidor de origem indica a origem. Neste caso, é o Banco de Dados do Azure para PostgreSQL Single Server

A opção de migração permite executar validações antes de acionar 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 a migração para o destino.
• Migrar - Ignora validações e inicia a migração.
• Validar e migrar - Executa a validação antes de acionar uma migração. A migração só é acionada se não houver falhas de validação.

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

O modo de migração permite que você escolha entre uma migração online e offline, neste caso, deve ser definido como Online.

Quando o modo de migração Online é selecionado, a replicação lógica deve ser ativada no servidor único de origem. Se não estiver ativado, o serviço de migração ativará automaticamente a replicação lógica no servidor único de origem. A replicação também pode ser configurada manualmente selecionando o item Replicação, em Configurações no menu de recursos do Servidor único, e definindo o suporte à replicação do Azure como LÓGICO. Qualquer uma das abordagens reinicia o servidor único de origem.

Selecione o botão Next: Select Runtime Server (Avançar: Selecionar servidor de tempo de execução).

Servidor de tempo de execução

O Servidor de Tempo de Execução 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. É um Banco de Dados do Azure separado para PostgreSQL - instância do 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 Migration Runtime Server.

Selecione o botão Next: Connect to source (Avançar: Conectar ao código-fonte ).

Ligar à origem

A seção Origem solicita que você forneça detalhes relacionados ao Servidor Único, que é a origem dos bancos de dados.

Depois de fazer as seleções de Assinatura e Grupo de Recursos, a lista suspensa para nomes de servidor mostra Servidores Únicos nesse grupo de recursos entre regiões. Selecione a origem da qual deseja migrar bancos de dados. Você pode migrar bancos de dados de um Servidor Único para um Servidor Flexível de destino na mesma região. As migrações entre regiões são habilitadas apenas para servidores da Índia, China e Emirados Árabes Unidos.

Depois de escolher a origem do Servidor Único, as caixas Localização e Versão do PostgreSQL são preenchidas automaticamente. Certifique-se de fornecer as credenciais de uma função de administrador, pois isso é necessário para que o serviço de migração migre com êxito os bancos de dados.

Depois de preencher todos os campos, selecione o link Conectar à fonte . Isso valida se os detalhes do servidor de origem inseridos estão corretos e se o servidor de origem está acessível.

Selecione o botão Next: Select migration target (Avançar: selecionar destino de migração) para continuar.

Selecionar destino de migração

A seção Selecionar destino de migração exibe metadados para o destino Servidor flexível, como Assinatura, Grupo de recursos, Nome do servidor, Local e Versão do PostgreSQL.

Escolha os valores apropriados para o método de autenticação e todos os campos relacionados à autenticação. Certifique-se de que a identidade fornecida é a do usuário administrador no servidor de destino. Depois de preencher todas as informações necessárias, selecione o link Conectar ao destino . Isso valida se os detalhes do servidor de destino inseridos estão corretos e se o servidor de destino está acessível.

Selecione o botão Next: Select database(s) for migration para selecionar os bancos de dados a serem migrados.

Selecionar banco(s) de dados para migração

Nesta guia, há uma lista de bancos de dados de usuários dentro do Servidor Único. 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 para o próximo conjunto de bancos de dados. Os bancos de dados selecionados que existem no servidor de destino com os mesmos nomes exatos são substituídos.

Selecione o botão Seguinte: Resumo para rever os detalhes.

Resumo

A guia Resumo resume todos os detalhes para criar a validação ou migração. Reveja os detalhes e selecione o botão Iniciar Validação e Migração .

Monitorar o portal de migração

Depois de iniciar a migração, uma notificação aparece para dizer que a validação ou a criação da migração foi bem-sucedida. Você será redirecionado automaticamente para a página Migração do Servidor flexível. Isso tem uma nova entrada para a validação ou migração criada recentemente.

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, Hora de início e Duração. 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 Atualizar para atualizar o status da validação ou migração.

Você também pode selecionar o nome de uma migração específica na grade para ver os detalhes associados.

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

Vejamos como monitorar as migrações para cada opção de migração.

Validar

Depois que o subestado PerformingPreRequisiteSteps for concluído, a validação será movida para o subestado de Validação em Andamento, onde as verificações são feitas no servidor de origem e de destino para avaliar a prontidão para a migração.

A validação será movida para o estado Bem-sucedido se todas as validações estiverem no estado Êxito ou Aviso .

A grelha de validação contém as seguintes informações:

• Detalhes de validação, por exemplo , e Detalhes de validação para bancos de dados , representando as regras de validação usadas para verificar a prontidão da migração.
• Nome da validação - O nome de cada regra de validação específica.
• Status de validação - Representa o resultado de cada regra e pode ter qualquer um dos três valores:
  • Bem sucedido - Se nenhum erro foi encontrado.
  • Falha - Se houver erros de validação.
  • Aviso - Se houver avisos de validação.
• Duração - Tempo necessário para a operação de validação.
• Hora de início (UTC) e hora de fim (UTC) - Horas de início e fim da operação de validação em UTC.

O status Validação será movido para o estado Falha se houver erros na validação. Selecione o Nome de validação ou a validação do nome do banco de dados que falhou e um painel de distribuição fornece os detalhes e a ação corretiva que você deve tomar para evitar esse erro.

Migrate

Após a conclusão do subestado PerformingPreRequisiteSteps , a migração é movida para o subestado de Migrando dados quando ocorre a clonagem/cópia dos bancos de dados. O tempo para a conclusão da migração depende do tamanho e da forma dos bancos de dados que você está migrando. A migração é rápida se os dados estiverem distribuídos uniformemente em todas as tabelas. Tamanhos de mesa distorcidos levam um tempo relativamente maior.

Quando você seleciona qualquer um dos bancos de dados na migração, um painel de distribuição é exibido. Ele tem todas as contagens de tabelas (copiadas, enfileiradas, copiando e erros) e também o status de migração do banco de dados.

A migração é movida para o estado Bem-sucedido quando o estado Migrando dados é concluído com êxito. Se houver um problema no estado Migrando dados , a migração será movida para um estado Falha .

Depois que a migração for movida para o estado Bem-sucedido, a migração de esquema e dados do Servidor Único para o destino do Servidor Flexível será concluída. Você pode atualizar a página para verificar o progresso.

Validar e migrar

Nessa opção, as validações são executadas primeiro antes do início da migração. Depois que o subestado PerformingPreRequisiteSteps for concluído, o fluxo de trabalho será movido para o subestado de Validação em Andamento.

• Se a validação tiver erros, a migração será movida para um estado Falha .
• Se a validação for concluída sem qualquer erro, a migração será iniciada e o fluxo de trabalho será movido para o subestado de Migrando dados.

Você pode ver os resultados de Validar e Migrar quando a operação for concluída.

Migração de substituição

Para as opções de migração Migrar e Validar e Migrar , a conclusão da migração online exige que o usuário conclua uma etapa adicional, que é acionar a ação de substituição. Após a conclusão da cópia/clone dos dados base, a migração é movida para o estado WaitingForUserAction e o subestado 'WaitingForCutoverTrigger . Nesse estado, o usuário pode acionar a substituição do portal selecionando a migração e selecionando o botão Substituição .

Antes de iniciar o corte, é essencial garantir que:

• As gravações na fonte são interrompidas -Latency (minutes) o parâmetro é 0 ou próximo de 0 As Latency (minutes) informações podem ser obtidas na tela de detalhes da migração:

Latency (minutes) indica quando o destino foi sincronizado pela última vez com a origem. Por exemplo, para o banco de dados Pedidos acima, é 0,33333. Isso significa que as alterações que ocorreram nos últimos ~0,3 minutos na origem ainda não foram enviadas para o destino, para o banco de dados de Pedidos . Neste ponto, as gravações na fonte podem ser interrompidas e a transferência iniciada. No caso de haver tráfego intenso na origem, recomenda-se parar as gravações primeiro para que Latency (minutes) possam chegar perto de 0 e só então iniciar a substituição. 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 latência diferente de zero, a replicação será interrompida até esse momento. Todos os dados na origem até o ponto de corte são então aplicados ao destino. Digamos que uma latência foi de 15 minutos no ponto de transferência, portanto, todos os dados alterados nos últimos 15 minutos são aplicados ao destino. O tempo gasto depende do acúmulo de alterações ocorridas nos últimos 15 minutos. Por isso, recomenda-se que a latência seja zero ou quase zero, antes de acionar o cutover.

A migração é movida para o estado Bem-sucedido assim que o subestado Migrando dados ou a substituição (no modo de migração online) é concluída com êxito. Se houver um problema no subestado Migrando dados , a migração será movida para um estado Falha .

Os possíveis estados de migração incluem:

• InProgress: A configuração da infraestrutura de migração está em andamento ou a migração de dados real está em andamento.
• Cancelado: a migração é cancelada ou excluída.
• Falha: A migração falhou.
• Falha na validação: A validação falhou.
• Êxito: a migração foi bem-sucedida e está concluída.

Os possíveis subestados de migração incluem:

• PerformingPreRequisiteSteps: A configuração da infraestrutura está em andamento para a migração de dados.
• Validação em Curso: A validação está em curso.
• MigratingData: A migração de dados está em andamento.
• CompletingMigration: A migração está em fase final de conclusão.
• Concluído: A migração foi concluída com êxito.

Cancelar a migração usando o portal

Você pode cancelar todas as validações ou migrações em andamento. O fluxo de trabalho deve estar no estado InProgress para ser cancelado. Não é possível cancelar uma validação ou migração que esteja no estado Bem-sucedido ou Reprovado .

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 a atividade de migração adicional no servidor de destino e passa para um estado Cancelado . A ação cancelar reverterá todas as alterações feitas pelo serviço de migração no servidor de destino.

CLI

Você pode migrar usando a CLI do Azure.

Offline

Pré-requisitos (offline)

Antes de iniciar a migração com o serviço de migração no Banco de Dados do Azure para PostgreSQL, você deve cumprir os seguintes pré-requisitos, que se aplicam a cenários de migração offline.

Verifique a versão de origem

A versão do PostgreSQL de origem deve ser >= 9.5. Se a versão de origem do PostgreSQL for menor que 9.5, atualize a versão de origem do PostgreSQL para 9.5 ou superior antes da migração.

Configuração de destino

• O servidor flexível do Banco de Dados do Azure para PostgreSQL deve ser implantado e configurado corretamente no Azure antes de iniciar o processo de migração.

• A SKU escolhida para o Banco de Dados do Azure para PostgreSQL deve corresponder às especificações do banco de dados de origem para garantir compatibilidade e desempenho adequado.

• Para obter instruções detalhadas sobre como criar um novo Banco de Dados do Azure para PostgreSQL, consulte o seguinte link: Guia de início rápido: criar servidor.

• Ao migrar entre versões do PostgreSQL (principais ou secundárias), garanta a compatibilidade entre seu banco de dados e o aplicativo revisando as notas de versão para verificar possíveis alterações de rutura.

Configuração da rede

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

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

Ativar 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 para sua instância do PostgreSQL de origem. As extensões fornecem funcionalidades e recursos que podem ser necessários para seu aplicativo. Certifique-se de verificar as extensões na instância PostgreSQL de origem 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 do PostgreSQL de origem.

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

Nota

Uma reinicialização é necessária quando você faz alterações no shared_preload_libraries parâmetro.

Verifique os parâmetros do servidor

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

• Coracione os valores dos parâmetros 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, se necessário, reinicie o Banco de Dados do Azure para servidor flexível PostgreSQL para aplicar a nova configuração.

Importante

Altere o parâmetro password_encryption server em seu servidor flexível de SCRAM-SHA-256 para MD5 antes de iniciar a migração. Isso é essencial para que as credenciais existentes em um único servidor funcionem em seu servidor flexível.

Desative a alta disponibilidade (confiabilidade) e leia réplicas no destino

• Desabilitar a alta disponibilidade (confiabilidade) e as réplicas de leitura 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 adicionais introduzidas pela alta disponibilidade e réplicas de leitura. Quando a migração estiver concluída e o banco de dados estiver estável, você poderá continuar habilitando esses recursos para aprimorar a disponibilidade e a escalabilidade do seu ambiente de banco de dados no Azure.

Começar agora

1. Se você é novo no Microsoft Azure, crie uma conta para avaliar as ofertas.

2. Instale a CLI do Azure mais recente para o seu sistema operativo a partir da página de instalação da CLI do Azure.

   Se a CLI do Azure já estiver instalada, verifique a versão usando o az version comando. A versão deve ser 2.50.0 ou posterior para usar os comandos da CLI de migração. Caso contrário, atualize sua versão da CLI do Azure.

3. Execute o az login comando:

   az login
   

   Uma janela do navegador é aberta com a página de entrada do Azure. Forneça suas credenciais do Azure para fazer uma autenticação bem-sucedida. Para obter outras maneiras de assinar com a CLI do Azure, consulte este artigo.

Comandos da CLI de migração (offline)

O serviço de migração vem com comandos CLI fáceis de usar para executar tarefas relacionadas à migração. Todos os comandos da CLI começam com az postgres flexible-server migration. É importante permitir a lista das extensões antes de iniciar uma migração.

Para obter ajuda com a compreensão das opções associadas a um comando e com o enquadramento da sintaxe correta, você pode usar o --help parâmetro:

az postgres flexible-server migration --help

A execução do comando anterior retorna a seguinte saída:

A saída lista os comandos de migração suportados, juntamente com suas ações. Vamos examinar esses comandos em detalhes.

Criar uma migração usando a CLI do Azure

O create comando ajuda na criação de uma migração de um servidor de origem para um servidor de destino:

az postgres flexible-server migration create --help

A execução do comando anterior retorna a seguinte saída:

Ele lista os argumentos esperados e tem uma sintaxe de exemplo para criar com êxito uma migração do servidor de origem para o servidor de destino. Aqui está o comando CLI para criar uma nova migração:

az postgres flexible-server migration create [--subscription]
                                             [--resource-group]
                                             [--name]
                                             [--migration-name]
                                             [--migration-mode]
                                             [--properties]

Parâmetro	Description
subscription	ID de assinatura do destino Servidor flexível.
resource-group	Grupo de recursos do destino Servidor flexível.
name	Nome do destino Servidor flexível.
migration-name	Identificador exclusivo para cada migração para este destino de Servidor Flexível. Este campo aceita apenas caracteres alfanuméricos e não aceita caracteres especiais, exceto sublinhado (_) e hífen (-). O nome deve começar e terminar com um caractere alfanumérico. O nome também deve ser exclusivo para um servidor de destino, porque não há duas migrações para o mesmo destino do Servidor Flexível podem ter o mesmo nome.
migration-mode	Este é um parâmetro opcional. Valor padrão: Offline. A migração offline envolve a cópia dos bancos de dados de origem em um determinado momento para o servidor de destino.
properties	Caminho absoluto para um arquivo JSON que contém as informações sobre a origem do Servidor Único.

Por exemplo:

az postgres flexible-server migration create --subscription 11111111-1111-1111-1111-111111111111 --resource-group my-learning-rg --name myflexibleserver --migration-name migration1 --properties "./migrationBody.json" --migration-mode offline

O migration-name argumento usado no create comando é usado em outros comandos da CLI, como update, deletee show. identifica exclusivamente a tentativa de migração nas ações correspondentes em todos esses comandos.

Finalmente, o create comando precisa de um arquivo JSON para ser passado como parte de seu properties argumento.

A estrutura da JSON é:

{
	"properties": {
		"sourceDbServerResourceId": "/subscriptions/<subscriptionid>/resourceGroups/<sourceServerResourceGroup>/providers/Microsoft.DBforPostgreSQL/servers/<sourceServer>",
		"secretParameters": {
			"adminCredentials": {
				"sourceServerPassword": "<password>",
				"targetServerPassword": "<password>"
			},
			"sourceServerUserName": "<username>@<servername>",
			"targetServerUserName": "<username>"
		},
		"dbsToMigrate": [
			"<db1>",
			"<db2>"
		],
		"overwriteDbsInTarget": "true"
	}
}

Os create parâmetros que entram no formato de arquivo JSON são os mostrados abaixo:

Parâmetro	Tipo	Descrição
sourceDbServerResourceId	Obrigatório	Este parâmetro é a ID do recurso da fonte do Servidor Único.
adminCredentials	Necessário	Este parâmetro lista senhas para usuários administradores para a origem Servidor Único e o destino Servidor Flexível. Essas senhas ajudam a autenticar nos servidores de origem e de destino.
sourceServerUserName	Necessário	O valor padrão é o usuário admin especificado durante a criação de um único servidor, e a senha fornecida é usada para autenticação com esse usuário. Se você não estiver usando o usuário padrão, esse parâmetro será o usuário ou a função no servidor de origem para executar a migração. Esse usuário deve ter os privilégios necessários e a propriedade dos objetos de banco de dados envolvidos na migração e deve ser um membro da função azure_pg_admin .
targetServerUserName	Necessário	O valor padrão é o usuário admin criado durante a criação de um servidor flexível, e a senha fornecida é usada para autenticação com esse usuário. Caso você não esteja usando o usuário padrão, esse parâmetro é o usuário ou função no servidor de destino usado para executar a migração. Esse usuário deve ser membro de azure_pg_admin, pg_read_all_settings, pg_read_all_stats.pg_stat_scan_tables funções e deve ter a função Criar, Criar atributos de banco de dados.
dbsToMigrate	Necessário	Especifique a lista de bancos de dados que você deseja migrar para o Servidor Flexível. Somente bancos de dados de usuários são migrados. Bancos de dados do sistema ou bancos de dados de modelo, como template0 e template1, não são migrados.
overwriteDbsInTarget	Necessário	Quando definido como true, se o servidor de destino tiver um banco de dados existente com o mesmo nome daquele que você está tentando migrar, o serviço de migração substituirá automaticamente o banco de dados.
setupLogicalReplicationOnSourceDBIfNeeded	Opcional	Você pode habilitar automaticamente a replicação lógica no servidor de origem definindo essa propriedade como true. Essa alteração nas configurações do servidor requer uma reinicialização do servidor com dois a três minutos de tempo de inatividade.
sourceDBServerFullyQualifiedDomainName	Opcional	Use-o quando um servidor DNS personalizado for usado para resolução de nomes para uma rede virtual. Forneça o FQDN da origem do Servidor Único de acordo com o servidor DNS personalizado para esta propriedade.
targetDBServerFullyQualifiedDomainName	Opcional	Use-o quando um servidor DNS personalizado for usado para resolução de nomes dentro de uma rede virtual. Forneça o FQDN do destino do Servidor Flexível de acordo com o servidor DNS personalizado. sourceDBServerFullyQualifiedDomainName e targetDBServerFullyQualifiedDomainName são incluídos como parte do JSON somente no raro cenário em que um servidor DNS personalizado é usado para resolução de nomes em vez do DNS fornecido pelo Azure. Caso contrário, não inclua esses parâmetros no arquivo JSON.

Observe estes pontos essenciais para a resposta do comando:

• Quando o create comando é acionado, a migração é movida para o InProgress estado e o PerformingPreRequisiteSteps subestado. O fluxo de trabalho de migração leva alguns minutos para implantar a infraestrutura de migração e configurar conexões entre a origem e o destino.
• Após a conclusão do PerformingPreRequisiteSteps subestado, a migração é movida para o subestado onde Migrating Data, ocorre a clonagem/cópia dos bancos de dados.
• Cada banco de dados migrado tem sua própria seção com todos os detalhes da migração, como contagem de tabelas, inserções incrementais, exclusões e bytes pendentes.
• O tempo que o Migrating Data subestado leva para concluir depende do tamanho dos bancos de dados que são migrados.
• A migração é movida para o Succeeded estado assim que o Migrating Data subestado é concluído com êxito. Se houver um problema no Migrating Data subestado, a migração passa para um Failed estado.

Listar as migrações

O list comando lista todas as tentativas de migração feitas para um destino de servidor flexível:

az postgres flexible-server migration list [--subscription]
                                           [--resource-group]
                                           [--name]
                                           [--filter]

O filter parâmetro tem duas opções:

• Active: Lista as tentativas de migração ativas (em andamento) atuais para o servidor de destino. Ele não inclui as migrações que falharam, foram canceladas ou bem-sucedidas.
• All: Lista todas as tentativas de migração para o servidor de destino. Isso inclui as migrações ativas e concluídas, independentemente do estado.

Para obter mais informações sobre esse comando, use o --help parâmetro:

az postgres flexible-server migration list --help

Monitorize a migração

O --show comando ajuda a monitorar as migrações em curso e fornece o estado atual e o subestado da migração.

az postgres flexible-server migration show [--subscription]
                                           [--resource-group]
                                           [--name]
                                           [--migration-name]

O migration_name parâmetro é o nome atribuído à migração durante o create comando. Aqui está um instantâneo da resposta de exemplo do comando CLI para mostrar detalhes:

Para obter mais informações sobre esse comando, use o --help parâmetro:

 az postgres flexible-server migration show --help

As tabelas a seguir descrevem os estados e subestados de migração.

Estado da migração	Description
InProgress	A infraestrutura de migração está configurada ou a migração de dados real está em andamento.
Canceled	A migração é cancelada ou excluída.
Failed	A migração falhou.
Succeeded	A migração foi bem-sucedida e está concluída.
ValidationFailed	A migração falhou durante a validação pré-migração.

Subestado de migração	Description
PerformingPreRequisiteSteps	A infraestrutura está configurada e preparada para a migração de dados.
MigratingData	A migração de dados está em andamento.
CompletingMigration	Conclusão do processo de migração.
Completed	A migração está concluída, seja em um estado bem-sucedido ou não.
CancelingRequestedDBMigrations	Cancelar a migração.
ValidationInProgress	A validação está em curso.

Online

Pré-requisitos (online)

Antes de iniciar sua migração com o serviço de migração no Banco de Dados do Azure para PostgreSQL, é essencial cumprir os seguintes pré-requisitos, que se aplicam a cenários de migração offline.

Verifique a versão de origem

A versão do PostgreSQL de origem deve ser >= 9.5. Se a versão de origem do PostgreSQL for menor que 9.5, atualize a versão de origem do PostgreSQL para 9.5 ou superior antes da migração.

Configurar parâmetros de migração online

Para migração online, o suporte à replicação deve ser definido como Lógico nas configurações de replicação do servidor PostgreSQL de origem. Além disso, os parâmetros max_wal_senders e max_replication_slots valores do servidor devem ser maiores do que o número de bancos de dados que precisam ser migrados. Os parâmetros podem ser definidos no portal do Azure em Configurações-Parâmetros> do Servidor ou configurados na linha de comando usando os seguintes comandos:

• ALTER SYSTEM SET wal_level = lógico;
• ALTERAR SISTEMA CONJUNTO max_wal_senders = number of databases to migrate + 1;
• ALTERAR SISTEMA CONJUNTO max_replication_slots = number of databases to migrate + 1;

Certifique-se de que não há transações de longa duração. Transações de longa duração não permitem a criação de slots de replicação. A criação de um slot de replicação será bem-sucedida se todas as transações de longa execução forem confirmadas ou revertidas. Você precisará reiniciar o servidor PostgreSQL de origem depois de concluir todos os pré-requisitos de migração online.

Nota

Para migração online com o Banco de Dados do Azure para servidor único PostgreSQL, o suporte à replicação do Azure é definido como lógico nas configurações de replicação da página de servidor único no portal do Azure.

Para evitar que a migração Online fique sem armazenamento para armazenar os logs, verifique se você tem espaço de tabela suficiente usando um disco gerenciado provisionado. Para conseguir isso, desative o parâmetro azure.enable_temp_tablespaces_on_local_ssd server no servidor flexível durante a migração e restaure-o para o estado original após a migração.

Configurar destino

• O Banco de Dados do Azure para PostgreSQL deve ser configurado no Azure antes da migração.

• A SKU escolhida para o Banco de Dados do Azure para PostgreSQL deve corresponder às especificações do banco de dados de origem para garantir compatibilidade e desempenho adequado.

• Para obter instruções detalhadas sobre como criar um novo Banco de Dados do Azure para PostgreSQL, consulte o seguinte link: Guia de início rápido: criar servidor.

• O parâmetro max_replication_slots server deve ser maior do que o número de bancos de dados que precisam ser migrados. Ele pode ser definido no portal do Azure em Configurações-Parâmetros> do Servidor ou configurado na linha de comando usando o seguinte comando:

• ALTERAR SISTEMA CONJUNTO max_replication_slots = number of databases to migrate + 1;

• Ao migrar entre versões do PostgreSQL (principais ou secundárias), garanta a compatibilidade entre seu banco de dados e o aplicativo revisando as notas de versão para verificar possíveis alterações de rutura.

Importante

Altere o parâmetro password_encryption server em seu servidor flexível de SCRAM-SHA-256 para MD5 antes de iniciar a migração. Isso é essencial para que as credenciais existentes em um único servidor funcionem em seu servidor flexível.

Configurar a rede

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

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

Ativar 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 para sua instância do PostgreSQL de origem. As extensões fornecem funcionalidades e recursos que podem ser necessários para seu aplicativo. Certifique-se de verificar as extensões na instância PostgreSQL de origem 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 do PostgreSQL de origem.

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

Nota

Uma reinicialização é necessária quando você faz alterações no shared_preload_libraries parâmetro.

Parâmetros do servidor

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

• Correlacione os valores dos parâmetros 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.

Desative a alta disponibilidade (confiabilidade) e leia réplicas 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. Quando a migração estiver concluída e o banco de dados estiver estável, você poderá continuar habilitando esses recursos para aprimorar a disponibilidade e a escalabilidade do seu ambiente de banco de dados no Azure.

Nota

Algumas limitações aplicam-se à migração on-line que estão documentadas aqui. Certifique-se de que seu banco de dados esteja em conformidade para executar uma migração online.

Começar agora

1. Se você é novo no Microsoft Azure, crie uma conta para avaliar as ofertas.

2. Instale a CLI do Azure mais recente para o seu sistema operativo a partir da página de instalação da CLI do Azure.

   Se a CLI do Azure já estiver instalada, verifique a versão usando o az version comando. A versão deve ser 2.50.0 ou posterior para usar os comandos da CLI de migração. Caso contrário, atualize sua versão da CLI do Azure.

3. Execute o az login comando:

   az login
   

   Uma janela do navegador é aberta com a página de entrada do Azure. Forneça suas credenciais do Azure para fazer uma autenticação bem-sucedida. Para obter outras maneiras de assinar com a CLI do Azure, consulte este artigo.

Comandos da CLI de migração (online)

O serviço de migração vem com comandos CLI fáceis de usar para executar tarefas relacionadas à migração. Todos os comandos da CLI começam com az postgres flexible-server migration. É importante permitir a lista das extensões antes de iniciar uma migração.

Para obter ajuda com a compreensão das opções associadas a um comando e com o enquadramento da sintaxe correta, você pode usar o --help parâmetro:

az postgres flexible-server migration --help

A execução do comando anterior retorna a seguinte saída:

A saída lista os comandos de migração suportados, juntamente com suas ações. Vamos examinar esses comandos em detalhes.

Criar uma migração usando a CLI do Azure

O create comando ajuda na criação de uma migração de um servidor de origem para um servidor de destino:

az postgres flexible-server migration create --help

A execução do comando anterior retorna a seguinte saída:

Ele lista os argumentos esperados e tem uma sintaxe de exemplo para criar com êxito uma migração do servidor de origem para o servidor de destino. Aqui está o comando CLI para criar uma nova migração:

az postgres flexible-server migration create [--subscription]
                                             [--resource-group]
                                             [--name]
                                             [--migration-name]
                                             [--migration-mode]
                                             [--properties]

Parâmetro	Description
subscription	ID de assinatura do destino Servidor flexível.
resource-group	Grupo de recursos do destino Servidor flexível.
name	Nome do destino Servidor flexível.
migration-name	Identificador exclusivo para cada migração para este destino de Servidor Flexível. Este campo aceita apenas caracteres alfanuméricos e não aceita caracteres especiais, exceto sublinhado (_) e hífen (-). O nome deve começar e terminar com um caractere alfanumérico. O nome também deve ser exclusivo para um servidor de destino, porque não há duas migrações para o mesmo destino do Servidor Flexível podem ter o mesmo nome.
migration-mode	Este é um parâmetro opcional. O valor predefinido é Offline. Para migrações on-line você tem que passar Online.
properties	Caminho absoluto para um arquivo JSON que contém as informações sobre a origem do Servidor Único.

Por exemplo:

az postgres flexible-server migration create --subscription 11111111-1111-1111-1111-111111111111 --resource-group my-learning-rg --name myflexibleserver --migration-name migration1 --properties "./migrationBody.json" --migration-mode online

O migration-name argumento usado no create comando é usado em outros comandos da CLI, como update, deletee show. identifica exclusivamente a tentativa de migração nas ações correspondentes em todos esses comandos.

Finalmente, o create comando precisa de um arquivo JSON para ser passado como parte de seu properties argumento.

A estrutura da JSON é:

{
  "properties": {
    "sourceDbServerResourceId": "/subscriptions/<subscriptionid>/resourceGroups/<sourceServerResourceGroup>/providers/Microsoft.DBforPostgreSQL/servers/<sourceServer>",
    "secretParameters": {
      "adminCredentials": {
        "sourceServerPassword": "<password>",
        "targetServerPassword": "<password>"
      }
    },
    "sourceServerUserName": "<username>@<servername>",
    "targetServerUserName": "<username>",
    "dbsToMigrate": ["<db1>", "<db2>"],
    "overwriteDbsInTarget": "true"
  }
}

Os create parâmetros que entram no formato de arquivo JSON são os mostrados abaixo:

Parâmetro	Tipo	Descrição
sourceDbServerResourceId	Obrigatório	Este parâmetro é a ID do recurso da fonte do Servidor Único.
adminCredentials	Necessário	Este parâmetro lista senhas para usuários administradores para a origem Servidor Único e o destino Servidor Flexível. Essas senhas ajudam a autenticar nos servidores de origem e de destino.
sourceServerUserName	Necessário	O valor padrão é o usuário admin especificado durante a criação de um único servidor, e a senha fornecida é usada para autenticação com esse usuário. Se você não estiver usando o usuário padrão, esse parâmetro será o usuário ou a função no servidor de origem para executar a migração. Esse usuário deve ter os privilégios necessários e a propriedade dos objetos de banco de dados envolvidos na migração e deve ser um membro da função azure_pg_admin .
targetServerUserName	Necessário	O valor padrão é o usuário admin criado durante a criação de um servidor flexível, e a senha fornecida é usada para autenticação com esse usuário. Caso você não esteja usando o usuário padrão, esse parâmetro é o usuário ou função no servidor de destino usado para executar a migração. Esse usuário deve ser membro de azure_pg_admin, pg_read_all_settings, pg_read_all_stats.pg_stat_scan_tables funções e deve ter a função Criar, Criar atributos de banco de dados.
dbsToMigrate	Necessário	Especifique a lista de bancos de dados que você deseja migrar para o Servidor Flexível. Somente bancos de dados de usuários são migrados. Bancos de dados do sistema ou bancos de dados de modelo, como template0 e template1, não são migrados.
overwriteDbsInTarget	Necessário	Quando definido como true, se o servidor de destino tiver um banco de dados existente com o mesmo nome daquele que você está tentando migrar, o serviço de migração substituirá automaticamente o banco de dados.
setupLogicalReplicationOnSourceDBIfNeeded	Opcional	Você pode habilitar automaticamente a replicação lógica no servidor de origem definindo essa propriedade como true. Essa alteração nas configurações do servidor requer uma reinicialização do servidor com dois a três minutos de tempo de inatividade.
sourceDBServerFullyQualifiedDomainName	Opcional	Use-o quando um servidor DNS personalizado for usado para resolução de nomes para uma rede virtual. Forneça o FQDN da origem do Servidor Único de acordo com o servidor DNS personalizado para esta propriedade.
targetDBServerFullyQualifiedDomainName	Opcional	Use-o quando um servidor DNS personalizado for usado para resolução de nomes dentro de uma rede virtual. Forneça o FQDN do destino do Servidor Flexível de acordo com o servidor DNS personalizado. sourceDBServerFullyQualifiedDomainName e targetDBServerFullyQualifiedDomainName são incluídos como parte do JSON somente no raro cenário em que um servidor DNS personalizado é usado para resolução de nomes em vez do DNS fornecido pelo Azure. Caso contrário, não inclua esses parâmetros no arquivo JSON.

Observe estes pontos essenciais para a resposta do comando:

• Quando o create comando é acionado, a migração é movida para o InProgress estado e o PerformingPreRequisiteSteps subestado. O fluxo de trabalho de migração leva alguns minutos para implantar a infraestrutura de migração e configurar conexões entre a origem e o destino.
• Após a conclusão do PerformingPreRequisiteSteps subestado, a migração é movida para o subestado onde Migrating Data, ocorre a clonagem/cópia dos bancos de dados.
• Cada banco de dados migrado tem sua própria seção com todos os detalhes da migração, como contagem de tabelas, inserções incrementais, exclusões e bytes pendentes.
• O tempo que o Migrating Data subestado leva para concluir depende do tamanho dos bancos de dados que são migrados.
• A migração é movida para o Succeeded estado assim que o Migrating Data subestado é concluído com êxito. Se houver um problema no Migrating Data subestado, a migração passa para um Failed estado.

Configurar replicação

Para o modo de migração online, a replicação lógica deve ser ativada no servidor único de origem. Se não estiver ativado, o serviço de migração ativará automaticamente a replicação lógica no servidor único de origem quando o setupLogicalReplicationOnSourceDBIfNeeded parâmetro for passado com um valor de true no arquivo JSON que o acompanha. A replicação também pode ser configurada manualmente na origem depois de iniciar a migração usando o comando abaixo. Qualquer uma das abordagens de ativação da replicação lógica reinicia o servidor único de origem.

Por exemplo:

az postgres flexible-server migration update --subscription 11111111-1111-1111-1111-111111111111 --resource-group my-learning-rg --name myflexibleserver --migration-name CLIMigrationExample --setup-replication

Este comando é necessário para avançar a migração quando o servidor flexível está aguardando no WaitingForLogicalReplicationSetupRequestOnSourceDB estado.

Para executar a migração online, use:

az postgres flexible-server migration create --subscription 11111111-1111-1111-1111-111111111111 --resource-group my-learning-rg --name myflexibleserver --migration-name migration1 --properties "./migrationBody.json" --migration-mode online

Listar as migrações

O list comando lista todas as tentativas de migração feitas para um destino de servidor flexível:

az postgres flexible-server migration list [--subscription]
                                           [--resource-group]
                                           [--name]
                                           [--filter]

O filter parâmetro tem duas opções:

• Active: Lista as tentativas de migração ativas (em andamento) atuais para o servidor de destino. Ele não inclui as migrações que falharam, foram canceladas ou bem-sucedidas.
• All: Lista todas as tentativas de migração para o servidor de destino. Isso inclui as migrações ativas e concluídas, independentemente do estado.

Para obter mais informações sobre esse comando, use o --help parâmetro:

az postgres flexible-server migration list --help

Monitorar as migrações

O show comando ajuda a monitorar as migrações em curso e fornece o estado atual e o subestado da migração.

az postgres flexible-server migration show [--subscription]
                                           [--resource-group]
                                           [--name]
                                           [--migration-name]

O migration_name parâmetro é o nome atribuído à migração durante o create comando. Aqui está um instantâneo da resposta de exemplo do comando CLI para monitorar a migração:

Para obter mais informações sobre esse comando, use o --help parâmetro:

 az postgres flexible-server migration show --help

As tabelas a seguir descrevem os estados e subestados de migração.

Estado da migração	Description
InProgress	A infraestrutura de migração está configurada ou a migração de dados real está em andamento.
Canceled	A migração é cancelada ou excluída.
Failed	A migração falhou.
Succeeded	A migração foi bem-sucedida e está concluída.
ValidationFailed	A migração falhou durante a validação pré-migração.

Subestado de migração	Description
PerformingPreRequisiteSteps	A infraestrutura está configurada e preparada para a migração de dados.
MigratingData	A migração de dados está em andamento.
WaitingForCutoverTrigger	Tarefa de migração de dados concluída e aguardando o usuário acionar a substituição.
CompletingMigration	Conclusão do processo de migração.
Completed	A migração está concluída, seja em um estado bem-sucedido ou não.
CancelingRequestedDBMigrations	Cancelar a migração.
ValidationInProgress	A validação está em curso.

Anulação das migrações

Nas migrações online, após a conclusão da migração de dados de base, a tarefa de migração é movida para WaitingForCutoverTrigger o subestado. Nesse estado, o usuário pode acionar a substituição através da CLI usando o comando abaixo. A substituição também pode ser acionada a partir do portal selecionando o nome da migração na grade de migração.

Por exemplo:

az postgres flexible-server migration update --subscription 11111111-1111-1111-1111-111111111111 --resource-group my-learning-rg --name myflexibleserver --migration-name CLIMigrationExample --cutover

Antes de iniciar o corte, é essencial garantir que:

• As gravações na fonte são interrompidas -latency o parâmetro é 0 ou próximo de 0

latency indica quando o destino foi sincronizado pela última vez com a origem. Por exemplo, aqui é 201 e 202 para os dois bancos de dados, como mostrado na imagem abaixo. Isso significa que as alterações que ocorreram nos últimos ~200 segundos na origem ainda não foram sincronizadas com o destino. Neste ponto, as gravações na fonte podem ser interrompidas e a transferência iniciada. No caso de haver tráfego intenso na origem, recomenda-se parar as gravações primeiro para que Latency possa chegar perto de 0 e, em seguida, a substituição é 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 diferente de zero Latency, a replicação será interrompida até esse momento. Todos os dados na origem até o ponto de corte são então aplicados ao destino. Digamos que uma latência foi de 15 minutos no ponto de transferência, portanto, todos os dados de alteração nos últimos 15 minutos se aplicam ao destino. O tempo necessário depende da acumulação de alterações ocorridas nos últimos 15 minutos. Por isso, recomenda-se que a latência vá para zero ou perto de zero, antes de acionar o cutover. As latency informações podem ser obtidas usando o comando migration show.

Aqui está um instantâneo da migração antes de iniciar a substituição:

Depois que a transferência é iniciada, todas as transações que aconteceram durante a cópia base são copiadas sequencialmente para o destino e a migração é concluída.

Se a transferência não for bem-sucedida, a migração será transferida para o Failed estado.

Para obter mais informações sobre esse comando, use o --help parâmetro:

 az postgres flexible-server migration update --help

Cancelar a migração usando a CLI

Você pode cancelar todas as tentativas de migração em andamento usando o cancel comando. Este comando interrompe a tentativa de migração específica e reverte todas as alterações no servidor de destino. Aqui está o comando da CLI para cancelar uma migração:

az postgres flexible-server migration update cancel [--subscription]
                                                    [--resource-group]
                                                    [--name]
                                                    [--migration-name]

Por exemplo:

az postgres flexible-server migration update cancel --subscription 11111111-1111-1111-1111-111111111111 --resource-group my-learning-rg --name myflexibleserver --migration-name migration1

Para obter mais informações sobre esse comando, use o --help parâmetro:

 az postgres flexible-server migration update cancel --help

O comando fornece a seguinte saída:

Verifique a migração depois de concluída

Após uma migração bem-sucedida, certifique-se de que pode iniciar sessão no seu servidor flexível utilizando as mesmas credenciais que no servidor único. Se você estiver encontrando erros de autenticação em seu servidor flexível depois de migrar de um único servidor, isso pode ser devido à VM do servidor flexível ser compatível com FIPS ou usar um algoritmo de criptografia de senha diferente (SCRAM-SHA-256) em comparação com a criptografia MD5 do servidor único. Para mitigar este problema, siga estes passos:

1. Altere o parâmetro do servidor password_encryption em seu servidor flexível de SCRAM-SHA-256 para MD5.
2. Reinicie a migração do seu servidor único para o servidor flexível.
3. Se os problemas de autenticação persistirem, exclua o servidor flexível existente e provisione um novo. Repita as etapas 1 e 2 para resolver o problema.

Isso deve resolver os erros de autenticação.

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

• Verifique os dados em seu servidor flexível e certifique-se de que é uma cópia exata da instância de origem.

• Após a verificação, ative a opção de alta disponibilidade em seu servidor flexível, conforme necessário.

• Altere a SKU do servidor flexível para corresponder às necessidades do aplicativo. Essa alteração precisa ser reiniciada pelo servidor de banco de dados.

• Se você alterar quaisquer parâmetros do servidor de seus valores padrão na instância de origem, copie esses valores de parâmetro do servidor no servidor flexível.

• Copie outras configurações do servidor, como tags, 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 requer ajuste de desempenho.

Conteúdos relacionados

• Serviço de migração
• Migrar do AWS RDS
• Melhores práticas
• Problemas conhecidos e limitações
• Configuração da rede
• Validações pré-migração