Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
Este artigo orienta você na migração de uma instância do PostgreSQL de suas máquinas virtuais (VMs) locais ou do Azure para o Banco de Dados do Azure para PostgreSQL no modo 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 simplifica sua jornada de migração para o Banco de Dados do Azure para o servidor flexível PostgreSQL.
- Pré-requisitos
- Executar a migração
- Monitorize a migração
- Iniciar a transição
- Verifique a migração quando concluída
Pré-requisitos
Para iniciar 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
- Instalar test_decoding - Configuração da fonte
- Configurar a configuração de destino
- Habilitar o CDC como fonte
- Configurar a configuração da rede
- Ativar extensões
- Verificar parâmetros do servidor
- Verificar usuários e funções
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.
Observação
O serviço de migração no Azure Database for PostgreSQL dá suporte a conexões usando o endereço IP para o Google AlloyDB para PostgreSQL de origem. 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 AlloyDB 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 a Base de Dados Azure para PostgreSQL – O servidor flexível deve estar em conformidade com a fonte.
- 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_decodingO 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 <user> WITH REPLICATION;
Vá para a instância do Google AlloyDB 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
alloydb.logical_decoding = on - Defina flag
max_replication_slotscomo 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_senderspara um valor maior que um. Deve ser pelo menos igual amax_replication_slots, mais o número de remetentes já usados na sua instância. - O sinalizador
wal_sender_timeoutencerra 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.
- Definir sinalizador
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_ssdserver 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 e módulos.
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_dumpallutilitário com o--globals-onlysinalizador 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>>.sqlRestriçã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 adequadamente.
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.
Este artigo orienta você pelo uso do portal do Azure para migrar seu banco de dados PostgreSQL de um servidor Google AlloyDB para PostgreSQL para um Banco de Dados do Azure para PostgreSQL. O portal do Azure permite que você execute várias tarefas, incluindo a migração de banco de dados. Seguindo as etapas descritas neste tutorial, você pode transferir perfeitamente seu banco de dados para o Azure e aproveitar seus poderosos recursos e escalabilidade.
Configurar a tarefa de migração
O serviço de migração oferece uma experiência simples orientada por assistente no portal do Azure.
Usando o portal do Azure:
Selecione o seu servidor flexível do Azure Database for PostgreSQL.
No menu de recursos, selecione Migração.
Selecione Criar para percorrer uma série de guias baseada em assistente para executar uma migração para um servidor flexível a partir da VM local ou do Azure.
Observação
Na primeira vez que você usar o serviço de migração, uma grade vazia será exibida com um prompt para iniciar sua primeira migração.
Se as migrações para o destino flexível do servidor já tiverem sido criadas, a grade agora conterá informações sobre tentativas de migração.
Configuração
Você precisa fornecer vários detalhes relacionados à migração, como o nome da migração, o tipo de servidor de origem, a opção e o modo.
O nome da migração é o identificador exclusivo de cada migração para esse destino de 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 de servidor flexível que possam ter o mesmo nome.
Tipo de servidor de origem - Dependendo da sua origem PostgreSQL, pode selecionar Máquina Virtual do Azure ou Servidor no local.
Opção de migração - Permite executar validações antes de acionar uma migração. Você pode escolher qualquer uma das seguintes opções:
- Validar - Verifica a preparação do servidor e do banco de dados para a migração para o destino.
- Validar e migrar — Executa a validação antes de acionar uma migração. Se não houver falhas de validação, a migração será iniciada.
Escolher a opção Validar ou Validar e migrar é sempre uma boa prática para executar validações de pré-migração antes de executar a migração.
Para saber mais sobre a validação pré-migração, visite pré-migração.
- O modo de migração permite que você escolha o modo para a migração. Offline é a opção padrão. Neste caso, vamos alterá-lo para Online.
Selecione Próximo: Servidor de Execução.
Servidor de tempo de execução
O servidor de tempo de execução da migração é um recurso especializado dentro do serviço de migração no Banco de Dados do Azure para PostgreSQL, projetado para atuar como um servidor intermediário durante a migração. É 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 servidor de tempo de execução, visite Servidor de tempo de execução de migração.
Servidor de origem
A guia Servidor de origem solicita que você forneça detalhes relacionados à fonte selecionada na guia Configuração , que é a origem dos bancos de dados.
- Nome do servidor - Forneça o nome do host ou o endereço IP do servidor PostgreSQL de origem.
- Porta - Número da porta do servidor de origem.
- Login de administrador - Nome do usuário administrador do servidor PostgreSQL de origem.
- Senha - Senha do login do administrador fornecida para se conectar ao servidor PostgreSQL de origem.
-
Modo SSL - Os valores suportados são
preferrederequired. Quando o SSL no servidor PostgreSQL de origem forOFF, useprefer. Se o SSL no servidor de origem forON, use orequire. Os valores SSL podem ser determinados no arquivo postgresql.conf do servidor de origem. - Testar conexão — Executa o teste de conectividade entre o destino e a origem. Quando a conexão for bem-sucedida, você poderá prosseguir para a próxima guia. Esses testes visam identificar quaisquer problemas de conectividade que possam existir entre os servidores de destino e de origem, incluindo a verificação da autenticação usando as credenciais fornecidas. Estabelecer uma conexão de teste leva alguns segundos.
Após a conexão de teste bem-sucedida, selecione Avançar: Servidor de destino.
Servidor de destino
A guia Servidor de destino exibe metadados para o destino flexível do servidor, como o nome da assinatura, o grupo de recursos, o nome do servidor, o local e a versão do PostgreSQL.
- Login de administrador - Nome do usuário administrador do servidor PostgreSQL de destino.
- Senha - Senha do login do administrador fornecida para se conectar ao servidor PostgreSQL de destino.
-
FQDN ou endereço IP personalizado: O campo FQDN ou endereço 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
production-flexible-server.example.com,198.1.0.2ou um FQDN do PostgreSQL, comoproduction-flexible-server.postgres.database.azure.com, se o servidor DNS personalizado contiver a zonapostgres.database.azure.comDNS ou encaminhar consultas para essa zona para168.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 a origem e o destino. Quando a conexão for bem-sucedida, você poderá prosseguir para a próxima guia. Esses testes visam identificar quaisquer problemas de conectividade que possam existir entre os servidores de origem e de destino, incluindo a verificação da autenticação usando as credenciais fornecidas. Estabelecer uma conexão de teste leva alguns segundos.
Após a conexão de teste bem-sucedida, selecione Next : Databases para validar ou migrar
Bases de dados para validar ou migrar
Na guia Bancos de dados para validar ou migrar , você pode escolher uma lista de bancos de dados de usuários para migrar do seu servidor PostgreSQL de origem.
Depois de selecionar os bancos de dados, selecione Avançar: Resumo.
Resumo
A aba Resumo apresenta de forma resumida todos os detalhes de origem e destino para criar a validação ou migração. Reveja os detalhes e selecione Iniciar validação e migração.
Cancelar a validação ou migração
Você pode cancelar todas as validações ou migrações em andamento. O fluxo de trabalho deve estar no status Em andamento para ser cancelado. Não é possível cancelar uma validação ou migração no status Bem-sucedido ou Reprovado .
O cancelamento de uma validação interrompe qualquer atividade de validação adicional e a validação passa para um status Cancelado .
O cancelamento de uma migração interrompe a atividade de migração adicional no servidor de destino e passa para o status Cancelado . Ele não solta ou reverte nenhuma alteração no servidor de destino. Certifique-se de soltar os bancos de dados no servidor de destino envolvido em uma migração cancelada.
Monitorize a migração
Depois de selecionar o botão Iniciar validação e migração , uma notificação aparece, em alguns segundos, informando que a validação ou a criação da migração foi bem-sucedida. Você será redirecionado automaticamente para a página Migração do servidor flexível. A entrada mostra Status como Em andamento. O fluxo de trabalho leva de 2 a 3 minutos para configurar a infraestrutura de migração e verificar as conexões de rede.
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, Duração e Hora de início. As entradas são exibidas ordenadas por hora de início em ordem decrescente, com a entrada mais recente no topo. Você pode usar o botão Atualizar na barra de ferramentas para atualizar o status da execução de validação ou migração.
Detalhes da migração
Selecione o nome da migração na grade para ver os detalhes associados.
Lembre-se de que, nas etapas anteriores, ao criar essa migração, você configurou a opção de migração como Validar e migrar. Nesse cenário, as validações são executadas primeiro, antes do início da migração. Depois que o subestado Executando etapas de pré-requisito 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.
Os detalhes de validação estão disponíveis no nível da instância e do banco de dados.
-
Detalhes de validação, por exemplo
- Contém validação relacionada à verificação de conectividade, versão de origem, ou seja, versão >do PostgreSQL = 9.5, e verificação de parâmetros do servidor, se as extensões estão habilitadas nos parâmetros de servidor do Banco de Dados do Azure para servidor flexível PostgreSQL.
-
Detalhes de validação e migração para bancos de dados
- Ele contém a validação dos bancos de dados individuais relacionados ao suporte a extensões e agrupamentos no Banco de Dados do Azure para o servidor flexível PostgreSQL.
Você pode ver o status de validação e o status de migração na página de detalhes da migração.
Alguns status de migração possíveis:
Estado de migração
| Situação | Description |
|---|---|
| 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. |
| Aguardando ação do usuário | Aguardando a ação do usuário para executar a transferência. |
Detalhes da migração
| Subestatuto | Description |
|---|---|
| Executando etapas preparatórias | A configuração da infraestrutura está em andamento para a migração de dados. |
| Validação em curso | A validação está em curso. |
| Eliminando o banco de dados no destino | Descartando o banco de dados já existente no servidor de destino. |
| Migração de dados | A migração de dados está em andamento. |
| Concluir a migração | A migração está em fase final de conclusão. |
| Concluído | A migração foi concluída. |
| Falha | A migração falhou. |
Substatus de validação
| Subestatuto | Description |
|---|---|
| Falha | A validação falhou. |
| Bem-sucedido | A validação foi bem-sucedida. |
| Warning | A validação está em estado de alerta. |
Iniciar a transição
Você pode iniciar a substituição usando o portal do Azure ou a CLI do Azure.
Para a opção Validar e migrar , a conclusão da migração online exige que o usuário conclua uma etapa adicional, que é acionar a ação de substituição. Após a conclusão da cópia ou clonagem dos dados base, a migração passa para o estado Waiting for user action e o subestado Waiting for cutover trigger. Nesse estado, o utilizador pode iniciar a transição do portal ao selecionar a migração.
Antes de iniciar a transição, é importante garantir que:
- As gravações na fonte são interrompidas -
latencyo valor é 0 ou próximo de 0. Aslatencyinformações podem ser obtidas na tela de detalhes da migração, conforme mostrado abaixo: -
latencyo valor diminui para 0 ou perto de 0 - O
latencyvalor indica quando o destino foi sincronizado pela última vez com a origem. A escrita na fonte pode ser interrompida neste ponto, e uma transição pode ser iniciada. No caso de haver tráfego intenso na origem, recomenda-se parar as gravações primeiro para quelatencypossa chegar perto de 0 e, em seguida, uma substituição é iniciada.
A operação de substituição aplica todas as alterações pendentes do servidor de origem para o servidor de destino e conclui a migração. Se acionar um corte, mesmo com um valor diferente de zero latency, a replicação será interrompida até esse momento. Todos os dados na origem até o ponto de corte são então aplicados ao destino. Se ocorrer uma latência de 15 minutos no ponto de transferência, todas as alterações feitas nos dados nos últimos 15 minutos serão aplicadas ao destino.
O tempo depende do backlog 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 corte.
- A migração passa para o estado
Succeededquando o subestadoMigrating dataou o corte (na migração online) é concluído com êxito. Se houver um problema noMigrating datasubestado, a migração será movida para umFailedestado.
Verifique a migração quando concluída
Depois de concluir os bancos de dados, você precisa validar manualmente os dados entre origem e destino e verificar se todos os objetos no banco de dados de destino foram criados com êxito.
Após a migração, você pode executar as seguintes tarefas:
Verifique os dados em seu servidor flexível e certifique-se de que é uma cópia exata da instância de origem.
Após a verificação, ative a opção de alta disponibilidade em seu servidor flexível, conforme necessário.
Altere a SKU do servidor flexível para corresponder às necessidades do aplicativo. Essa alteração precisa ser reiniciada pelo servidor de banco de dados.
Se você alterar quaisquer parâmetros do servidor de seus valores padrão na instância de origem, copie esses valores de parâmetro do servidor no servidor flexível.
Copie outras configurações do servidor, como tags, alertas e regras de firewall (se aplicável), da instância de origem para o servidor flexível.
Faça alterações em seu aplicativo para apontar as cadeias de conexão para um servidor flexível.
Monitore o desempenho do banco de dados de perto para ver se ele requer ajuste de desempenho.