Tutorial: como migrar do Banco de Dados do Azure para PostgreSQL – Servidor Único para o 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 sua migração com o serviço de migração no Banco de Dados do Azure para PostgreSQL, você deve cumprir os seguintes pré-requisitos, que se aplicam a cenários de migração offline.

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 servidor flexível do Banco de Dados do Azure para PostgreSQL deve ser implantado e configurado adequadamente no Azure antes de você iniciar o processo de migração.

• A SKU escolhida para o Banco de Dados do Azure para PostgreSQL deve corresponder às especificações do banco de dados de origem para garantir 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.

• Ao migrar entre versões do PostgreSQL (principais ou secundárias), certifique-de que haja compatibilidade entre seu banco de dados e o aplicativo lendo as notas de versão para detectar possíveis alterações interruptivas.

Configuração da rede

A configuração de rede é essencial para que o serviço de migração funcione corretamente. Verifique se o servidor PostgreSQL de origem consegue se comunicar com o servidor de destino do Banco de Dados do Azure para PostgreSQL. As configurações de rede a seguir são fundamentais para uma migração bem-sucedida.

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

Habilitar extensões

Para garantir uma migração bem-sucedida usando o serviço de migração no Banco de Dados do Azure para PostgreSQL, talvez seja necessário verificar as extensões da sua instância de origem do PostgreSQL. As extensões oferecem funcionalidades e recursos que podem ser necessários para seu aplicativo. Certifique-se de verificar as extensões na instância de origem do PostgreSQL antes de iniciar o processo de migração.

Na instância de destino do Banco de Dados do Azure para PostgreSQL – Servidor Flexível, habilite as extensões com suporte identificadas na instância de origem do PostgreSQL.

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

Observação

É obrigatório reiniciar quando você fizer qualquer alteração no parâmetro shared_preload_libraries.

Verificar os parâmetros do servidor

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

• Faça a correspondência entre os valores dos parâmetros do servidor do banco de dados PostgreSQL de origem e o 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 nos parâmetros e, se necessário, reinicie o servidor flexível do Banco de Dados do Azure para PostgreSQL para aplicar a nova configuração.

Importante

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

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

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

• Ao seguir essas diretrizes, você poderá ajudar a garantir um processo de migração tranquilo, sem as variáveis adicionais introduzidas pela alta disponibilidade e pelas 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 permitidos 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 for distorcida, a velocidade de migração poderá ser mais lenta do que o esperado. Nesse caso, a velocidade de migração pode ser aumentada migrando a tabela grande em paralelo.

Configurar a tarefa de migração

O serviço de migração vem com uma experiência simples 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. 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 diferentes fontes possíveis. Por padrão, o tipo de servidor de origem é definido como Servidor Único do Banco de Dados do Azure para PostgreSQL, que é aquele em que estamos interessados nesse cenário.

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á tiver criado um Servidor Flexível e quiser usá-lo como destino, escolha Selecionar existente e selecione os detalhes correspondentes de Assinatura, Grupo de recursos e Nome do servidor. Depois de feitas as seleções, selecione Ir para o assistente de migração e siga as instruções na seção Configuração.

   

4. Caso opte por criar um servidor flexível, selecione Criar e 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.

Instalação

A primeira guia é Configuração. Caso você não tenha percebido, permita as extensões necessárias, conforme descrito em Configurar seu servidor flexível do Banco de Dados do Azure para PostgreSQL, 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 somente caracteres alfanuméricos e não aceita nenhum caractere especial, exceto sublinhado (_) e hífen (-). O nome deve começar com um caractere alfanumérico. O nome também deve ser exclusivo para um servidor de destino, pois duas migrações para o mesmo destino do Servidor Flexível não podem ter o mesmo nome.

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

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

Modo de migração permite que você escolha entre uma migração online e offline; nesse caso, deve ser definido como Offline.

Selecione o botão Avançar: Selecionar Servidor de Runtime.

Servidor de Runtime

O Servidor de Runtime de Migração é uma funcionalidade especializada dentro do serviço de migração no Banco de Dados do Azure para PostgreSQL, desenvolvida para atuar como um servidor intermediário durante a migração. É uma instância separada do Banco de Dados do Azure para PostgreSQL – Servidor Flexível que não é o servidor de destino, mas é usada para facilitar a migração de bancos de dados de um ambiente de origem que só é acessível por meio de uma rede privada.

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

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

Conectar à origem

A seção Origem solicita que você forneça 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 que você escolher a origem do Servidor Único, as caixas Localização e Versão do PostgreSQL serão preenchidas automaticamente. Certifique-se de fornecer as credenciais de uma função de administrador, pois isso é necessário para que o serviço de migração migre com êxito os bancos de dados.

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

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

Selecione o destino de migração

A seção Selecionar alvo de migração exibe metadados para o destino do Servidor Flexível, como Assinatura, Grupo de recursos, Nome do servidor, Localização e versão do PostgreSQL.

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

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

Selecione o botão Avançar: Selecionar banco(s) de dados para migração para selecionar os bancos de dados a serem migrados.

Selecionar os banco(s) de dados para 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. Os bancos de dados selecionados que existem no servidor de destino com exatamente os mesmos nomes são substituídos.

Selecione o botão Avançar: Resumo 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 o botão Iniciar Validação e Migração.

Monitore o portal de migração

Depois de iniciada a migração, aparecerá uma notificação 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 as seguintes colunas: Nome, Status, Modo de migração, Tipo de migração, Servidor de origem, Tipo de servidor de origem, Bancos de dados, Hora de início e Duração. As entradas são exibidas na ordem decrescente da hora de início com a entrada mais recente na parte superior.

Você pode usar o botão Atualizar para atualizar o status da validação ou migração.

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

Quando a validação ou migração é criada, ela 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 as 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 as seguintes informações:

• 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.
• Nome da Validação: O nome de cada regra de validação específica.
• Status da validação: Representa o resultado de 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 gasto para a operação de validação.
• Hora de início (UTC) e Hora de término (UTC) - Horários 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 subestado PerformingPreRequisiteSteps, a migração passa para o subestado Migrando Dados 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 tem todas as contagens de tabelas (copiadas, enfileiradas, copiadas e erros) e também o status da 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 atualizar a página para verificar o progresso.

Validar e Migrar

Nessa opção, as validações são executadas primeiro antes do início da migração. 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

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.

Configure os 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.

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

Configurar o 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;

• Ao migrar entre versões do PostgreSQL (principais ou secundárias), certifique-de que haja compatibilidade entre seu banco de dados e o aplicativo lendo as notas de versão para detectar possíveis alterações interruptivas.

Importante

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

Configurar a rede

A configuração de rede é essencial para que o serviço de migração funcione corretamente. Verifique se o servidor PostgreSQL de origem consegue se comunicar com o servidor de destino do Banco de Dados do Azure para PostgreSQL. As configurações de rede a seguir são fundamentais para uma migração bem-sucedida.

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

Habilitar extensões

Para garantir uma migração bem-sucedida usando o serviço de migração no Banco de Dados do Azure para PostgreSQL, talvez seja necessário verificar as extensões da sua instância de origem do PostgreSQL. As extensões oferecem funcionalidades e recursos que podem ser necessários para seu aplicativo. Certifique-se de verificar as extensões na instância de origem do PostgreSQL antes de iniciar o processo de migração.

Na instância de destino do Banco de Dados do Azure para PostgreSQL – Servidor Flexível, habilite as extensões com suporte identificadas na instância de origem do PostgreSQL.

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

Observação

É obrigatório reiniciar quando você fizer qualquer alteração no parâmetro shared_preload_libraries.

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.

Observação

Algumas limitações se aplicam à migração online documentada aqui. Verifique se o banco de dados está em conformidade para executar uma migração online.

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 permitidos 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 for distorcida, a velocidade de migração poderá ser mais lenta do que o esperado. Nesse caso, a velocidade de migração pode ser aumentada migrando a tabela grande em paralelo.

Configurar a tarefa de migração

O serviço de migração vem com uma experiência simples 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. 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 diferentes fontes possíveis. Por padrão, o tipo de servidor de origem é definido como Servidor Único do Banco de Dados do Azure para PostgreSQL, que é aquele em que estamos interessados nesse cenário.

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á tiver criado um Servidor Flexível e quiser usá-lo como destino, escolha Selecionar existente e selecione os detalhes correspondentes de Assinatura, Grupo de recursos e Nome do servidor. Depois de feitas as seleções, selecione Ir para o assistente de migração e siga as instruções na seção Configuração.

   

4. Caso opte por criar um servidor flexível, selecione Criar e 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.

Instalação

A primeira guia é Configuração. Caso você não tenha percebido, permita as extensões necessárias, conforme descrito em Configurar seu servidor flexível do Banco de Dados do Azure para PostgreSQL, 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 somente caracteres alfanuméricos e não aceita nenhum caractere especial, exceto sublinhado (_) e hífen (-). O nome deve começar com um caractere alfanumérico. O nome também deve ser exclusivo para um servidor de destino, pois duas migrações para o mesmo destino do Servidor Flexível não podem ter o mesmo nome.

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

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

Modo de migração permite que você escolha entre uma migração online e offline; nesse caso, ele deve ser definido como Online.

Quando o modo de migração Online for selecionado, 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 selecionando o item Replicação, em Configurações no menu de recursos do servidor único, e configurando Suporte à replicação do Azure para LÓGICA. Qualquer abordagem reinicia o servidor único de origem.

Selecione o botão Avançar: Selecionar Servidor de Runtime.

Servidor de Runtime

O Servidor de Runtime de Migração é uma funcionalidade especializada dentro do serviço de migração no Banco de Dados do Azure para PostgreSQL, desenvolvida para atuar como um servidor intermediário durante a migração. É uma instância separada do Banco de Dados do Azure para PostgreSQL – Servidor Flexível que não é o servidor de destino, mas é usada para facilitar a migração de bancos de dados de um ambiente de origem que só é acessível por meio de uma rede privada.

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

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

Conectar à origem

A seção Origem solicita que você forneça 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 que você escolher a origem do Servidor Único, as caixas Localização e Versão do PostgreSQL serão preenchidas automaticamente. Certifique-se de fornecer as credenciais de uma função de administrador, pois isso é necessário para que o serviço de migração migre com êxito os bancos de dados.

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

Selecione o destino de migração

A seção Selecionar alvo de migração exibe metadados para o destino do Servidor Flexível, como Assinatura, Grupo de recursos, Nome do servidor, Localização e versão do PostgreSQL.

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

Selecione o botão Avançar: Selecionar banco(s) de dados para migração para selecionar os bancos de dados a serem migrados.

Selecionar os banco(s) de dados para 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. Os bancos de dados selecionados que existem no servidor de destino com exatamente os mesmos nomes são substituídos.

Selecione o botão Avançar: Resumo 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 o botão Iniciar Validação e Migração.

Monitore o portal de migração

Depois de iniciada a migração, aparecerá uma notificação 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 as seguintes colunas: Nome, Status, Modo de migração, Tipo de migração, Servidor de origem, Tipo de servidor de origem, Bancos de dados, Hora de início e Duração. As entradas são exibidas na ordem decrescente da hora de início com a entrada mais recente na parte superior.

Você pode usar o botão Atualizar para atualizar o status da validação ou migração.

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

Quando a validação ou migração é criada, ela 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 as 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 as seguintes informações:

• 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.
• Nome da Validação: O nome de cada regra de validação específica.
• Status da validação: Representa o resultado de 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 gasto para a operação de validação.
• Hora de início (UTC) e Hora de término (UTC) - Horários 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 subestado PerformingPreRequisiteSteps, a migração passa para o subestado Migrando Dados 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 tem todas as contagens de tabelas (copiadas, enfileiradas, copiadas e erros) e também o status da 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 atualizar a página para verificar o progresso.

Validar e Migrar

Nessa opção, as validações são executadas primeiro antes do início da migração. 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

Para as opções de migração Migrar e Validar e Migrar, a conclusão da migração online requer que o usuário complete uma etapa adicional, que é disparar a ação de Substituição. Após a conclusão da cópia/clonagem dos dados básicos, a migração passa para o estado WaitingForUserAction e para o sub-estado WaitingForCutoverTrigger. Nesse estado, o usuário pode disparar o corte a partir do portal selecionando a migração e selecionando o botão Substituiçã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 de 0. As Latency (minutes) informações podem ser obtidas na tela de detalhes da migração:

O parâmetro Latency (minutes) indica quando o destino foi sincronizado pela última vez com a origem. Por exemplo, para o banco de dados Pedidos acima, é 0,33333. Isso significa que as alterações que ocorreram nos últimos ~0,3 minutos na origem ainda não foram enviadas para o destino, para o banco de dados Pedidos. 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 (minutes) possa se aproximar de 0 e só então iniciar a substituição. A operação de substituição aplica todas as alterações pendentes da origem ao destino e conclui a migração. Se você disparar uma substituição mesmo com latência diferente de zero, a replicação será interrompida até aquele momento. Todos os dados na origem até o ponto de transição são então aplicados ao destino. Digamos que a latência seja de 15 minutos no ponto de substituição, então todos os dados alterados nos últimos 15 minutos serã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 seja zero ou próxima de zero antes de disparar o substituição.

A migração passa para o estado Bem-sucedido assim que o subestado Migrando Dados ou o substituição (no modo de migração online) for concluído com êxito. Se houver um problema no subestado Migrando Dados, a migração passa para um estado Com Falha.

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. A ação de cancelamento reverterá todas as alterações feitas pelo serviço de migração no servidor de destino.

CLI

Você pode migrar usando a CLI do Azure.

Offline

Pré-requisitos (offline)

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

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 servidor flexível do Banco de Dados do Azure para PostgreSQL deve ser implantado e configurado adequadamente no Azure antes de você iniciar o processo de migração.

• A SKU escolhida para o Banco de Dados do Azure para PostgreSQL deve corresponder às especificações do banco de dados de origem para garantir 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.

• Ao migrar entre versões do PostgreSQL (principais ou secundárias), certifique-de que haja compatibilidade entre seu banco de dados e o aplicativo lendo as notas de versão para detectar possíveis alterações interruptivas.

Configuração da rede

A configuração de rede é essencial para que o serviço de migração funcione corretamente. Verifique se o servidor PostgreSQL de origem consegue se comunicar com o servidor de destino do Banco de Dados do Azure para PostgreSQL. As configurações de rede a seguir são fundamentais para uma migração bem-sucedida.

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

Habilitar extensões

Para garantir uma migração bem-sucedida usando o serviço de migração no Banco de Dados do Azure para PostgreSQL, talvez seja necessário verificar as extensões da sua instância de origem do PostgreSQL. As extensões oferecem funcionalidades e recursos que podem ser necessários para seu aplicativo. Certifique-se de verificar as extensões na instância de origem do PostgreSQL antes de iniciar o processo de migração.

Na instância de destino do Banco de Dados do Azure para PostgreSQL – Servidor Flexível, habilite as extensões com suporte identificadas na instância de origem do PostgreSQL.

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

Observação

É obrigatório reiniciar quando você fizer qualquer alteração no parâmetro shared_preload_libraries.

Verificar os parâmetros do servidor

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

• Faça a correspondência entre os valores dos parâmetros do servidor do banco de dados PostgreSQL de origem e o 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 nos parâmetros e, se necessário, reinicie o servidor flexível do Banco de Dados do Azure para PostgreSQL para aplicar a nova configuração.

Importante

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

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

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

• Ao seguir essas diretrizes, você poderá ajudar a garantir um processo de migração tranquilo, sem as variáveis adicionais introduzidas pela alta disponibilidade e pelas 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

A execução do comando anterior retorna 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

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

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 para cada migração para esse destino do Servidor flexível. Esse campo aceita somente caracteres alfanuméricos e não aceita nenhum caractere especial, exceto sublinhado (_) e hífen (-). O nome deve começar e terminar com um caractere alfanumérico. O nome também deve ser exclusivo para um servidor de destino, pois duas migrações para o mesmo destino do Servidor Flexível não podem ter o mesmo nome.
migration-mode	Esse é um parâmetro opcional. Valor padrão: offline. A migração offline envolve copiar seus bancos de dados de origem em um determinado momento para o seu 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 "./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/<sourceServerResourceGroup>/providers/Microsoft.DBforPostgreSQL/servers/<sourceServer>",
		"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 do Servidor Único.
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 especificado durante a criação de um servidor único, e a senha fornecida é usada para autenticação com esse usuário. Se você não estiver usando o usuário padrão, esse parâmetro será o usuário ou a função no servidor de origem para 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 com esse 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 modelos, como template0 e template1, não sã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 é disparado, a migração passa para o estado InProgress e para o subestado 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 subestado Migrating Data,, no qual 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.

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 atuais (em andamento) 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 tanto as migrações ativas quanto as concluídas, 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.

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.
ValidationFailed	A migração falhou durante a validação da pré-migração.

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	Conclusão do processo de migração.
Completed	A migração foi concluída, seja em um estado bem-sucedido ou não.
CancelingRequestedDBMigrations	Cancelamento da migração.
ValidationInProgress	Validação em andamento.

Online

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.

Configure os 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.

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

Configurar o 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;

• Ao migrar entre versões do PostgreSQL (principais ou secundárias), certifique-de que haja compatibilidade entre seu banco de dados e o aplicativo lendo as notas de versão para detectar possíveis alterações interruptivas.

Importante

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

Configurar a rede

A configuração de rede é essencial para que o serviço de migração funcione corretamente. Verifique se o servidor PostgreSQL de origem consegue se comunicar com o servidor de destino do Banco de Dados do Azure para PostgreSQL. As configurações de rede a seguir são fundamentais para uma migração bem-sucedida.

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

Habilitar extensões

Para garantir uma migração bem-sucedida usando o serviço de migração no Banco de Dados do Azure para PostgreSQL, talvez seja necessário verificar as extensões da sua instância de origem do PostgreSQL. As extensões oferecem funcionalidades e recursos que podem ser necessários para seu aplicativo. Certifique-se de verificar as extensões na instância de origem do PostgreSQL antes de iniciar o processo de migração.

Na instância de destino do Banco de Dados do Azure para PostgreSQL – Servidor Flexível, habilite as extensões com suporte identificadas na instância de origem do PostgreSQL.

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

Observação

É obrigatório reiniciar quando você fizer qualquer alteração no parâmetro shared_preload_libraries.

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.

Observação

Algumas limitações se aplicam à migração online documentada aqui. Verifique se o banco de dados está em conformidade para executar uma migração online.

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

A execução do comando anterior retorna 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

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

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 para cada migração para esse destino do Servidor flexível. Esse campo aceita somente caracteres alfanuméricos e não aceita nenhum caractere especial, exceto sublinhado (_) e hífen (-). O nome deve começar e terminar com um caractere alfanumérico. O nome também deve ser exclusivo para um servidor de destino, pois duas migrações para o mesmo destino do Servidor Flexível não podem ter o mesmo nome.
migration-mode	Esse é um parâmetro opcional. O valor padrão é Offline. Para migrações online, você deve passar Online.
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 "./migrationBody.json" --migration-mode online

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/<sourceServerResourceGroup>/providers/Microsoft.DBforPostgreSQL/servers/<sourceServer>",
    "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 do Servidor Único.
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 especificado durante a criação de um servidor único, e a senha fornecida é usada para autenticação com esse usuário. Se você não estiver usando o usuário padrão, esse parâmetro será o usuário ou a função no servidor de origem para 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 com esse 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 modelos, como template0 e template1, não sã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 é disparado, a migração passa para o estado InProgress e para o subestado 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 subestado Migrating Data,, no qual 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

Para o modo de migração online, a replicação lógica deve 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, use:

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

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 atuais (em andamento) 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 tanto as migrações ativas quanto as concluídas, independentemente do estado.

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

az postgres flexible-server migration list --help

Monitorar as migrações

O comando show ajuda você a monitorar as migrações em andamento e fornece o estado e o subestado atuais 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. Aqui temos um instantâneo da amostra de resposta do comando da CLI para monitorar a migração:

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.
ValidationFailed	A migração falhou durante a validação da pré-migração.

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.
WaitingForCutoverTrigger	Tarefa de migração de dados concluída e aguardando que o usuário dispare a transferência.
CompletingMigration	Conclusão do processo de migração.
Completed	A migração foi concluída, seja em um estado bem-sucedido ou não.
CancelingRequestedDBMigrations	Cancelamento da migração.
ValidationInProgress	Validação em andamento.

Substituição das migrações

Nas migrações online, após a conclusão da migração dos dados básicos, 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 transição, é essencial garantir que:

• As gravações na origem são interrompidas -latency parâmetro é 0 ou próximo 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 e reverte todas as alterações no servidor de destino. Aqui está o comando da CLI para cancelar uma migração:

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

Por exemplo:

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

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

 az postgres flexible-server migration update cancel --help

Esse comando fornece a seguinte saída:

Verifique a migração depois de concluí-la

Após uma migração bem-sucedida, certifique-se de que você pode fazer logon no seu servidor flexível usando as mesmas credenciais do servidor único. Se estiver encontrando erros de autenticação no seu servidor flexível depois de migrar de um único servidor, isso poderá ser devido ao fato de a VM do servidor flexível ser FIPS-compliant ou usar um algoritmo de criptografia de senha diferente (SCRAM-SHA-256) em comparação com a criptografia MD5 do servidor único. Para atenuar esse problema, siga estas etapas:

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

Isso deve resolver os erros de autenticação.

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

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