Para migrar ou sincronizar dados de um cluster HBase autogerenciado ou de um cluster ApsaraDB for HBase para o Lindorm wide table engine, utilize o Lindorm Tunnel Service (LTS). Esse service permite concluir a migração de dados históricos e a sincronização de dados em tempo real. Este tópico descreve os cenários de uso, recursos, vantagens da migração, limites de uso e tarefas de sincronização e migração de dados do HBase.
Cenários de uso
Migração de HBase autogerenciado para a cloud: transfira dados do HBase para o Lindorm.
Migração entre regiões: por exemplo, migre da região China (Qingdao) para a região China (Beijing).
Divisão de negócios: mova parte das operações para um novo cluster.
Recursos e vantagens
Recursos
Oferece migração sem tempo de inatividade do HBase 1.x e 2.x para o Lindorm.
Compatível com migração de schema de tabela, sincronização de dados em tempo real e migração de dados históricos.
Permite migração nos níveis de banco de dados, namespace e tabela.
Suporta renomeação de tabelas durante a migração.
Possibilita especificar intervalos de tempo, intervalos de rowkey e colunas específicas para migração.
Disponibiliza OpenAPI para criação de tarefas de migração.
Vantagens da migração
Executa migração de dados sem tempo de inatividade, concluindo tanto a migração de dados históricos quanto a sincronização incremental em tempo real.
Durante o processo, o HBase autogerenciado não interage com o cluster HBase de source. O sistema lê apenas o HDFS do cluster de source, o que reduz efetivamente o impacto nos negócios online desse cluster.
A cópia de dados na camada de arquivo é mais eficiente que a migração na camada de API, economizando geralmente mais de 50% de tráfego.
Um único nó atinge velocidade de migração de 150 MB/s. A quantidade de nós suporta dimensionamento horizontal para atender a requisitos de migração de dados na escala de TB ou PB.
Inclui mecanismos abrangentes de nova tentativa em caso de erro, monitoramento em tempo real da velocidade e do progresso da tarefa, além de suporte a alertas de falha.
Sincroniza schemas automaticamente para garantir a consistência das partições.
Limites
Não há suporte para migração para HBase autogerenciado.
Clusters com Kerberos ativado não são suportados.
Instâncias de nó único do ApsaraDB for HBase não são compatíveis.
Devido a limitações de rede, instâncias do ApsaraDB for HBase em redes clássicas não são suportadas.
Não é possível migrar ou sincronizar dados para instâncias independentes do Lindorm.
A sincronização incremental de dados baseia-se no WAL do HBase para sincronização assíncrona. Dados carregados via bulkload e dados não gravados no WAL não serão sincronizados.
Somente o LTS 3.8.10 e versões posteriores suportam migração de índices de pesquisa em tabelas. Para limites e precauções relacionados a esse recurso, consulte Perguntas frequentes sobre índice de pesquisa.
Precauções
Antes da migração, verifique a capacidade do HDFS do cluster de destino para evitar que o armazenamento fique cheio durante o processo.
-
Se o cluster de source for um cluster HBase autogerenciado ou ApsaraDB for HBase, antes de enviar a sincronização incremental, recomendamos defina o tempo de retenção de log do cluster de source como superior a 12 horas. Isso reserva tempo suficiente para processamento e recuperação de exceções que possam ocorrer durante a sincronização. Método de modificação: modifique o valor do parâmetro hbase.master.logcleaner.ttl no arquivo
hbase-site.xmle reinicie o HMaster após a alteração. A unidade do parâmetro hbase.master.logcleaner.ttl é milissegundos (ms). Atenção à conversão de unidades ao configurar. Por exemplo,hbase.master.logcleaner.ttl=43200000indica que o tempo de retenção de log está definido como 12 horas.NotaSe o cluster de source for um cluster Lindorm, não é necessário modifique o tempo de retenção de log.
Não é preciso crie tabelas no cluster de destino. O service de sincronização LTS cria automaticamente tabelas idênticas às do cluster de source, incluindo informações de partição. Tabelas de destino criadas manualmente podem ter partições muito inconsistentes em relação às tabelas de source, causando splits e compactações frequentes na tabela de destino após a migração. Se o volume de dados da tabela for muito grande, esse processo pode ser extremamente demorado.
Caso a tabela de source possua um coprocessador, garanta que o cluster de destino contenha o pacote JAR correspondente ao coprocessador ao crie a tabela de destino.
Após ativar a sincronização incremental, se os dados não forem consumidos, os logs serão retidos por 48 horas por padrão. Após o tempo limite, o relacionamento de assinatura é cancelado automaticamente e os dados retidos são excluídos.
Pré-requisitos
A conectividade de rede entre o cluster de source, o cluster de destino e o LTS foi verificada.
As fontes de dados HBase e Lindorm foram adicionadas. Para mais informações, consulte Adicionar uma fonte de dados HBase e Adicionar uma fonte de dados LindormTable.
Ative o acesso a arquivos subjacentes para o Lindorm no console.
Crie uma tarefa
No painel de navegação à esquerda, escolha .
Clique em Create a task.
Na caixa de texto Task Name (Optional), insira um nome para a tarefa. O nome da tarefa aceita apenas caracteres em inglês e dígitos. Este parâmetro é opcional. Se não for especificado, o ID da tarefa será usado como nome da tarefa por padrão.
Defina o Source Cluster e o Destination Cluster conforme solicitado.
-
Selecione a Operation desejada.
Table Schema Migration: cria tabelas no cluster de destino (com schema e informações de partição consistentes). Se a tabela já existir no cluster de destino, ela será ignorada.
Real-time Data Replication: sincroniza dados incrementais em tempo real do cluster de source.
Historical Data Migration: realiza migração física completa no nível de arquivo.
Em Tables to Synchronize/Migrate, insira as tabelas principais a serem migradas.
-
Selecione operações em tabelas de índice.
(Opcional) Configure as Advanced Configurations.
Clique em Create.
Visualize tarefas e detalhes da tarefa
No painel de navegação à esquerda, escolha para visualize as tarefas.
Clique em no nome da tarefa para visualize o status de execução da tarefa correspondente.
Switchover
Aguarde a conclusão da tarefa de migração completa. A latência da migração incremental é relativamente pequena (alguns segundos ou centenas de milissegundos).
Ative a verificação por amostragem de dados do LTS. Para tabelas grandes, a taxa de amostragem não deve ser muito alta para evitar impactos nos negócios online.
Realize a verificação dos negócios.
Execute o switchover dos negócios.
Perguntas frequentes
Quais cenários fazem com que os dados não sejam consumidos?
Liberar o cluster LTS diretamente sem encerrar a tarefa, suspender a tarefa de sincronização ou bloqueio por exceção da tarefa.
O que devo fazer se uma tarefa de migração falhar?
Existem vários motivos possíveis para falha na tarefa de migração, como instabilidade de rede e conflitos de service. O LTS possui um mecanismo de nova tentativa integrado e tentará novamente automaticamente após a falha da tarefa. Se a falha persistir após a nova tentativa, entre em contato com o suporte técnico do Lindorm (ID do DingTalk: s0s3eg3).