PolarDB:Clonar RDS for MySQL para PolarDB for MySQL

Observações de uso

Ao clonar uma instância do ApsaraDB RDS for MySQL para um cluster PolarDB, os dados incrementais da instância de origem não são sincronizados com o cluster PolarDB de destino.

Visão geral

O PolarDB permite clonar dados de uma instância do ApsaraDB RDS for MySQL para um novo cluster PolarDB for MySQL com um único clique. Esse recurso cria um novo cluster PolarDB com os mesmos dados da instância RDS de origem. O novo cluster PolarDB inclui contas, bancos de dados, lista de permissões de IP e parâmetros necessários da instância de origem.

A tabela a seguir descreve as versões e os tipos de armazenamento compatíveis para a instância de origem do ApsaraDB RDS for MySQL e o cluster de destino PolarDB for MySQL.

• É possível clonar instâncias de origem do ApsaraDB RDS for MySQL de all versions e all storage types. Independentemente de a instância executar MySQL 5,6, 5,7 ou 8,0 e utilizar SSDs locais ou discos em nuvem, você pode cloná-la para um cluster PolarDB for MySQL com um único clique.

• Você pode clonar uma instância do ApsaraDB RDS for MySQL para um cluster PolarDB for MySQL que execute a same or a different version. Por exemplo, é possível clonar uma instância do ApsaraDB RDS for MySQL 5,6 para um cluster PolarDB for MySQL 5,6 ou para um cluster PolarDB for MySQL 8,0.

Migração física e lógica

O recurso de clonagem com um clique oferece suporte a dois métodos: migração física (replicação física) e migração lógica (sincronização de dados usando DTS).

• Physical migration (physical replication): Este método copia todos os dados da instância de origem do ApsaraDB RDS for MySQL para o cluster PolarDB for MySQL recém-criado por meio de replicação física.

• Logical migration (data synchronization by using DTS): Esta abordagem utiliza o Data Transmission Service (DTS) para criar uma tarefa de sincronização de dados que migra o esquema e todos os dados da instância de origem do ApsaraDB RDS for MySQL para o cluster PolarDB for MySQL recém-criado.

A tabela a seguir compara os dois métodos de migração.

A tabela a seguir descreve as edições e os tipos de armazenamento compatíveis do ApsaraDB RDS for MySQL.

A migração física é utilizada apenas quando você clona uma instância do ApsaraDB RDS for MySQL 5,6 ou 5,7 High-availability Edition que usa SSDs locais para um cluster PolarDB for MySQL da mesma versão. Em todos os outros cenários, a migração lógica é usada para clonar uma instância do ApsaraDB RDS for MySQL para um cluster PolarDB for MySQL da mesma versão ou de uma versão diferente.

Benefícios

O processo de clonagem garante perda zero de dados.

Pré-requisitos

• Caso utilize migração física, a instância RDS de origem deve atender aos seguintes requisitos de versão. A migração lógica não possui requisitos de versão.

  • Para o ApsaraDB RDS for MySQL 5,6, a versão secundária deve ser 20190815 ou posterior.

  • Para o ApsaraDB RDS for MySQL 5,7, a versão secundária deve ser 20200331 ou posterior.

  Nota

  Execute o comando SHOW VARIABLES LIKE '%rds_release_date%'; para verificar a versão secundária da instância RDS de origem. Se a versão secundária for anterior à necessária, atualize-a para a versão mais recente. Para obter mais informações, consulte Atualizar a versão secundária do mecanismo.

• O recurso de clonagem com um clique é suportado apenas para instâncias RDS de origem cujas tabelas utilizam os mecanismos de armazenamento InnoDB ou X-Engine.

• A instância RDS de origem não deve ter o TDE ou o SSL ativados. Se estiverem ativados, crie manualmente uma tarefa de migração de dados do DTS para migrar a instância RDS de origem para o PolarDB. Para obter mais informações, consulte Migrar dados do ApsaraDB RDS for MySQL para o PolarDB for MySQL.

• Se a instância RDS de origem estiver no Modo de Alta Segurança (que utiliza um proxy de banco de dados), crie uma conta privilegiada ou mude para o Modo de Alto Desempenho para realizar a clonagem com um clique. Para obter mais informações, consulte Criar uma conta e [[Alteração de Produto/Recurso] Atualização do link de rede do RDS](t64586.dita#concept_vyz_wf2_wfb).

Limitações

• Você só pode clonar uma instância do ApsaraDB RDS for MySQL para um cluster PolarDB for MySQL da mesma versão ou de uma versão posterior. Não há suporte para clonagem para uma versão anterior.

  Por exemplo, não é possível clonar uma instância do ApsaraDB RDS for MySQL 5,7 para um cluster PolarDB for MySQL 5,6, nem clonar uma instância do ApsaraDB RDS for MySQL 8.0.2 para um cluster PolarDB for MySQL 8.0.1.

• O método de migração física apresenta as seguintes limitações:

  • Não há suporte para migração entre regiões.

  • Não altere os parâmetros da instância RDS de origem durante a migração.

• O método de migração lógica possui as seguintes restrições:

  • Não há suporte para migração entre regiões.

  • Não altere os parâmetros da instância RDS de origem durante a migração.

  • O banco de dados de origem tem as seguintes limitações:

    Tipo

    Descrição

    Limitações do banco de dados de origem

    As tabelas a serem sincronizadas devem ter uma PRIMARY KEY ou uma restrição exclusiva, e os campos na restrição devem ser exclusivos. Caso contrário, dados duplicados podem aparecer no banco de dados de destino. Se você sincronizar no nível de tabela e precisar editar objetos (como mapear nomes de colunas), uma única tarefa de sincronização suporta no máximo 1.000 tabelas. Se exceder esse limite, o envio da tarefa falhará. Nesse caso, recomendamos dividir as tabelas em várias tarefas ou configurar uma tarefa para sincronizar todo o banco de dados. Log binário: O log binário deve estar habilitado na instância de origem e o parâmetro binlog_row_image deve ser definido como full. Caso contrário, a pré-verificação falhará e a tarefa de sincronização de dados não poderá ser iniciada. Para obter mais informações, consulte Configurar parâmetros da instância.

  • Outras limitações:

    Tipo

    Descrição

    Outras limitações

    Antes de começar, avalie o desempenho dos bancos de dados de origem e de destino. Recomendamos realizar a sincronização de dados fora dos horários de pico. A sincronização inicial completa de dados consome recursos de leitura e gravação em ambos os bancos de dados, o que pode aumentar a carga deles. A sincronização completa inicial executa operações INSERT simultâneas, o que pode causar fragmentação de tabela no banco de dados de destino. Como resultado, o espaço de tabela na instância de destino pode ficar maior do que na instância de origem após a conclusão da sincronização inicial. Se você estiver sincronizando tabelas individuais (não o banco de dados inteiro), não execute alterações de DDL online nas tabelas de origem usando ferramentas como gh-ost ou pt-online-schema-change durante a sincronização de dados. Isso pode causar falha na sincronização. Você pode usar o Data Management Service (DMS) para realizar alterações de DDL online. Para obter mais informações, consulte Alterar esquemas sem bloquear tabelas. Durante a sincronização do DTS, não grave nenhum dado externo no banco de dados de destino. Isso pode causar inconsistência de dados entre a origem e o destino. Por exemplo, se você usar o DMS para realizar uma alteração de DDL online enquanto dados externos estão sendo gravados no destino, pode ocorrer perda de dados. Por padrão, o DTS desabilita restrições de chave estrangeira no banco de dados de destino durante a sincronização. Portanto, operações em cascata como DELETE do banco de dados de origem não são sincronizadas com o destino.

Faturamento

• As regras de faturamento para migração física são as seguintes:

  A migração do ApsaraDB RDS para o PolarDB é gratuita. Você paga apenas pelo cluster PolarDB adquirido. Para obter mais informações sobre as taxas do cluster PolarDB, consulte Visão geral dos itens faturáveis.

• As regras de faturamento para migração lógica são as seguintes:

  Além do custo do cluster PolarDB, você também paga pela tarefa de sincronização do DTS. No entanto, esse recurso está atualmente em período de teste. As tarefas de sincronização são gratuitas nos primeiros 30 dias. Esse teste gratuito não está disponível para alguns tipos de conta, incluindo usuários de operadora de rede virtual (VNO), usuários Jushita, usuários do site internacional da Alibaba Cloud e usuários RAM. Os detalhes são os seguintes:

  Objeto de migração	Taxa
  Sincronização de esquema e sincronização completa de dados	Nenhuma taxa é cobrada pela tarefa de sincronização dentro de 30 dias após sua criação. Após 30 dias, a tarefa de sincronização será cancelada. Nota Acesse a Página de Tarefas de Sincronização de Dados do novo console DTS para visualizar o tempo restante da tarefa.

As seções a seguir descrevem como clonar uma instância do ApsaraDB RDS for MySQL para um cluster PolarDB for MySQL.

Pré-verificações (apenas para migração lógica)

Etapa 1: Clonar a partir de uma instância RDS

Esta operação cria um cluster PolarDB com os mesmos dados da instância RDS de origem.

1. Faça login no console do PolarDB.

2. No canto superior esquerdo, selecione a região onde o cluster está implantado.

3. Clique em Create Cluster.

4. Defina Billing Method como Subscription, Pay-As-You-Go ou Serverless.

   • Assinatura: Você paga pelos nós de computação ao criar o cluster. O espaço de armazenamento é faturado por hora com base no volume real de dados, e as cobranças são deduzidas do saldo da sua conta.

   • Pagamento conforme o uso: Nenhum pagamento antecipado é necessário. Tanto os nós de computação quanto o espaço de armazenamento (com base no volume real de dados) são faturados por hora, e as cobranças são deduzidas do saldo da sua conta.

   • Serverless: Nenhum pagamento antecipado é necessário. Recursos como nós de computação, espaço de armazenamento e proxy de banco de dados são dimensionados dinâmica e elasticamente com base na demanda real. Você é faturado pelo uso real dos recursos dimensionados.

5. Configure os seguintes parâmetros.

   Nota

   Para parâmetros não detalhados na tabela a seguir, consulte as seções relevantes em Adquirir um cluster.

   Parâmetro	Descrição
   Creation Method	Selecione Clone from RDS.
   Region	Selecione a região onde a instância de origem do ApsaraDB RDS for MySQL está localizada. Nota O novo cluster PolarDB é criado na mesma região.
   Source RDS Version	A versão da instância RDS de origem. Selecione 5,6, 5,7 ou 8,0.
   Source RDS Instance	Selecione a instância RDS de origem. Instâncias somente leitura não estão incluídas.
   Database Engine	A versão do mecanismo de banco de dados para o cluster PolarDB de destino. Escolha uma versão igual à da instância RDS de origem ou uma versão diferente.
   Node Specifications	Selecione especificações com base nas suas necessidades. Recomendamos selecionar especificações iguais ou superiores às da instância RDS de origem. Para obter mais informações sobre as especificações de nó do PolarDB, consulte Especificações de nó de computação da Enterprise Edition.

6. No canto superior direito, revise a configuração do cluster. Defina Subscription Duration (para clusters Subscription ), Quantity e se deseja ativar a Auto-renewal.

7. Leia e aceite o Contrato de Serviço. Clique em Buy Now.

8. Na página Payment , confirme os detalhes do pedido não pago e o método de pagamento e clique em Place Order .

   Nota

   • Após o pagamento bem-sucedido, a criação do cluster leva de 10 a 15 minutos. Em seguida, você poderá ver o novo cluster na Cluster List .

   • Se os nós do cluster exibirem Creating , o cluster não estará pronto. Somente quando o status do cluster for Running você poderá usá-lo.

   • Certifique-se de ter selecionado a região correta. Caso contrário, você não verá seu cluster.

9. Faça login no console do PolarDB e visualize o status do novo cluster PolarDB.

   Nota

   Se estiver clonando usando migração lógica (sincronização de dados usando DTS), clique no ID do cluster para acessar a página Basic Information e visualizar o status da migração. Se o status da migração do RDS mudar para Pre-check failed, resolva o problema de acordo com a Error Message.

   Por exemplo, se existir um gatilho na instância RDS de origem, a pré-verificação falhará e reportará o erro "The RDS instance has a trigger". Exclua o gatilho da instância RDS de origem e clique em Continue migrating. Alternativamente, clique em Give up migration e crie manualmente uma tarefa de migração no console DTS. Para obter detalhes, consulte Como configurar uma tarefa de sincronização ou migração quando o banco de dados de origem contém gatilhos.

   Você também pode optar por Give up migration nesta etapa. Para obter informações sobre as consequências, consulte Perguntas frequentes.

Etapa 2: Visualizar detalhes da tarefa de sincronização de dados

Se estiver usando migração lógica, clique no ID do cluster para acessar a página Basic Information e visualizar o status da migração. Se ocorrer um erro de migração (como falha na pré-verificação) ou outra exceção (como alta latência de replicação), acesse a página de detalhes da tarefa de sincronização de dados correspondente do DTS para visualizar mais informações.

1. Faça login no console do PolarDB.

2. Localize o cluster de destino e clique no respectivo ID.

3. Na página Basic Information, na seção RDS Migration, clique no nome da tarefa em DTS Data Synchronization Task para abrir a lista de tarefas de sincronização de dados no console DTS.

   

4. Localize a tarefa de sincronização de dados correspondente. É possível visualizar detalhes de falha na pré-verificação, detalhes da tarefa, logs da tarefa e muito mais.

   

Perguntas frequentes

• P: Qual é a diferença entre atualizar uma instância do ApsaraDB RDS for MySQL e cloná-la para um cluster PolarDB for MySQL?

  R: A tabela a seguir descreve as diferenças.

  Item	Atualização	Clonagem com um clique do ApsaraDB RDS for MySQL para o PolarDB for MySQL
  Suporta sincronização de dados incrementais	Sim	Não
  Afeta operações na instância RDS de origem	Não	Não
  Suporta versões diferentes do MySQL para origem e destino	Sim	Sim

• P: A clonagem a partir de uma instância RDS afeta a instância de origem?

  R: Isso não afeta a operação normal da instância RDS de origem, mas a clonagem completa de dados consome alguns recursos da instância de origem.

Referência de API

Próximas etapas

Após a conclusão da migração, atualize a string de conexão do banco de dados do seu aplicativo para o endpoint do cluster PolarDB o mais rápido possível. Para obter mais informações, consulte Gerenciar endpoints.