Use o Data Transmission Service (DTS) para sincronizar dados continuamente de uma instância ApsaraDB RDS for MySQL para um projeto MaxCompute. O DTS gerencia todo o pipeline — replicação de schema, carga de dados históricos e captura contínua de alterações — para que você possa construir um sistema de análise em tempo real sem gerenciar a infraestrutura de sincronização.
O que você fará
Configure os pré-requisitos (projeto MaxCompute, lista de permissões de IP, AccessKey).
Configure as conexões de source e destino no DTS.
Selecione objetos e defina as opções de sincronização.
Execute a pré-verificação, adquira e inicie a instância.
Faturamento
|
Tipo de sincronização |
Custo |
|
Sincronização de schema e sincronização completa de dados |
Gratuito |
|
Sincronização incremental de dados |
Pago. Consulte Visão geral do faturamento. |
Pré-requisitos
Antes de começar, verifique se você tem:
Um projeto MaxCompute. Consulte Ativar MaxCompute e DataWorks e Criar um projeto MaxCompute.
Uma lista de permissões de endereços IP configurada no projeto MaxCompute para permitir o acesso do DTS. Consulte Configurar uma lista de permissões de endereços IP para permitir o acesso de services Alibaba Cloud ao MaxCompute.
Um par de AccessKey da conta Alibaba Cloud proprietária do projeto MaxCompute. Consulte Criar um par de AccessKey.
Em vez de usar o AccessKey da conta raiz, crie um usuário RAM e defina-o como superadministrador do projeto MaxCompute .
Como funciona
O DTS sincroniza os dados em três fases sequenciais:
Sincronização de schema — O DTS replica os schemas das tabelas do banco de dados de source para o MaxCompute e adiciona
_baseao final de cada nome de tabela. Por exemplo, a tabela de sourcecustomertorna-secustomer_baseno MaxCompute.Sincronização completa de dados — O DTS carrega todos os dados históricos da source para as tabelas
_base(chamadas tabelas de linha de base completa). Esse snapshot serve como ponto de partida para a sincronização incremental.Sincronização incremental de dados — O DTS cria uma tabela
_logcorrespondente para cada tabela sincronizada (por exemplo,customer_log) e grava continuamente eventos de alteração do log binário da source nessa tabela.
Para obter detalhes sobre o schema da tabela _log, consulte Schema da tabela de dados incrementais.
Operações SQL suportadas para sincronização incremental
|
Tipo de operação |
Instruções |
|
DML |
INSERT, UPDATE, DELETE |
|
DDL |
ADD COLUMN (ADD COLUMN com colunas de atributo não é suportado) |
O DTS não sincroniza chaves estrangeiras. Operações em cascata e de exclusão na source não são refletidas no destino.
Permissões necessárias
A conta do banco de dados da instância ApsaraDB RDS for MySQL de source deve ter permissões de leitura e escrita. Consulte Criar uma conta e Modificar permissões da conta.
Se a conta não foi criada no console ApsaraDB RDS for MySQL, conceda a ela as permissões: REPLICATION CLIENT, REPLICATION SLAVE, SHOW VIEW e SELECT.
Limitações
Requisitos do banco de dados de source
As tabelas devem possuir restrições PRIMARY KEY ou UNIQUE com todos os campos únicos. Caso contrário, o destino poderá conter registros duplicados.
Ao sincronizar tabelas com renomeação de colunas ou tabelas, uma única tarefa suporta até 1.000 tabelas. Se você executar uma tarefa para sincronizar mais de 1.000 tabelas, ocorrerá um erro de solicitação. Use múltiplas tarefas ou faça a sincronização no nível do banco de dados.
Não execute instruções DDL durante a sincronização de schema ou a sincronização completa de dados. Essa ação causa falha na tarefa.
Dados gerados por operações em cascata ou restauração de backup físico não são sincronizados.
Se a source executar MySQL 8.0.23 ou posterior e as tabelas contiverem colunas invisíveis, essas colunas serão excluídas e haverá perda de dados. Execute
ALTER TABLE <table_name> ALTER COLUMN <column_name> SET VISIBLE;para torná-las visíveis antes de iniciar a tarefa. Tabelas sem chaves primárias recebem automaticamente chaves primárias invisíveis — torne-as visíveis também. Consulte Invisible Columns e Generated Invisible Primary Keys.
Requisitos de log binário
Configure os seguintes parâmetros do MySQL antes de criar a tarefa:
|
Parâmetro |
Valor obrigatório |
Aplica-se a |
|
|
|
ApsaraDB RDS for MySQL e MySQL autogerenciado |
|
|
|
Apenas MySQL autogerenciado |
|
|
|
MySQL autogerenciado em cluster dual-primary |
Requisitos de retenção de log binário:
ApsaraDB RDS for MySQL: mantenha os logs binários por pelo menos 3 dias; recomenda-se 7 dias.
MySQL autogerenciado: mantenha os logs binários por pelo menos 7 dias.
Se os logs binários forem purgados antes que o DTS os leia, a tarefa falhará e poderá ocorrer inconsistência ou perda de dados. Consulte Excluir arquivos de log binário para saber como definir o período de retenção.
Para MySQL autogerenciado, ative explicitamente o registro de log binário. Em clusters dual-primary com MySQL autogerenciado, definir log_slave_updates como ON garante que o DTS consiga ler todos os logs binários. Consulte Criar uma conta para um banco de dados MySQL autogerenciado e configurar o registro de log binário.
Outras limitações
Sincronize fora dos horários de pico. A sincronização completa de dados consome recursos de leitura e escrita tanto na source quanto no destino, o que aumenta a carga do servidor.
Após a conclusão da sincronização completa, o tablespace de destino fica maior que o da source devido à fragmentação causada por operações INSERT concorrentes.
Não execute
pt-online-schema-changeou ferramentas similares de DDL online nos objetos sincronizados enquanto a tarefa estiver em execução. Isso causará falha na tarefa.Gravar dados de outras sources no destino durante a sincronização pode causar inconsistência de dados.
Se a source tiver o EncDB ativado, a sincronização completa de dados não é suportada. O Transparent Data Encryption (TDE) não possui essa restrição — instâncias com TDE suportam sincronização de schema, completa e incremental.
Em caso de falha em uma tarefa DTS, o suporte técnico tentará restaurá-la dentro de 8 horas. Durante esse período, a tarefa pode ser reiniciada e seus parâmetros (não os do banco de dados) podem ser modificados.
Casos especiais para MySQL autogerenciado
Um failover entre primário e secundário durante a execução da tarefa causa falha na tarefa.
A latência de sincronização é calculada comparando o timestamp dos dados mais recentes sincronizados no destino com o timestamp atual da source. Se nenhuma operação DML for executada na source por um longo período, a latência exibida pode ser imprecisa. Para atualizá-la, execute qualquer operação DML na source. Se estiver sincronizando um banco de dados inteiro, crie uma tabela de heartbeat que receba atualizações a cada segundo.
Periodicamente, o DTS executa
CREATE DATABASE IF NOT EXISTS 'test'na source para avançar a posição do log binário.
Casos especiais para ApsaraDB RDS for MySQL
Instâncias somente leitura do ApsaraDB RDS for MySQL 5.6 que não registram logs de transação não podem ser usadas como source.
Periodicamente, o DTS executa
CREATE DATABASE IF NOT EXISTS 'test'na source para avançar a posição do log binário.
Criar uma tarefa de sincronização de dados
Etapa 1: Abrir a página de Sincronização de Dados
Use qualquer um dos consoles para abrir a página de configuração da tarefa.
Console DTS
Faça login no console DTS.
No painel de navegação à esquerda, clique em Data Synchronization.
No canto superior esquerdo, selecione a região onde a instância de sincronização residirá.
Console DMS
O caminho exato de navegação depende do modo e do layout do seu console DMS. Consulte Simple mode e Customize the layout and style of the DMS console .
Faça login no console DMS.
Na barra de navegação superior, passe o ponteiro sobre Data + AI e escolha DTS (DTS) > Data Synchronization.
Na lista suspensa à direita de Data Synchronization Tasks, selecione a região.
Etapa 2: Configurar bancos de dados de source e destino
Clique em Create Task e configure os seguintes parâmetros.
| Seção | Parâmetro | Descrição |
|---|---|---|
| N/A | Task Name | Nome da tarefa. O DTS gera um automaticamente. Especifique um nome descritivo para facilitar a identificação — a unicidade não é obrigatória. |
| Source Database | Select Existing Connection | Selecione uma instância de banco de dados registrada para preencher automaticamente os parâmetros ou configure a conexão manualmente. |
| Database Type | Selecione MySQL. | |
| Access Method | Selecione Alibaba Cloud Instance. | |
| Instance Region | Região da instância ApsaraDB RDS for MySQL de source. | |
| Replicate Data Across Alibaba Cloud Accounts | Selecione No (cenário de mesma conta). | |
| RDS Instance ID | ID da instância de source. | |
| Database Account | Conta com as permissões necessárias. Consulte Permissões necessárias. | |
| Database Password | Senha da conta do banco de dados. | |
| Encryption | Selecione Non-encrypted ou SSL-encrypted. Para SSL, ative primeiro a criptografia SSL na instância RDS. Consulte Use a cloud certificate to enable SSL encryption. | |
| Destination Database | Select Existing Connection | Selecione uma instância registrada ou configure manualmente. |
| Database Type | Selecione MaxCompute. | |
| Access Method | Selecione Alibaba Cloud Instance. | |
| Instance Region | Região do projeto MaxCompute. | |
| Project | Nome do projeto MaxCompute de destino. | |
| AccessKey ID of Alibaba Cloud Account | AccessKey ID da conta proprietária do projeto MaxCompute. | |
| AccessKey Secret of Alibaba Cloud Account |
Etapa 3: Testar conectividade
Clique em Test Connectivity and Proceed na parte inferior da página.
O DTS precisa de acesso a ambos os bancos de dados. Se estiver conectando a um banco de dados autogerenciado, adicione os blocos CIDR do DTS às configurações de segurança dele. Consulte Add the CIDR blocks of DTS servers . Para bancos de dados autogerenciados que não utilizam o método de acesso Alibaba Cloud Instance , clique em Test Connectivity na caixa de diálogo CIDR Blocks of DTS Servers .
Clique em OK para conceder permissões à sua conta MaxCompute e, em seguida, clique em Test Connectivity and Proceed.
Etapa 4: Configurar objetos
Na etapa Configure Objects, defina os seguintes parâmetros.
|
Parâmetro |
Descrição |
|
Synchronization Types |
Selecione Schema Synchronization, Full Data Synchronization e Incremental Data Synchronization. A sincronização completa carrega os dados históricos antes do início da sincronização incremental. |
|
Naming Rules of Additional Columns |
O DTS adiciona colunas de metadados às tabelas de destino. Se houver conflito com nomes de colunas existentes, a tarefa falhará. Escolha New Rule ou Previous Rule conforme sua configuração. Verifique se há conflitos antes de prosseguir. Consulte Regras de nomenclatura para colunas adicionais. |
|
Partition Definition of Incremental Data Table |
Selecione os nomes das partições conforme suas necessidades. Consulte Partition. |
|
Processing Mode of Conflicting Tables |
Precheck and Report Errors (padrão): falha na pré-verificação se o destino tiver tabelas com os mesmos nomes da source. Ignore Errors and Proceed: ignora essa verificação. Use com cautela — se os schemas diferirem, apenas algumas colunas poderão ser sincronizadas ou a tarefa poderá falhar. Se os schemas forem iguais e um registro tiver a mesma chave primária ou única, a sincronização completa mantém o registro existente no destino; a sincronização incremental o sobrescreve. |
|
Capitalization of Object Names in Destination Instance |
Controla o uso de maiúsculas e minúsculas nos nomes de bancos de dados, tabelas e colunas no MaxCompute. Padrão: DTS default policy. Consulte Specify the capitalization of object names in the destination instance. |
|
Source Objects |
Selecione os objetos e clique no ícone de seta para movê-los para Selected Objects. É possível selecionar tabelas. |
|
Selected Objects |
Clique com o botão direito em um objeto para renomeá-lo ou filtrar quais operações SQL sincronizar. Para renomear vários objetos, clique em Batch Edit. Para filtrar linhas, clique com o botão direito em uma tabela e especifique condições WHERE. Consulte Map object names e Specify filter conditions. |
Renomear um objeto usando o mapeamento de nomes pode causar falha na sincronização de objetos dependentes.
Etapa 5: Configurar definições avançadas
Clique em Next: Advanced Settings e configure os seguintes parâmetros.
|
Parâmetro |
Descrição |
|
Dedicated Cluster for Task Scheduling |
Por padrão, o DTS agenda tarefas no cluster compartilhado. Para maior estabilidade, adquira um cluster dedicado. Consulte What is a DTS dedicated cluster. |
|
Retry Time for Failed Connections |
Tempo durante o qual o DTS tenta reconectar após uma falha de conexão. Valores válidos: 10–1440 minutos. Padrão: 720 minutos. Defina pelo menos 30 minutos. Se várias tarefas compartilharem uma source ou destino, prevalece o menor tempo de nova tentativa. Durante as tentativas, o DTS cobra pela instância. |
|
Retry Time for Other Issues |
Tempo durante o qual o DTS tenta novamente quando operações DML ou DDL falham. Valores válidos: 1–1440 minutos. Padrão: 10 minutos. Defina pelo menos 10 minutos. Deve ser menor que Retry Time for Failed Connections. |
|
Enable Throttling for Full Data Synchronization |
Limita o QPS (consultas por segundo) na source, o RPS da migração completa de dados e a velocidade de migração (MB/s) para reduzir a carga. Disponível apenas se Full Data Synchronization estiver selecionado. |
|
Enable Throttling for Incremental Data Synchronization |
Limita o RPS e a velocidade de sincronização de dados (MB/s) na sincronização incremental para reduzir a carga no destino. |
|
Environment Tag |
Tag opcional para identificar a instância DTS por ambiente (por exemplo, produção ou teste). |
|
Whether to delete SQL operations on heartbeat tables of forward and reverse tasks |
Yes: o DTS não grava operações da tabela de heartbeat na source. Uma leitura de latência pode ser exibida. No: o DTS grava operações de heartbeat, o que pode afetar o backup físico e a clonagem da source. |
|
Configure ETL |
Yes: ativa extração, transformação e carga (ETL). Insira as instruções de processamento no editor de código. Consulte Configure ETL in a data migration or data synchronization task. No: desativa o ETL. |
|
Monitoring and Alerting |
Yes: configura alertas para falhas de tarefa ou latência acima de um limiar. Defina o limiar e os contatos de notificação. Consulte Configure monitoring and alerting. No: desativa os alertas. |
Etapa 6: Executar a pré-verificação
Clique em Next: Save Task Settings and Precheck.
Para visualizar os parâmetros da API desta configuração de tarefa, passe o mouse sobre o botão e clique em Preview OpenAPI parameters antes de prosseguir.
O DTS executa uma pré-verificação antes que a tarefa possa ser iniciada.
Se um item falhar, clique em View Details para ver a causa. Corrija o problema e clique em Precheck Again.
Se um item gerar um alerta que possa ser ignorado, clique em Confirm Alert Details, depois clique em Ignore na caixa de diálogo e clique em OK. Clique em Precheck Again para continuar. Ignorar alertas pode resultar em inconsistência de dados.
Etapa 7: Adquirir e iniciar a instância
Aguarde até que Success Rate atinja 100% e clique em Next: Purchase Instance.
Na página de compra, configure os seguintes parâmetros.
|
Parâmetro |
Descrição |
|
Billing Method |
Subscription: pagamento antecipado por um período fixo. Mais econômico para uso de longo prazo. Pay-as-you-go: faturamento horário. Adequado para uso de curto prazo — libere a instância ao terminar para interromper as cobranças. |
|
Resource Group Settings |
Grupo de recursos da instância. Padrão: default resource group. Consulte What is Resource Management? |
|
Instance Class |
Determina a velocidade de sincronização. Consulte Instance classes of data synchronization instances. |
|
Subscription Duration |
Disponível para o método de faturamento por assinatura. Opções: 1–9 meses, 1 ano, 2 anos, 3 anos ou 5 anos. |
Leia e aceite os Data Transmission Service (Pay-as-you-go) Service Terms.
Clique em Buy and Start. Na caixa de diálogo de confirmação, clique em OK.
A tarefa aparecerá na lista de tarefas. Monitore o progresso dela nesse local.
Schema da tabela de dados incrementais
Antes de consultar a tabela de dados incrementais, execute o seguinte comando no MaxCompute para permitir varreduras completas de tabela:
set odps.sql.allow.fullscan=true;
Cada tabela _log armazena eventos de alteração da source. Além dos dados originais das colunas, o DTS adiciona os seguintes campos de metadados a cada linha:
|
Campo |
Descrição |
|
|
Identificador exclusivo da entrada de log. Incrementa automaticamente a cada nova entrada. Para operações UPDATE, o DTS gera duas entradas (antes e depois da alteração) com o mesmo |
|
|
Tipo de operação: |
|
|
Timestamp da operação em UTC, correspondente ao timestamp do arquivo de log binário. |
|
|
|
|
|
|
Leitura de eventos UPDATE: O DTS grava duas linhas para cada UPDATE — uma com before_flag=Y (valores originais) e outra com after_flag=Y (novos valores). Ambas as linhas compartilham o mesmo record_id.