Lindorm:Resumo de problemas

Por que o Lindorm-cli falha ao se conectar ao LindormTable?

Verifique os itens a seguir:

• Conexão de rede pública: Obtenha um endereço IP público e adicione-o à lista de permissões do Lindorm.

• Proxy ou VPN: Adicione o IP do proxy à lista de permissões.

• Disponibilidade da porta: Teste a conectividade usando telnet.

• Conexão ECS: Consulte Problemas e soluções de conexão do Lindorm.

Quais são as portas comuns do LindormTable?

Qual é o impacto de uma atualização de versão secundária? Quanto tempo leva?

Uma atualização de versão secundária execute uma reinicialização contínua, um nó por vez. Durante cada reinicialização, as Regions ficam offline brevemente e depois voltam a ficar online. Após a atualização, o sistema reequilibra a carga automaticamente.

Impacto: Instâncias com baixa carga sofrem impacto mínimo. Instâncias com alta carga ou sensíveis à latência podem apresentar interrupções breves. Agende atualizações fora do horário de pico.

Duração: De 5 a 30 minutos por nó, dependendo do número de Regions e da carga atual.

O que a compactação faz?

A compactação limpa dados expirados (TTL), remove marcadores de exclusão, arquiva dados quentes e frios e comprime dados para reduzir o uso de armazenamento.

Com que frequência a compactação é executada automaticamente?

O intervalo padrão é de 20 dias. Em cenários de TTL, o padrão é min(TTL value, 20 days).

Para alterar o intervalo, use um destes métodos:

• SQL: Execute ALTER TABLE <tableName> SET 'COMPACTION_MAJOR_PERIOD'='172800000'; (unidade: milissegundos). Este exemplo defina o intervalo como 2 dias (172.800.000 ms).

• Lindorm Insight: No sistema de gerenciamento de cluster (Lindorm Insight), use o gerenciamento de alterações de tabela para modifique o Compaction period.

Posso acionar a compactação manualmente?

Sim. Use a instrução SQL execute major compaction.

Qual é o impacto da compactação nos negócios?

A compactação usa múltiplas threads. O número de threads depende da especificação da instância: especificações mais altas processam mais rápido, enquanto especificações inferiores podem enfileirar muitas tarefas. Quando há CPU disponível, a compactação melhora o desempenho de leitura e libera armazenamento, com efeito mínimo no throughput de gravação.

Para verifique o status da compactação, visualize Compaction queue length em LindormTable metrics — cluster load no monitoramento da instância:

• Normal: O valor diminui constantemente ou aumenta periodicamente e depois cai, sem continuar subindo ou permanecer estável por mais de um dia.

• Anormal: O valor continua subindo ou permanece estável por mais de um dia.

Se a utilização da CPU estiver abaixo de 40%: O LindormTable 2.6.5 e versões posteriores ajustam automaticamente os parâmetros de compactação. Atualize para uma versão secundária mais recente para obter esse comportamento.

Se a utilização da CPU exceder 40%: Adicione mais nós do LindormTable.

Por que o armazenamento continua crescendo mesmo após definir o TTL?

Causa: Se a fila de compactação tiver um grande acúmulo, a limpeza de dados fica atrasada em relação à expiração.

Resolução:

1. Verifique Compaction queue length no monitoramento da instância em LindormTable metrics — cluster load.

2. Se a fila estiver acumulada:

   • CPU abaixo de 40%: Atualize para o LindormTable 2.6.5 ou posterior para ajuste automático de parâmetros.

   • CPU acima de 40%: Adicione mais nós do LindormTable.

3. Se a fila estiver vazia, mas o armazenamento ainda estiver crescendo, a carga de I/O pode estar baixa. Acione a compactação manualmente ou reduza o intervalo de compactação. Por exemplo, para defina o intervalo como 2 dias: ALTER TABLE <tableName> SET 'COMPACTION_MAJOR_PERIOD'='172800000';

Como reduzir o espaço de armazenamento usando compressão?

Defina o algoritmo de compressão da tabela como ZSTD e o codec como INDEX, e então execute a compactação principal (major compaction).

SQL

Conecte-se usando o Lindorm-cli ou o Lindorm Insight e execute:

-- Set compression to ZSTD and encoding to INDEX
ALTER TABLE <tablename> SET 'COMPRESSION' = 'ZSTD', 'DATA_BLOCK_ENCODING' = 'INDEX';
ALTER TABLE <tablename> COMPACT;
-- For tables with many Regions, wait for the queue to drain

API HBase

alter 'ns:tablename', {NAME=>'family', DATA_BLOCK_ENCODING => 'INDEX', COMPRESSION => 'ZSTD'}
major_compact 'ns:tablename'
-- For tables with many Regions, wait for the queue to drain

Lindorm Insight

Use o gerenciamento de alterações de tabela para defina a compressão como ZSTD. Em seguida, acesse a página Visão geral da tabela e role até a parte inferior para monitorar o progresso da compactação.

Acompanhe o progresso por meio de Compaction queue length no monitoramento da instância.

O que fazer quando a capacidade do disco está cheia?

Execute uma das seguintes ações:

• Dimensione a capacidade de hot storage.

• Execute DROP TABLE para exclua tabelas não utilizadas e liberar espaço imediatamente.

• Execute TRUNCATE TABLE para limpar todos os dados de uma tabela e liberar espaço imediatamente.

Por que não consigo excluir dados quando o disco está cheio?

Causa: O LindormTable prioriza o throughput de gravação. Uma operação DELETE não remove os dados imediatamente; ela escreve um marcador de exclusão que oculta os dados das consultas. A remoção física só acontece durante a compactação. Quando o disco está cheio, o sistema bloqueia todas as gravações, incluindo marcadores de exclusão. Como nenhum marcador pode ser escrito, a compactação não tem nada para purgar e não consegue liberar espaço.

Resolução: Use DROP TABLE ou TRUNCATE TABLE para liberar espaço imediatamente, ou dimensione a capacidade de hot storage.

O LindormTable suporta dimensionamento de nós ou capacidade de disco?

Alterar a contagem de nós é uma operação no nível do mecanismo. Dimensionar a capacidade do disco é uma operação no nível da instância.

Quais unidades as propriedades comuns de tabela utilizam?

Como defina NUMREGIONS ao crie uma tabela?

Se NUMREGIONS não for especificado, a tabela começa com 1 partição. Como ponto de partida, defina NUMREGIONS como number of server nodes × 4.

As partições são divididas automaticamente quando:

• Os dados da partição atingem 8 GB, ou

• O QPS combinado de leitura e gravação da partição excede 1.000 (o sistema detecta o hotspot e decide se deve dividir).

Para melhor autorrecuperação de hotspots, use o LindormTable 2.4.x ou posterior. Atualize para uma versão secundária mais recente se necessário.

O que acontece quando executo ALTER TABLE?

O comando ALTER TABLE fecha e reabre todas as Regions da tabela. O impacto é mínimo. Se sua aplicação exigir latência de leitura em milissegundos, agende esta operação fora do horário de pico.

Por que minha gravação falha com um erro de limite de tamanho de coluna?

Erro:

com.alibaba.lindorm.client.exception.IllegalDataException: Column [xxx] is too big, max length is 2097152 bytes but has 7621168 bytes.

Causa: O tamanho máximo padrão da célula é 2 MB (2.097.152 bytes). Colunas VARBINARY não têm limite de tamanho. Para outros limites, consulte cotas e limites.

Resolução: Se a carga for baixa, aumente temporariamente o limite com o comando abaixo (não recomendado para produção):

ALTER TABLE <tablename> SET 'MAX_NONPK_LEN'='4194304';  -- unit: bytes

Respeite estes limites com base na memória do nó:

Quais são os métodos e considerações para exclusão de dados?

O LindormTable suporta dois métodos de exclusão:

• TRUNCATE TABLE: Limpa todos os dados de uma tabela imediatamente. Use TRUNCATE TABLE.

• Exclusão de linhas por chave primária: Exclui linhas específicas usando chaves primárias completas. Exclusões por intervalo não são suportadas; consulte primeiro a chave primária completa e depois exclua usando condições exatas.

Após a exclusão, se sua aplicação for sensível à latência de leitura, acione manualmente a compactação principal. Caso contrário, aguarde o próximo ciclo de compactação agendado.

Como verifique se os dados foram movidos para o cold storage?

Compare os resultados de duas consultas usando a mesma chave primária:

1. Execute uma consulta completa para recuperar todos os dados.

2. Execute uma consulta apenas de dados quentes usando um HINT.

Se ambas as consultas retornarem o mesmo resultado, os dados ainda estão no hot storage. Se diferirem e os dados estiverem ausentes na consulta de dados quentes, eles foram movidos para o cold storage.

Antes de consultar, verifique os tamanhos de cold storage e hot storage na página Visão geral da tabela no Lindorm Insight. Compare os tamanhos antes e depois do arquivamento.

Por que meus dados não foram movidos para o cold storage?

Consulte por que os dados não foram movidos para o cold storage após a compactação.

Causas comuns:

• Flush não realizado: Os dados devem ser descarregados (flushed) para o disco antes que a compactação possa arquivá-los. Execute flush primeiro.

• Acúmulo na compactação: Verifique Compaction queue length no monitoramento da instância em LindormTable metrics — cluster load. Se o valor permanecer acima de 0 e continuar crescendo, existe um acúmulo. Dimensione horizontalmente ou faça upgrade para resolver.

• Dados possuem timestamp: Dados com um timestamp personalizado ou especial podem não ser elegíveis para arquivamento no cold storage.

Por que uma consulta de índice secundário não retorna valores NULL?

Ao usar reordenação de chave primária ou índices de múltiplas colunas, o sistema ignora entradas de índice em que a primeira coluna não primária é NULL. Apenas linhas com valores reais (não NULL) nessa coluna aparecem na tabela de índice.

O que causa resultados de consulta inesperados?

Consulte motivos comuns pelos quais os resultados da consulta não correspondem às expectativas.

O que significa a métrica de token de cold storage?

O cold storage destina-se a dados arquivados acessados com pouca frequência; minimize as leituras nele. A métrica de token de cold storage rastreia a limitação de taxa para acesso ao cold storage. Uma contagem de tokens continuamente decrescente indica que algumas solicitações foram limitadas.

Quais são as configurações de monitoramento recomendadas?

Consulte melhores práticas de monitoramento e alerta.

Perguntas frequentes sobre monitoramento no nível de tabela

Por que as métricas de monitoramento não atualize após renomear uma tabela?

Apenas Wide Table Engine > Table-level monitoring reflete a renomeação. Outras métricas, como as de nível de sistema, permanecem inalteradas.

Por que não consigo encontrar minha tabela no monitoramento de tabelas?

Estenda o intervalo de tempo (por exemplo, de 1 hora para 24 horas). Se a tabela ainda não aparecer, ela não teve atividade de leitura ou gravação durante esse período, logo nenhum dado de monitoramento foi relatado.

Qual é a diferença entre tabelas SQL e tabelas HBase?

Tabelas SQL possuem esquemas fixos com nomes e tipos de colunas definidos na criação e suportam apenas operações SQL. Tabelas HBase não possuem esquema fixo, suportam colunas dinâmicas e são escritas por meio de APIs HBase (embora possam ser lidas via SQL).

Para verifique se uma tabela é SQL ou HBase:

SHOW TABLE VARIABLES FROM <database_name> LIKE 'IS_HBASE_LIKE';

• true: Tabela HBase

• false: Tabela SQL

O ApsaraDB for HBase Performance-enhanced Edition suporta SQL?

Sim. O ApsaraDB for HBase Performance-enhanced Edition usa o mecanismo LindormTable (compatível com HBase ou Cassandra) e suporta SQL. Conecte-se usando o Lindorm-cli:

./lindorm-cli -url jdbc:lindorm:table:url=http://ld-bp17j28j2y7pm****-proxy-lindorm-pub.lindorm.rds.aliyuncs.com:30060 -username xxx -password xxx
# After connecting
lindorm:default> show databases;

O que devo saber antes de usar um cliente HBase open-source?

Clientes HBase open-source não suportam autenticação ou implantações multizona. Antes de se conectar ao LindormTable, instale o SDK do HBase.

Como ative a exclusão em lote?

-- Enable batch deletion
ALTER SYSTEM SET `lindorm.allow.range.delete`=TRUE;
-- Verify the setting
SHOW SYSTEM variables LIKE 'lindorm.allow.range.delete';

Como ative a atualização em lote ou por que ocorre o erro "Update's WHERE clause can only contain PK columns"?

Causa: Atualizações de linha única estão ativadas por padrão. Atualizações em lote estão desativadas.

Resolução: Ative as atualizações em lote usando SQL.

-- Enable batch update
ALTER SYSTEM SET `lindorm.allow.batch.update`=TRUE;
-- Verify the setting
SHOW SYSTEM variables LIKE 'lindorm.allow.batch.update';

Se a atualização em lote de uma tabela com índice secundário causar timeouts de consulta, consulte timeout de consulta após atualização em lote com índice secundário.

Timeout de consulta após exclusão em lote

Causa: O LindormTable prioriza o throughput de gravação. O DELETE escreve um marcador de exclusão em vez de remover os dados imediatamente. Os dados excluídos ficam ocultos das leituras, mas permanecem fisicamente no disco até a compactação. Exclusões em grande escala acumulam muitos marcadores de exclusão. Por exemplo, uma varredura por intervalo com 100.000 linhas válidas, juntamente com 1.000.000 de linhas excluídas e 1.000.000 de marcadores de exclusão, força o sistema a varrer aproximadamente 2.100.000 registros para retornar resultados válidos, aumentando significativamente a latência de leitura.

Resolução: Execute a compactação para remover permanentemente marcadores de exclusão e dados expirados. A compactação pode ser acionada automática ou manualmente. Consulte como funciona a compactação.

Timeout de consulta após atualização em lote com índice secundário

Causa: Um índice secundário é uma tabela de índice separada. Sua chave primária é [indexed column value] + [primary table RowKey]. Quando registros da tabela primária são atualizados, o LindormTable exclui automaticamente entradas antigas do índice (escrevendo marcadores de exclusão) e insere novas. Atualizações em grande escala em colunas indexadas acumulam muitos marcadores de exclusão na tabela de índice. Consultas que usam esse índice precisam varrer todos os RowKeys para o valor alvo e pular entradas excluídas. Se poucas entradas forem válidas, a sobrecarga de varredura aumenta drasticamente. Por exemplo, uma varredura por intervalo com 100.000 linhas válidas, juntamente com 1.000.000 de linhas excluídas e 1.000.000 de marcadores de exclusão, força o sistema a varrer aproximadamente 2.100.000 registros para retornar resultados válidos.

Resolução: Execute a compactação para remover permanentemente marcadores de exclusão e dados expirados. A compactação pode ser acionada automática ou manualmente. Consulte como funciona a compactação.