Tutorial: Migrar do Banco de Dados do Azure para PostgreSQL - Servidor Único para o Banco de Dados do Azure para PostgreSQL - Servidor Flexível usando 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 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.

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

Configuração da rede

A configuração de rede adequada é essencial para garantir uma conectividade bem-sucedida entre a origem e o destino durante a migração. Aqui está um guia para ajudá-lo a estabelecer a conexão de rede para diferentes cenários:

Requisitos de rede para migração:

• Encapsulamento VPN/VPN ExpressRoute/IPsec: ao conectar sua fonte local/AWS ao Azure, talvez seja necessário configurar um túnel ExpressRoute, IPsec VPN ou VPN para facilitar a transferência segura de dados.

• Emparelhamento VNET: estabeleça emparelhamento de rede virtual entre as duas redes virtuais distintas para habilitar a conectividade direta de rede, um pré-requisito para a migração entre a VM do Azure e o Banco de Dados do Azure para PostgreSQL.

Cenários de conectividade:

A tabela a seguir pode ajudar a configurar a rede entre a origem e o destino.

Origem	Destino	Dicas de conectividade
Público	Público	Nenhuma outra ação será necessária se a origem estiver na lista de permissões nas regras de firewall do destino.
Privado	Público	Esta configuração não é suportada; Use pg_dump/pg_restore para transferência de dados.
Público	Privado	Nenhuma outra ação será necessária se a origem estiver na lista de permissões nas regras de firewall do destino.
Privado	Privado	Estabeleça uma Rota Expressa, VPN IPsec, Túnel VPN ou emparelhamento de rede virtual entre a origem e o destino.
Privado	Ponto Final Privado	Esta configuração não é suportada; entre em contato com o suporte da Microsoft.

Considerações adicionais de rede:

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

Nota

O arquivo pg_hba.conf está localizado no diretório de dados da instalação do PostgreSQL. Esse arquivo deve ser verificado e configurado se o banco de dados de origem for um servidor PostgreSQL local ou um servidor PostgreSQL hospedado em uma VM do Azure. Para instâncias do PostgreSQL no AWS RDS ou serviços gerenciados semelhantes, o arquivo pg_hba.conf não é diretamente acessível ou aplicável. Em vez disso, o acesso é controlado através das configurações de segurança e acesso à rede fornecidas pelo serviço.

Para obter mais informações sobre a configuração de rede, visite Guia de rede para o serviço de migração no Banco de Dados do Azure para PostgreSQL - Servidor Flexível.

Extensões

As extensões são recursos extras que podem ser adicionados ao PostgreSQL para melhorar sua funcionalidade. As extensões têm suporte no Banco de Dados do Azure para PostgreSQL, mas devem ser habilitadas manualmente. Para ativar extensões, siga estes passos:

• Use o comando select na fonte para listar todas as extensões que estão sendo usadas - select extname,extversion from pg_extension;

• Procure o parâmetro azure.extensions server na página Server parameter no seu Banco de Dados do Azure para PostgreSQL. Habilite as extensões encontradas na fonte dentro do PostgreSQL.

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

  

• Verifique se a lista contém alguma das seguintes extensões:

  • PG_CRON
  • PG_HINT_PLAN
  • PG_PARTMAN_BGW
  • PG_PREWARM
  • PG_STAT_STATEMENTS
  • PG_AUDIT
  • PGLÓGICO
  • WAL2JSON

Em caso afirmativo, procure o parâmetro shared_preload_libraries na página de parâmetros do servidor. Este parâmetro indica o conjunto de bibliotecas de extensão que são pré-carregadas na reinicialização do servidor.

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.

Configurar seu Banco de Dados do Azure para o 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 pode 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. Selecione o botão Migrar de um único servidor . Você passa por uma série de guias baseadas em assistente para criar uma migração para esse destino de Servidor Flexível a partir de qualquer Servidor Único de origem.

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 pule para as instruções na seção da guia Configuração desta página.

   

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.

Guia Configuração

A primeira guia é Configuração. Caso você tenha perdido, permita listar as extensões necessárias, conforme mostrado em É essencial permitir essas extensões 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 nenhum caractere especial, exceto um hífen (-). O nome não pode começar com um hífen e deve ser exclusivo para um servidor de destino. Não há duas migrações para o mesmo destino do Servidor Flexível que possam ter o mesmo nome.

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

A opção de migração permite que você execute 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 migrações.
• 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.

Se a visualização da migração online estiver selecionada, a replicação lógica deverá 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 na guia Replicação no painel Único do lado do servidor, definindo o nível de suporte de replicação do Azure como Lógico. Qualquer uma das abordagens reinicia o servidor único de origem.

Selecione o botão Next : Connect to Source .

Separador Origem

A guia 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 Local, Versão do PostgreSQL e Nome de login do administrador do servidor são preenchidas automaticamente. O nome de entrada do administrador do servidor é o nome de usuário do administrador usado para criar o Servidor Único. Na caixa Palavra-passe, introduza a palavra-passe desse utilizador administrador. O serviço de migração migra bancos de dados de servidor único como o usuário administrador.

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 Avançar : Selecione o destino da migração para continuar.

Separador Destino

A guia Destino exibe metadados para o destino Servidor flexível, como nome da assinatura, grupo de recursos, nome do servidor, local e versão do PostgreSQL.

Para Nome de login do administrador do servidor, a guia exibe o nome de usuário do administrador usado durante a criação do destino do Servidor flexível. Digite a senha correspondente para o usuário administrador. Depois de preencher a senha, 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 Avançar para selecionar os bancos de dados a serem migrados.

Selecione Bancos de dados para a guia de 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. Por padrão, os bancos de dados selecionados com o mesmo nome no destino são substituídos.

Selecione o botão Avançar para revisar os detalhes.

Resumo

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

Monitorar o portal de migração

Depois de selecionar o botão Iniciar, uma notificação aparece em alguns segundos 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, Tipo de migração, Modo 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 da migração 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 tem a

• 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.
• 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 e fim - Hora 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.

Migrar

Depois que o substrato PerformingPreRequisiteSteps for concluído, a migração será movida para o substrato de Migrando dados quando ocorrer 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 toda a contagem de tabelas - copiadas, enfileiradas, copiando e erros, além do 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 usar o botão de atualização na página para confirmar o mesmo.

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é-visualização)

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.

Configuração de 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;

Configuração da rede

A configuração de rede adequada é essencial para garantir uma conectividade bem-sucedida entre a origem e o destino durante a migração. Aqui está um guia para ajudá-lo a estabelecer a conexão de rede para diferentes cenários:

Requisitos de rede para migração:

• Encapsulamento VPN/VPN ExpressRoute/IPsec: ao conectar sua fonte local/AWS ao Azure, talvez seja necessário configurar um túnel ExpressRoute, IPsec VPN ou VPN para facilitar a transferência segura de dados.

• Emparelhamento VNET: estabeleça emparelhamento de rede virtual entre as duas redes virtuais distintas para habilitar a conectividade direta de rede, um pré-requisito para a migração entre a VM do Azure e o Banco de Dados do Azure para PostgreSQL.

Cenários de conectividade:

A tabela a seguir pode ajudar a configurar a rede entre a origem e o destino.

Origem	Destino	Dicas de conectividade
Público	Público	Nenhuma outra ação será necessária se a origem estiver listada como permitida nas regras de firewall do destino.
Privado	Público	Esta configuração não é suportada; Use pg_dump/pg_restore para transferência de dados.
Público	Privado	Nenhuma outra ação será necessária se a origem estiver listada como permitida nas regras de firewall do destino.
Privado	Privado	Estabeleça uma Rota Expressa, VPN IPsec, Túnel VPN ou emparelhamento de rede virtual entre a origem e o destino.
Privado	Ponto Final Privado	Esta configuração não é suportada; entre em contato com o suporte da Microsoft.

Para obter mais informações sobre a configuração de rede, visite Guia de rede para o serviço de migração no Banco de Dados do Azure para PostgreSQL - Servidor Flexível.

Extensões

As extensões são recursos extras que podem ser adicionados ao PostgreSQL para melhorar sua funcionalidade. As extensões têm suporte no Banco de Dados do Azure para PostgreSQL, mas devem ser habilitadas manualmente. Para ativar extensões, siga estes passos:

• Use o comando select na fonte para listar todas as extensões que estão sendo usadas - select extname,extversion from pg_extension;

• Procure o parâmetro azure.extensions server na página Server parameter no seu Banco de Dados do Azure para PostgreSQL. Habilite as extensões encontradas na fonte dentro do PostgreSQL.

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

  

• Verifique se a lista contém alguma das seguintes extensões:

  • PG_CRON
  • PG_HINT_PLAN
  • PG_PARTMAN_BGW
  • PG_PREWARM
  • PG_STAT_STATEMENTS
  • PG_AUDIT
  • PGLÓGICO
  • WAL2JSON

Em caso afirmativo, procure o parâmetro shared_preload_libraries na página de parâmetros do servidor. Este parâmetro indica o conjunto de bibliotecas de extensão que são pré-carregadas na reinicialização do servidor.

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.

Configurar seu Banco de Dados do Azure para o 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 pode 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. Selecione o botão Migrar de um único servidor . Você passa por uma série de guias baseadas em assistente para criar uma migração para esse destino de Servidor Flexível a partir de qualquer Servidor Único de origem.

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 pule para as instruções na seção da guia Configuração desta página.

   

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.

Guia Configuração

A primeira guia é Configuração. Caso você tenha perdido, permita listar as extensões necessárias, conforme mostrado em É essencial permitir essas extensões 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 nenhum caractere especial, exceto um hífen (-). O nome não pode começar com um hífen e deve ser exclusivo para um servidor de destino. Não há duas migrações para o mesmo destino do Servidor Flexível que possam ter o mesmo nome.

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

A opção de migração permite que você execute 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 migrações.
• 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.

Se a visualização da migração online estiver selecionada, a replicação lógica deverá 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 na guia Replicação no painel Único do lado do servidor, definindo o nível de suporte de replicação do Azure como Lógico. Qualquer uma das abordagens reinicia o servidor único de origem.

Selecione o botão Next : Connect to Source .

Separador Origem

A guia 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 Local, Versão do PostgreSQL e Nome de login do administrador do servidor são preenchidas automaticamente. O nome de entrada do administrador do servidor é o nome de usuário do administrador usado para criar o Servidor Único. Na caixa Palavra-passe, introduza a palavra-passe desse utilizador administrador. O serviço de migração migra bancos de dados de servidor único como o usuário administrador.

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 Avançar : Selecione o destino da migração para continuar.

Separador Destino

A guia Destino exibe metadados para o destino Servidor flexível, como nome da assinatura, grupo de recursos, nome do servidor, local e versão do PostgreSQL.

Para Nome de login do administrador do servidor, a guia exibe o nome de usuário do administrador usado durante a criação do destino do Servidor flexível. Digite a senha correspondente para o usuário administrador. Depois de preencher a senha, 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 Avançar para selecionar os bancos de dados a serem migrados.

Selecione Bancos de dados para a guia de 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. Por padrão, os bancos de dados selecionados com o mesmo nome no destino são substituídos.

Selecione o botão Avançar para revisar os detalhes.

Resumo

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

Monitorar a migração usando o portal do Azure

Depois de selecionar o botão Iniciar, uma notificação aparece em alguns segundos 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, Tipo de migração, Modo 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 da migração 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 tem a

• 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.
• 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 e fim - Hora 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.

Migrar

Depois que o substrato PerformingPreRequisiteSteps for concluído, a migração será movida para o substrato de Migrando dados quando ocorrer 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 toda a contagem de tabelas - copiadas, enfileiradas, copiando e erros, além do 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 usar o botão de atualização na página para confirmar o mesmo.

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

Se houver Migrar e Validar e Migrar, a conclusão da migração Online exigirá outra etapa - uma ação de substituição será necessária do usuário. Após a conclusão da cópia/clone dos dados de base, a migração é movida para o WaitingForUserAction estado e o WaitingForCutoverTrigger substrato. Nesse estado, o usuário pode acionar a transferência do portal selecionando a migraçã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, conforme mostrado abaixo:

Latency (minutes) indica quando o destino foi sincronizado pela última vez com a origem. Por exemplo, para o Banco de Dados de Pedidos acima, é 0,33333. Isso significa que as alterações que ocorreram nos últimos ~0,3 minutos na origem ainda não foram sincronizadas com 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) possa chegar perto de 0 e, em seguida, uma 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 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 de alteração 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 vá para zero ou perto de zero, antes de acionar o cutover.

A migração é movida para o Succeeded estado assim que o Migrating Data subestado ou a substituição (na migração online) é concluída com êxito. Se houver um problema no Migrating Data subestado, a migração passa para um Failed estado.

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 . Ele não solta ou reverte nenhuma alteração no servidor de destino. Certifique-se de soltar os bancos de dados no servidor de destino envolvidos em uma migração cancelada.

CLI

Você pode migrar usando a CLI do Azure.

Offline

Pré-requisitos (offline)

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.

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

Configuração da rede

A configuração de rede adequada é essencial para garantir uma conectividade bem-sucedida entre a origem e o destino durante a migração. Aqui está um guia para ajudá-lo a estabelecer a conexão de rede para diferentes cenários:

Requisitos de rede para migração:

• Encapsulamento VPN/VPN ExpressRoute/IPsec: ao conectar sua fonte local/AWS ao Azure, talvez seja necessário configurar um túnel ExpressRoute, IPsec VPN ou VPN para facilitar a transferência segura de dados.

• Emparelhamento VNET: estabeleça emparelhamento de rede virtual entre as duas redes virtuais distintas para habilitar a conectividade direta de rede, um pré-requisito para a migração entre a VM do Azure e o Banco de Dados do Azure para PostgreSQL.

Cenários de conectividade:

A tabela a seguir pode ajudar a configurar a rede entre a origem e o destino.

Origem	Destino	Dicas de conectividade
Público	Público	Nenhuma outra ação será necessária se a origem estiver na lista de permissões nas regras de firewall do destino.
Privado	Público	Esta configuração não é suportada; Use pg_dump/pg_restore para transferência de dados.
Público	Privado	Nenhuma outra ação será necessária se a origem estiver na lista de permissões nas regras de firewall do destino.
Privado	Privado	Estabeleça uma Rota Expressa, VPN IPsec, Túnel VPN ou emparelhamento de rede virtual entre a origem e o destino.
Privado	Ponto Final Privado	Esta configuração não é suportada; entre em contato com o suporte da Microsoft.

Considerações adicionais de rede:

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

Nota

O arquivo pg_hba.conf está localizado no diretório de dados da instalação do PostgreSQL. Esse arquivo deve ser verificado e configurado se o banco de dados de origem for um servidor PostgreSQL local ou um servidor PostgreSQL hospedado em uma VM do Azure. Para instâncias do PostgreSQL no AWS RDS ou serviços gerenciados semelhantes, o arquivo pg_hba.conf não é diretamente acessível ou aplicável. Em vez disso, o acesso é controlado através das configurações de segurança e acesso à rede fornecidas pelo serviço.

Para obter mais informações sobre a configuração de rede, visite Guia de rede para o serviço de migração no Banco de Dados do Azure para PostgreSQL - Servidor Flexível.

Extensões

As extensões são recursos extras que podem ser adicionados ao PostgreSQL para melhorar sua funcionalidade. As extensões têm suporte no Banco de Dados do Azure para PostgreSQL, mas devem ser habilitadas manualmente. Para ativar extensões, siga estes passos:

• Use o comando select na fonte para listar todas as extensões que estão sendo usadas - select extname,extversion from pg_extension;

• Procure o parâmetro azure.extensions server na página Server parameter no seu Banco de Dados do Azure para PostgreSQL. Habilite as extensões encontradas na fonte dentro do PostgreSQL.

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

  

• Verifique se a lista contém alguma das seguintes extensões:

  • PG_CRON
  • PG_HINT_PLAN
  • PG_PARTMAN_BGW
  • PG_PREWARM
  • PG_STAT_STATEMENTS
  • PG_AUDIT
  • PGLÓGICO
  • WAL2JSON

Em caso afirmativo, procure o parâmetro shared_preload_libraries na página de parâmetros do servidor. Este parâmetro indica o conjunto de bibliotecas de extensão que são pré-carregadas na reinicialização do servidor.

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.

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

O comando acima fornece 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

O comando acima fornece o seguinte resultado:

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 migrações tentadas para Servidor Flexível. Este campo aceita apenas caracteres alfanuméricos e não aceita caracteres especiais, exceto um hífen (-). O nome não pode começar com -, e não há duas migrações para um destino de Servidor Flexível que possam 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 "C:\Users\Administrator\Documents\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/<src_ rg_name>/providers/Microsoft.DBforPostgreSQL/servers/<source server name>",
"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 é o ID do recurso da fonte do Servidor Único e é obrigatório.
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 administrador criado durante a criação de um único servidor, e a senha fornecida é usada para autenticação contra 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 contra 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. Os bancos de dados do sistema ou os bancos de dados de modelo, como template0 e template1, não serã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 se move para o InProgress estado e o PerformingPreRequisiteSteps substrato. 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 substrato de Migrating Data, onde 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

Se a visualização da migração online estiver selecionada, a replicação lógica deverá 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 em qualquer uma das regiões acima, use:

az postgres flexible-server migration create --subscription 11111111-1111-1111-1111-111111111111 --resource-group my-learning-rg --name myflexibleserver --migration-name migration1 --properties "C:\Users\Administrator\Documents\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 atuais (em andamento) 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 passadas, 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. Esses detalhes incluem informações sobre 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.

Subestado de migração	Description
PerformingPreRequisiteSteps	A infraestrutura é configurada e preparada para a migração de dados.
MigratingData	A migração de dados está em andamento.
CompletingMigration	A transição migratória está em curso.
Completed	A substituição foi bem-sucedida e a migração foi concluída.

Online (pré-visualização)

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.

Configuração de 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;

Configuração da rede

A configuração de rede adequada é essencial para garantir uma conectividade bem-sucedida entre a origem e o destino durante a migração. Aqui está um guia para ajudá-lo a estabelecer a conexão de rede para diferentes cenários:

Requisitos de rede para migração:

• Encapsulamento VPN/VPN ExpressRoute/IPsec: ao conectar sua fonte local/AWS ao Azure, talvez seja necessário configurar um túnel ExpressRoute, IPsec VPN ou VPN para facilitar a transferência segura de dados.

• Emparelhamento VNET: estabeleça emparelhamento de rede virtual entre as duas redes virtuais distintas para habilitar a conectividade direta de rede, um pré-requisito para a migração entre a VM do Azure e o Banco de Dados do Azure para PostgreSQL.

Cenários de conectividade:

A tabela a seguir pode ajudar a configurar a rede entre a origem e o destino.

Origem	Destino	Dicas de conectividade
Público	Público	Nenhuma outra ação será necessária se a origem estiver listada como permitida nas regras de firewall do destino.
Privado	Público	Esta configuração não é suportada; Use pg_dump/pg_restore para transferência de dados.
Público	Privado	Nenhuma outra ação será necessária se a origem estiver listada como permitida nas regras de firewall do destino.
Privado	Privado	Estabeleça uma Rota Expressa, VPN IPsec, Túnel VPN ou emparelhamento de rede virtual entre a origem e o destino.
Privado	Ponto Final Privado	Esta configuração não é suportada; entre em contato com o suporte da Microsoft.

Para obter mais informações sobre a configuração de rede, visite Guia de rede para o serviço de migração no Banco de Dados do Azure para PostgreSQL - Servidor Flexível.

Extensões

As extensões são recursos extras que podem ser adicionados ao PostgreSQL para melhorar sua funcionalidade. As extensões têm suporte no Banco de Dados do Azure para PostgreSQL, mas devem ser habilitadas manualmente. Para ativar extensões, siga estes passos:

• Use o comando select na fonte para listar todas as extensões que estão sendo usadas - select extname,extversion from pg_extension;

• Procure o parâmetro azure.extensions server na página Server parameter no seu Banco de Dados do Azure para PostgreSQL. Habilite as extensões encontradas na fonte dentro do PostgreSQL.

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

  

• Verifique se a lista contém alguma das seguintes extensões:

  • PG_CRON
  • PG_HINT_PLAN
  • PG_PARTMAN_BGW
  • PG_PREWARM
  • PG_STAT_STATEMENTS
  • PG_AUDIT
  • PGLÓGICO
  • WAL2JSON

Em caso afirmativo, procure o parâmetro shared_preload_libraries na página de parâmetros do servidor. Este parâmetro indica o conjunto de bibliotecas de extensão que são pré-carregadas na reinicialização do servidor.

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.

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

O comando acima fornece 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

O comando acima fornece o seguinte resultado:

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 migrações tentadas para Servidor Flexível. Este campo aceita apenas caracteres alfanuméricos e não aceita caracteres especiais, exceto um hífen (-). O nome não pode começar com -, e não há duas migrações para um destino de Servidor Flexível que possam 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 "C:\Users\Administrator\Documents\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/<src_ rg_name>/providers/Microsoft.DBforPostgreSQL/servers/<source server name>",
"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 é o ID do recurso da fonte do Servidor Único e é obrigatório.
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 administrador criado durante a criação de um único servidor, e a senha fornecida é usada para autenticação contra 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 contra 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. Os bancos de dados do sistema ou os bancos de dados de modelo, como template0 e template1, não serã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 se move para o InProgress estado e o PerformingPreRequisiteSteps substrato. 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 substrato de Migrating Data, onde 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

Se a visualização da migração online estiver selecionada, a replicação lógica deverá 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 em qualquer uma das regiões acima, use:

az postgres flexible-server migration create --subscription 11111111-1111-1111-1111-111111111111 --resource-group my-learning-rg --name myflexibleserver --migration-name migration1 --properties "C:\Users\Administrator\Documents\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 atuais (em andamento) 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 passadas, 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. Esses detalhes incluem informações sobre 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.

Subestado de migração	Description
PerformingPreRequisiteSteps	A infraestrutura é configurada e preparada para a migração de dados.
MigratingData	A migração de dados está em andamento.
CompletingMigration	A transição migratória está em curso.
Completed	A substituição foi bem-sucedida e a migração foi concluída.

Substituição da migração

Nas migrações online, após a conclusão da migração de dados 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, é importante garantir que:

• As gravações na fonte são interrompidas -latency o parâmetro diminui para 0 ou perto 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, mas não descarta nem reverte nenhuma alteração no servidor de destino. Aqui está o comando da CLI para excluir 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:

Pós-migração

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

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

• Verifique os dados em seu servidor flexível e 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