Migrar seus bancos de dados usando um arquivo físico do Percona XtraBackup

É possível migrar bancos de dados MySQL para o Cloud SQL usando arquivos de backup de banco de dados físico criados com o utilitário Percona XtraBackup para MySQL. A migração com arquivos de backup físico oferece melhor velocidade de restauração de dados em comparação com as migrações que usam arquivos de backup lógico. Isso as torna ideais para mover grandes bancos de dados que contêm muitos terabytes de dados.

Este fluxo de migração envolve as seguintes tarefas:

  1. Fazer backup da instância do MySQL de origem e preparar os arquivos de backup físico usando o utilitário Percona XtraBackup para MySQL.

  2. Enviar os arquivos de backup para um bucket do Cloud Storage.

  3. Criar e executar o job de migração no Database Migration Service.

    Dependendo do cenário, é possível criar a instância de destino por conta própria ou fazer com que o Database Migration Service crie a instância de destino para você como parte do fluxo de criação do job de migração. Para mais informações, consulte a etapa Configurar e executar o job de migração.

  4. Promover o job de migração após a migração completa dos dados.

Migrações off-line

Este guia descreve cenários de migração para ambientes em que é possível garantir a conectividade de rede entre as instâncias de banco de dados de origem e de destino.

É possível realizar uma migração de teste em que o Database Migration Service não se conecta à sua instância de origem. Em vez disso, o Database Migration Service lê apenas os arquivos de backup que você faz upload para o bucket do Cloud Storage e replica o conteúdo deles para o destino do Cloud SQL para MySQL. Um fluxo de migração que não usa conectividade de rede não é recomendado para migrações de produção, porque o Database Migration Service não pode realizar a validação de dados por completo.

Se você quiser tentar realizar um job de migração off-line, ajuste os procedimentos da seguinte maneira:

Limitações

Esta seção lista as limitações das migrações que usam arquivos físicos do Percona XtraBackup:

  • Não é possível migrar para o MySQL 5.6, 8.4 ou 9.7 com um arquivo de backup físico. Consulte Limitações conhecidas.

  • Considerações entre versões:

    • Só é possível migrar dentro da mesma versão principal do banco de dados, por exemplo, do MySQL 8.0.30 para o MySQL 8.0.35 ou do MySQL 5.7.0 para o MySQL 5.7.1.

    • Não é possível migrar do MySQL 5.7 para o MySQL 8.0.

    • A migração não é suportada para versões principais ou secundárias anteriores do banco de dados. Por exemplo, não é possível migrar do MySQL 8.0 para o 5.7 ou do MySQL 8.0.36 para o 8.0.16.

  • Considerações entre arquiteturas: o Cloud SQL é compatível com a arquitetura ARM. Só é possível migrar bancos de dados entre máquinas do mesmo tipo de arquitetura. Por exemplo, se o banco de dados estiver hospedado em uma máquina ARM64, migre para uma máquina ARM64.

  • O tamanho do disco do banco de dados de destino precisa ser igual ou maior que o tamanho do banco de dados de origem. Para mais informações, consulte Tipos de máquina do MySQL para sua edição do Cloud SQL.

  • Não é possível fazer backups que contenham arquivos maiores que 5 TB.

    O tamanho máximo de arquivo para uploads do Cloud Storage é de 5 TB. Essa limitação se refere apenas ao tamanho dos arquivos de backup, não ao tamanho total do banco de dados. Talvez seja possível seguir esse cenário de migração mesmo que o tamanho total do banco de dados exceda 5 TB. Os tamanhos dos arquivos de backup são determinados (entre outras configurações) pela flag innodb_file_per_table:

    • Se innodb_file_per_table estiver definido como OFF, várias tabelas poderão ser salvas em um único arquivo. Nesse caso, se o banco de dados tiver mais de 5 TB, talvez ele não seja compatível com esse cenário.
    • Quando innodb_file_per_table é definido como ON, cada tabela é colocada em um arquivo *.ibd separado. Se você não tiver uma única tabela com mais de 5 TB, os arquivos de backup poderão ser enviados para o Cloud Storage.

    Se o tamanho total do banco de dados exceder 5 TB e os dados incluírem tabelas excepcionalmente grandes, recomendamos que você primeiro faça um backup de simulação em um volume local. Assim, você pode verificar se nenhum arquivo de backup excede o limite de 5 TB do Cloud Storage.

  • Use o Percona XtraBackup para fazer backup dos dados para o bucket do Cloud Storage. Outros utilitários de backup não são compatíveis.

  • Envie os arquivos de backup para uma pasta dedicada do Cloud Storage que não contenha nenhum outro arquivo.

  • A migração de um arquivo físico do Percona XtraBackup só é compatível com bancos de dados MySQL locais ou de VM autogerenciada. A migração do Amazon Aurora ou do MySQL em bancos de dados do Amazon RDS não é compatível.

  • Só é possível migrar de um backup completo. Outros tipos de backup, como backups incrementais ou parciais, não são compatíveis.

  • A migração de banco de dados não inclui usuários ou privilégios dele.

  • Defina o formato do registro binário como ROW. Se você configurar o registro binário para qualquer outro formato, como STATEMENT ou MIXED, a replicação pode falhar.

  • O parâmetro innodb_page_size na instância de origem precisa ser configurado com o valor padrão 16384.

  • Não é possível migrar plug-ins do seu banco de dados externo.

Custos

Para migrações homogêneas para o Cloud SQL, o Database Migration Service é oferecido sem custo adicional. No entanto, os preços do Cloud SQL e do Cloud Storage se aplicam às cobranças de rede, bem como às entidades do Cloud SQL e do Cloud Storage criadas para fins de migração.

Neste documento, você vai usar os seguintes componentes faturáveis do Google Cloud:

  • Cloud Storage
  • Cloud SQL

Para gerar uma estimativa de custo baseada na sua projeção de uso, use a calculadora de preços.

Novos usuários do Google Cloud podem estar qualificados para um teste sem custo financeiro.

Antes de começar

  1. Considere em qual região você quer criar o banco de dados de destino. O Database Migration Service é um produto totalmente regional, o que significa que todas as entidades relacionadas à migração (perfis de conexão de origem e destino, jobs de migração, bancos de dados de destino, buckets de armazenamento) precisam ser salvas em uma única região.

  2. No console do Google Cloud , na página do seletor de projetos, selecione ou crie um projeto do Google Cloud .

    Papéis necessários para selecionar ou criar um projeto

    • Selecionar um projeto: não é necessário ter um papel específico do IAM para selecionar um projeto. É possível selecionar qualquer projeto em que você tenha um papel.
    • Criar um projeto: para criar um projeto, é preciso ter o papel de Criador de projetos (roles/resourcemanager.projectCreator), que contém a permissão resourcemanager.projects.create. Saiba como conceder papéis.

    Acessar o seletor de projetos

  3. Ative as APIs Database Migration Service, Compute Engine e Cloud SQL Admin, se ainda não estiverem ativadas.

    Funções necessárias para ativar APIs

    Para ativar APIs, você precisa da permissão serviceusage.services.enable. Se você criou o projeto, provavelmente já tem essa permissão pelo papel de proprietário (roles/owner). Caso contrário, é possível receber essa permissão pelo papel de administrador do Service Usage (roles/serviceusage.serviceUsageAdmin). Saiba como conceder papéis.

    Ativar as APIs

Funções exigidas

Para receber as permissões necessárias para fazer migrações homogêneas do MySQL usando arquivos de backup físico, peça ao administrador para conceder a você os seguintes papéis do IAM no projeto:

Para mais informações sobre a concessão de papéis, consulte Gerenciar o acesso a projetos, pastas e organizações.

Esses papéis predefinidos contêm as permissões necessárias para realizar migrações homogêneas do MySQL usando arquivos de backup físico. Para acessar as permissões exatas necessárias, expanda a seção Permissões necessárias:

Permissões necessárias

As permissões a seguir são necessárias para realizar migrações homogêneas do MySQL usando arquivos de backup físico:

  • Conta de usuário que realiza a migração:
    • datamigration.*
    • resourcemanager.projects.get
    • resourcemanager.projects.list
    • cloudsql.instances.create
    • cloudsql.instances.get
    • cloudsql.instances.list
    • compute.machineTypes.list
    • compute.machineTypes.get
    • compute.projects.get
    • storage.buckets.create
    • storage.buckets.list

Essas permissões também podem ser concedidas com funções personalizadas ou outros papéis predefinidos.

Etapa 1. Considere os requisitos de conectividade de rede

Há diferentes métodos de rede que podem ser usados para configurar a conectividade entre as instâncias de origem e de destino do Cloud SQL. Dependendo do método usado, talvez seja necessário realizar outras etapas durante o processo de migração.

Considere qual método de conectividade é adequado para seu cenário antes de prosseguir para as próximas etapas, já que sua escolha pode afetar as configurações que você precisa usar. Para mais informações, consulte Configurar a conectividade.

Etapa 2. Preparar os dados de origem

Para preparar os dados para migração, siga estas etapas:

  1. Instale a versão correta do utilitário Percona XtraBackup na instância de origem. Use uma versão do Percona XtraBackup igual ou posterior à versão da instância de origem. Para mais informações, consulte Comparação entre versões de servidor e de backup na documentação do Percona XtraBackup.
  2. Exporte e prepare o arquivo de backup físico da instância de origem usando o Percona XtraBackup. Para informações completas sobre como usar o Percona XtraBackup, consulte a documentação da ferramenta. Você também pode abrir a seção a seguir para conferir um exemplo de etapas recomendadas.

    Exemplo de etapas recomendadas para criar e preparar arquivos de backup físico usando o Percona XtraBackup

    Antes de usar os dados do comando abaixo, faça estas substituições:

    • TARGET_DIR pelo caminho em que você quer salvar o arquivo de backup de saída.
    • USERNAME com um usuário que tem o privilégio BACKUP_ADMIN na instância de origem.
    • PASSWORD com a senha da conta USERNAME.
    1. Faça um backup físico completo da instância de origem. Execute este comando: 
        xtrabackup --backup \
    --target-dir=TARGET_DIR \
    --user=USERNAME \
    --password=PASSWORD
    2. Quando o arquivo de backup estiver pronto, use o comando --prepare para garantir a consistência do arquivo. Execute este comando: 
        xtrabackup --prepare --target-dir=TARGET_DIR
  3. Crie o bucket para armazenar os arquivos de backup. Use a mesma região em que você pretende criar a instância de destino do Cloud SQL para MySQL.

    O Database Migration Service é um produto totalmente regional, o que significa que todas as entidades relacionadas à migração (perfis de conexão de origem e destino, jobs de migração, bancos de dados de destino, buckets de armazenamento para arquivos de backup) precisam ser salvas em uma única região.

  4. Faça upload dos arquivos de backup no bucket do Cloud Storage. Envie os arquivos de backup para uma pasta dedicada do Cloud Storage que não contenha nenhum outro arquivo. Consulte Fazer upload de objetos de um sistema de arquivos na documentação do Cloud Storage.
  5. Crie o perfil de conexão de origem para a instância do banco de dados de origem.

    Console

    Para criar um perfil de conexão de origem, siga estas etapas:

    1. Acesse a página Perfis de conexão no console do Google Cloud .
    2. Clique em Criar perfil.
    3. Na página Criar um perfil de conexão, no menu suspenso Mecanismo de banco de dados, selecione MySQL.
    4. No campo Nome do perfil de conexão, insira um nome legível por humanos para o perfil de conexão. Esse valor é exibido na lista de perfis de conexão.
    5. Mantenha o ID do perfil de conexão gerado automaticamente.
    6. Insira um Nome do host ou Endereço IP.

      • Se o banco de dados de origem estiver hospedado em Google Cloud, ou se um túnel SSH reverso for usado para conectar o banco de dados de destino ao de origem, especifique o endereço IP particular (interno) do banco de dados de origem. Esse endereço poderá ser acessado pelo destino do Cloud SQL. Para mais informações, consulte Configurar a conectividade usando o peering de VPC.

        Para outros métodos de conectividade, como lista de permissões de IP, forneça o endereço IP público.

    7. Insira a porta usada para acessar o host. A porta padrão do MySQL é 3306.
    8. Insira um nome de usuário e uma senha para o banco de dados de destino. A conta de usuário precisa ter os privilégios necessários para acessar seus dados. Para mais informações, consulte Configurar o banco de dados de origem para migrações únicas ou Configurar o banco de dados de origem para migrações contínuas.
    9. Na seção Região do perfil de conexão da página, selecione a região em que você quer salvar o perfil de conexão.

    10. Opcional: se a conexão for feita por uma rede pública (usando listas de permissões de IP), recomendamos usar a criptografia SSL/TLS para a conexão entre os bancos de dados de origem e de destino.

      Há três opções para a configuração de SSL/TLS que podem ser selecionadas na seção Proteger sua conexão da página:

      1. Nenhuma: a instância de destino do Cloud SQL se conecta ao banco de dados de origem sem criptografia.

      2. Autenticação somente do servidor: quando a instância de destino do Cloud SQL se conecta ao banco de dados de origem, ela autentica a origem, garantindo que a instância se conecte ao host correto com segurança. Isso evita ataques de pessoa no meio. Para autenticação somente de servidor, a origem não autentica a instância.

        Para usar a autenticação somente de servidor, forneça o certificado x509 codificado por PEM da autoridade de certificação (CA) que assinou o certificado do servidor externo.

      3. Autenticação de servidor-cliente: quando a instância de destino se conecta à origem, a instância autentica a origem e a origem autentica a instância.

        A autenticação cliente-servidor proporciona a segurança mais forte. No entanto, se você não quiser fornecer o certificado do cliente e a chave privada ao criar a instância de destino do Cloud SQL, ainda poderá usar a autenticação somente de servidor.

        Para usar a autenticação servidor-cliente, é necessário informar os seguintes itens ao criar o perfil de conexão de destino:

        • O certificado da autoridade de certificação que assinou o certificado do servidor de banco de dados de origem (o certificado da CA).
        • O certificado usado pela instância para autenticação no servidor de banco de dados de origem (o certificado do cliente)
        • A chave privada associada ao certificado do cliente (a chave do cliente).
    11. Clique em Criar. Seu perfil de conexão foi criado.

    gcloud

    Este exemplo usa a flag opcional --no-async para que todas as operações sejam realizadas de forma síncrona. Isso significa que alguns comandos podem levar um tempo para serem concluídos. É possível ignorar a flag --no-async para executar comandos de forma assíncrona. Se você fizer isso, use o comando gcloud database-migration operations describe para verificar se a operação foi bem-sucedida.

    Antes de usar os dados do comando abaixo, faça estas substituições:

    • CONNECTION_PROFILE_ID por um identificador legível por máquina para seu perfil de conexão.
    • REGION pelo identificador da região em que você quer salvar o perfil de conexão.
    • HOST_IP_ADDRESS pelo endereço IP em que o Database Migration Service pode acessar sua instância de banco de dados de origem. Esse valor pode variar dependendo do método de conectividade usado na migração.
    • PORT_NUMBER com o número da porta em que o banco de dados de origem aceita conexões de entrada. A porta padrão do MySQL é 3306.
    • USERNAME pelo nome da conta de usuário do banco de dados que o Database Migration Service vai usar para se conectar à instância do banco de dados de origem.
    • PASSWORD com a senha da conta de usuário do banco de dados.
    • (Opcional) CONNECTION_PROFILE_NAME com um nome legível por humanos para o perfil de conexão. Esse valor é exibido no console do Google Cloud .

    Execute o seguinte comando:

    Linux, macOS ou Cloud Shell

    gcloud database-migration connection-profiles \
create mysql CONNECTION_PROFILE_ID \
  --no-async \
  --region=REGION \
  --host=HOST_IP_ADDRESS \
  --port=PORT_NUMBER \
  --username=USERNAME \
  --password=PASSWORD \
  --display-name=CONNECTION_PROFILE_NAME

    Windows (PowerShell)

    gcloud database-migration connection-profiles `
create mysql CONNECTION_PROFILE_ID `
  --no-async `
  --region=REGION `
  --host=HOST_IP_ADDRESS `
  --port=PORT_NUMBER `
  --username=USERNAME `
  --password=PASSWORD `
  --display-name=CONNECTION_PROFILE_NAME

    Windows (cmd.exe)

    gcloud database-migration connection-profiles ^
create mysql CONNECTION_PROFILE_ID ^
  --no-async ^
  --region=REGION ^
  --host=HOST_IP_ADDRESS ^
  --port=PORT_NUMBER ^
  --username=USERNAME ^
  --password=PASSWORD ^
  --display-name=CONNECTION_PROFILE_NAME

    Você receberá uma resposta semelhante a esta:

    Waiting for connection profile [CONNECTION_PROFILE_ID]
to be created with [OPERATION_ID]

Waiting for operation [OPERATION_ID] to complete...done.

Created connection profile CONNECTION_PROFILE_ID [OPERATION_ID]

Etapa 3. Configurar e executar o job de migração

Ao migrar com o Percona XtraBackup, é possível criar a instância de destino do Cloud SQL por conta própria ou deixar que o Database Migration Service a crie para você. Para mais informações, consulte Visão geral da criação de jobs de migração.

Cada uma dessas abordagens exige que você siga um conjunto de procedimentos um pouco diferente. Use o menu suspenso para mostrar os procedimentos relevantes para seu cenário:

  • Se você quiser que o Database Migration Service crie o banco de dados de destino, selecione Migrar para uma nova instância de destino.
  • Se você quiser migrar para um banco de dados de destino criado fora do Database Migration Service, selecione Migrar para uma instância de destino atual.

  • Ao migrar para uma nova instância de destino, o Database Migration Service cria a instância de destino do Cloud SQL para MySQL durante o fluxo de criação do job de migração.

    Etapa 3a. Criar o job de migração para uma nova instância de destino

    Para criar um job de migração para uma nova instância de destino, siga estas etapas:

    Console

    Definir configurações para o job de migração

    1. No console do Google Cloud , acesse a página Jobs de migração.

      Acessar Jobs de migração

    2. Clique em Criar job de migração.

      A página do assistente de configuração do job de migração é aberta. Esse assistente contém vários painéis que mostram cada etapa de configuração.

      É possível pausar a criação de um job de migração a qualquer momento clicando em SALVAR E SAIR. Todos os dados inseridos até esse ponto são salvos em um rascunho de job de migração. Você pode concluir o rascunho do job de migração depois.

    3. Na página Começar, insira as seguintes informações:
      1. Nome do job de migração

        Este é um nome legível por humanos para o job de migração. Esse valor é exibido no console do Google Cloud .

      2. ID da tarefa de migração

        É um identificador legível por máquina do seu job de migração. Use esse valor para trabalhar com jobs de migração usando os comandos da CLI do Google Cloud ou a API do Database Migration Service.

      3. Na lista Mecanismo de banco de dados de origem, selecione MySQL.

        O campo Mecanismo do banco de dados de destino é preenchido automaticamente e não pode ser alterado.

      4. Selecione a região em que você salvou o job de migração.

        O Database Migration Service é um produto totalmente regional, o que significa que todas as entidades relacionadas à migração (perfis de conexão de origem e destino, jobs de migração, bancos de dados de destino) precisam ser salvas em uma única região. Selecione a região com base na localização dos serviços que precisam dos seus dados, como instâncias do Compute Engine ou apps do App Engine, entre outros serviços. Depois de escolher a região de destino, essa seleção não poderá ser alterada.

    4. Clique em Salvar e continuar.

    Especificar informações sobre o perfil de conexão de origem

    1. Na página Definir uma origem, siga estas etapas:
      1. No menu suspenso Perfil de conexão de origem, selecione o perfil de conexão do banco de dados de origem.
      2. Na seção Personalizar a configuração de despejo completo, clique em Editar configuração.
      3. No painel Editar configuração de despejo completo, no menu suspenso Método de despejo completo, selecione Baseado em físico.
      4. Em Fornecer sua pasta, clique em Procurar e selecione a pasta em que você fez upload do arquivo dump completo (etapa 3 na seção Preparar os dados de origem).
      5. Clique em Salvar.
    2. Clique em Salvar e continuar.

    Configurar e criar a instância de destino do Cloud SQL

    1. Na página Definir um destino, no menu suspenso Tipo de instância de destino, selecione Nova instância. Defina todas as configurações relevantes:
      1. No campo ID da instância de destino, forneça um identificador para a instância do Cloud SQL ou use o identificador gerado automaticamente.

        Não inclua informações sensíveis ou de identificação pessoal no identificador. Não é necessário incluir o ID do projeto no nome da instância. Isso é feito automaticamente quando necessário, como nos arquivos de registros.

      2. No campo Senha, forneça uma senha alfanumérica para a instância de destino do Cloud SQL. Esta é a senha da conta de administrador root na instância.

        Insira a senha manualmente ou clique em Gerar para que o Database Migration Service crie uma automaticamente.

      3. No menu suspenso Versão do banco de dados, escolha a versão do banco de dados para a instância de destino.

        Clique em Mostrar versões secundárias para conferir todas as versões secundárias. Saiba mais sobre o suporte à migração entre versões.

      4. Selecione a edição do Cloud SQL para MySQL da instância de destino. Há duas opções disponíveis: Cloud SQL para MySQL Enterprise e Cloud SQL para MySQL Enterprise Plus.

        As edições do Cloud SQL para MySQL vêm com diferentes conjuntos de recursos, tipos de máquina disponíveis e preços. Consulte a documentação do Cloud SQL para escolher a edição adequada às suas necessidades. Para mais informações, consulte Introdução às edições do Cloud SQL para MySQL.

      5. O menu Região mostra a mesma região que você selecionou na página Começar.

        Se você estiver configurando a instância para alta disponibilidade, selecione Várias zonas (altamente disponível). É possível selecionar as zonas primária e secundária. As condições a seguir se aplicam quando a zona secundária é usada durante a criação da instância:

        • As zonas padrão são Qualquer para a zona primária e Qualquer (diferente da primária) para a zona secundária.
        • Se as zonas primária e secundária forem especificadas, elas precisarão ser diferentes.
      6. Na seção Conexões, escolha se quer adicionar um endereço IP público ou particular para a instância de destino. É possível configurar a instância para ter os dois tipos de endereços IP, mas pelo menos um tipo é necessário para a migração. Selecione uma destas opções:
        • Se você quiser migrar usando o peering de VPC ou um túnel SSH reverso, selecione IP privado.

          • Para ativar a conectividade de IP privado, verifique se você atende a todos os requisitos de rede adicionais.

            Abra esta seção para ver todos os requisitos de IP particular.
          • Selecione a rede VPC associada para fazer peering. Se você planeja se conectar à origem da migração usando o peering de VPC, escolha a VPC em que a instância está localizada.
          • Se uma rede de serviço gerenciado nunca tiver sido configurada para a VPC selecionada, você poderá selecionar um intervalo de IP e clicar em Conectar ou usar um intervalo de IP selecionado automaticamente e clicar em Alocar e conectar.
        • Se você quiser migrar pela Internet usando uma lista de permissão de IP, selecione IP público.

          Se quiser, em IP público, clique no campo Redes autorizadas e autorize uma rede ou um proxy a se conectar à instância do Cloud SQL. As redes são autorizadas apenas com os endereços que você fornecer. Consulte Configurar IP público na documentação do Cloud SQL.

        Você vai configurar a conectividade do job de migração em uma etapa posterior. Para saber mais sobre os métodos de rede disponíveis, consulte Configurar conectividade.

    2. Selecione o tipo de máquina para a instância do Cloud SQL.

      Para mais informações, consulte Limitações.

    3. Para o Cloud SQL para MySQL Enterprise Plus: marque a caixa de seleção Ativar cache de dados se quiser usar o recurso de cache de dados no banco de dados de destino.

      O cache de dados é um recurso opcional disponível para instâncias da edição Cloud SQL para MySQL Enterprise Plus que adiciona uma unidade de estado sólido local de alta velocidade ao banco de dados de destino. Esse recurso pode gerar custos adicionais para o Cloud SQL. Para mais informações sobre o cache de dados, consulte Visão geral do cache de dados na documentação do Cloud SQL.

    4. Especifica o tipo de armazenamento da instância do Cloud SQL. É possível escolher entre uma unidade de estado sólido (SSD) ou uma unidade de disco rígido (HDD).
    5. Especifique a capacidade de armazenamento (em GBytes) da instância do Cloud SQL.

      Verifique se a instância tem capacidade de armazenamento suficiente para processar os dados do banco de dados de origem. É possível aumentar essa capacidade a qualquer momento, mas não é possível diminuí-la.

    6. (Opcional) Configure as opções de criptografia de dados ou os rótulos de recursos para a instância de destino.

      Abra esta seção para ver as etapas opcionais.

      Clique em Mostrar configurações opcionais e, em seguida:

      1. Especifique se você quer gerenciar a criptografia dos dados migrados da origem para o destino. Por padrão, seus dados são criptografados com uma chave gerenciada pelo Google Cloud. Se você quiser gerenciar a criptografia, use uma chave de criptografia gerenciada pelo cliente (CMEK). Para fazer isso, siga estas etapas:

        1. Marque a caixa de seleção Usar uma chave de criptografia gerenciada pelo cliente (CMEK).
        2. No menu Selecionar uma chave gerenciada pelo cliente, escolha sua CMEK.

        Se a chave não aparecer, clique em Inserir nome do recurso da chave para fornecer o nome do recurso da chave que você quer usar. Exemplo de nome de recurso da chave: projects/my-project-name/locations/my-location/keyRings/my-keyring/cryptoKeys/my-key.

      2. Adicione as flags necessárias para serem aplicadas ao servidor de banco de dados. Se possível, verifique se as flags de banco de dados na instância de destino do Cloud SQL criada são as mesmas do banco de dados de origem. Saiba mais sobre as flags de banco de dados compatíveis com o MySQL.
      3. Adicione rótulos específicos da instância do Cloud SQL.

        Os rótulos ajudam a organizar as instâncias. Por exemplo, é possível organizar rótulos por centro de custos ou por ambiente. Os rótulos também são incluídos na fatura para que você confira a distribuição de custos entre eles.

    7. Clique em Criar destino e continuar. O Database Migration Service está criando sua instância de destino do Cloud SQL. Esse processo pode levar vários minutos.

    Configurar a conectividade entre as instâncias de banco de dados de origem e destino

    No menu suspenso Método de conectividade, selecione um método de conectividade de rede. Esse método define como a instância recém-criada do Cloud SQL vai se conectar ao banco de dados de origem. Os métodos atuais de conectividade de rede incluem lista de permissões de IP, túnel SSH reverso e peering de VPC.

    Se você quiser usar...Faça o seguinte:
    O método de conectividade de rede da lista de permissões de IP, É preciso especificar o endereço IP de saída da instância de destino. Se a instância do Cloud SQL criada for de alta disponibilidade, inclua os endereços IP de saída das instâncias primária e secundária.
    O método de conectividade de rede do túnel SSH reverso. Você precisa selecionar a instância de VM do Compute Engine que vai hospedar o túnel.

    Depois de especificar a instância, o Google vai fornecer um script que executa as etapas para configurar o túnel entre os bancos de dados de origem e de destino. Você precisará executar o script na Google Cloud CLI.

    Execute os comandos em uma máquina com conectividade ao banco de dados de origem e ao Google Cloud.
    O método de conectividade de rede de peering de VPC, Selecione a rede VPC em que o banco de dados de origem está localizado. A instância do Cloud SQL será atualizada para se conectar a essa rede.

    Depois de selecionar e configurar a conectividade de rede, clique em Configurar e continuar.

    Criar o job de migração

    Em Testar e criar job de migração, verifique as configurações do job de migração. Neste ponto, o teste do job de migração vai falhar, porque a conta de serviço associada à instância de destino do Cloud SQL não tem as permissões necessárias.

    Realize uma das seguintes ações antes de testar o job para validar a configuração dele:

    • Se você quiser testar o job de migração usando o console do Google Cloud depois de atribuir as permissões à conta de serviço da instância de destino, clique em Salvar e sair. Isso vai salvar o job de migração como rascunho. Você pode voltar a esta tela mais tarde, testar e executar o job de migração.
    • Se você quiser testar o job de migração usando a Google Cloud CLI depois de atribuir as permissões à conta de serviço da instância de destino,clique em Criar. Com a CLI do Google Cloud, é possível testar um job de migração que foi criado, mas ainda não foi iniciado.

    gcloud

    1. Crie o perfil de conexão de destino.
      Ao migrar para uma nova instância de destino com a Google Cloud CLI, você cria a instância de destino e o perfil de conexão em uma única ação.
      Execute o comando a seguir (clique no link para expandir):

      gcloud database-migration connection-profiles create cloudsql

      Este exemplo usa a flag opcional --no-async para que todas as operações sejam realizadas de forma síncrona. Isso significa que alguns comandos podem levar um tempo para serem concluídos. É possível ignorar a flag --no-async para executar comandos de forma assíncrona. Se você fizer isso, use o comando gcloud database-migration operations describe para verificar se a operação foi bem-sucedida.

      Antes de usar os dados do comando abaixo, faça estas substituições:

      • CONNECTION_PROFILE_ID por um identificador legível por máquina para seu perfil de conexão.
      • DATABASE_VERSION com a versão do MySQL que você quer usar na instância de destino. As versões do banco de dados são especificadas como strings que incluem as versões principal e secundária. Por exemplo: MYSQL_8_0, MYSQL_8_0_32, MYSQL_8_0_36.

        Para todas as versões possíveis do MySQL, consulte a referência da flag --database-version.

      • (Opcional) EDITION Por padrão, as novas instâncias criadas com a Google Cloud CLI usam o Cloud SQL para MySQL Enterprise Plus. Se você planeja usar o Cloud SQL para MySQL Enterprise Plus, verifique se a região é compatível com essa edição. Consulte Suporte de região do Cloud SQL para MySQL Enterprise Plus.

        É possível mudar sua edição usando a flag --edition com um dos seguintes valores:

        • enterprise-plus para a edição Enterprise Plus do Cloud SQL para MySQL
        • enterprise para a edição Cloud SQL para MySQL Enterprise
      • TIER pelo nome do tipo de máquina do Cloud SQL que você quer usar. Os tipos de máquina são especificados como strings que seguem a convenção do Cloud SQL, por exemplo, db-n1-standard-1, db-perf-optimized-N-2. Para uma lista completa dos tipos de máquina disponíveis e os identificadores deles para uso com a Google Cloud CLI, consulte Tipos de máquina na documentação do Cloud SQL para MySQL.

        As instâncias criadas com a Google Cloud CLI usam por padrão a edição Cloud SQL para MySQL Enterprise Plus, que tem diferentes tipos de máquina disponíveis. Se você quiser usar um tipo de máquina disponível apenas na edição Cloud SQL para MySQL Enterprise, use a flag opcional --edition=enterprise para especificar a edição.

      • REGION com o identificador da região em que você quer salvar o perfil de conexão.

        Por padrão, as novas instâncias criadas com a Google Cloud CLI usam o Cloud SQL para MySQL Enterprise Plus. Se você planeja usar o Cloud SQL para MySQL Enterprise Plus, verifique se a região é compatível com essa edição. Consulte Suporte de região do Cloud SQL para MySQL Enterprise Plus. É possível mudar a edição usando a flag opcional --edition.

      • (Opcional) CONNECTION_PROFILE_NAME com um nome legível por humanos para o perfil de conexão. Esse valor é exibido no console do Google Cloud .
      • Configuração de rede

        Por padrão, as novas instâncias criadas com a Google Cloud CLI têm um endereço IP público atribuído e são configuradas para usar a conexão por IP público. Você pode usar outros métodos de conectividade. Para mais informações, consulte Configurar a conectividade.

        Não é necessário usar flags adicionais se você quiser usar a conectividade de IP público. Se você quiser usar a conectividade de IP particular com o peering de rede VPC ou um túnel SSH reverso, verifique se você atende aos seguintes requisitos de rede adicionais para ativar a conectividade de IP particular e inclua flags adicionais no comando.

        Expanda esta seção para conferir todos os requisitos de IP particular.

        Inclua as seguintes flags adicionais se quiser usar a conexão por IP particular (com o peering de rede VPC ou com um túnel SSH reverso em uma VM do Compute Engine):

        • --no-enable-ip-v4: (opcional) para não atribuir um endereço IP público à instância de destino. É possível ter um endereço IP público e um privado atribuídos à instância de destino, mas talvez você não queira um endereço IP público se usar a conectividade de IP privado.
        • --private-network: para atribuir um endereço IP particular à instância de destino, especifique o nome da nuvem privada virtual em que você quer que um endereço IP particular seja atribuído.

      Execute o seguinte comando:

      Linux, macOS ou Cloud Shell

      gcloud database-migration connection-profiles \
create mysql CONNECTION_PROFILE_ID \
  --no-async \
  --region=REGION \
  --database-version=DATABASE_VERSION \
  --tier=TIER \
  --display-name=CONNECTION_PROFILE_NAME

      Windows (PowerShell)

      gcloud database-migration connection-profiles `
create mysql CONNECTION_PROFILE_ID `
  --no-async `
  --region=REGION `
  --database-version=DATABASE_VERSION `
  --tier=TIER `
  --display-name=CONNECTION_PROFILE_NAME

      Windows (cmd.exe)

      gcloud database-migration connection-profiles ^
create mysql CONNECTION_PROFILE_ID ^
  --no-async ^
  --region=REGION ^
  --database-version=DATABASE_VERSION ^
  --tier=TIER ^
  --display-name=CONNECTION_PROFILE_NAME

      Você receberá uma resposta semelhante a esta:

      Waiting for connection profile [CONNECTION_PROFILE_ID]
to be created with [OPERATION_ID]

Waiting for operation [OPERATION_ID] to complete...done.

Created connection profile CONNECTION_PROFILE_ID [OPERATION_ID]
    2. Conclua a configuração de rede.

      Dependendo da conectividade de rede que você quer usar, talvez seja necessário seguir outras etapas antes de criar o job de migração.

    3. Crie o job de migração.
      Execute o seguinte comando (clique no link para expandir):

      gcloud database-migration migration-jobs create

      Este exemplo usa a flag opcional --no-async para que todas as operações sejam realizadas de forma síncrona. Isso significa que alguns comandos podem levar um tempo para serem concluídos. É possível pular a flag --no-async para executar comandos de forma assíncrona. Se você fizer isso, use o comando gcloud database-migration operations describe para verificar se a operação foi bem-sucedida.

      Antes de usar os dados do comando abaixo, faça estas substituições:

      • MIGRATION_JOB_ID por um identificador legível por máquina para o job de migração. Use esse valor para trabalhar com jobs de migração usando os comandos da CLI do Google Cloud ou a API do Database Migration Service.
      • REGION pelo identificador da região em que você quer salvar o job de migração.
      • MIGRATION_JOB_NAME por um nome legível por humanos para o job de migração. Esse valor é exibido no Database Migration Service no console do Google Cloud .
      • SOURCE_CONNECTION_PROFILE_ID por um identificador legível por máquina do perfil de conexão de origem.
      • DESTINATION_CONNECTION_PROFILE_ID pelo identificador legível por máquina do perfil de conexão de destino.
      • MIGRATION_JOB_TYPE pelo tipo do job de migração. Dois valores são permitidos: ONE_TIME ou CONTINUOUS. Para mais informações, consulte Tipos de migração.
      • PATH_TO_THE_FOLDER_IN_STORAGE_BUCKET_WITH_PHYSICAL_BACKUP_FILES pelo caminho para os arquivos de backup físico armazenados em uma pasta em um bucket do Cloud Storage. Use o seguinte formato: gs://<bucket_name>/<path_to_backup_file_folder>.
      • Configuração de rede

        Se você usa conexão por IP particular com peering de rede VPC ou um túnel SSH reverso, adicione as seguintes flags ao comando:

        Conectividade de IP particular com peering de rede VPC
        Use a flag --peer-vpc para especificar o nome da rede com que você quer fazer peering.
        Túnel SSH reverso em uma VM do Compute Engine
        Use as seguintes flags para fornecer detalhes de rede para o Compute Engine: --vm-ip, --vm-port, --vpc. Também é possível usar a flag opcional --vm para especificar o nome da VM.

        Para mais exemplos de uso, consulte Exemplos da Google Cloud CLI.

      Execute o seguinte comando:

      Linux, macOS ou Cloud Shell

      gcloud database-migration migration-jobs \
create MIGRATION_JOB_ID \
  --no-async \
  --region=REGION \
  --display-name=MIGRATION_JOB_NAME \
  --source=SOURCE_CONNECTION_PROFILE_ID \
  --destination=DESTINATION_CONNECTION_PROFILE_ID \
  --type=MIGRATION_JOB_TYPE
  --dump-type=PHYSICAL
  --dump-path=PATH_TO_THE_FOLDER_IN_STORAGE_BUCKET_WITH_PHYSICAL_BACKUP_FILES

      Windows (PowerShell)

      gcloud database-migration migration-jobs `
create MIGRATION_JOB_ID `
  --no-async `
  --region=REGION `
  --display-name=MIGRATION_JOB_NAME `
  --source=SOURCE_CONNECTION_PROFILE_ID `
  --destination=DESTINATION_CONNECTION_PROFILE_ID `
  --type=MIGRATION_JOB_TYPE
  --dump-type=PHYSICAL
  --dump-path=PATH_TO_THE_FOLDER_IN_STORAGE_BUCKET_WITH_PHYSICAL_BACKUP_FILES

      Windows (cmd.exe)

      gcloud database-migration migration-jobs ^
create MIGRATION_JOB_ID ^
  --no-async ^
  --region=REGION ^
  --display-name=MIGRATION_JOB_NAME ^
  --source=SOURCE_CONNECTION_PROFILE_ID ^
  --destination=DESTINATION_CONNECTION_PROFILE_ID ^
  --type=MIGRATION_JOB_TYPE
  --dump-type=PHYSICAL
  --dump-path=PATH_TO_THE_FOLDER_IN_STORAGE_BUCKET_WITH_PHYSICAL_BACKUP_FILES

      Você receberá uma resposta semelhante a esta:

      Waiting for migration job [MIGRATION_JOB_ID]
to be created with [OPERATION_ID]

Waiting for operation [OPERATION_ID] to complete...done.

Created migration job MIGRATION_JOB_ID [OPERATION_ID]

    Etapa 3b. Conceder as permissões necessárias à conta de serviço da instância do Cloud SQL

    Quando você cria o job de migração para uma nova instância, o Database Migration Service também cria a instância de destino do Cloud SQL para você. Antes de executar a migração, é preciso atribuir permissões do Cloud Storage à conta de serviço da instância.

    Para conceder as permissões do Cloud Storage à conta de serviço associada à instância de destino, siga estas etapas:

    1. Encontre o endereço de e-mail da conta de serviço da instância do Cloud SQL na página de detalhes da instância do Cloud SQL. Esse endereço usa o seguinte formato: <project-identifier>@gcp-sa-cloud-sql.iam.gserviceaccount.com. Consulte Ver informações da instância na documentação do Cloud SQL.
    2. Adicione o papel do IAM de Leitor de objetos do Storage (roles/storage.objectViewer) à conta de serviço. Para saber como gerenciar o acesso com o Identity and Access Management, confira Gerenciar o acesso a projetos, pastas e organizações na documentação do IAM.

    Etapa 3c. (Opcional) Testar o job de migração

    Antes de executar o job de migração, faça um teste para verificar se o Database Migration Service pode acessar todas as entidades de origem e destino necessárias. Com a CLI gcloud, é possível testar jobs de migração criados, mas ainda não iniciados.

    Console

    No console do Google Cloud , só é possível testar rascunhos de jobs de migração criados no assistente de criação de jobs de migração. Se você não salvou o job como rascunho, mas o criou totalmente no assistente, só é possível realizar o teste usando a Google Cloud CLI.

    Para testar um job de migração de rascunho, siga estas etapas:

    1. No console do Google Cloud , acesse a página Jobs de migração.

      Acessar Jobs de migração

    2. Na guia Rascunhos, clique no nome de exibição do job de migração que você quer terminar de criar.

      O assistente de criação de jobs de migração é aberto.

    3. Na página Testar e criar job de migração, clique em Testar job. O Database Migration Service agora verifica se a instância de destino tem todas as permissões necessárias e pode se conectar ao banco de dados de origem.
    4. Quando o teste terminar, clique em Criar.

      O job de migração foi criado e está pronto para ser iniciado.

    gcloud

    Antes de usar os dados do comando abaixo, faça estas substituições:

    • MIGRATION_JOB_ID pelo identificador do job de migração.

      Se você não souber o identificador, use o comando gcloud database-migration migration-jobs list para listar todos os jobs de migração em uma determinada região e conferir os identificadores deles.

    • REGION pelo identificador da região em que o perfil de conexão está salvo.

    Execute o seguinte comando:

    Linux, macOS ou Cloud Shell

    gcloud database-migration migration-jobs \
verify MIGRATION_JOB_ID \
  --region=REGION

    Windows (PowerShell)

    gcloud database-migration migration-jobs `
verify MIGRATION_JOB_ID `
  --region=REGION

    Windows (cmd.exe)

    gcloud database-migration migration-jobs ^
verify MIGRATION_JOB_ID ^
  --region=REGION

    Resultado

    A ação é realizada de maneira assíncrona. Assim, esse comando retorna uma entidade de operação que representa uma operação de longa duração: 

    done: false
metadata:
  '@type': type.googleapis.com/google.cloud.clouddms.v1.OperationMetadata
  apiVersion: v1
  createTime: '2024-02-20T12:20:24.493106418Z'
  requestedCancellation: false
  target: MIGRATION_JOB_ID
  verb: verify
name: OPERATION_ID

    Para saber se a operação foi bem-sucedida, consulte o objeto de operação retornado ou verifique o status do job de migração:

    Etapa 3d. Iniciar o job de migração

    Quando o job de migração estiver totalmente criado (ou seja, não estiver salvo como rascunho), você poderá iniciá-lo a qualquer momento para começar a migrar dados.

    Para iniciar um job de migração, siga estas etapas:

    Console

    1. No console do Google Cloud , acesse a página Jobs de migração.

      Acessar Jobs de migração

    2. Na guia Jobs, clique no nome de exibição do job de migração que você quer iniciar.

      A página de detalhes do job de migração é aberta.

    3. Clique em Iniciar.
    4. Na caixa de diálogo, clique em Iniciar.

    gcloud

    Antes de usar os dados do comando abaixo, faça estas substituições:

    • MIGRATION_JOB_ID pelo identificador do job de migração.

      Se você não souber o identificador, use o comando gcloud database-migration migration-jobs list para listar todos os jobs de migração em uma determinada região e conferir os identificadores deles.

    • REGION com o identificador da região em que o perfil de conexão está salvo.

    Execute o seguinte comando:

    Linux, macOS ou Cloud Shell

    gcloud database-migration migration-jobs \
start MIGRATION_JOB_ID \
  --region=REGION

    Windows (PowerShell)

    gcloud database-migration migration-jobs `
start MIGRATION_JOB_ID `
  --region=REGION

    Windows (cmd.exe)

    gcloud database-migration migration-jobs ^
start MIGRATION_JOB_ID ^
  --region=REGION

    Resultado

    A ação é realizada de maneira assíncrona. Assim, esse comando retorna uma entidade de operação que representa uma operação de longa duração: 

    done: false
metadata:
  '@type': type.googleapis.com/google.cloud.clouddms.v1.OperationMetadata
  apiVersion: v1
  createTime: '2024-02-20T12:20:24.493106418Z'
  requestedCancellation: false
  target: MIGRATION_JOB_ID
  verb: start
name: OPERATION_ID

    Para ver se a operação foi bem-sucedida, consulte o objeto de operação retornado ou verifique o status do job de migração:


  • Para migrar para uma instância de destino, primeiro é preciso criar e configurar essa instância.

    Etapa 3a. Preparar a instância de destino

    Para configurar a instância de destino do Cloud SQL, siga estas etapas:

    1. Crie sua instância de destino do Cloud SQL para MySQL. Use recursos de computação e memória suficientes para atender às suas necessidades de migração. Consulte Criar uma instância na documentação do Cloud SQL.

      Dependendo do método de conectividade que você quer usar na migração, talvez seja necessário adicionar um endereço IP público ou privado à instância de destino. Para mais informações sobre métodos de conectividade, consulte Configurar conectividade.

    2. Conceda as permissões do Cloud Storage à conta de serviço associada à instância de destino. Essa conta é criada depois que você cria a instância de destino.
      1. Encontre o endereço de e-mail da conta de serviço da instância do Cloud SQL na página de detalhes da instância do Cloud SQL. Esse endereço usa o seguinte formato: <project-identifier>@gcp-sa-cloud-sql.iam.gserviceaccount.com. Consulte Ver informações da instância na documentação do Cloud SQL.
      2. Adicione o papel do IAM de Leitor de objetos do Storage (roles/storage.objectViewer) à conta de serviço. Para saber como gerenciar o acesso com o Identity and Access Management, consulte Gerenciar o acesso a projetos, pastas e organizações na documentação do IAM.
    3. Crie um perfil de conexão de destino para sua instância do Cloud SQL.

      Console

      Não é necessário criar o perfil de conexão de destino. Ao criar um job de migração no console do Google Cloud , você usa o identificador da instância de destino, e o Database Migration Service gerencia o perfil de conexão para você.

      Acesse a seção Criar e executar job de migração.

      gcloud

      Este exemplo usa a flag opcional --no-async para que todas as operações sejam realizadas de forma síncrona. Isso significa que alguns comandos podem levar um tempo para serem concluídos. É possível pular a flag --no-async para executar comandos de forma assíncrona. Se você fizer isso, use o comando gcloud database-migration operations describe para verificar se a operação foi bem-sucedida.

      Antes de usar os dados do comando abaixo, faça estas substituições:

      • CONNECTION_PROFILE_ID por um identificador legível por máquina para seu perfil de conexão.
      • REGION com o identificador da região em que você quer salvar o perfil de conexão.
      • DESTINATION_INSTANCE_ID pelo identificador da instância de destino.
      • (Opcional) CONNECTION_PROFILE_NAME com um nome legível por humanos para o perfil de conexão. Esse valor é exibido no console Google Cloud .

      Execute o seguinte comando:

      Linux, macOS ou Cloud Shell

      gcloud database-migration connection-profiles \
create mysql CONNECTION_PROFILE_ID \
  --no-async \
  --cloudsql-instance=DESTINATION_INSTANCE_ID \
  --region=REGION \
  --display-name=CONNECTION_PROFILE_NAME

      Windows (PowerShell)

      gcloud database-migration connection-profiles `
create mysql CONNECTION_PROFILE_ID `
  --no-async `
  --cloudsql-instance=DESTINATION_INSTANCE_ID `
  --region=REGION `
  --display-name=CONNECTION_PROFILE_NAME

      Windows (cmd.exe)

      gcloud database-migration connection-profiles ^
create mysql CONNECTION_PROFILE_ID ^
  --no-async ^
  --cloudsql-instance=DESTINATION_INSTANCE_ID ^
  --region=REGION ^
  --display-name=CONNECTION_PROFILE_NAME

      Você receberá uma resposta semelhante a esta:

      Waiting for connection profile [CONNECTION_PROFILE_ID]
to be created with [OPERATION_ID]

Waiting for operation [OPERATION_ID] to complete...done.

Created connection profile CONNECTION_PROFILE_ID [OPERATION_ID]

    Etapa 3b. Criar e executar o job de migração

    Console

    Definir configurações para o job de migração

    1. No console do Google Cloud , acesse a página Jobs de migração.

      Acessar Jobs de migração

    2. Clique em Criar job de migração.

      A página do assistente de configuração do job de migração é aberta. Esse assistente contém vários painéis que mostram cada etapa de configuração.

      É possível pausar a criação de um job de migração a qualquer momento clicando em SALVAR E SAIR. Todos os dados inseridos até esse ponto são salvos em um rascunho de job de migração. Você pode concluir o rascunho do job de migração depois.

    3. Na página Começar, insira as seguintes informações:
      1. Nome do job de migração

        Este é um nome legível por humanos para o job de migração. Esse valor é exibido no console Google Cloud .

      2. ID da tarefa de migração

        É um identificador legível por máquina do seu job de migração. Use esse valor para trabalhar com jobs de migração usando os comandos da CLI do Google Cloud ou a API do Database Migration Service.

      3. Na lista Mecanismo de banco de dados de origem, selecione MySQL.

        O campo Mecanismo do banco de dados de destino é preenchido automaticamente e não pode ser alterado.

      4. Selecione a região em que você salvou o job de migração.

        O Database Migration Service é um produto totalmente regional, o que significa que todas as entidades relacionadas à migração (perfis de conexão de origem e destino, jobs de migração, bancos de dados de destino) precisam ser salvas em uma única região. Selecione a região com base na localização dos serviços que precisam dos seus dados, como instâncias do Compute Engine ou apps do App Engine, entre outros serviços. Depois de escolher a região de destino, essa seleção não poderá ser alterada.

    4. Clique em Salvar e continuar.

    Especificar informações sobre o perfil de conexão de origem

    1. Na página Definir uma origem, siga estas etapas:
      1. No menu suspenso Perfil de conexão de origem, selecione o perfil de conexão do banco de dados de origem.
      2. Na seção Personalizar a configuração de despejo completo, clique em Editar configuração.
      3. No painel Editar configuração de despejo completo, no menu suspenso Método de despejo completo, selecione Com base em física.
      4. Em Fornecer sua pasta, clique em Procurar e selecione a pasta em que você fez upload do arquivo dump completo (etapa 4 na seção Preparar os dados de origem).
      5. Clique em Salvar.
    2. Clique em Salvar e continuar.

    Selecione a instância de destino do Cloud SQL

    1. No menu Tipo de instância de destino, selecione Instância atual.
    2. Na seção Selecionar instância de destino, selecione a instância de destino.
    3. Analise as informações na seção Detalhes da instância e clique em Selecionar e continuar.
    4. Para migrar para um banco de dados de destino, o Database Migration Service rebaixa a instância de destino e a converte em uma réplica. Para indicar que o rebaixamento pode ser realizado com segurança, insira o identificador da instância de destino na janela de confirmação.
    5. Clique em Confirmar e continuar.

    Configurar a conectividade entre as instâncias de banco de dados de origem e destino

    No menu suspenso Método de conectividade, selecione um método de conectividade de rede. Esse método define como a instância recém-criada do Cloud SQL vai se conectar ao banco de dados de origem. Os métodos atuais de conectividade de rede incluem lista de permissões de IP, túnel SSH reverso e peering de VPC.

    Se você quiser usar...Faça o seguinte:
    O método de conectividade de rede da lista de permissões de IP, É preciso especificar o endereço IP de saída da instância de destino. Se a instância do Cloud SQL criada for de alta disponibilidade, inclua os endereços IP de saída das instâncias primária e secundária.
    O método de conectividade de rede do túnel SSH reverso. Você precisa selecionar a instância de VM do Compute Engine que vai hospedar o túnel.

    Depois de especificar a instância, o Google vai fornecer um script que executa as etapas para configurar o túnel entre os bancos de dados de origem e de destino. Você precisará executar o script na Google Cloud CLI.

    Execute os comandos em uma máquina que tenha conectividade com o banco de dados de origem e com o Google Cloud.
    O método de conectividade de rede de peering de VPC, Selecione a rede VPC em que o banco de dados de origem está localizado. A instância do Cloud SQL será atualizada para se conectar a essa rede.

    Depois de selecionar e configurar a conectividade de rede, clique em Configurar e continuar.

    Testar, criar e executar o job de migração

    Nesta etapa final, revise o resumo das configurações do job de migração, da origem, do destino e do método de conectividade e teste a validade da configuração do job de migração. Se houver problemas, modifique as configurações do job de migração. Nem todas as configurações podem ser editadas.

    1. Na página Testar e criar job de migração, clique em Testar job.

      Se o teste falhar, você pode resolver o problema na parte do fluxo destinada a isso e refazer o teste. Para informações sobre como solucionar problemas em um teste de job de migração com falha, consulte Diagnosticar problemas do MySQL.

    2. Quando o teste do job de migração terminar, clique em Criar e iniciar job.

      A migração está em andamento. Quando você inicia o job de migração, o Database Migration Service começa o despejo completo, bloqueando brevemente o banco de dados de origem.

    gcloud

    Para configurar e executar a migração, siga estas etapas:

    1. Crie o job de migração.
      Execute o seguinte comando (clique no link para expandir):

      gcloud database-migration migration-jobs create

      Este exemplo usa a flag opcional --no-async para que todas as operações sejam realizadas de forma síncrona. Isso significa que alguns comandos podem levar um tempo para serem concluídos. É possível pular a flag --no-async para executar comandos de forma assíncrona. Se você fizer isso, use o comando gcloud database-migration operations describe para verificar se a operação foi bem-sucedida.

      Antes de usar os dados do comando abaixo, faça estas substituições:

      • MIGRATION_JOB_ID por um identificador legível por máquina para o job de migração. Use esse valor para trabalhar com jobs de migração usando os comandos da CLI do Google Cloud ou a API do Database Migration Service.
      • REGION pelo identificador da região em que você quer salvar o job de migração.
      • MIGRATION_JOB_NAME por um nome legível por humanos para o job de migração. Esse valor é exibido no Database Migration Service no console do Google Cloud .
      • SOURCE_CONNECTION_PROFILE_ID com um identificador legível por máquina do perfil de conexão de origem.
      • DESTINATION_CONNECTION_PROFILE_ID pelo identificador legível por máquina do perfil de conexão de destino.
      • MIGRATION_JOB_TYPE com o tipo do seu job de migração. Dois valores são permitidos: ONE_TIME ou CONTINUOUS. Para mais informações, consulte Tipos de migração.
      • PATH_TO_THE_FOLDER_IN_STORAGE_BUCKET_WITH_PHYSICAL_BACKUP_FILES pelo caminho para os arquivos de backup físico armazenados em uma pasta em um bucket do Cloud Storage. Use o seguinte formato: gs://<bucket_name>/<path_to_backup_file_folder>.
      • Configuração de rede

        Se você usa conexão por IP particular com peering de rede VPC ou um túnel SSH reverso, adicione as seguintes flags ao comando:

        Conectividade de IP particular com peering de rede VPC
        Use a flag --peer-vpc para especificar o nome da rede com que você quer fazer peering.
        Túnel SSH reverso em uma VM do Compute Engine
        Use as seguintes flags para fornecer detalhes de rede para o Compute Engine: --vm-ip, --vm-port, --vpc. Também é possível usar a flag opcional --vm para especificar o nome da VM.

        Para mais exemplos de uso, consulte Exemplos da Google Cloud CLI.

      Execute o seguinte comando:

      Linux, macOS ou Cloud Shell

      gcloud database-migration migration-jobs \
create MIGRATION_JOB_ID \
  --no-async \
  --region=REGION \
  --display-name=MIGRATION_JOB_NAME \
  --source=SOURCE_CONNECTION_PROFILE_ID \
  --destination=DESTINATION_CONNECTION_PROFILE_ID \
  --type=MIGRATION_JOB_TYPE
  --dump-type=PHYSICAL
  --dump-path=PATH_TO_THE_FOLDER_IN_STORAGE_BUCKET_WITH_PHYSICAL_BACKUP_FILES

      Windows (PowerShell)

      gcloud database-migration migration-jobs `
create MIGRATION_JOB_ID `
  --no-async `
  --region=REGION `
  --display-name=MIGRATION_JOB_NAME `
  --source=SOURCE_CONNECTION_PROFILE_ID `
  --destination=DESTINATION_CONNECTION_PROFILE_ID `
  --type=MIGRATION_JOB_TYPE
  --dump-type=PHYSICAL
  --dump-path=PATH_TO_THE_FOLDER_IN_STORAGE_BUCKET_WITH_PHYSICAL_BACKUP_FILES

      Windows (cmd.exe)

      gcloud database-migration migration-jobs ^
create MIGRATION_JOB_ID ^
  --no-async ^
  --region=REGION ^
  --display-name=MIGRATION_JOB_NAME ^
  --source=SOURCE_CONNECTION_PROFILE_ID ^
  --destination=DESTINATION_CONNECTION_PROFILE_ID ^
  --type=MIGRATION_JOB_TYPE
  --dump-type=PHYSICAL
  --dump-path=PATH_TO_THE_FOLDER_IN_STORAGE_BUCKET_WITH_PHYSICAL_BACKUP_FILES

      Você receberá uma resposta semelhante a esta:

      Waiting for migration job [MIGRATION_JOB_ID]
to be created with [OPERATION_ID]

Waiting for operation [OPERATION_ID] to complete...done.

Created migration job MIGRATION_JOB_ID [OPERATION_ID]

    2. Rebaixe a instância de destino do Cloud SQL.
      Execute o seguinte comando (clique no link para expandir):

      gcloud database-migration migration-jobs demote-destination

      Antes de usar os dados do comando abaixo, faça estas substituições:

      • MIGRATION_JOB_ID pelo identificador do job de migração.

        Se você não souber o identificador, use o comando gcloud database-migration migration-jobs list para listar todos os jobs de migração em uma determinada região e ver os identificadores deles.

      • REGION pelo identificador da região em que o perfil de conexão está salvo.

      Execute o seguinte comando:

      Linux, macOS ou Cloud Shell

      gcloud database-migration migration-jobs \
demote-destination MIGRATION_JOB_ID \
  --region=REGION

      Windows (PowerShell)

      gcloud database-migration migration-jobs `
demote-destination MIGRATION_JOB_ID `
  --region=REGION

      Windows (cmd.exe)

      gcloud database-migration migration-jobs ^
demote-destination MIGRATION_JOB_ID ^
  --region=REGION

      Resultado

      A ação é realizada de forma assíncrona. Assim, esse comando retorna uma entidade Operation que representa uma operação de longa duração: 

      done: false
metadata:
  '@type': type.googleapis.com/google.cloud.clouddms.v1.OperationMetadata
  apiVersion: v1
  createTime: '2024-02-20T12:20:24.493106418Z'
  requestedCancellation: false
  target: MIGRATION_JOB_ID
  verb: demote-destination
name: OPERATION_ID

      Para conferir se a operação foi bem-sucedida, consulte o objeto de operação retornado ou verifique o status do job de migração:

    3. (Opcional) Realizar um teste de job de migração
      É possível executar uma verificação para conferir se o Database Migration Service pode acessar todas as entidades de origem e destino necessárias. Execute o seguinte comando (clique no link para expandir):

      gcloud database-migration migration-jobs verify

      Antes de usar os dados do comando abaixo, faça estas substituições:

      • MIGRATION_JOB_ID com o identificador do job de migração.

        Se você não souber o identificador, use o comando gcloud database-migration migration-jobs list para listar todos os jobs de migração em uma determinada região e conferir os identificadores deles.

      • REGION pelo identificador da região em que o perfil de conexão está salvo.

      Execute o seguinte comando:

      Linux, macOS ou Cloud Shell

      gcloud database-migration migration-jobs \
verify MIGRATION_JOB_ID \
  --region=REGION

      Windows (PowerShell)

      gcloud database-migration migration-jobs `
verify MIGRATION_JOB_ID `
  --region=REGION

      Windows (cmd.exe)

      gcloud database-migration migration-jobs ^
verify MIGRATION_JOB_ID ^
  --region=REGION

      Resultado

      A ação é realizada de maneira assíncrona. Assim, esse comando retorna uma entidade de operação que representa uma operação de longa duração: 

      done: false
metadata:
  '@type': type.googleapis.com/google.cloud.clouddms.v1.OperationMetadata
  apiVersion: v1
  createTime: '2024-02-20T12:20:24.493106418Z'
  requestedCancellation: false
  target: MIGRATION_JOB_ID
  verb: verify
name: OPERATION_ID

      Para ver se a operação foi bem-sucedida, consulte o objeto de operação retornado ou verifique o status do job de migração:

    4. Inicie o job de migração.
      Execute o seguinte comando (clique no link para expandir):

      gcloud database-migration migration-jobs start

      Antes de usar os dados do comando abaixo, faça estas substituições:

      • MIGRATION_JOB_ID pelo identificador do job de migração.

        Se você não souber o identificador, use o comando gcloud database-migration migration-jobs list para listar todos os jobs de migração em uma determinada região e conferir os identificadores deles.

      • REGION pelo identificador da região em que o perfil de conexão está salvo.

      Execute o seguinte comando:

      Linux, macOS ou Cloud Shell

      gcloud database-migration migration-jobs \
start MIGRATION_JOB_ID \
  --region=REGION

      Windows (PowerShell)

      gcloud database-migration migration-jobs `
start MIGRATION_JOB_ID `
  --region=REGION

      Windows (cmd.exe)

      gcloud database-migration migration-jobs ^
start MIGRATION_JOB_ID ^
  --region=REGION

      Resultado

      A ação é realizada de forma assíncrona. Assim, esse comando retorna uma entidade Operation que representa uma operação de longa duração: 

      done: false
metadata:
  '@type': type.googleapis.com/google.cloud.clouddms.v1.OperationMetadata
  apiVersion: v1
  createTime: '2024-02-20T12:20:24.493106418Z'
  requestedCancellation: false
  target: MIGRATION_JOB_ID
  verb: start
name: OPERATION_ID

      Para ver se a operação foi bem-sucedida, consulte o objeto de operação retornado ou verifique o status do job de migração:

      Quando você inicia o job de migração, a instância de destino do Cloud SQL é colocada em um modo somente leitura totalmente gerenciado pelo Database Migration Service. É possível promovê-la a uma instância independente quando os dados forem totalmente migrados.

      Observação: é possível monitorar o progresso da migração e a integridade da instância de destino com os recursos de observabilidade do Database Migration Service. Consulte Métricas de jobs de migração.

Etapa 4. (Opcional) Interromper a migração

É possível interromper e excluir o job de migração a qualquer momento se quiser cancelar o processo de migração de dados. É possível gerenciar o job de migração no console Google Cloud ou com a Google Cloud CLI.

Etapa 5. Finalizar a migração

Quando o job de migração for concluído, finalize-o seguindo uma destas etapas:

  • Para migrações únicas: o status do job de migração muda para Concluído. Nenhuma outra ação é necessária. É possível limpar os recursos do job de migração e do perfil de conexão.

  • Para migrações contínuas: promova o job de migração para alternar o aplicativo para a nova instância de banco de dados.