Lindorm:Résumé des problèmes

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

Vérifiez les points suivants :

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

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

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

• Connexion ECS : Consultez la section 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 ? Quelle est sa durée ?

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 à faible charge sont peu affectées. Les instances à charge élevée 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 le compactage ?

Le compactage nettoie les données expirées (TTL), supprime les marqueurs de suppression, archive les données chaudes et froides, et compresse les données afin de réduire l'utilisation du stockage.

À quelle fréquence le compactage s'exécute-t-il automatiquement ?

L'intervalle par défaut est de 20 jours. Dans les scénarios 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 le compactage ?

Oui. Utilisez l'instruction SQL execute major compaction.

Quel est l'impact métier du compactage ?

Le compactage s'exécute sur plusieurs threads. Le nombre de threads dépend de la spécification de l'instance : les spécifications plus élevées traitent les données plus rapidement. Les spécifications inférieures peuvent mettre en file d'attente de nombreuses tâches. Lorsque le processeur est disponible, le compactage 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 du compactage, affichez 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 augmentation continue ni stagnation pendant plus d'un jour.

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

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

Si l'utilisation du processeur 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 compactage présente un important retard, le nettoyage des données accuse un décalage 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 :

   • Processeur 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.

   • Processeur 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 le compactage ou réduisez l'intervalle de compactage. 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 un compactage majeur.

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 du compactage.

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 du compactage. 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, le compactage 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 de la partition dépasse 1 000 (le système détecte le point chaud et décide s'il doit effectuer une division)

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 lorsque j'exécute 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 par défaut d'une cellule 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

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

Quelles sont les méthodes et les précautions à prendre 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 en utilisant les clés primaires complètes. Les suppressions par plage ne sont pas prises en charge : interrogez d'abord la clé primaire complète, puis effectuez la suppression en utilisant des conditions exactes.

Après la suppression, si votre application est sensible à la latence de lecture, déclenchez manuellement un compactage majeur. Sinon, attendez le prochain cycle de compactage 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 cold storage et 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 section pourquoi les données n'ont pas été déplacées vers le stockage froid après le compactage.

Causes courantes :

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

• Retard de compactage : 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 retard existe. Effectuez un scale out ou une mise à niveau pour résoudre le problème.

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

Pourquoi une requête d'index secondaire ne renvoie-t-elle pas de 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 de 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 à partir de 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 avoir renommé une table ?

Seuls les éléments Wide Table Engine > Table-level monitoring reflètent 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, cela signifie 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 ont des schémas fixes avec des noms et types de colonnes définis lors de la création, et prennent en charge uniquement 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 lot ?

-- 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 lot, 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 lot sont désactivées.

Résolution : Activez les mises à jour par lot à 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 lot d'une table avec un index secondaire provoque des délais d'expiration de requête, consultez la section délai d'expiration de requête après mise à jour par lot avec un index secondaire.

Délai d'expiration de requête après suppression par lot

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'au compactage. Les suppressions à grande échelle accumulent de nombreux marqueurs de suppression. Par exemple, un scan de plage avec 100 000 lignes valides, accompagné de 1 000 000 de lignes supprimées et de 1 000 000 de marqueurs de suppression, oblige le système à scanner environ 2 100 000 enregistrements pour renvoyer des résultats valides, ce qui augmente considérablement la latence de lecture.

Résolution : Exécutez un compactage pour supprimer définitivement les marqueurs de suppression et les données expirées. Le compactage peut être déclenché automatiquement ou manuellement — consultez la section fonctionnement du compactage.

Délai d'expiration de requête après mise à jour par lot 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, accompagné de 1 000 000 de lignes supprimées et de 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 un compactage pour supprimer définitivement les marqueurs de suppression et les données expirées. Le compactage peut être déclenché automatiquement ou manuellement — consultez la section fonctionnement du compactage.