Partager via

Utiliser l'outil Apache HBase HBCK2

  • Article

Cet article vous explique comment utiliser l'outil HBase HBCK2. HBCK2 est l'outil de réparation des clusters Apache HBase.

Vue d'ensemble de HBCK2

HBCK2 est actuellement un outil simple qui ne fait qu'une chose à la fois. Dans hbase-2.x, le Master est l'arbitre final de tous les états. Ainsi, un principe général pour la plupart des commandes HBCK2 est de demander au Master d'effectuer toutes les réparations.

Un Master doit être opérationnel pour pouvoir exécuter des commandes HBCK2. HBCK1 a effectué une analyse et signalé votre cluster comme bon ou mauvais, mais HBCK2 est moins présomptueux. Dans hbase-2.x, l'opérateur détermine ce qui doit être résolu, puis utilise des outils, y compris HBCK2, pour effectuer des réparations.

Comparaison entre HBCK2 et HBCK1

HBCK2 est le successeur de HBCK, l'outil de réparation fourni avec hbase-1.x (également appelé HBCK1). Vous pouvez utiliser HBCK2 en lieu et place de HBCK1 pour effectuer des réparations sur des clusters hbase-2.x. HBCK1 ne doit pas être exécuté sur une installation hbase-2.x, car il peut causer des dommages. Sa fonctionnalité d'écriture (-fix) a été supprimée. Il peut rendre compte de l'état d'un cluster hbase-2.x, mais ses évaluations sont inexactes, car il ne comprend pas le fonctionnement interne d'un tel cluster.

HBCK2 ne fonctionne pas comme HBCK1, même dans les cas où les commandes portent des noms similaires dans les deux versions.

Obtenir HBCK2

Vous trouverez la version dans le répertoire de distribution HBase. Pour plus d'informations, consultez la page consacrée au téléchargements de HBase.

Interface utilisateur principale : le rapport HBCK

Une page de rapport HBCK ajoutée au Master dans la version 2.1.6 à /hbck.jsp, qui affiche la sortie de deux inspections exécutées par le Master suivant un intervalle. L’un est la sortie de CatalogJanitor chaque fois qu’il s’exécute. En cas de chevauchements ou de trous dans hbase:meta, CatalogJanitor énumère ce qu'il a trouvé. Un autre processus chore en arrière-plan compare le contenu de hbase:meta et du système de fichiers. Si une anomalie est détectée, il dépose une note dans sa section Rapport HBCK.

Pour exécuter CatalogJanitor, exécutez la commande dans l'interpréteur de commandes hbase : catalogjanitor_run.

Pour exécuter hbck chore, exécutez la commande dans l'interpréteur de commandes hbase : hbck_chore_run.

Les deux commandes ne prennent aucune entrée.

Exécuter HBCK2

Vous pouvez exécuter la commande hbck en la lançant au moyen du script $HBASE_HOME/bin/hbase. Par défaut, lorsque vous exécutez bin/hbase hbck, les outils HBCK1 intégrés sont exécutés. Pour exécuter HBCK2, vous devez pointer vers un fichier jar HBCK2 généré à l'aide de l'option -j, comme dans cet exemple :

hbase --config /etc/hbase/conf hbck -j ~/hbase-operator-tools/hbase-hbck2/target/hbase-hbck2-1.x.x-SNAPSHOT.jar

Cette commande imprime l'aide HBCK2, sans passer d'options ou d'arguments.

Commandes HBCK2

Notes

Testez ces commandes sur un cluster de test pour en comprendre les fonctionnalités avant de les exécuter dans un environnement de production

assigns [OPTIONS] <ENCODED_REGIONNAME/INPUTFILES_FOR_REGIONNAMES>... | -i <INPUT_FILE>...

Options :

  • -o,--override : remplace la propriété par une autre procédure.
  • -i,--inputFiles : prend un ou plusieurs noms de régions encodés.

Cette attribution raw peut être utilisée même pendant l'initialisation du Master (si l'indicateur -skip est spécifié). Elle contourne les coprocesseurs et transmet un ou plusieurs noms de régions encodés. de00010733901a05f5a2a3a382e27dd4 est un exemple de nom de région encodé d'espace utilisateur. Par exemple :

hbase --config /etc/hbase/conf hbck -j ~/hbase-operator-tools/hbase-hbck2/target/hbase-hbck2-1.x.x-SNAPSHOT.jar assigns de00010733901a05f5a2a3a382e27dd4

Il retourne les PID du AssignProcedures créé ou -1 si aucun n'a été créé. Si -i or --inputFiles est spécifié, il transmet un ou plusieurs noms de fichiers d'entrée. Chaque fichier contient des noms de région encodés, un par ligne. Par exemple :

hbase --config /etc/hbase/conf hbck -j ~/hbase-operator-tools/hbase-hbck2/target/hbase-hbck2-1.x.x-SNAPSHOT.jar assigns -i fileName1 fileName2

unassigns [OPTIONS] <ENCODED_REGIONNAME>...| -i <INPUT_FILE>...

Options :

  • -o,--override : remplace la propriété par une autre procédure.
  • -i,--inputFiles : prend un ou plusieurs fichiers d'entrée de noms encodés.

Cette annulation d'attribution raw peut être utilisée même pendant l'initialisation du Master (si l'indicateur -skip est spécifié). Elle contourne les coprocesseurs et transmet un ou plusieurs noms de régions encodés. de00010733901a05f5a2a3a382e27dd4 est un exemple de nom de région encodé d'espace de remplacement par l'utilisateur. Par exemple :

hbase --config /etc/hbase/conf hbck -j ~/hbase-operator-tools/hbase-hbck2/target/hbase-hbck2-1.x.x-SNAPSHOT.jar unassign de00010733901a05f5a2a3a382e27dd4

Il retourne les PID du UnassignProcedures créé ou -1 si aucun n'a été créé. Si -i or --inputFiles est spécifié, il transmet un ou plusieurs noms de fichiers d'entrée. Chaque fichier contient des noms de région encodés, un par ligne. Par exemple :

hbase --config /etc/hbase/conf hbck -j ~/hbase-operator-tools/hbase-hbck2/target/hbase-hbck2-1.x.x-SNAPSHOT.jar unassigns fileName1 -i fileName2

bypass [OPTIONS] <PID>...

Options :

  • -o,--override : remplacé si la procédure est en cours d'exécution ou bloquée.
  • -r,--recursive : contourne le parent et ses enfants. Cette option est lente et coûteuse.
  • -w,--lockWait : temps d'attente de quelques millisecondes la suppression. Valeur par défaut = 1.
  • -i,--inputFiles : prend un ou plusieurs fichiers d'entrée de PID

Il transmet un ou plusieurs PID de procédure pour passer à la fin de la procédure. Le parent de la procédure contournée passe à la fin. Les entités sont laissées dans un état incohérent et nécessitent des réparations manuelles. Un redémarrage Master peut être nécessaire pour supprimer les verrous qui sont encore conservés. Le contournement échoue si la procédure a des enfants. Ajoutez recursive si vous disposez uniquement d'un PID parent pour terminer le parent et les enfants. Cette option étant lente et dangereuse. Utilisez-la de manière sélective. Ne fonctionne pas toujours.

hbase --config /etc/hbase/conf hbck -j ~/hbase-operator-tools/hbase-hbck2/target/hbase-hbck2-1.x.x-SNAPSHOT.jar bypass <PID>

Si -i or --inputFiles est spécifié, transmettez un ou plusieurs noms de fichiers d’entrée. Chaque fichier contient des PID, un par ligne. Par exemple :

hbase --config /etc/hbase/conf hbck -j ~/hbase-operator-tools/hbase-hbck2/target/hbase-hbck2-1.x.x-SNAPSHOT.jar bypass -i fileName1 fileName2

reportMissingRegionsInMeta <NAMESPACE|NAMESPACE:TABLENAME>... | -i <INPUT_FILE>...

Option :

  • i,--inputFiles : prend un ou plusieurs fichiers d'entrée d'espace de noms ou de noms ou de noms de tables.

Utilisez cette option lorsque des régions sont manquantes dans hbase:meta, mais que des répertoires sont toujours présents dans HDFS. Cette commande n'est qu'une méthode de vérification. Elle vise à créer des rapports et n'effectue aucun correctif. Elle fournit une vue des régions (le cas échéant) qui seraient lues dans hbase:meta, regroupées par table ou espace de noms respectif.

Pour lire efficacement les régions dans meta, exécutez addFsRegionsMissingInMeta. Cette commande nécessite que hbase:meta soit en ligne. Pour chaque espace de noms/table passé en paramètre, elle effectue une comparaison entre les régions disponibles dans hbase:meta et les répertoires de régions existants sur HDFS. Les répertoires de régions qui ne correspondent pas sont imprimés groupés sous le nom de la table à laquelle ils se rapportent. Les tables sans régions manquantes affichent un message : « Aucune région manquante ». Si aucun espace de noms ou table n’est spécifié, il vérifie toutes les régions existantes.

Accepte une combinaison de plusieurs espaces de noms et tables. Les noms de tables doivent inclure la partie relative à l'espace de noms, même pour les tables de l'espace de noms par défaut. Sinon, ils imaginent une valeur d'espace de noms. Cet exemple déclenche des rapports de régions manquantes pour les tables table_1 et table_2, sous un espace de noms par défaut :

hbase --config /etc/hbase/conf hbck -j ~/hbase-operator-tools/hbase-hbck2/target/hbase-hbck2-1.x.x-SNAPSHOT.jar reportMissingRegionsInMeta default:table_1 default:table_2

Cet exemple déclenche un rapport de régions manquantes pour la table table_1 sous l'espace de noms par défaut et pour toutes les tables de l'espace de noms ns1 :

hbase --config /etc/hbase/conf hbck -j ~/hbase-operator-tools/hbase-hbck2/target/hbase-hbck2-1.x.x-SNAPSHOT.jar reportMissingRegionsInMeta default:table_1 ns1

Il renvoie une liste des régions manquantes pour chaque table passée en tant que paramètre ou pour chaque table sur les espaces de noms spécifiés en tant que paramètre. Si -i or --inputFiles est spécifié, il transmet un ou plusieurs noms de fichiers d'entrée. Chaque fichier contient des <NAMESPACE|NAMESPACE:TABLENAME>, un par ligne. Par exemple :

hbase --config /etc/hbase/conf hbck -j ~/hbase-operator-tools/hbase-hbck2/target/hbase-hbck2-1.x.x-SNAPSHOT.jar reportMissingRegionsInMeta -i fileName1 fileName2

addFsRegionsMissingInMeta <NAMESPACE|NAMESPACE:TABLENAME>... | -i <INPUT_FILE>...

Option :

  • -i,--inputFiles : prend un ou plusieurs fichiers d'entrée des noms de tables d'espaces de noms à utiliser lorsque des régions sont manquantes dans hbase:meta, mais que des répertoires demeurent présents dans HDFS. Nécessite la mise en ligne de hbase:meta.

Pour chaque nom de table passé en paramètre, il effectue la différence entre les régions disponibles dans hbase:meta et les répertoires de régions présents sur HDFS. Ensuite, pour les répertoires sans correspondance de hbase:meta, il lit le fichier de métadonnées regioninfo et crée à nouveau une région spécifique dans hbase:meta. Les régions sont recréées à l'état FERMÉ dans la table hbase:meta, mais pas dans le cache Masters. Elles ne sont pas attribuées non plus. Pour mettre ces régions en ligne, exécutez l'impression de la commande assigns de HBCK2 une fois cette exécution de commande terminée.

Si vous utilisez des versions hbase antérieures à 2.3.0, un redémarrage continu des HMasters est nécessaire avant l'exécution du jeu de sortie assigns. Cet exemple montre l'ajout des régions manquantes pour les tables tbl_1 dans l'espace de noms par défaut, de tbl_2 dans l'espace de noms n1 et pour toutes les tables de l'espace de noms n2 :

hbase --config /etc/hbase/conf hbck -j ~/hbase-operator-tools/hbase-hbck2/target/hbase-hbck2-1.x.x-SNAPSHOT.jar addFsRegionsMissingInMeta default:tbl_1 n1:tbl_2 n2

Il renvoie HBCK2 et une commande assigns avec toutes les régions réinsérées. Si -i or --inputFiles est spécifié, il transmet un ou plusieurs noms de fichiers d'entrée. Chaque fichier contient des <NAMESPACE|NAMESPACE:TABLENAME>, un par ligne. Par exemple :

hbase --config /etc/hbase/conf hbck -j ~/hbase-operator-tools/hbase-hbck2/target/hbase-hbck2-1.x.x-SNAPSHOT.jar addFsRegionsMissingInMeta -i fileName1 fileName2

extraRegionsInMeta <NAMESPACE|NAMESPACE:TABLENAME>... | -i <INPUT_FILE>...

Options :

  • -f, --fix : corrige méta en supprimant toutes les régions supplémentaires trouvées.
  • -i,--inputFiles : prend un ou plusieurs fichiers d'entrée d'espace de noms ou de noms ou de noms de tables.

Il signale les régions présentes sur hbase:meta, mais sans les répertoires associés sur le système de fichiers. Doit hbase:meta être en ligne. Pour chaque nom de table passé en paramètre, il effectue la différence entre les régions disponibles dans hbase:meta et les répertoires de régions figurant sur le système de fichiers spécifique. Les régions supplémentaires sont supprimées de Meta si l'option --fix est passée.

Notes

Avant de décider d'utiliser l'option --fix, il est utile de vérifier tout chevauchement entre les régions supplémentaires signalées et les régions valides existantes. Dans ce cas, alors extraRegionsInMeta --fix est la solution optimale. Sinon, la commande assigns est la solution la plus simple. Il recrée les répertoires des régions dans le système de fichiers, s'ils sont manquants.

Cet exemple déclenche des rapports de régions supplémentaires pour table_1 sous l'espace de noms par défaut et pour toutes les tables de l'espace de noms ns1 :

hbase --config /etc/hbase/conf hbck -j ~/hbase-operator-tools/hbase-hbck2/target/hbase-hbck2-1.x.x-SNAPSHOT.jar extraRegionsInMeta default:table_1 ns1

Cet exemple déclenche des rapports de régions supplémentaires pour table_1 sous l'espace de noms par défaut et pour toutes les tables de l'espace de noms ns1 avec l'option de correctif :

hbase --config /etc/hbase/conf hbck -j ~/hbase-operator-tools/hbase-hbck2/target/hbase-hbck2-1.x.x-SNAPSHOT.jar extraRegionsInMeta -f default:table_1 ns1

Il renvoie une liste des régions supplémentaires pour chaque table passée en tant que paramètre ou pour chaque table sur les espaces de noms spécifiés en tant que paramètre. Si -i or --inputFiles est spécifié, transmettez un ou plusieurs noms de fichiers d’entrée. Chaque fichier contient des <NAMESPACE|NAMESPACE:TABLENAME>, un par ligne. Par exemple :

hbase --config /etc/hbase/conf hbck -j ~/hbase-operator-tools/hbase-hbck2/target/hbase-hbck2-1.x.x-SNAPSHOT.jar extraRegionsInMeta -i fileName1 fileName2

fixMeta

Notes

Cela ne fonctionne pas bien avec HBase 2.1.6. Nous ne recommandons pas son utilisation sur un cluster HBase 2.1.6.

Effectuez une correction côté serveur d’un état mauvais ou incohérent dans hbase:meta. L'IU Master comporte un nouvel onglet de correspondance HBCK Report (qui permet de sauvegarder les rapports générés par l'exécution la plus récente de catalogjanitor) et un nouveau hbck chore.

Il est essentiel que hbase:meta soit d'abord assaini avant que vous ne procédiez à d'autres réparations. Il corrige holes et overlaps, créant des répertoires de régions (vides) dans HDFS pour correspondre aux régions ajoutées à hbase:meta.

Cette commande n'est pas identique à l'ancienne commande hbck1, qui porte un nom similaire. Elle agit sur les rapports générés par les dernières exécutions catalog_janitor et hbck chore. S'il n'y a rien à corriger, l'exécution est une boucle. Sinon, si l'interface utilisateur HBCK Report signale des problèmes, une exécution de fixMeta permet de les résoudre (hbase:meta).

hbase --config /etc/hbase/conf hbck -j ~/hbase-operator-tools/hbase-hbck2/target/hbase-hbck2-1.x.x-SNAPSHOT.jar fixMeta

generateMissingTableDescriptorFile <NAMESPACE:TABLENAME>

Cette commande essaie de corriger une table orpheline en générant un fichier de description de tables manquantes. Cette commande est sans incidence si le dossier de tables est manquant ou si .tableinfo est présent. (Nous ne remplaçons pas les descripteurs de tables existants.) Cette commande vérifie d'abord si .tableinfo est mis en cache dans HBase Master, auquel cas il récupère TableDescriptor en conséquence. Si TableDescriptor n'est pas mis en cache dans le Master, il crée un fichier .tableinfo par défaut avec les éléments suivants :

  • Nom de la table.
  • la liste de familles de colonnes déterminée en fonction du système de fichiers.
  • Les propriétés par défaut pour TableDescriptor et ColumnFamilyDescriptors. Si le fichier .tableinfo a été généré à l'aide de paramètres par défaut, veillez à cocher les propriétés de la famille de tables ou de colonnes ultérieurement. Cette commande n'entraîne aucune modification dans HBase. Elle écrit uniquement le nouveau fichier .tableinfo dans le système de fichiers. Pour les tables orphelines, par exemple, ServerCrashProcedures doivent être conservées. Il se peut que vous deviez corriger l'erreur après avoir généré les fichiers d'information sur les tables manquantes.
hbase --config /etc/hbase/conf hbck -j ~/hbase-operator-tools/hbase-hbck2/target/hbase-hbck2-1.x.x-SNAPSHOT.jar generateMissingTableDescriptorFile namespace:table_name

replication [OPTIONS] [<NAMESPACE:TABLENAME>... | -i <INPUT_FILE>...]

Options :

  • -f, --fix : résout les problèmes de réplication détectés.
  • -i,--inputFiles : prend un ou plusieurs fichiers d'entrée de noms de tables.

Il recherche les files d'attente de réplication non supprimées et les supprime si l'option --fix est passée. Il passe un nom de table pour vérifier s'il existe une barrière de réplication et la purge si --fix.

hbase --config /etc/hbase/conf hbck -j ~/hbase-operator-tools/hbase-hbck2/target/hbase-hbck2-1.x.x-SNAPSHOT.jar replication namespace:table_name

Si -i or --inputFiles est spécifié, il transmet un ou plusieurs noms de fichiers d'entrée. Chaque fichier contient des <TABLENAME>, un par ligne. Par exemple :

hbase --config /etc/hbase/conf hbck -j ~/hbase-operator-tools/hbase-hbck2/target/hbase-hbck2-1.x.x-SNAPSHOT.jar replication -i fileName1 fileName2

setRegionState [<ENCODED_REGIONNAME> <STATE> | -i <INPUT_FILE>...]

Option :

  • -i,--inputFiles : prend un ou plusieurs fichiers d'entrée de noms et d'états de régions encodés.

États régionaux possibles :

  • OFFLINE
  • OUVERTURE
  • OPEN
  • FERMETURE
  • CLOSED
  • FRACTIONNER
  • FRACTION
  • FAILED_OPEN
  • FAILED_CLOSE
  • FUSIONNER
  • FUSIONNÉ
  • SPLITTING_NEW
  • MERGING_NEW
  • ABNORMALLY_CLOSED

Avertissement

Cette option à risque ne doit être utilisée qu'en dernier recours.

Les exemples de scénarios incluent des annulations d'attribution ou des attributions qui ne peuvent pas évoluer, car la région est dans un état incohérent dans hbase:meta. Par exemple, la commande unassigns ne peut continuer que si une région a été transmise dans l'un des états suivants : FRACTIONNEMENT, FRACTION, FUSIONNER, OUVERT ou FERMETURE.

Avant de définir manuellement un état de région avec cette commande, vérifiez que cette région n'est pas gérée par une procédure en cours d'exécution, comme assign ou split. Vous pouvez obtenir une vue des procédures en cours d'exécution dans l'interpréteur de commandes hbase à l'aide de la commande list_procedures. Cet exemple montre comment définir la région de00010733901a05f5a2a3a382e27dd4 sur FERMETURE :

hbase --config /etc/hbase/conf hbck -j ~/hbase-operator-tools/hbase-hbck2/target/hbase-hbck2-1.x.x-SNAPSHOT.jar setRegionState de00010733901a05f5a2a3a382e27dd4 CLOSING

Elle renvoie 0 si l'état de la région a changé, et 1 si non. Si -i or --inputFiles est spécifié, transmettez un ou plusieurs noms de fichiers d’entrée. Chaque fichier contient des <ENCODED_REGIONNAME> <STATE>, un par ligne. Par exemple :

hbase --config /etc/hbase/conf hbck -j ~/hbase-operator-tools/hbase-hbck2/target/hbase-hbck2-1.x.x-SNAPSHOT.jar setRegionState -i fileName1 fileName2

setTableState [<TABLENAME> <STATE> | -i <INPUT_FILE>...]

Option :

  • -i,--inputFiles : prend un ou plusieurs fichiers d'entrée de noms et d'états de tables

Les états de tables possibles sont : ACTIVÉ, DÉSACTIVÉ, DÉSACTIVATION et ACTIVATION.

Pour lire l'état de table actuel, dans l'interpréteur de commandes hbase, exécutez :

hbase> get 'hbase:meta', '<TABLENAME>', 'table:state'

une valeur de x08x00 == ENABLED, x08x01 == DISABLED, etc. Cela peut également exécuter describe <TABLENAME> à l'invite de l'interpréteur de commandes. Cet exemple montre l'utilisateur de nom de table ACTIVÉ :

hbase --config /etc/hbase/conf hbck -j ~/hbase-operator-tools/hbase-hbck2/target/hbase-hbck2-1.x.x-SNAPSHOT.jar setTableState users ENABLED

Il renvoie l'état précédent de la table. Si -i or --inputFiles est spécifié, il transmet un ou plusieurs noms de fichiers d'entrée. Chaque fichier contient des <TABLENAME> <STATE>, un par ligne. Par exemple :

hbase --config /etc/hbase/conf hbck -j ~/hbase-operator-tools/hbase-hbck2/target/hbase-hbck2-1.x.x-SNAPSHOT.jar setTableState -i fileName1 fileName2

scheduleRecoveries <SERVERNAME>... | -i <INPUT_FILE>...

Option :

  • -i,--inputFiles :prend un ou plusieurs fichiers d'entrée de noms de serveurs.

Planifiez ServerCrashProcedure(SCP) pour une liste de RegionServers. Mettez en forme le nom du serveur en tant que <HOSTNAME>,<PORT>,<STARTCODE>. (Voir l'interface utilisateur/les journaux d'activité HBase.)

Cet exemple utilise RegionServer a.example.org, 29100,1540348649479 :

hbase --config /etc/hbase/conf hbck -j ~/hbase-operator-tools/hbase-hbck2/target/hbase-hbck2-1.x.x-SNAPSHOT.jar scheduleRecoveries a.example.org,29100,1540348649479

Il renvoie les PID de ServerCrashProcedures créé ou -1 si aucune procédure n'a été créée. (Consultez les journaux d'activité Master pour savoir pourquoi l'opération échoue.) La prise en charge des commandes est ajoutée dans les versions 2.0.3, 2.1.2, 2.2.0 ou ultérieures de HBase. Si -i or --inputFiles est spécifié, il transmet un ou plusieurs noms de fichiers d'entrée. Chaque fichier contient des <SERVERNAME>, un par ligne. Par exemple :

hbase --config /etc/hbase/conf hbck -j ~/hbase-operator-tools/hbase-hbck2/target/hbase-hbck2-1.x.x-SNAPSHOT.jar scheduleRecoveries -i fileName1 fileName2

Corriger des problèmes

Cette section vous aide à résoudre les problèmes courants.

Principes généraux

Lorsque vous effectuez une réparation, assurez-vous d'abord que hbase:meta est cohérent avant de corriger à tout autre type de problème, tel qu'un écart par rapport au système de fichiers. Les écarts dans le système de fichiers ou des problèmes d'attribution doivent être résolus une fois que hbase:meta a été mis dans l'ordre. En cas de problèmes avec hbase:meta, le Master ne peut pas effectuer les placements appropriés lors de l'adoption de données de systèmes de fichiers orphelins, ni procéder à l'attribution de régions.

Une région ne peut pas être attribuée si elle est à l'état FERMETURE (ou l'inverse : une région ne peut pas faire l'objet d'une annulation d'attribution si elle est à l'état OUVERTURE) sans d'abord passer par l'état FERMÉ. Les régions doivent toujours passer de l'état FERMÉ à OUVERTURE, puis OUVERT, et ensuite de l'état FERMÉ, à FERMETURE.

Lorsque vous effectuez une réparation, corrigez les tables une par une.

Si une table est à l'état DÉSACTIVÉ, vous ne pouvez pas attribuer une région. Dans les journaux d’activité Master, vous voyez que les rapports Master ont été ignorés, car la table est DÉSACTIVÉE. Vous pouvez attribuer une région, car elle est actuellement à l'état OUVERTURE et vous souhaitez qu'elle soit à l'état FERMÉ afin d'être en harmonie avec l'état DÉSACTIVÉ de la table. Dans ce cas, vous pouvez temporairement définir l'état de la table sur ACTIVÉ, afin de pouvoir procéder à l'attribution. Ensuite, vous la réattribuez après l'instruction d'annulation d'attribution. HBCK2 vous permet d'effectuer ce changement. Consultez la sortie de l’utilisation de HBCK2.

Attribuer ou annuler l'attribution

En règle générale, lors de l'attribution, le Master persiste jusqu'à ce que l'opération réussisse. Une attribution applique un verrou exclusif sur la région. Cela empêche l'exécution d'une attribution ou d'une annulation d'attribution simultanée. Une attribution sur une région verrouillée attend que le verrou soit libéré avant de continuer.

Master startup cannot progress, in holding-pattern until region online :

2018-10-01 22:07:42,792 WARN org.apache.hadoop.hbase.master.HMaster: hbase:meta,1.1588230740 isn't online; state={1588230740 state=CLOSING, ts=1538456302300, server=ve1017.example.org,22101,1538449648131}; ServerCrashProcedures=true. Master startup cannot progress, in holding-pattern until region online.

Le Master ne peut pas continuer le démarrage, car il n'existe aucune procédure à attribuer hbase:meta (ou hbase:namespace). Pour en injecter un, utilisez l’outil HBCK2 :

hbase --config /etc/hbase/conf hbck -j ~/hbase-operator-tools/hbase-hbck2/target/hbase-hbck2-1.x.x-SNAPSHOT.jar assigns -skip 1588230740

Dans cet exemple, 1588230740 est le nom encodé de la région hbase:meta. Ignorez l'option -skip pour empêcher HBCK2 d'effectuer une vérification de version sur le Master distant. Si le Master distant n'est pas opérationnel, la vérification de version renvoie Master is initializing response ou PleaseHoldException et annule la tentative d'attribution. La commande -skip empêche la vérification de version et applique l'attribution planifiée.

La même chose peut se produire pour la table système hbase:namespace. Recherchez le nom de région encodé de la région hbase:namespace et procédez comme nous l'avons fait pour hbase:meta. Dans ce dernier cas, le Master imprime en fait un message utile similaire à l'exemple ci-dessous :

2019-07-09 22:08:38,966 WARN  [master/localhost:16000:becomeActiveMaster] master.HMaster: hbase:namespace,,1562733904278.9559cf72b8e81e1291c626a8e781a6ae. isn't online; state={9559cf72b8e81e1291c626a8e781a6ae state=CLOSED, ts=1562735318897, server=null}; ServerCrashProcedures=true. Master startup cannot progress, in holding-pattern until region onlined.

Pour planifier une attribution pour la table hbase:namespace notée dans la ligne du journal d'activité précédent :

hbase --config /etc/hbase/conf hbck -j ~/hbase-operator-tools/hbase-hbck2/target/hbase-hbck2-1.x.x-SNAPSHOT.jar -skip assigns 9559cf72b8e81e1291c626a8e781a6ae

Transmettez le nom encodé de la région d'espace de noms. (Le nom encodé diffère selon le déploiement.)

Régions manquantes dans hbase :région meta/restauration de table/régénération

Exceptionnellement, des régions de tables ont été supprimées de la table hbase:meta. Le triage sur ces cas a révélé qu'ils étaient induits par l'opérateur. Les utilisateurs ont exécuté l'outil HBCK1 OfflineMetaRepair obsolète sur un cluster HBCK2. OfflineMetaRepair est un outil bien connu pour résoudre les problèmes liés à la table hbase:meta sur les versions HBase 1.x. La version d'origine n'étant pas compatible avec HBase 2.x ou les versions ultérieures, elle a subi quelques ajustements. Dans des situations extrêmes, l'outil peut désormais être exécuté via HBCK2.

Dans la plupart de ces cas, des régions finissent par échouer de façon aléatoire dans hbase:meta, mais hbase peut toujours être opérationnel. Dans de telles situations, ce problème peut être résolu avec le Master en ligne, à l'aide de la commande addFsRegionsMissingInMeta dans HBCK2. Cette commande entraîne moins de perturbations sur hbase qu'une régénération complète hbase:meta, qui sera abordée ultérieurement. Il peut être utilisé même pour récupérer la région de table d'espace de noms.

Régions supplémentaires dans hbase :région meta/restauration de table/régénération

Il peut également arriver que des régions de tables aient été supprimées dans le système de fichiers, mais qu'elles aient toujours des entrées associées sur la table hbase:meta. Cela peut être dû à des problèmes de fractionnement, aux erreurs liées à des opérations manuelles (comme la suppression/le déplacement manuel du répertoire de la région), ou même à des problèmes de perte de données d'informations meta, comme HBASE-21843.

Ce problème peut être résolu avec le Master en ligne, à l'aide de la commande extraRegionsInMeta --fix dans HBCK2. Cette commande entraîne moins de perturbations sur hbase qu'une régénération complète hbase:meta, qui sera abordée ultérieurement. Elle est également utile lorsque cela se produit sur des versions qui ne prennent pas en charge l'option fixMeta HBCK2 (toute version antérieure à 2.0.6, 2.1.6, 2.2.1, 2.3.0 ou 3.0.0).

Recette de régénération hbase:meta en ligne

Si le niveau de corruption de hbase:meta n'est pas trop critique, hbase est toujours en mesure de le mettre en ligne. Même si la région d'espace de noms fait partie des régions manquantes, il est possible d'analyser hbase:meta pendant la période d'initialisation, où le Master attend que l'espace de noms soit attribué. Pour vérifier cette situation, une commande d'analyse hbase:meta peut être exécutée. Si elle n'expire pas ou si elle affiche des erreurs, le hbase:meta est en ligne :

echo "scan 'hbase:meta', {COLUMN=>'info:regioninfo'}" | hbase shell

HBCK2 addFsRegionsMissingInMeta peut être utilisé si le message n’affiche aucune erreur. Elle lit les informations de métadonnées de région disponibles dans les répertoires de région FS afin de recréer des régions dans hbase:meta. Étant donné qu'elle peut s'exécuter avec hbase partiellement opérationnel, elle tente de désactiver les tables en ligne qui sont affectées par le problème signalé, puis lit les régions dans hbase:meta. Elle peut vérifier des tables/espaces de noms spécifiques ou toutes les tables de tous les espaces de noms. Cet exemple montre l'ajout des régions manquantes pour les tables tbl_1 dans l'espace de noms par défaut, de tbl_2 dans l'espace de noms n1 et pour toutes les tables de l'espace de noms n2 :

hbase --config /etc/hbase/conf hbck -j ~/hbase-operator-tools/hbase-hbck2/target/hbase-hbck2-1.x.x-SNAPSHOT.jar addFsRegionsMissingInMeta default:tbl_1 n1:tbl_2 n2

Comme il fonctionne indépendamment du Master, une fois qu'il s'est achevé avec succès, d'autres étapes sont nécessaires pour que les régions lues soient effectivement attribuées. Ces messages sont répertoriés comme suit :

  • addFsRegionsMissingInMeta génère une commande assigns avec toutes les régions qui ont été lues. Cette commande doit être exécutée ultérieurement. Copiez-la donc et enregistrez-la pour des raisons pratiques.
  • Pour les versions HBase antérieures à la version 2.3.0, une fois que addFsRegionsMissingInMeta est terminé et que la sortie a été enregistrée, redémarrez tous les HBaseMasters en cours d'exécution.

Une fois que les Masters ont été redémarrés et que hbase:meta est déjà en ligne (vérifiez si l'interface utilisateur web est accessible), exécutez la commande d'attribution à partir de la sortie addFsRegionsMissingInMeta enregistrée précédemment.

Notes

Si la région d'espace de noms fait partie des régions manquantes, vous devez ajouter l'indicateur --skip au début de la commande d'attribution renvoyée.

Si un cluster subit une perte catastrophique de la table hbase:meta, une régénération approximative est possible à l'aide de la recette suivante. Dans le plan, nous arrêtons le cluster. Exécutez l'outil HBCK2 OfflineMetaRepair, qui lit les répertoires et les métadonnées déposés dans le système de fichiers et s'efforce au mieux de régénérer une table hbase:met viable. Redémarrez votre cluster. Injectez une attribution pour mettre la table d'espace de noms système en ligne. Pour finir, réattribuez les tables d'espaces utilisateur que vous souhaitez activer. (Le hbase:meta régénéré crée une table avec toutes les tables hors connexion et aucune région attribuée.)

Recette de reconstruction détaillée

Notes

Utilisez cette option uniquement comme dernier recours. Nous ne le recommandons pas.

  • Arrêtez le cluster.

  • Exécutez la commande regénération hbase:meta à partir de HBCK2. Cette commande met de côté le hbase:meta d'origine et met en place un nouvellement régénéré. Cet exemple montre comment exécuter l'outil. Il ajoute l'indicateur -details afin que l'outil vide les informations sur les régions qu'il trouve dans HDFS :

    hbase --config /etc/hbase/conf -j ~/hbase-operator-tools/hbase-hbck2/target/hbase-hbck2-1.x.x-SNAPSHOT.jar org.apache.hbase.hbck1.OfflineMetaRepair -details

  • Démarrez le cluster. Il ne démarre pas entièrement. Il est bloqué, car la table d’espace de noms n’est pas en ligne et il n’existe aucune procédure d’attribution dans le magasin de procédures pour cette éventualité. Le journal HBase Master affiche cet état. Cet exemple montre ce qu'il consigne :

    2019-07-10 18:30:51,090 WARN  [master/localhost:16000:becomeActiveMaster] master.HMaster: hbase:namespace,,1562808216225.725a0fe6c2c869d3d0a9ed82bfa80fa3. isn't online; state={725a0fe6c2c869d3d0a9ed82bfa80fa3 state=CLOSED, ts=1562808619952, server=null}; ServerCrashProcedures=false. Master startup can't progress, in holding-pattern until region onlined.

    Pour attribuer la région de table d’espace de noms, vous ne pouvez pas utiliser l’interpréteur de commandes. Si vous utilisez l'interpréteur de commandes, il échoue avec PleaseHoldException, car le Master n'est pas encore opérationnel. (Il attend que la table d'espace de noms soit mise en ligne pour devenir opérationnel.) Vous devez utiliser la commande d'attribution HBCK2. Pour l’attribuer, vous avez besoin du nom encodé de l’espace de noms. Il s’affiche dans le journal entre guillemets. Dans ce cas, il s'agit de 725a0fe6c2c869d3d0a9ed82bfa80fa3. Vous devez passer la commande -skip pour ignorer la vérification de version Master. (Sans cela, votre appel HBCK2 déclenche le PleaseHoldException, car le Master n'est pas encore opérationnel.) Cet exemple montre comment ajouter une attribution de la table d'espace de noms :

    hbase --config /etc/hbase/conf hbck -j ~/hbase-operator-tools/hbase-hbck2/target/hbase-hbck2-1.x.x-SNAPSHOT.jar -skip assigns 725a0fe6c2c869d3d0a9ed82bfa80fa3

    Si l'appel renvoie la sortie Connection refused, le Master est-il opérationnel ? Le Master s'arrête au bout d'un certain temps s'il ne peut pas s'initialiser. Redémarrez simplement le cluster/Master et réexécutez la commande d'attribution.

  • Lorsque les attributions s'exécutent correctement, la sortie est similaire à l'exemple suivant. Le 48 à la fin est le PID de la planification de procédure d'attribution. Si le PID renvoyé est -1, cela signifie que le démarrage du Master n'a pas suffisamment progressé. Veuillez donc réessayer. Ou bien, le nom de la région encodé peut être incorrect. Vérifiez donc ce problème.

    hbase --config /etc/hbase/conf hbck -j ~/hbase-operator-tools/hbase-hbck2/target/hbase-hbck2-1.x.x-SNAPSHOT.jar -skip assigns 725a0fe6c2c869d3d0a9ed82bfa80fa3

    18:40:43.817 [main] WARN  org.apache.hadoop.util.NativeCodeLoader - Unable to load native-hadoop library for your platform... using builtin-java classes where applicable
18:40:44.315 [main] INFO  org.apache.hbase.HBCK2 - hbck sufpport check skipped
[48]

  • Consultez les journaux Master. Le Master aurait dû apparaître. Vous voyez que l’exécution de PID=48 a réussi. Recherchez une ligne de ce type pour vérifier que le lancement du Master a été effectué avec succès :

    master.HMaster: Master has completed initialization 132.515sec

    L’affichage peut prendre un certain temps.

    La reconstruction de hbase:meta ajoute les tables utilisateur à l’état DÉSACTIVÉ et les régions en mode FERMÉ. Réactivez les tables via l'interpréteur de commandes pour remettre toutes les régions de table en ligne. Faites-le une par une ou consultez la commande Tout activer « .* » pour activer toutes les tables en une seule fois.

    Des modifications sont manquantes dans le meta de régénération. Il peut nécessiter des réparations et des nettoyages ultérieurs en utilisant les fonctionnalités décrites plus haut dans cet article.

Fichiers de référence supprimés, fichier hbase.version manquant et fichiers endommagés

HBCK2 peut vérifier les références suspendues et les fichiers corrompus. Vous pouvez lui demander de mettre de côté les fichiers incorrects, ce qui peut s'avérer nécessaire pour surmonter les difficultés rencontrées par les régions qui ne se connectent pas ou dont les lectures échouent. Consultez la commande système de fichiers dans la liste HBCK2. Passez un ou plusieurs noms de table (ou utilisez none pour cocher toutes les tables). Les fichiers incorrects sont signalés. Passez l'option --fix permettant d'effectuer des réparations.

Redémarrage de la procédure

En dernier recours, si le Master connaît des perturbations et que toutes les tentatives de réparation n'aboutissent qu'à des verrous irréalisables ou à des procédures qui ne peuvent pas se terminer, ou si l'ensemble de MasterProcWALs s'accroît de façon illimitée, il est possible de faire table rase de l'état Master. Déplacez le répertoire /hbase/MasterProcWALs/ sous votre installation HBase et redémarrez le processus Master. Il revient sous la forme d’un format tabulaire sans mémoire.

Si, au moment de l'effacement, toutes les régions ont été attribuées ou déconnectées de manière satisfaisante, au redémarrage du Master, celui-ci doit reprendre et continuer comme si de rien n'était. Toutefois, si des régions étaient en transition à ce moment, l'opérateur doit intervenir pour mettre les attributions/annulations d'attribution en attente à leur point terminal.

Lisez les colonnes hbase:meta info:state comme décrit pour déterminer ce qui doit faire l'objet d'une attribution ou d'une annulation d'attribution. Une fois que tout l'historique a été effacé en écartant le MasterProcWALs, aucune des entités ne doit être verrouillée. Vous êtes donc libre d'effectuer une attribution ou une annulation d'attribution en bloc.