Tutorial: Migrar online do Google Cloud SQL para PostgreSQL para o Banco de Dados do Azure para PostgreSQL usando a versão prévia do serviço de migração

O portal do Azure oferece uma experiência simples e intuitiva baseada em um assistente que orienta você durante a migração. Seguindo as etapas descritas neste tutorial, você pode transferir seu banco de dados diretamente para o Banco de Dados do Azure para PostgreSQL – Servidor Flexível e aproveitar os recursos avançados e escalabilidade dele.

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

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. Insira suas credenciais para entrar. 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 para baixo até Migração e selecione-a.

   

4. Selecione o botão Criar para migrar do Google Cloud SQL para PostgreSQL para o Banco de Dados do Azure para PostgreSQL – 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á tiver criado migrações para o destino do Banco de Dados do Azure para PostgreSQL, a grade conterá informações sobre tentativas de migrações já realizadas.

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

Instalação

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

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

• Tipo de servidor de origem – dependendo da origem do PostgreSQL, você pode selecionar o tipo de origem 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 realizar validações antes de acionar uma migração. Você pode escolher uma das seguintes opções:

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

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

• O Modo de migração permite escolher o modo para a migração. Offline é a opção padrão.

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

Selecione Servidor de Runtime

O Servidor de Runtime de migração é um recurso especializado dentro do serviço de migração, projetado para atuar como um servidor intermediário durante a migração. Trata-se de uma instância separada do Banco de Dados do Azure para PostgreSQL - Servidor Flexível que não é o servidor de destino, mas é usado 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.

Conectar à origem

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

• Nome do Servidor - Fornece o nome do host ou o endereço IP da instância do PostgreSQL de origem
• Porta – Número da porta do servidor de origem
• ID de logon do administrador do servidor – Nome de usuário do servidor PostgreSQL de origem
• Senha – Senha do servidor PostgreSQL de origem
• Modo SSL – Os valores com suporte são preferenciais e obrigatórios. Quando o SSL no servidor PostgreSQL de origem estiver definido como OFF, use SSLMODE=prefer. Se o SSL no servidor de origem estiver definido como 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. Depois que 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 da origem. Estabelecer uma conexão de teste leva alguns minutos.

Após a conexão de teste bem-sucedida, selecione o botão Avançar: Selecionar Destino de Migração

Selecionar destino de migração

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

• Nome de usuário do administrador – nome de usuário administrador 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 somente 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 DNS postgres.database.azure.com ou encaminhar consultas para essa zona para 168.63.129.16, onde o FQDN é resolvido na zona DNS pública ou privada do Azure.
• Testar Conexão – executa o teste de conectividade entre o destino e a origem. Depois que 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 do 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 Próximo: Selecionar Bancos de Dados para Migração

Selecionar bancos de dados para migração

Nessa guia, uma lista de bancos de dados de usuário 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 no próximo conjunto de bancos de dados.

Depois de selecionar os bancos de dados, selecione Avançar:Resumo

Resumo

A guia Resumo resume todos os detalhes da origem e do destino para criar a validação ou a migração. Revise os detalhes e selecione no botão Iniciar.

Monitorar a migração

Depois de selecionar o botão Iniciar, uma notificação aparecerá em alguns segundos informando que a validação ou criação da migração foi bem-sucedida. 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.

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

Detalhes da migração

Na guia Instalaçã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. 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 é 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 da validação e migração no nível da instância e do banco de dados.

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

Estados de migração

Subestados de migração

Substratos de validação

Substituição

Se houver Migrar e Validar e Migrar, a conclusão da migração online exigirá outra etapa – o usuário precisará realizar uma ação de substituição. Após a conclusão da cópia/clone dos dados base, a migração passa para o estado WaitingForUserAction e o subestado WaitingForCutoverTrigger. Nesse estado, o usuário pode disparar a substituição do portal selecionando a migração.

Antes de iniciar a substituição, é importante garantir que:

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

  

• O valor de latency diminui para 0 ou perto de 0

• O valor de latency indica quando o destino foi sincronizado pela última vez com a origem. Neste momento, as gravações na origem podem ser interrompidas e a substituição iniciada. Caso haja tráfego intenso na origem, é recomendável interromper as gravações primeiro para que Latency possa chegar perto de 0 e, em seguida, uma transição seja iniciada. A operação de substituição aplica todas as alterações pendentes da Origem para o Destino e conclui a migração. Se você acionar uma "Substituição" mesmo com um Latency, diferente de zero, a replicação será interrompida até esse momento. Todos os dados na origem até o ponto de substituição são então aplicados ao destino. Digamos que uma latência foi de 15 minutos no ponto de substituição, portanto todos os dados alterados nos últimos 15 minutos são aplicados ao destino. O tempo gasto depende da lista de pendências das alterações ocorridas nos últimos 15 minutos. Portanto, é recomendável que a latência atinja zero ou perto de zero, antes de disparar a substituição.

  

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

  

Este artigo explora o uso da CLI do Azure para migrar seu banco de dados PostgreSQL do Google Cloud SQL para PostgreSQL para o Banco de Dados do Azure para PostgreSQL. A CLI do Azure fornece uma interface de linha de comando poderosa e flexível que permite executar várias tarefas, incluindo a migração de banco de dados. Seguindo as etapas descritas neste artigo, você pode transferir seu banco de dados diretamente para o Azure e aproveitar os recursos avançados e escalabilidade dele.

Para saber mais sobre a CLI do Azure com o serviço de migração, visite Como configurar a CLI do Azure para o serviço de migração.

Depois que a CLI estiver instalada, abra o prompt de comando e faça logon na conta do Azure usando o comando abaixo.

az login

Configurar a tarefa de migração

Para iniciar a migração, você precisa criar um arquivo JSON com os detalhes da migração. O arquivo JSON contém as seguintes informações:

• Edite os espaços reservados abaixo << >> nas linhas JSON e armazene-os no computador local como <<filename>>.json em que a CLI está sendo invocada. Neste tutorial, salvamos o arquivo em C:\migration-CLI\migration_body.json

{
	"properties": {
		"SourceDBServerResourceId": "<<source hostname or IP address>>:<<port>>@<<username>>",
		"SecretParameters": {
			"AdminCredentials": {
				"SourceServerPassword": "<<Source Password>>",
				"TargetServerPassword": "<<Target Password>>"
			},
			"targetServerUserName": "<<Target username>>"
		},
		"DBsToMigrate": "<<comma separated list of databases in a array like - ["ticketdb","timedb","inventorydb"]>>",
		"OverwriteDBsInTarget": "true",
		"sourceType": "GCP_CloudSQL",
		"sslMode": "Require"
	}
}

• Execute o comando a seguir para verificar se alguma migração está em execução. O nome da migração é exclusivo entre as migrações no destino do servidor flexível do Banco de Dados do Azure para PostgreSQL.

  az postgres flexible-server migration list --subscription 11111111-1111-1111-1111-111111111111 --resource-group my-learning-rg --name myflexibleserver --filter All
  

• Nas etapas acima, não há migrações executadas, portanto, começamos com a nova migração executando o comando a seguir

  az postgres flexible-server migration create --subscription 11111111-1111-1111-1111-111111111111 --resource-group my-learning-rg --name myflexibleserver --migration-name migration1 --migration-mode online --migration-option ValidateAndMigrate --properties "C:\migration-cli\migration_body.json"
  

• Execute o comando a seguir para iniciar o status de migração na etapa anterior. Você pode verificar o status da migração fornecendo o nome da migração

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

• O status do progresso da migração é mostrado na CLI do Azure.

• Você também pode ver o status do servidor flexível do Banco de Dados do Azure para PostgreSQL no portal do Azure.

• 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. Veja o comando da CLI usado para excluir uma migração:

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

Substituição

• Nas migrações Online, após a conclusão da migração de dados base, a tarefa de migração passa para o subestado WaitingForCutoverTrigger. Nesse estado, o usuário pode disparar a substituição por meio da CLI usando o comando abaixo. A substituição também pode ser disparada no portal selecionando o nome da migração na grade de migrações.

• Você também pode iniciar a substituição no portal do Azure.

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