Partilhar via

Tutorial: Migrar online do Google Cloud SQL para PostgreSQL para o Banco de Dados do Azure para PostgreSQL com o serviço de migração Preview

Este artigo explora como migrar seu banco de dados PostgreSQL do Google Cloud SQL para PostgreSQL para o Banco de Dados do Azure para PostgreSQL online.

O serviço de migração no Banco de Dados do Azure para PostgreSQL é um serviço totalmente gerenciado integrado ao portal do Azure e à CLI do Azure. Ele foi projetado para simplificar sua jornada de migração para o Banco de Dados do Azure para o servidor PostgreSQL.

  • Pré-requisitos
  • Executar a migração
  • Monitorize a migração
  • Transição de Sistema
  • Verifique a migração quando concluída

Pré-requisitos

Para concluir a migração, você precisa dos seguintes pré-requisitos:

Antes de iniciar a migração com o serviço de migração Banco de Dados do Azure para PostgreSQL, é importante cumprir os seguintes pré-requisitos, projetados especificamente para cenários de migração online.

Verifique a versão de origem

A versão do servidor PostgreSQL de origem deve ser 9.5 ou posterior.

Se a versão de origem do PostgreSQL for menor que 9.5, atualize-a para 9.5 ou superior antes de iniciar a migração.

Nota

O serviço de migração no Banco de Dados do Azure para PostgreSQL dá suporte a conexões usando o endereço IP de origem do Google Cloud SQL para PostgreSQL. O formato myproject:myregion:myinstance não é suportado.

Instalar test_decoding - configuração fonte

  • test_decoding recebe WAL através do mecanismo de decodificação lógica e decodifica-o em representações de texto das operações realizadas.
  • No Google Cloud SQL para PostgreSQL, o plug-in test_decoding está pré-instalado e pronto para replicação lógica. Isso permite configurar facilmente slots de replicação lógica e transmitir alterações de WAL, facilitando casos de uso, como captura de dados de alteração (CDC) ou replicação para sistemas externos.
  • Para obter mais informações sobre o plug-in de descodificação de teste, consulte a documentação do PostgreSQL

Configurar a configuração de destino

  • Antes de migrar, o Banco de Dados do Azure para PostgreSQL – Servidor flexível deve ser criado.
  • SKU provisionado para o Banco de Dados do Azure para PostgreSQL – O servidor flexível deve corresponder à origem.
  • Para criar um novo Banco de Dados do Azure para PostgreSQL, visite Criar um Banco de Dados do Azure para servidor flexível PostgreSQL

Habilitar o CDC como fonte

  • test_decoding O plugin de decodificação lógica captura os registros alterados da fonte.
  • Para garantir que o usuário de migração tenha os privilégios de replicação necessários, execute o seguinte comando SQL:
Alter user <<username>> with REPLICATION;

  • Vá para a instância do Google Cloud SQL PostgreSQL no Google Cloud Console, selecione o nome da instância para abrir sua página de detalhes, selecione o botão Editar e, na seção Sinalizadores, modifique os seguintes sinalizadores:

    • Definir sinalizador cloudsql.logical_decoding = on
    • Defina flag max_replication_slots como um valor maior que um, o valor deve ser maior do que o número de bancos de dados selecionados para migração.
    • Defina sinalizador max_wal_senders para um valor maior que um. Deve ser pelo menos o mesmo que max_replication_slots, mais o número de remetentes já usados na sua instância.
    • O sinalizador wal_sender_timeout encerra conexões de replicação inativas por mais tempo do que o número especificado de milissegundos. Definir o valor como 0 (zero) desativa o mecanismo de tempo limite e é uma configuração válida para migração.

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

Configurar a configuração da rede

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

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

Ativar extensões

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

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

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

Nota

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

Verificar parâmetros do servidor

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

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

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

Verificar usuários e funções

Ao migrar para o Banco de Dados do Azure para PostgreSQL, é essencial abordar a migração de usuários e funções separadamente, pois eles exigem intervenção manual:

  • Migração manual de usuários e funções: os usuários e suas funções associadas devem ser migrados manualmente para o Banco de Dados do Azure para PostgreSQL. Para facilitar esse processo, você pode usar o pg_dumpall utilitário com o --globals-only sinalizador para exportar objetos globais, como funções e contas de usuário. Execute o seguinte comando, substituindo <<username>> pelo nome de usuário real e <<filename>> pelo nome do arquivo de saída desejado:

    pg_dumpall --globals-only -U <<username>> -f <<filename>>.sql

  • Restrição de funções de superusuário: o Banco de Dados do Azure para PostgreSQL não oferece suporte a funções de superusuário. Portanto, os usuários com privilégios de superusuário devem ter esses privilégios removidos antes da migração. Certifique-se de ajustar as permissões e funções de forma adequada.

Seguindo estas etapas, você pode garantir que as contas e funções de usuário sejam migradas corretamente para o Banco de Dados do Azure para PostgreSQL sem encontrar problemas relacionados a restrições de superusuário.

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

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

  • Seguindo estas diretrizes, podes ajudar a garantir um processo de migração suave, sem as variáveis introduzidas pelo HA e pelas Read Replicas. Quando a migração estiver concluída e o banco de dados estiver estável, você poderá continuar habilitando esses recursos para aprimorar a disponibilidade e a escalabilidade do seu ambiente de banco de dados no Azure.

Executar a migração

Você pode migrar usando o portal do Azure ou a CLI do Azure.

O portal do Azure fornece uma experiência simples e intuitiva baseada em assistente que o orienta durante a migração. Seguindo as etapas descritas neste tutorial, você pode transferir perfeitamente seu banco de dados para o banco de dados do Azure para o servidor flexível PostgreSQL e aproveitar seus poderosos recursos e escalabilidade.

Para migrar com o portal do Azure, primeiro configure a tarefa de migração, conecte-se à origem e ao destino e, em seguida, execute a migração.

Configurar a tarefa de migração

O serviço de migração oferece uma experiência simples orientada por assistente no portal do Azure. Veja como começar:

  1. Abra o browser e aceda ao portal do Azure. Introduza as suas credenciais para iniciar sessão. A vista predefinida é o painel de controlo do serviço.

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

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

    Captura de tela mostrando a seleção Migração no portal do Azure, destacando a opção de migração para PostgreSQL.

  4. Selecione o botão Criar para migrar do Google Cloud SQL para PostgreSQL para o banco de dados do Azure para o servidor flexível PostgreSQL. Se esta for a primeira vez que você usa o serviço de migração, uma grade vazia será exibida com um prompt para iniciar sua primeira migração.

    Captura de ecrã a mostrar a criação de uma migração a partir do portal.

    Se você já criou migrações para seu Banco de Dados do Azure para destino PostgreSQL, a grade contém informações sobre tentativas de migração.

  5. Selecione o botão Criar. Em seguida, você percorre uma série de guias baseada em assistente para criar uma migração para esse destino do Banco de Dados do Azure para PostgreSQL a partir da instância de origem do PostgreSQL.

Configuração

A primeira guia é a guia Configuração , onde o usuário precisa fornecer detalhes de migração, como o tipo de origem do nome da migração, para iniciar as migrações.

Captura de ecrã a mostrar o separador de migração de configuração no portal do Azure.

  • O nome da migração é o identificador exclusivo de cada migração para esse destino do Servidor Flexível. Este campo aceita apenas caracteres alfanuméricos e não aceita nenhum caractere especial, exceto um hífen (-). O nome não pode começar com um hífen e deve ser exclusivo para um servidor de destino. Não há duas migrações para o mesmo destino do Servidor Flexível que possam ter o mesmo nome.

  • Tipo de servidor de origem — Dependendo da origem do PostgreSQL, você pode selecionar o tipo de fonte correspondente, como um serviço PostgreSQL baseado em nuvem, uma configuração local ou uma máquina virtual.

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

    • Validar - Verifica a preparação do servidor e do banco de dados para a migração para o destino.
    • Migrar - Ignora validações e inicia migrações.
    • Validar e Migrar—Executa a validação antes de acionar uma migração. A migração é acionada somente se não houver falhas de validação.

Escolher a opção Validar ou Validar e Migrar é sempre uma boa prática ao executar validações de pré-migração antes de executar a migração. Para obter mais informações sobre a validação pré-migração, consulte esta documentação.

  • O modo de migração permite que você escolha o modo para a migração. Offline é a opção padrão.

Selecione o botão Seguinte: Ligar à Fonte.

Selecionar Servidor de Tempo de Execução

O migration Runtime Server é um recurso especializado dentro do serviço de migração, projetado para atuar como um servidor intermediário durante a migração. É uma instância de servidor flexível separada do Banco de Dados do Azure para PostgreSQL que não é o servidor de destino, mas é usada para facilitar a migração de bancos de dados de um ambiente de origem acessível apenas por meio de uma rede privada.

Para obter mais informações sobre o Runtime Server, visite o Migration Runtime Server.

Captura de ecrã da página Migration Runtime Server.

Ligar à origem

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

Captura de tela de Connectsourcemigration.

  • Nome do servidor - Forneça o nome do host ou o endereço IP da instância PostgreSQL de origem
  • Porta - Número da porta do servidor de origem
  • Nome de login do administrador do servidor - Nome de usuário do servidor PostgreSQL de origem
  • Senha - Senha do servidor PostgreSQL de origem
  • Modo SSL—Os valores suportados são preferenciais e obrigatórios. Quando o SSL no servidor PostgreSQL de origem estiver desativado, use SSLMODE=prefer. Se o SSL no servidor de origem estiver ON, use SSLMODE=require. Os valores SSL podem ser determinados no arquivo Postgresql.conf.
  • Testar conexão—Executa o teste de conectividade entre o destino e a origem. Quando a conexão for bem-sucedida, os usuários poderão prosseguir com a próxima etapa. Caso contrário, precisamos identificar os problemas de rede entre o destino e a Fonte e verificar o nome de usuário/senha da Fonte. Estabelecer uma conexão de teste leva alguns minutos.

Após a conexão de teste bem-sucedida, selecione Seguinte: selecionar o destino da migração

Selecionar destino de migração

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

Captura de tela da tela de migração de destino de conexão.

  • Admin username - Nome de usuário Admin do servidor PostgreSQL de destino
  • Senha - Senha do servidor PostgreSQL de destino
  • FQDN/IP personalizado (opcional): O campo FQDN/IP personalizado é opcional e pode ser usado quando o destino está atrás de um servidor DNS personalizado ou tem namespaces DNS personalizados, tornando-o acessível apenas por meio de FQDNs ou endereços IP específicos. Por exemplo, isso pode incluir entradas como flexibleserver.example.com, 198.1.0.2 ou um FQDN do PostgreSQL, como flexibleserver.postgres.database.azure.com, se o servidor DNS personalizado contiver a zona postgres.database.azure.com DNS ou encaminhar consultas para essa zona para 168.63.129.16, onde o FQDN for resolvido na zona DNS pública ou privada do Azure.
  • Testar conexão - Executa o teste de conectividade entre o destino e a origem. Quando a conexão for bem-sucedida, os usuários poderão prosseguir com a próxima etapa. Caso contrário, precisamos identificar os problemas de rede entre o destino e a origem e verificar o nome de usuário/senha para o destino. A conexão de teste leva alguns minutos para estabelecer uma conexão entre o destino e a origem.

Após a conexão de teste bem-sucedida, selecione o botão Avançar: Selecionar banco de dados para migração

Selecionar bancos de dados para migração

Nesta guia, uma lista de bancos de dados de usuários está dentro do servidor de origem selecionado na guia de configuração. Você pode selecionar e migrar até oito bancos de dados em uma única tentativa de migração. Se houver mais de oito bancos de dados de usuários, o processo de migração será repetido entre os servidores de origem e de destino para o próximo conjunto de bancos de dados.

Captura de tela do FetchDBmigration do portal.

Depois de selecionar os bancos de dados, selecione Next : Summary

Resumo

O separador Resumo apresenta um resumo de todos os detalhes de origem e destino para criar a validação ou migração. Reveja os detalhes e selecione o botão Iniciar.

Captura de ecrã do resumo da migração do portal.

Monitorize a migração

Depois de selecionar o botão Iniciar, uma notificação aparecerá em alguns segundos informando que a validação ou a criação da migração foi bem-sucedida. Em seguida, você será redirecionado automaticamente para a página Migração do Servidor Flexível, que tem uma nova entrada para a validação ou migração criada recentemente.

Captura de ecrã da migração do Monitor a partir do portal.

A grade que exibe as migrações tem estas colunas: Nome, Status, Modo de migração, Tipo de migração, Servidor de origem, Tipo de servidor de origem, Bancos de dados, Duração e Hora de início. 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. Selecione o nome da migração na grade para ver os detalhes associados.

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

Detalhes da migração

Na guia Configuração, selecionamos a opção de migração como Migrar e Validar. Nesse cenário, as validações são executadas primeiro antes do início da migração. Depois que o subestado PerformingPreRequisiteSteps for concluído, o fluxo de trabalho será movido para o subestado de Validação em Andamento.

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

Você pode ver os resultados da validação e migração no nível da instância e do banco de dados.

Captura de ecrã da transferência de detalhes.

Alguns estados de migração possíveis:

Estados de migração

Estado Descrição
Em curso A configuração da infraestrutura de migração está em andamento ou a migração de dados real está em andamento.
Cancelado A migração é cancelada ou excluída.
Falha A migração falhou.
Falha na validação A validação falhou.
Bem sucedido A migração foi bem-sucedida e está concluída.
WaitingForUserAction Aplicável apenas para migração online. A aguardar a ação do utilizador para realizar a transição.

Subestados de migração

Subestado Descrição
ExecutandoPassosPré-requisitos A configuração da infraestrutura está em andamento para a migração de dados.
Validação em Curso A validação está em curso.
MigrandoData A migração de dados está em andamento.
ConcluindoMigração A migração está em fase final de conclusão.
Concluído A migração foi concluída.
Falha A migração falhou.

Subestados de validação

Subestado Descrição
Falhado A validação falhou.
Bem sucedido A validação foi bem-sucedida.
Aviso A validação está em estado de alerta.

Transição

Se existirem tanto Migrar como Validar e Migrar, concluir a migração online exigirá outro passo — o utilizador terá de realizar uma ação de transição. Após a conclusão da cópia/clone dos dados de base, a migração avança para o estado WaitingForUserAction e o subestado WaitingForCutoverTrigger. Nesse estado, o usuário pode acionar a mudança a partir do portal selecionando a migração.

Antes de iniciar o corte, é importante garantir que:

  • As gravações na origem estão interrompidas - Latency o valor é 0 ou próximo de 0. As Latency informações podem ser obtidas na tela de detalhes da migração, conforme mostrado abaixo:

    Captura de tela da migração de substituição.

  • latency o valor diminui para 0 ou perto de 0

  • O latency valor indica quando o destino foi sincronizado pela última vez com a origem. Neste ponto, a gravação na Fonte pode ser interrompida e a substituição pode ser iniciada. No caso de haver tráfego intenso na fonte, recomenda-se parar as gravações primeiro para que Latency possa chegar perto de 0 e, em seguida, uma substituição é iniciada. A operação de substituição aplica todas as alterações pendentes da origem para o destino e conclui a migração. Se desencadear um "Cutover" mesmo com Latency, diferente de zero, a replicação será interrompida até esse momento. Todos os dados estão na origem até que o ponto de corte seja aplicado ao destino. Digamos que uma latência foi de 15 minutos no ponto de transferência, portanto, todos os dados alterados nos últimos 15 minutos são aplicados ao destino. O tempo depende do acúmulo de alterações ocorridas nos últimos 15 minutos. Assim, recomenda-se que a latência vá para zero ou perto de zero antes de acionar o cutover.

    Screenshot de Confirmcutovermigration.

  • A migração avança para o Succeeded estado quando o Migrating Data subestado ou a transferência (na migração online) é concluída com êxito. Se houver um problema no Migrating Data subestado, a migração passa para um estado Failed.

    Captura de tela da migração bem-sucedida.

Verifique a migração quando concluída

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 certifique-se de que é uma cópia exata da instância de origem.
  • Após a verificação, ative a opção de alta disponibilidade em seu servidor flexível, conforme necessário.
  • Altere a SKU do servidor flexível para corresponder às necessidades do aplicativo. Essa alteração precisa ser reiniciada pelo servidor de banco de dados.
  • Se você alterar quaisquer parâmetros do servidor de seus valores padrão na instância de origem, copie esses valores de parâmetro do servidor no servidor flexível.
  • Copie outras configurações do servidor, como tags, alertas e regras de firewall (se aplicável), da instância de origem para o servidor flexível.
  • Faça alterações em seu aplicativo para apontar as cadeias de conexão para um servidor flexível.
  • Monitore o desempenho do banco de dados de perto para ver se ele requer ajuste de desempenho.

Conteúdos relacionados