Lindorm:Résumé des problèmes

Pourquoi Lindorm-cli échoue-t-il à se connecter à LindormTable ?

Vérifiez chaque point suivant :

• Connexion au réseau public : Obtenez une adresse IP publique et ajoutez-la à la liste d'autorisation Lindorm.

• Proxy ou VPN : Ajoutez l'adresse IP du proxy à la liste d'autorisation.

• Disponibilité du port : Testez la connectivité à l'aide de telnet.

• Connexion ECS : Consultez la rubrique Problèmes de connexion Lindorm et solutions.

Quels sont les numéros de port courants pour LindormTable ?

Quel est l'impact d'une mise à jour mineure de version ? Combien de temps cela prend-il ?

Une mise à jour mineure de version effectue un redémarrage progressif, nœud par nœud. Lors de chaque redémarrage, les Regions passent brièvement hors ligne, puis reviennent en ligne. Après la mise à jour, le système rééquilibre automatiquement la charge.

Impact : Les instances faiblement chargées sont peu affectées. Les instances fortement chargées ou sensibles à la latence peuvent subir de brèves interruptions. Planifiez les mises à jour pendant les heures creuses.

Durée : 5 à 30 minutes par nœud, selon le nombre de Regions et la charge actuelle.

À quoi sert la compaction ?

La compaction nettoie les données expirées (TTL, time-to-live), supprime les marqueurs de suppression, archive les données chaudes et froides, et compresse les données pour réduire l'utilisation du stockage.

À quelle fréquence la compaction s'exécute-t-elle automatiquement ?

L'intervalle par défaut est de 20 jours. Dans les scénarios utilisant le TTL (time-to-live), la valeur par défaut est min(TTL value, 20 days).

Pour modifier l'intervalle, utilisez l'une des méthodes suivantes :

• SQL : Exécutez ALTER TABLE <tableName> SET 'COMPACTION_MAJOR_PERIOD'='172800000'; (unité : millisecondes). Cet exemple définit l'intervalle sur 2 jours (172 800 000 ms).

• Lindorm Insight : Dans le système de gestion de cluster (Lindorm Insight), utilisez la gestion des modifications de table pour modifier la Compaction period.

Puis-je déclencher manuellement la compaction ?

Oui. Utilisez l'instruction SQL execute major compaction.

Quel est l'impact métier de la compaction ?

La compaction s'exécute sur plusieurs threads. Le nombre de threads dépend de la spécification de l'instance : plus la spécification est élevée, plus le traitement est rapide. Les spécifications inférieures peuvent mettre en file d'attente de nombreuses tâches. Lorsque le CPU est disponible, la compaction améliore les performances en lecture et libère de l'espace de stockage tout ayant un impact minimal sur le débit d'écriture.

Pour vérifier l'état de la compaction, consultez la Compaction queue length sous LindormTable metrics — cluster load dans la surveillance de l'instance :

• Normal : La valeur diminue régulièrement, ou augmente périodiquement puis chute, sans augmenter continuellement ni rester stable pendant plus d'un jour.

• Anormal : La valeur augmente continuellement ou reste stable pendant plus d'un jour.

Si l'utilisation du CPU est inférieure à 40 % : LindormTable 2.6.5 et versions ultérieures ajustent automatiquement les paramètres de compaction. Mettez à jour vers une version mineure plus récente pour bénéficier de ce comportement.

Si l'utilisation du CPU dépasse 40 % : Ajoutez davantage de nœuds LindormTable.

Pourquoi le stockage continue-t-il d'augmenter même après avoir configuré le TTL ?

Cause : Si la file d'attente de compaction présente un important arriéré, le nettoyage des données prend du retard par rapport à l'expiration des données.

Résolution :

1. Vérifiez la Compaction queue length dans la surveillance de l'instance sous LindormTable metrics — cluster load.

2. Si la file d'attente est encombrée :

   • CPU inférieur à 40 % : Mettez à jour vers LindormTable 2.6.5 ou une version ultérieure pour bénéficier du réglage automatique des paramètres.

   • CPU supérieur à 40 % : Ajoutez davantage de nœuds LindormTable.

3. Si la file d'attente est vide mais que le stockage continue d'augmenter, la charge d'E/S peut être faible. Déclenchez manuellement la compaction ou réduisez l'intervalle de compaction. Par exemple, pour définir l'intervalle sur 2 jours : ALTER TABLE <tableName> SET 'COMPACTION_MAJOR_PERIOD'='172800000';

Comment réduire l'espace de stockage à l'aide de la compression ?

Définissez l'algorithme de compression de la table sur ZSTD et le codec sur INDEX, puis exécutez une compaction majeure.

SQL

Connectez-vous à l'aide de Lindorm-cli ou de Lindorm Insight et exécutez :

-- 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

Utilisez la gestion des modifications de table pour définir la compression sur ZSTD. Accédez ensuite à la page table Overview et faites défiler jusqu'en bas pour surveiller la progression de la compaction.

Suivez la progression via la Compaction queue length dans la surveillance de l'instance.

Que faire lorsque la capacité du disque est pleine ?

Effectuez l'une des actions suivantes :

• Augmentez la capacité du stockage chaud.

• Exécutez DROP TABLE pour supprimer les tables inutilisées et libérer immédiatement de l'espace.

• Exécutez TRUNCATE TABLE pour effacer toutes les données d'une table et libérer immédiatement de l'espace.

Pourquoi ne puis-je pas supprimer de données lorsque le disque est plein ?

Cause : LindormTable privilégie le débit d'écriture. Une opération DELETE ne supprime pas immédiatement les données ; elle écrit un marqueur de suppression qui masque les données des requêtes. La suppression physique n'a lieu que lors de la compaction. Lorsque le disque est plein, le système bloque toutes les écritures, y compris les marqueurs de suppression. Comme aucun marqueur de suppression ne peut être écrit, la compaction n'a rien à purger et ne peut pas libérer d'espace.

Résolution : Utilisez DROP TABLE ou TRUNCATE TABLE pour libérer immédiatement de l'espace, ou augmentez la capacité du stockage chaud.

LindormTable prend-il en charge la mise à l'échelle des nœuds ou de la capacité du disque ?

La modification du nombre de nœuds est une opération au niveau du moteur. La mise à l'échelle de la capacité du disque est une opération au niveau de l'instance.

Quelles unités utilisent les propriétés de table courantes ?

Comment configurer NUMREGIONS lors de la création d'une table ?

Si NUMREGIONS n'est pas spécifié, la table commence avec 1 partition. Comme point de départ, définissez NUMREGIONS sur number of server nodes × 4.

Les partitions se divisent automatiquement lorsque :

• Les données de la partition atteignent 8 Go, ou

• Le QPS combiné en lecture/écriture pour la partition dépasse 1 000 (le système détecte le point chaud et décide s'il faut diviser la partition)

Pour une meilleure auto-réparation des points chauds, utilisez LindormTable 2.4.x ou une version ultérieure. Mettez à jour vers une version mineure plus récente si nécessaire.

Que se passe-t-il lors de l'exécution de ALTER TABLE ?

ALTER TABLE ferme et rouvre toutes les Regions de la table. L'impact est minime. Si votre application nécessite une latence de lecture en millisecondes, planifiez cette opération pendant les heures creuses.

Pourquoi mon écriture échoue-t-elle avec une erreur de limite de taille de colonne ?

Erreur :

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

Cause : La taille maximale de cellule par défaut est de 2 Mo (2 097 152 octets). Les colonnes VARBINARY n'ont aucune limite de taille. Pour les autres limites, consultez les quotas et limites.

Résolution : Si la charge est faible, augmentez temporairement la limite avec (non recommandé pour la production) :

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

Respectez les limites suivantes en fonction de la mémoire du nœud :

Quelles sont les méthodes et les considérations pour la suppression de données ?

LindormTable prend en charge deux méthodes de suppression :

• TRUNCATE TABLE : Efface immédiatement toutes les données d'une table. Utilisez TRUNCATE TABLE.

• Suppression de lignes par clé primaire : Supprime des lignes spécifiques à l'aide de clés primaires complètes. Les suppressions par plage ne sont pas prises en charge : interrogez d'abord la clé primaire complète, puis supprimez en utilisant des conditions exactes.

Après la suppression, si votre application est sensible à la latence de lecture, déclenchez manuellement une compaction majeure. Sinon, attendez le prochain cycle de compaction planifié.

Comment vérifier que les données ont été déplacées vers le stockage froid ?

Comparez les résultats de deux requêtes utilisant la même clé primaire :

1. Exécutez une requête complète pour récupérer toutes les données.

2. Exécutez une requête limitée aux données chaudes à l'aide d'un HINT.

Si les deux requêtes renvoient le même résultat, les données se trouvent toujours dans le stockage chaud. Si elles diffèrent — et que les données sont absentes de la requête sur les données chaudes — les données ont été déplacées vers le stockage froid.

Avant d'interroger, vérifiez les tailles du cold storage et du hot storage sur la page table Overview dans Lindorm Insight. Comparez les tailles avant et après l'archivage.

Pourquoi mes données n'ont-elles pas été déplacées vers le stockage froid ?

Consultez la rubrique pourquoi les données n'ont pas été déplacées vers le stockage froid après la compaction.

Causes courantes :

• Flush non effectué : Les données doivent être vidées sur le disque avant que la compaction puisse les archiver. Exécutez d'abord flush.

• Arriéré de compaction : Vérifiez la Compaction queue length dans la surveillance de l'instance sous LindormTable metrics — cluster load. Si la valeur reste supérieure à 0 et continue d'augmenter, un arriéré existe. Mettez à l'échelle horizontalement ou mettez à niveau pour résoudre le problème.

• Données avec horodatage : Les données dotées d'un horodatage personnalisé ou spécial peuvent ne pas être éligibles à l'archivage dans le stockage froid.

Pourquoi l'instruction SHOW CREATE TABLE renvoie-t-elle une erreur de commande inconnue ?

Lorsque vous exécutez l'instruction SHOW CREATE TABLE, l'erreur suivante est renvoyée : java.lang.IllegalArgumentException: unknown command.

L'instruction SHOW CREATE TABLE s'applique uniquement au moteur de table large Lindorm. La version de Lindorm SQL doit être 2.6.3.2 ou ultérieure, et la version du moteur de table large doit être 2.6.2 ou ultérieure.

Assurez-vous que votre instance répond aux exigences de version précédentes. Si la version ne correspond pas, mettez à niveau l'instance et réessayez.

Pourquoi une requête d'index secondaire ne renvoie-t-elle pas les valeurs NULL ?

Lors de l'utilisation du réordonnancement de clé primaire ou d'index multicolumnes, le système ignore les entrées d'index où la première colonne non-clé primaire est NULL. Seules les lignes avec des valeurs réelles (non NULL) dans cette colonne apparaissent dans la table d'index.

Quelles sont les causes des résultats de requête inattendus ?

Consultez les raisons courantes pour lesquelles les résultats de requête ne correspondent pas aux attentes.

Que signifie la métrique de jeton de stockage froid ?

Le stockage froid est destiné aux données archivées rarement consultées ; minimisez les lectures depuis celui-ci. La métrique de jeton de stockage froid suit la limitation de débit pour l'accès au stockage froid. Une diminution continue du nombre de jetons signifie que certaines requêtes ont été limitées.

Quelles sont les configurations de surveillance recommandées ?

Consultez les bonnes pratiques de surveillance et d'alerte.

FAQ sur la surveillance au niveau de la table

Pourquoi les métriques de surveillance ne se mettent-elles pas à jour après le renommage d'une table ?

Seule la section Wide Table Engine > Table-level monitoring reflète le renommage. Les autres métriques, telles que les métriques au niveau du système, restent inchangées.

Pourquoi ne puis-je pas trouver ma table dans la surveillance des tables ?

Étendez la plage de temps (par exemple, de 1 heure à 24 heures). Si la table n'apparaît toujours pas, c'est qu'elle n'a eu aucune activité de lecture ou d'écriture durant cette période, donc aucune donnée de surveillance n'a été rapportée.

Quelle est la différence entre les tables SQL et les tables HBase ?

Les tables SQL possèdent des schémas fixes avec des noms et types de colonnes définis à la création, et ne prennent en charge que les opérations SQL. Les tables HBase n'ont pas de schéma fixe, prennent en charge les colonnes dynamiques et sont écrites via les API HBase (bien qu'elles puissent être lues via SQL).

Pour vérifier si une table est une table SQL ou une table HBase :

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

• true : Table HBase

• false : Table SQL

ApsaraDB for HBase Performance-enhanced Edition prend-il en charge SQL ?

Oui. ApsaraDB for HBase Performance-enhanced Edition utilise le moteur LindormTable (compatible avec HBase ou Cassandra) et prend en charge SQL. Connectez-vous à l'aide de 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;

Que dois-je savoir avant d'utiliser un client HBase open source ?

Les clients HBase open source ne prennent pas en charge l'authentification ni les déploiements multi-zones. Avant de vous connecter à LindormTable, installez le SDK HBase.

Comment activer la suppression par lots ?

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

Comment activer la mise à jour par lots, ou pourquoi l'erreur « Update's WHERE clause can only contain PK columns » se produit-elle ?

Cause : Les mises à jour sur une seule ligne sont activées par défaut. Les mises à jour par lots sont désactivées.

Résolution : Activez les mises à jour par lots à l'aide de SQL.

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

Si la mise à jour par lots d'une table avec un index secondaire provoque des expirations de requête, consultez la rubrique expiration de requête après mise à jour par lots avec un index secondaire.

Expiration de requête après suppression par lots

Cause : LindormTable privilégie le débit d'écriture. DELETE écrit un marqueur de suppression au lieu de supprimer immédiatement les données — les données supprimées sont masquées des lectures mais restent physiquement sur le disque jusqu'à la compaction. Les suppressions à grande échelle accumulent de nombreux marqueurs de suppression. Par exemple, un scan de plage avec 100 000 lignes valides aux côtés de 1 000 000 de lignes supprimées et 1 000 000 de marqueurs de suppression oblige le système à scanner environ 2 100 000 enregistrements pour renvoyer des résultats valides, augmentant considérablement la latence de lecture.

Résolution : Exécutez une compaction pour supprimer définitivement les marqueurs de suppression et les données expirées. La compaction peut être déclenchée automatiquement ou manuellement — consultez la rubrique fonctionnement de la compaction.

Expiration de requête après mise à jour par lots avec un index secondaire

Cause : Un index secondaire est une table d'index distincte. Sa clé primaire est [indexed column value] + [primary table RowKey]. Lorsque les enregistrements de la table principale sont mis à jour, LindormTable supprime automatiquement les anciennes entrées d'index (en écrivant des marqueurs de suppression) et insère de nouvelles entrées. Les mises à jour à grande échelle des colonnes indexées accumulent de nombreux marqueurs de suppression dans la table d'index. Les requêtes utilisant cet index doivent scanner tous les RowKeys pour la valeur cible et ignorer les entrées supprimées — si peu d'entrées sont valides, la charge de scan augmente fortement. Par exemple, un scan de plage avec 100 000 lignes valides aux côtés de 1 000 000 de lignes supprimées et 1 000 000 de marqueurs de suppression oblige le système à scanner environ 2 100 000 enregistrements pour renvoyer des résultats valides.

Résolution : Exécutez une compaction pour supprimer définitivement les marqueurs de suppression et les données expirées. La compaction peut être déclenchée automatiquement ou manuellement — consultez la rubrique fonctionnement de la compaction.