Data Transmission Service:Sincronizar dados de uma instância do ApsaraDB RDS for MySQL para uma instância do PolarDB-X 1.0

ApsaraDB RDS for MySQL

O log binário é ativado por padrão nas instâncias do ApsaraDB RDS for MySQL. Certifique-se de que:

• O parâmetro binlog_row_image esteja definido como full. Caso contrário, ocorre um erro de pré-verificação e a tarefa não poderá ser iniciada. Consulte Definir parâmetros da instância.

• Os logs binários locais sejam retidos por pelo menos 3 dias (recomenda-se 7 dias). Se os logs forem purgados antes de o DTS conseguir lê-los, a tarefa falhará. Em casos extremos, pode ocorrer perda ou inconsistência de dados. Tarefas que falham devido à retenção insuficiente de logs não são cobertas pelo SLA do DTS. Para definir o Retention Period dos logs binários locais, consulte exclua logs locais automaticamente.

As instâncias somente leitura do ApsaraDB RDS for MySQL 5.6 não registram logs de transação e não podem ser usadas como banco de dados de origem.

MySQL autogerenciado

Para um banco de dados MySQL autogerenciado, configure os seguintes parâmetros:

Retenha os logs binários por pelo menos 7 dias. Se os logs forem purgados antes de o DTS conseguir lê-los, a tarefa falhará. Problemas causados pela retenção insuficiente de logs não são cobertos pelo SLA do DTS.

Requisitos adicionais:

• Arquitetura primária/primária: Para isso, ative o parâmetro log_slave_updates para que o DTS possa obter todos os logs binários de ambos os nós. Consulte Criar uma conta de banco de dados para um banco de dados MySQL autogerenciado e configurar o log binário.

• Amazon Aurora MySQL ou instâncias em modo cluster: Certifique-se de que o nome de domínio ou endereço IP configurado para a tarefa sempre aponte para o nó de leitura e gravação (RW). Caso contrário, a tarefa poderá não ser executada corretamente.

Limites do banco de dados de origem

• O servidor onde o banco de dados de origem está implantado deve ter largura de banda de saída suficiente. A largura de banda insuficiente reduz a velocidade de sincronização.

• As tabelas a serem sincronizadas devem ter uma chave primária ou uma restrição UNIQUE com valores de campo exclusivos. Tabelas sem essas restrições podem gerar dados duplicados no destino.

• Somente tabelas podem ser selecionadas como objetos de sincronização.

• Ao usar o mapeamento de nomes de objetos (como nomes de tabelas ou colunas), uma única tarefa suporta no máximo 1.000 tabelas. Para sincronizar mais de 1.000 tabelas com mapeamento de nomes, divida-as em várias tarefas.

• A classe de armazenamento da instância do PolarDB-X 1.0 deve ser RDS MySQL (um RDS personalizado privado). O PolarDB MySQL não é suportado.

• Não execute operações DDL durante a sincronização completa de dados, pois isso causa falha na tarefa.

  Durante a fase de sincronização completa, o DTS consulta o banco de dados de origem e pode gerar bloqueios de metadados, o que pode impedir operações DDL na origem.

• Alterações de dados provenientes de operações não registradas em logs binários não são sincronizadas. Isso inclui a recuperação de dados com backups físicos e operações em cascata.

  Se isso ocorrer, remova o banco de dados ou a tabela afetada dos objetos de sincronização e adicione-a novamente, caso o seu negócio permita. Consulte Modificar objetos de sincronização .

• Colunas invisíveis (MySQL 8.0.23 e posterior): Se os dados a serem sincronizados contiverem colunas invisíveis, o DTS não conseguirá obter os dados nessas colunas, o que pode causar perda de dados. Execute o seguinte comando para tornar as colunas invisíveis visíveis:

  ALTER TABLE <table_name> ALTER COLUMN <column_name> SET VISIBLE;

  Tabelas sem chave primária geram automaticamente uma chave primária invisível, a qual também deve ser tornada visível. Consulte Colunas invisíveis e Chaves primárias invisíveis geradas.

• Se a tabela de destino do PolarDB-X 1.0 tiver o particionamento automático ativado (auto_partition=true), cada instrução DDL executada na origem poderá conter apenas uma alter_specification. Caso contrário, o DTS relatará um erro (TDDL-4998: Multi alter specifications when create GSI not support yet). Para executar uma instrução DDL que contenha vários itens alter_specification, divida cada um em uma instrução DDL separada e execute-os um por um. Para mais informações, consulte ALTER TABLE.

Outros limites

• EncDB (always-confidential): A sincronização completa de dados não é suportada quando o recurso always-confidential (EncDB) está ativado na instância de origem do RDS MySQL.

  Instâncias com Transparent Data Encryption (TDE) ativado suportam sincronização de schema, sincronização completa de dados e sincronização incremental de dados.

• Se você executar operações DDL online que utilizem tabelas temporárias no banco de dados de origem (como mesclar várias tabelas), os dados poderão ser perdidos no banco de dados de destino ou a instância do DTS poderá falhar.

• Não use ferramentas como pt-online-schema-change para executar operações DDL online em objetos em sincronização, pois isso causa falha na tarefa.

• Gravar dados de outras origens no banco de dados de destino durante a sincronização pode causar inconsistência de dados.

• Avalie o impacto de desempenho nos bancos de dados de origem e de destino antes de iniciar a sincronização. Execute tarefas de sincronização em horários de menor pico, quando possível. A sincronização completa de dados consome recursos de leitura e gravação em ambos os bancos de dados e pode aumentar a carga do servidor.

• Após a conclusão da sincronização completa de dados, operações INSERT simultâneas podem causar fragmentação nas tabelas de destino. O tablespace utilizado no banco de dados de destino pode ser maior que o do banco de dados de origem.

• Se uma instância do DTS falhar, a equipe de suporte tentará recuperá-la em até 8 horas. As operações de recuperação podem incluir a reinicialização da instância ou o ajuste de parâmetros da instância do DTS (não do banco de dados). Consulte Modificar parâmetros da instância.

Casos especiais para origens MySQL autogerenciadas

• Se ocorrer um failover primário/secundário no banco de dados de origem durante a sincronização, a tarefa falhará.

• A latência de sincronização é calculada pela diferença entre o timestamp atual e o timestamp do último registro de dados sincronizado. Se nenhuma operação DML for executada no banco de dados de origem por um longo período, a latência exibida poderá ser imprecisa. Execute uma operação DML na origem e atualize a leitura de latência.

  Se você optar por sincronizar todo o banco de dados, crie uma tabela de heartbeat. O DTS atualiza ou grava na tabela de heartbeat a cada segundo para manter a leitura de latência precisa.

• O DTS executa periodicamente CREATE DATABASE IF NOT EXISTS no banco de dados de origem para avançar o offset do log binário.

Casos especiais para origens do ApsaraDB RDS for MySQL

• Instâncias do ApsaraDB RDS for MySQL que não registram logs de transação, como as instâncias somente leitura do ApsaraDB RDS for MySQL 5.6, não podem ser usadas como banco de dados de origem.

• O DTS executa periodicamente CREATE DATABASE IF NOT EXISTS no banco de dados de origem para avançar o offset do log binário.

Etapa 1: Acessar a página Data Synchronization

Utilize o console do DTS ou o console do DMS.

Etapa 2: Configurar bancos de dados de origem e de destino

1. Clique em Create Task.

2. Na página de configuração da tarefa, defina os seguintes parâmetros.

Geral

Banco de dados de origem

Banco de dados de destino

1. Clique em Test Connectivity and Proceed.

Certifique-se de que os blocos CIDR dos servidores DTS estejam adicionados às configurações de segurança dos bancos de dados de origem e de destino. Consulte Adicionar endereços IP do servidor DTS a uma lista de permissões . Se o banco de dados de origem ou de destino for autogerenciado e não acessado por meio de Alibaba Cloud Instance , clique em Test Connectivity na caixa de diálogo CIDR Blocks of DTS Servers .

Etapa 3: Configurar objetos de sincronização

Na etapa Configure Objects, defina os seguintes parâmetros.

Clique em Next: Advanced Settings.

Etapa 4: Definir configurações avançadas

Etapa 5: Executar a pré-verificação

Agora, salve as configurações clicando em Next: Save Task Settings and Precheck.

Para a API, visualize os parâmetros desta configuração de tarefa passando o mouse sobre Next: Save Task Settings and Precheck e clique em Preview OpenAPI parameters .

A tarefa executa uma pré-verificação antes de iniciar. Ela só poderá ser iniciada após a aprovação da pré-verificação.

• Se algum item falhar, clique em View Details ao lado do item com falha, corrija o problema e clique em Precheck Again.

• Se um item acionar um alerta que possa ser ignorado, clique em Confirm Alert Details e, em seguida, clique em Ignore > OK > Precheck Again. Ignorar itens de alerta pode causar inconsistência de dados.

Etapa 6: Adquirir a instância

1. Aguarde até que a Success Rate atinja 100% e clique em Next: Purchase Instance.

2. Na página de compra, configure os seguintes parâmetros.

1. Leia e selecione Data Transmission Service (Pay-as-you-go) Service Terms.

2. Clique em Buy and Start e, em seguida, clique em OK e confirme a operação.

A tarefa aparecerá na lista de tarefas. Monitore o progresso por lá.