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

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

• Configurar seu Servidor Flexível de Banco de Dados do Azure para PostgreSQL
• Configurar a tarefa de migração
• Monitorar a migração
• Cancelar a migração
• Após a 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, é essencial atender aos pré-requisitos a seguir, que se aplicam a cenários de migração offline.

Verificar a versão de origem

A versão PostgreSQL de origem deve ser >= 9.5. Se a versão do PostgreSQL de origem for menor que 9.5, atualize a versão do PostgreSQL de origem 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 a compatibilidade e o desempenho adequado.

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

Configuração da rede

A configuração de rede adequada é essencial para garantir a 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:

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

• Emparelhamento VNET: estabeleça o emparelhamento de rede virtual entre as duas VNets distintas para habilitar a conectividade de rede direta, um pré-requisito para 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
Setor Público	Setor 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	Setor Público	Não há suporte para essa configuração; use pg_dump/pg_restore para transferência de dados.
Setor Público	Privados	Nenhuma outra ação será necessária se a origem estiver na lista de permissões nas regras de firewall do destino.
Privados	Privados	Estabeleça um Emparelhamento de rede virtual, VPN IPsec, IPsec ou ExpressRoute entre a origem e o destino.
Privados	Ponto de extremidade privado	Não há suporte para essa configuração; entre em contato com o suporte da Microsoft.

Considerações adicionais de rede:

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

Observação

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

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

Extensões

Extensões são recursos extras que podem ser adicionados ao PostgreSQL para aprimorar sua funcionalidade. Há suporte para extensões no Banco de Dados do Azure para PostgreSQL, mas devem ser habilitadas manualmente. Para habilitar extensões, siga estas etapas:

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

• Pesquise o parâmetro do servidor azure.extensions na página de parâmetros do servidor no Banco de Dados do Azure para PostgreSQL. Habilite as extensões encontradas na origem no 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 uma das seguintes extensões:

  • PG_CRON
  • PG_HINT_PLAN
  • PG_PARTMAN_BGW
  • PG_PREWARM
  • PG_STAT_STATEMENTS
  • PG_AUDIT
  • PGLOGICAL
  • WAL2JSON

Em caso afirmativo, pesquise na página de parâmetros do servidor o parâmetro shared_preload_libraries. Esse parâmetro indica o conjunto de bibliotecas de extensã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.

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

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

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

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

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

Configurar seu Servidor Flexível de Banco de Dados do Azure para PostgreSQL

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

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

• Verifique se a distribuição dos dados entre as tabelas de um banco de dados está distorcida, com a maioria dos dados presentes em uma única (ou poucas) tabelas. Se estiver distorcida, a velocidade da 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 e baseada em assistente no portal do Azure. Veja como começar:

1. Abra o navegador da Web e acesse o portal. Para fazer login, insira suas credenciais. A exibição padrão é o painel de serviço.

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

3. Na guia Visão geral do servidor flexível, no menu à esquerda, role a página para baixo até Migração (versão prévia) e selecione-a.

   

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

   

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

5. Escolha o botão Migrar do Servidor Único. Você passa por uma série de guias baseadas em um assistente para criar uma migração para esse Servidor Flexível de destino a partir de qualquer Servidor Único de origem.

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

1. Abra o navegador da Web e acesse o portal. Para entrar, você deve inserir suas credenciais. A exibição padrão é o painel de serviço.

2. Ao selecionar o Servidor Único, você pode observar uma faixa relacionada à migração na guia Visão Geral. Selecione Migrar agora para começar.

   

3. Você é levado a 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 da assinatura, do grupo de recursos e do 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 Guia Configuração dessa 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. Essa ação leva você ao processo de criação do Servidor Flexível e implanta o Servidor Flexível.

   

Após 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, coloque na lista de permissões as extensões necessárias, conforme mostrado em É essencial colocar essas extensões na lista de permissões antes de iniciar uma migração.

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

Tipo de servidor de origem indica a origem. Nesse caso, é o servidor único do Banco de Dados do Azure para PostgreSQL

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

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

É sempre uma boa prática escolher a opção Validar ou Validar e Migrar para realizar 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á estar 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 abordagem reinicia o servidor único de origem.

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

Guia Origem

A guia Fonte solicita detalhes relacionados ao Servidor Único, que é a origem dos bancos de dados.

Depois que você fizer as seleções de Assinatura e Grupo de Recursos, a lista suspensa de nomes de servidores mostrará os servidores únicos nesse grupo de recursos em todas as regiões. Selecione a origem da qual você deseja migrar os bancos de dados. Você pode migrar bancos de dados de um Servidor Único para um Servidor Flexível na mesma região. As migrações entre regiões estão habilitadas apenas para servidores da Índia, China e UAE.

Depois de escolher o Servidor Único de origem, as caixas Localização, Versão do PostgreSQL e ID de logon do administrador do Servidor são preenchidas automaticamente. O nome de login do administrador do servidor é o nome de usuário do administrador usado para criar o Servidor Único. Na caixa Senha, digite a senha desse usuário administrador. O serviço de migração migra bancos de dados de servidor único como usuário administrador.

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

Selecione o botão Avançar: Selecione o destino de migração para continuar.

Guia Destino

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

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. Insira a senha correspondente para o usuário administrador. Após preencher a senha, selecione o link Conectar ao destino. Isso valida se os detalhes do servidor de destino inseridos estão corretos e o servidor de destino é 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

Nessa 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 no 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 a migração. Revise os detalhes e selecione no botão Iniciar.

Monitore o portal de migração

Depois de selecionar o botão Iniciar, uma notificação aparecerá em alguns segundos informando que a validação ou criação da migração foi bem-sucedida. Você é 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 de atualização 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 passa para o estado InProgress e para o subestado PerformingPreRequisiteSteps. O fluxo de trabalho leva de 2 a 3 minutos para configurar a infraestrutura de migração e as conexões de rede.

Vejamos como monitorar migrações para cada Opção de Migração.

Validar

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

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

A grade de validação tem

• Detalhes de validação para seções e Detalhes de validação para bancos de dados, representando as regras de validação usadas para verificar a preparação para migração.
• Status de Validação – representa o resultado para cada regra e pode ter qualquer um dos três valores
  • Êxito – 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 término – Hora de início e término da operação de validação em UTC.

O Status de validação passa para o estado Com falha se houver erros na validação. Selecione a validação Nome de validação ou Nome do banco de dados que falhou e um painel distribuído fornece os detalhes e a ação corretiva que você deve tomar para evitar esse erro.

Migrações

Após a conclusão do substrato PerformingPreRequisiteSteps, a migração passa para o substrato de Migrating Data quando ocorre a clonagem/cópia dos bancos de dados. O tempo para a migração ser concluída depende do tamanho e do formato dos bancos de dados que você está migrando. A migração é rápida se os dados estiverem distribuídos uniformemente em todas as tabelas. Tabelas de tamanhos distorcidos levam um tempo relativamente maior.

Quando você seleciona qualquer um dos bancos de dados sendo migrados, aparece um painel de dispersão. Ele contém toda a contagem de tabelas - copiadas, enfileiradas, cópias e erros, além do status de migração do banco de dados.

A migração passa para o estado Bem Sucedido quando o estado Migrando Dados é concluído com sucesso. Se houver um problema no estado Migrando Dados, a migração passará para o estado Falha.

Depois que a migração passar para o estado Bem-sucedido, a migração de esquema e dados do seu servidor único para o destino do servidor flexível será concluída. Você pode usar o botão Atualizar 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. Após a conclusão do substrato PerformingPreRequisiteSteps, o fluxo de trabalho passa para o subestado de Validação em andamento.

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

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

Online (versão prévia)

Pré-requisitos (online)

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

Verificar a versão de origem

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

Configurar parâmetros de migração online

Para migração online, o suporte de 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 de servidor max_wal_senders e max_replication_slots valores devem ser mais 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 = logical;
• ALTER SYSTEM SET max_wal_senders = number of databases to migrate + 1;
• ALTER SYSTEM SET max_replication_slots = number of databases to migrate + 1;

Verifique se não há transações de execução prolongada. As transações de execução prolongada não permitem a criação de slots de replicação. A criação de um slot de replicação terá êxito se todas as transações de execução prolongada forem confirmadas ou revertidas. Você precisará reiniciar o servidor PostgreSQL de origem após concluir todos os pré-requisitos de migração online.

Observação

Para a migração online com o servidor único do Banco de Dados do Azure para PostgreSQL, o suporte de replicação do Azure é definido como lógico nas configurações de replicação da página do 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 a compatibilidade e o desempenho adequado.

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

• O parâmetro de servidor max_replication_slots 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:

• ALTER SYSTEM SET max_replication_slots = number of databases to migrate + 1;

Configuração da rede

A configuração de rede adequada é essencial para garantir a 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:

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

• Emparelhamento VNET: estabeleça o emparelhamento de rede virtual entre as duas VNets distintas para habilitar a conectividade de rede direta, um pré-requisito para 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
Setor Público	Setor Público	Não serão necessárias outras ações se a origem estiver na lista de permissões das regras de firewall do destino.
Privado	Setor Público	Não há suporte para essa configuração; use pg_dump/pg_restore para transferência de dados.
Setor Público	Privados	Não serão necessárias outras ações se a origem estiver na lista de permissões das regras de firewall do destino.
Privado	Privados	Estabeleça um Emparelhamento de rede virtual, VPN IPsec, IPsec ou ExpressRoute entre a origem e o destino.
Privados	Ponto de extremidade privado	Não há suporte para essa configuração; entre em contato com o suporte da Microsoft.

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

Extensões

Extensões são recursos extras que podem ser adicionados ao PostgreSQL para aprimorar sua funcionalidade. Há suporte para extensões no Banco de Dados do Azure para PostgreSQL, mas devem ser habilitadas manualmente. Para habilitar extensões, siga estas etapas:

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

• Pesquise o parâmetro do servidor azure.extensions na página de parâmetros do servidor no Banco de Dados do Azure para PostgreSQL. Habilite as extensões encontradas na origem no 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 uma das seguintes extensões:

  • PG_CRON
  • PG_HINT_PLAN
  • PG_PARTMAN_BGW
  • PG_PREWARM
  • PG_STAT_STATEMENTS
  • PG_AUDIT
  • PGLOGICAL
  • WAL2JSON

Em caso afirmativo, pesquise na página de parâmetros do servidor o parâmetro shared_preload_libraries. Esse parâmetro indica o conjunto de bibliotecas de extensã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.

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

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

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

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

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

Configurar seu Servidor Flexível de Banco de Dados do Azure para PostgreSQL

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

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

• Verifique se a distribuição dos dados entre as tabelas de um banco de dados está distorcida, com a maioria dos dados presentes em uma única (ou poucas) tabelas. Se estiver distorcida, a velocidade da 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 e baseada em assistente no portal do Azure. Veja como começar:

1. Abra o navegador da Web e acesse o portal. Para fazer login, insira suas credenciais. A exibição padrão é o painel de serviço.

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

3. Na guia Visão geral do servidor flexível, no menu à esquerda, role a página para baixo até Migração (versão prévia) e selecione-a.

   

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

   

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

5. Escolha o botão Migrar do Servidor Único. Você passa por uma série de guias baseadas em um assistente para criar uma migração para esse Servidor Flexível de destino a partir de qualquer Servidor Único de origem.

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

1. Abra o navegador da Web e acesse o portal. Para entrar, você deve inserir suas credenciais. A exibição padrão é o painel de serviço.

2. Ao selecionar o Servidor Único, você pode observar uma faixa relacionada à migração na guia Visão Geral. Selecione Migrar agora para começar.

   

3. Você é levado a 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 da assinatura, do grupo de recursos e do 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 Guia Configuração dessa 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. Essa ação leva você ao processo de criação do Servidor Flexível e implanta o Servidor Flexível.

   

Após 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, coloque na lista de permissões as extensões necessárias, conforme mostrado em É essencial colocar essas extensões na lista de permissões antes de iniciar uma migração.

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

Tipo de servidor de origem indica a origem. Nesse caso, é o servidor único do Banco de Dados do Azure para PostgreSQL

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

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

É sempre uma boa prática escolher a opção Validar ou Validar e Migrar para realizar 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á estar 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 abordagem reinicia o servidor único de origem.

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

Guia Origem

A guia Fonte solicita detalhes relacionados ao Servidor Único, que é a origem dos bancos de dados.

Depois que você fizer as seleções de Assinatura e Grupo de Recursos, a lista suspensa de nomes de servidores mostrará os servidores únicos nesse grupo de recursos em todas as regiões. Selecione a origem da qual você deseja migrar os bancos de dados. Você pode migrar bancos de dados de um Servidor Único para um Servidor Flexível na mesma região. As migrações entre regiões estão habilitadas apenas para servidores da Índia, China e UAE.

Depois de escolher o Servidor Único de origem, as caixas Localização, Versão do PostgreSQL e ID de logon do administrador do Servidor são preenchidas automaticamente. O nome de login do administrador do servidor é o nome de usuário do administrador usado para criar o Servidor Único. Na caixa Senha, digite a senha desse usuário administrador. O serviço de migração migra bancos de dados de servidor único como usuário administrador.

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

Selecione o botão Avançar: Selecione o destino de migração para continuar.

Guia Destino

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

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. Insira a senha correspondente para o usuário administrador. Após preencher a senha, selecione o link Conectar ao destino. Isso valida se os detalhes do servidor de destino inseridos estão corretos e o servidor de destino é 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

Nessa 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 no 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 a migração. Revise os detalhes e selecione no botão Iniciar.

Monitore a migração usando o portal do Azure

Depois de selecionar o botão Iniciar, uma notificação aparecerá em alguns segundos informando que a validação ou criação da migração foi bem-sucedida. Você é 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 de atualização 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 passa para o estado InProgress e para o subestado PerformingPreRequisiteSteps. O fluxo de trabalho leva de 2 a 3 minutos para configurar a infraestrutura de migração e as conexões de rede.

Vejamos como monitorar migrações para cada Opção de Migração.

Validar

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

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

A grade de validação tem

• Detalhes de validação para seções e Detalhes de validação para bancos de dados, representando as regras de validação usadas para verificar a preparação para migração.
• Status de Validação – representa o resultado para cada regra e pode ter qualquer um dos três valores
  • Êxito – 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 término – Hora de início e término da operação de validação em UTC.

O Status de validação passa para o estado Com falha se houver erros na validação. Selecione a validação Nome de validação ou Nome do banco de dados que falhou e um painel distribuído fornece os detalhes e a ação corretiva que você deve tomar para evitar esse erro.

Migrações

Após a conclusão do substrato PerformingPreRequisiteSteps, a migração passa para o substrato de Migrating Data quando ocorre a clonagem/cópia dos bancos de dados. O tempo para a migração ser concluída depende do tamanho e do formato dos bancos de dados que você está migrando. A migração é rápida se os dados estiverem distribuídos uniformemente em todas as tabelas. Tabelas de tamanhos distorcidos levam um tempo relativamente maior.

Quando você seleciona qualquer um dos bancos de dados sendo migrados, aparece um painel de dispersão. Ele contém toda a contagem de tabelas - copiadas, enfileiradas, cópias e erros, além do status de migração do banco de dados.

A migração passa para o estado Bem Sucedido quando o estado Migrando Dados é concluído com sucesso. Se houver um problema no estado Migrando Dados, a migração passará para o estado Falha.

Depois que a migração passar para o estado Bem-sucedido, a migração de esquema e dados do seu servidor único para o destino do servidor flexível será concluída. Você pode usar o botão Atualizar 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. Após a conclusão do substrato PerformingPreRequisiteSteps, o fluxo de trabalho passa para o subestado de Validação em andamento.

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

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

Migração de transiçã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 base, a migração passa para o estado WaitingForUserAction e o substrato WaitingForCutoverTrigger. Nesse estado, o usuário pode disparar a substituição do portal selecionando a migração.

Antes de iniciar a transição, é essencial garantir que:

• As gravações na origem são interrompidas: o parâmetro Latency (minutes) é 0 ou próximo a 0. A informação de Latency (minutes) pode ser obtida na tela de detalhes da migração, conforme mostrado abaixo:

O parâmetro 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 aproximadamente no último 0,3 segundo na origem ainda não foram sincronizadas com o destino, para o Banco de Dados de Pedidos. Neste momento, as gravações na origem podem ser interrompidas e a substituição iniciada. Caso haja tráfego intenso na origem, é recomendável interromper as gravações primeiro para que Latency (minutes) possa chegar perto de 0 e, em seguida, uma transição seja iniciada. A operação Cutover aplica todas as alterações pendentes da origem para o destino e conclui a migração. Se você disparar uma "Substituição" mesmo com latência diferente de zero, a replicação é interrompida até esse momento. Todos os dados na origem até o ponto de transição são então aplicados ao destino. Digamos que uma latência foi de 15 minutos no ponto de transição, 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. Portanto, é recomendável que a latência atinja zero ou perto de zero, antes de disparar a substituição.

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

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

• EmAndamento: a instalação da infraestrutura de migração está em andamento ou a migração de dados real está em andamento.
• Cancelada: a migração foi cancelada ou excluída.
• 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 da migração incluem:

• ExecuçãoDasEtapasDePré-Requisitos: a configuração da infraestrutura está em andamento para a migração dos dados.
• Validação em andamento: a validação está em andamento.
• MigrandoDados: a migração dos dados está em andamento.
• ConcluindoMigração: a migração está na fase final da conclusão.
• Concluído: a migração foi concluída com êxito.

Cancelar a migração usando o portal

Você pode cancelar 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 migração que esteja no estado deÊxito ou de Falha.

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

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, é essencial atender aos pré-requisitos a seguir, que se aplicam a cenários de migração offline.

Verificar a versão de origem

A versão PostgreSQL de origem deve ser >= 9.5. Se a versão do PostgreSQL de origem for menor que 9.5, atualize a versão do PostgreSQL de origem 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 a compatibilidade e o desempenho adequado.

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

Configuração da rede

A configuração de rede adequada é essencial para garantir a 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:

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

• Emparelhamento VNET: estabeleça o emparelhamento de rede virtual entre as duas VNets distintas para habilitar a conectividade de rede direta, um pré-requisito para 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
Setor Público	Setor 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	Setor Público	Não há suporte para essa configuração; use pg_dump/pg_restore para transferência de dados.
Setor Público	Privados	Nenhuma outra ação será necessária se a origem estiver na lista de permissões nas regras de firewall do destino.
Privados	Privados	Estabeleça um Emparelhamento de rede virtual, VPN IPsec, IPsec ou ExpressRoute entre a origem e o destino.
Privados	Ponto de extremidade privado	Não há suporte para essa configuração; entre em contato com o suporte da Microsoft.

Considerações adicionais de rede:

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

Observação

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

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

Extensões

Extensões são recursos extras que podem ser adicionados ao PostgreSQL para aprimorar sua funcionalidade. Há suporte para extensões no Banco de Dados do Azure para PostgreSQL, mas devem ser habilitadas manualmente. Para habilitar extensões, siga estas etapas:

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

• Pesquise o parâmetro do servidor azure.extensions na página de parâmetros do servidor no Banco de Dados do Azure para PostgreSQL. Habilite as extensões encontradas na origem no 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 uma das seguintes extensões:

  • PG_CRON
  • PG_HINT_PLAN
  • PG_PARTMAN_BGW
  • PG_PREWARM
  • PG_STAT_STATEMENTS
  • PG_AUDIT
  • PGLOGICAL
  • WAL2JSON

Em caso afirmativo, pesquise na página de parâmetros do servidor o parâmetro shared_preload_libraries. Esse parâmetro indica o conjunto de bibliotecas de extensã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.

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

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

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

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

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

Introdução

1. Caso não esteja familiarizado com o Microsoft Azure, crie uma conta para avaliar as ofertas.

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

   Se a CLI do Azure já estiver instalada, verifique a versão usando o comando az version. 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. Executar o comando az login:

   az login
   

   Uma janela do navegador será aberta com a página de entrada do Azure. Forneça suas credenciais do Azure para fazer uma autenticação bem-sucedida. Para ver outras maneiras de se conectar com a CLI do Azure, confira este artigo.

Comandos CLI de migração (offline)

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

Para obter ajuda para entender as opções associadas a um comando e ao enquadramento da sintaxe certa, use o parâmetro help:

az postgres flexible-server migration --help

O comando acima fornece a seguinte saída:

A saída lista os comandos de migração compatíveis, acompanhado das respectivas ações. Vejamos esses comandos em detalhes.

Criar uma migração usando a CLI do Azure

O comando create ajuda na criação de uma migração de um servidor de origem para um 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 uma migração bem-sucedida do servidor de origem para o de destino. Este é o comando da CLI usado para criar uma nova migração:

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

Parâmetro	Descrição
subscription	ID da assinatura do destino de servidor flexível.
resource-group	Grupo de recursos do destino de servidor flexível.
name	Nome do destino de servidor flexível.
migration-name	Identificador exclusivo das tentativas de migração para o servidor flexível. Esse campo aceita apenas caracteres alfanuméricos e não aceita nenhum caractere especial, exceto um hífen (-). O nome não pode começar com -, e nenhuma migração para um destino de servidor flexível pode ter o mesmo nome de outra.
migration-mode	Esse é um parâmetro opcional. Valor padrão: offline. A migração offline envolve a cópia dos bancos dos dados de origem em um determinado momento para o servidor de destino.
properties	Caminho absoluto para um arquivo JSON com as informações sobre a origem de 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 argumento migration-name usado no comandocreate é usado em outros comandos CLI, como update, delete, e show.. Ele identifica exclusivamente a tentativa de migração nas ações correspondentes em todos esses comandos.

Finalmente, para o comando create, é necessário transmitir um arquivo JSON como parte do argumento properties.

A estrutura do 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 parâmetros create que vão para o formato de arquivo JSON são mostrados abaixo:

Parâmetro	Tipo	Descrição
sourceDbServerResourceId	Obrigatório	Esse parâmetro é a ID do recurso da origem de servidor único e é obrigatória.
adminCredentials	Obrigatório	Este parâmetro lista senhas para usuários administradores tanto para a origem do Servidor Único como para o destino do Servidor Flexível. Essas senhas ajudam na autenticação nos servidores de origem e de destino.
sourceServerUserName	Obrigató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 nesse 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 realizar a migração. Esse utilizador deve ter os privilégios necessários e a propriedade dos objetos de base de dados envolvidos na migração e deve ser membro da função azure_pg_admin.
targetServerUserName	Obrigatório	O valor padrão é o usuário administrador criado durante a criação de um servidor flexível e a senha fornecida é usada para autenticação nesse usuário. Caso não esteja usando o usuário padrão, esse parâmetro é o usuário ou a função no servidor de destino usado para executar a migração. Este usuário deve ser membro das funções azure_pg_admin, pg_read_all_settings, pg_read_all_stats,pg_stat_scan_tables e deve ter os atributos Criar função, Criar BD.
dbsToMigrate	Obrigató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 de modelo, como template0 e template1, não serão migrados.
overwriteDbsInTarget	Obrigatório	Quando definido como verdadeiro, 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 inatividade.
SourceDBServerFullyQualifiedDomainName	Opcional	Use-o quando um servidor DNS personalizado for usado para a resolução de nomes de uma rede virtual. Forneça o FQDN da origem de servidor único de acordo com o servidor DNS personalizado dessa propriedade.
TargetDBServerFullyQualifiedDomainName	Opcional	Use-o quando um servidor DNS personalizado for usado para a resolução de nomes em uma rede virtual. Forneça o FQDN do destino de servidor flexível de acordo com o servidor DNS personalizado. SourceDBServerFullyQualifiedDomainName e TargetDBServerFullyQualifiedDomainName devem ser incluídos como parte do JSON apenas no cenário raro de um servidor DNS personalizado ser usado para a resolução de nomes em vez do DNS fornecido pelo Azure. Caso contrário, não inclua esses parâmetros no arquivo JSON.

Observe esses pontos essenciais para a resposta do comando:

• Quando o comando create é acionado, a migração passa para o estado InProgress e para o substrato PerformingPreRequisiteSteps. 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 subestado PerformingPreRequisiteSteps, a migração passa para o substrato de Migrating Data, onde ocorre a clonagem/cópia dos bancos de dados.
• Cada banco de dados migrado tem uma seção própria com todos os detalhes da migração, como contagem de tabelas, inserções incrementais, exclusões e bytes pendentes.
• O tempo que o subestado Migrating Data leva para terminar depende do tamanho dos bancos de dados que são migrados.
• A migração passa para o estado Succeeded assim que o subestado Migrating Data é concluído com êxito. Se houver um problema no subestado Migrating Data, a migração passará para o estado Failed.

Replicação de configuração

Se a visualização da migração Online estiver selecionada, a replicação lógica deverá estar 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 parâmetro SetupLogicalReplicationOnSourceDBIfNeeded for passado com um valor true no arquivo JSON que o acompanha. A replicação também pode ser configurada manualmente na origem após iniciar a migração usando o comando abaixo. Qualquer abordagem 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

Esse comando é necessário para avançar na migração quando o servidor flexível estiver aguardando no estado WaitingForLogicalReplicationSetupRequestOnSourceDB.

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

Liste as migrações

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

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

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

• Active: Lista as tentativas de migração ativas atuais (em progresso) para o servidor de destino. Ela não inclui as migrações que falharam, foram canceladas ou foram 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 parâmetro help:

az postgres flexible-server migration list -- help

Monitorar a migração

O comando show ajuda você a monitorar as migrações em andamento e fornece o estado e o subestado atuais 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 parâmetro migration_name é o nome atribuído à migração durante o comando create. Este é um instantâneo da resposta de exemplo do comando da CLI para mostrar os detalhes:

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

 az postgres flexible-server migration show -- help

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

Estado de migração	Descrição
InProgress	A infraestrutura de migração está configurada ou a migração de dados atual está em andamento.
Canceled	A migração foi cancelada ou excluída.
Failed	A migração falhou.
Succeeded	A migração foi bem-sucedida e está concluída.

Subestado da migração	Descrição
PerformingPreRequisiteSteps	A infraestrutura está configurada e preparada para a migração de dados.
MigratingData	Migração de dados em andamento.
CompletingMigration	A substituição da migração está em andamento.
Completed	a transferência foi bem-sucedida e a migração foi concluída.

Online (versão prévia)

Pré-requisitos (online)

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

Verificar a versão de origem

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

Configurar parâmetros de migração online

Para migração online, o suporte de 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 de servidor max_wal_senders e max_replication_slots valores devem ser mais 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 = logical;
• ALTER SYSTEM SET max_wal_senders = number of databases to migrate + 1;
• ALTER SYSTEM SET max_replication_slots = number of databases to migrate + 1;

Verifique se não há transações de execução prolongada. As transações de execução prolongada não permitem a criação de slots de replicação. A criação de um slot de replicação terá êxito se todas as transações de execução prolongada forem confirmadas ou revertidas. Você precisará reiniciar o servidor PostgreSQL de origem após concluir todos os pré-requisitos de migração online.

Observação

Para a migração online com o servidor único do Banco de Dados do Azure para PostgreSQL, o suporte de replicação do Azure é definido como lógico nas configurações de replicação da página do 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 a compatibilidade e o desempenho adequado.

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

• O parâmetro de servidor max_replication_slots 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:

• ALTER SYSTEM SET max_replication_slots = number of databases to migrate + 1;

Configuração da rede

A configuração de rede adequada é essencial para garantir a 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:

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

• Emparelhamento VNET: estabeleça o emparelhamento de rede virtual entre as duas VNets distintas para habilitar a conectividade de rede direta, um pré-requisito para 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
Setor Público	Setor Público	Não serão necessárias outras ações se a origem estiver na lista de permissões das regras de firewall do destino.
Privado	Setor Público	Não há suporte para essa configuração; use pg_dump/pg_restore para transferência de dados.
Setor Público	Privados	Não serão necessárias outras ações se a origem estiver na lista de permissões das regras de firewall do destino.
Privado	Privados	Estabeleça um Emparelhamento de rede virtual, VPN IPsec, IPsec ou ExpressRoute entre a origem e o destino.
Privados	Ponto de extremidade privado	Não há suporte para essa configuração; entre em contato com o suporte da Microsoft.

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

Extensões

Extensões são recursos extras que podem ser adicionados ao PostgreSQL para aprimorar sua funcionalidade. Há suporte para extensões no Banco de Dados do Azure para PostgreSQL, mas devem ser habilitadas manualmente. Para habilitar extensões, siga estas etapas:

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

• Pesquise o parâmetro do servidor azure.extensions na página de parâmetros do servidor no Banco de Dados do Azure para PostgreSQL. Habilite as extensões encontradas na origem no 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 uma das seguintes extensões:

  • PG_CRON
  • PG_HINT_PLAN
  • PG_PARTMAN_BGW
  • PG_PREWARM
  • PG_STAT_STATEMENTS
  • PG_AUDIT
  • PGLOGICAL
  • WAL2JSON

Em caso afirmativo, pesquise na página de parâmetros do servidor o parâmetro shared_preload_libraries. Esse parâmetro indica o conjunto de bibliotecas de extensã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.

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

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

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

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

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

Introdução

1. Caso não esteja familiarizado com o Microsoft Azure, crie uma conta para avaliar as ofertas.

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

   Se a CLI do Azure já estiver instalada, verifique a versão usando o comando az version. 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. Executar o comando az login:

   az login
   

   Uma janela do navegador será aberta com a página de entrada do Azure. Forneça suas credenciais do Azure para fazer uma autenticação bem-sucedida. Para ver outras maneiras de se conectar com a CLI do Azure, confira este artigo.

Comandos CLI de migração (online)

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

Para obter ajuda para entender as opções associadas a um comando e ao enquadramento da sintaxe certa, use o parâmetro help:

az postgres flexible-server migration --help

O comando acima fornece a seguinte saída:

A saída lista os comandos de migração compatíveis, acompanhado das respectivas ações. Vejamos esses comandos em detalhes.

Criar uma migração usando a CLI do Azure

O comando create ajuda na criação de uma migração de um servidor de origem para um 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 uma migração bem-sucedida do servidor de origem para o de destino. Este é o comando da CLI usado para criar uma nova migração:

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

Parâmetro	Descrição
subscription	ID da assinatura do destino de servidor flexível.
resource-group	Grupo de recursos do destino de servidor flexível.
name	Nome do destino de servidor flexível.
migration-name	Identificador exclusivo das tentativas de migração para o servidor flexível. Esse campo aceita apenas caracteres alfanuméricos e não aceita nenhum caractere especial, exceto um hífen (-). O nome não pode começar com -, e nenhuma migração para um destino de servidor flexível pode ter o mesmo nome de outra.
migration-mode	Esse é um parâmetro opcional. Valor padrão: offline. A migração offline envolve a cópia dos bancos dos dados de origem em um determinado momento para o servidor de destino.
properties	Caminho absoluto para um arquivo JSON com as informações sobre a origem de 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 argumento migration-name usado no comandocreate é usado em outros comandos CLI, como update, delete, e show.. Ele identifica exclusivamente a tentativa de migração nas ações correspondentes em todos esses comandos.

Finalmente, para o comando create, é necessário transmitir um arquivo JSON como parte do argumento properties.

A estrutura do 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 parâmetros create que vão para o formato de arquivo JSON são mostrados abaixo:

Parâmetro	Tipo	Descrição
sourceDbServerResourceId	Obrigatório	Esse parâmetro é a ID do recurso da origem de servidor único e é obrigatória.
adminCredentials	Obrigatório	Este parâmetro lista senhas para usuários administradores tanto para a origem do Servidor Único como para o destino do Servidor Flexível. Essas senhas ajudam na autenticação nos servidores de origem e de destino.
sourceServerUserName	Obrigató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 nesse 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 realizar a migração. Esse utilizador deve ter os privilégios necessários e a propriedade dos objetos de base de dados envolvidos na migração e deve ser membro da função azure_pg_admin.
targetServerUserName	Obrigatório	O valor padrão é o usuário administrador criado durante a criação de um servidor flexível e a senha fornecida é usada para autenticação nesse usuário. Caso não esteja usando o usuário padrão, esse parâmetro é o usuário ou a função no servidor de destino usado para executar a migração. Este usuário deve ser membro das funções azure_pg_admin, pg_read_all_settings, pg_read_all_stats,pg_stat_scan_tables e deve ter os atributos Criar função, Criar BD.
dbsToMigrate	Obrigató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 de modelo, como template0 e template1, não serão migrados.
overwriteDbsInTarget	Obrigatório	Quando definido como verdadeiro, 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 inatividade.
SourceDBServerFullyQualifiedDomainName	Opcional	Use-o quando um servidor DNS personalizado for usado para a resolução de nomes de uma rede virtual. Forneça o FQDN da origem de servidor único de acordo com o servidor DNS personalizado dessa propriedade.
TargetDBServerFullyQualifiedDomainName	Opcional	Use-o quando um servidor DNS personalizado for usado para a resolução de nomes em uma rede virtual. Forneça o FQDN do destino de servidor flexível de acordo com o servidor DNS personalizado. SourceDBServerFullyQualifiedDomainName e TargetDBServerFullyQualifiedDomainName devem ser incluídos como parte do JSON apenas no cenário raro de um servidor DNS personalizado ser usado para a resolução de nomes em vez do DNS fornecido pelo Azure. Caso contrário, não inclua esses parâmetros no arquivo JSON.

Observe esses pontos essenciais para a resposta do comando:

• Quando o comando create é acionado, a migração passa para o estado InProgress e para o substrato PerformingPreRequisiteSteps. 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 subestado PerformingPreRequisiteSteps, a migração passa para o substrato de Migrating Data, onde ocorre a clonagem/cópia dos bancos de dados.
• Cada banco de dados migrado tem uma seção própria com todos os detalhes da migração, como contagem de tabelas, inserções incrementais, exclusões e bytes pendentes.
• O tempo que o subestado Migrating Data leva para terminar depende do tamanho dos bancos de dados que são migrados.
• A migração passa para o estado Succeeded assim que o subestado Migrating Data é concluído com êxito. Se houver um problema no subestado Migrating Data, a migração passará para o estado Failed.

Replicação de configuração

Se a visualização da migração Online estiver selecionada, a replicação lógica deverá estar 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 parâmetro SetupLogicalReplicationOnSourceDBIfNeeded for passado com um valor true no arquivo JSON que o acompanha. A replicação também pode ser configurada manualmente na origem após iniciar a migração usando o comando abaixo. Qualquer abordagem 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

Esse comando é necessário para avançar na migração quando o servidor flexível estiver aguardando no estado WaitingForLogicalReplicationSetupRequestOnSourceDB.

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

Liste as migrações

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

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

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

• Active: Lista as tentativas de migração ativas atuais (em progresso) para o servidor de destino. Ela não inclui as migrações que falharam, foram canceladas ou foram 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 parâmetro help:

az postgres flexible-server migration list -- help

Monitorar a migração

O comando show ajuda você a monitorar as migrações em andamento e fornece o estado e o subestado atuais 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 parâmetro migration_name é o nome atribuído à migração durante o comando create. Este é um instantâneo da resposta de exemplo do comando da CLI para mostrar os detalhes:

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

 az postgres flexible-server migration show -- help

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

Estado de migração	Descrição
InProgress	A infraestrutura de migração está configurada ou a migração de dados atual está em andamento.
Canceled	A migração foi cancelada ou excluída.
Failed	A migração falhou.
Succeeded	A migração foi bem-sucedida e está concluída.

Subestado da migração	Descrição
PerformingPreRequisiteSteps	A infraestrutura está configurada e preparada para a migração de dados.
MigratingData	Migração de dados em andamento.
CompletingMigration	A substituição da migração está em andamento.
Completed	a transferência 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 passa para o subestado WaitingForCutoverTrigger. Nesse estado, o usuário pode disparar a substituição por meio da CLI usando o comando abaixo. A substituição também pode ser disparada no portal selecionando o nome da migração na grade de migrações.

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 a substituição, é importante garantir que:

• As gravações na origem sejam interrompidas – o parâmetro latency diminui para 0 ou perto de 0

O parâmetro latency indica quando o destino foi sincronizado pela última vez com a origem. Por exemplo, aqui são 201 e 202 para os dois bancos de dados, conforme mostrado na imagem abaixo. Isso significa que as alterações que ocorreram aproximadamente nos últimos 200 segundos na origem ainda não foram sincronizadas com o destino. Neste ponto, as gravações na origem podem ser interrompidas e a substituição iniciada. Caso haja tráfego intenso na origem, é recomendável interromper as gravações primeiro para que Latency possa chegar perto de 0 e, em seguida, a transição seja iniciada. A operação Cutover aplica todas as alterações pendentes da origem para o destino e conclui a migração. Se você acionar uma "Cutover" mesmo com um Latency diferente de zero, a replicação será interrompida até esse momento. Todos os dados na origem até o ponto de transição são então aplicados ao destino. Digamos que uma latência foi de 15 minutos no ponto de transição, portanto todos os dados alterados nos últimos 15 minutos se aplicam ao destino. O tempo necessário depende do acúmulo de alterações ocorridas nos últimos 15 minutos. Portanto, é recomendável que a latência atinja zero ou perto de zero, antes de disparar a substituição. As informações latency 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 for iniciada, todas as transações que aconteceram durante a cópia base serão copiadas sequencialmente para o destino e a migração será concluída.

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

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

 az postgres flexible-server migration update -- help

Cancelar a migração usando CLI

Você pode cancelar todas as tentativas de migração em andamento usando o comando cancel. Esse comando interrompe a tentativa de migração específica, mas não descarta ou reverte nenhuma alteração no servidor de destino. Veja o comando da CLI usado 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 parâmetro help:

 az postgres flexible-server migration update cancel -- help

Esse comando fornece a seguinte saída:

Após a migração

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

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

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

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

• Altere o SKU do servidor flexível para que ele corresponda às necessidades do aplicativo. Essa alteração exige uma reinicialização do servidor de banco de dados.

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

• Copie outras configurações de servidor, como marcas, alertas e regras de firewall (se aplicável) da instância de origem para o servidor flexível.

• Faça alterações em seu aplicativo para apontar as cadeias de conexão para um servidor flexível.

• Monitore o desempenho do banco de dados de perto para ver se ele exige um ajuste de desempenho.

Conteúdo relacionado

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