次の方法で共有

Apache HBase HBCK2 ツールを使用する

  • [アーティクル]

この記事では、HBase HBCK2 ツールを使用する方法を示します。 HBCK2 は、Apache HBase クラスターの修復ツールです。

HBCK2 の概要

HBCK2 は現在、一度に 1 つの処理のみを行うシンプルなツールです。 hbase-2.x では、Master はすべての状態の最終アービターであるため、ほとんどの HBCK2 コマンドの一般的な原則は、すべての修復を行うようにマスターに要求することです。

HBCK2 コマンドを実行する前に、Master が稼働している必要があります。 HBCK1 では分析が実行され、クラスターの良し悪しが報告されていましたが、HBCK2 ではそれほどの差し出がましさはありません。 hbase-2.x では、オペレーターは修正が必要な内容を判別し、HBCK2 を含むツールを使用して修正を行います。

HBCK2 と HBCK1 の比較

HBCK2 は、Hbase-1.x (HBCK1 とも言います) に付属した修復ツールである HBCK の後継です。 HBCK1 の代わりに HBCK2 を使用して、Hbase-2.x クラスターに対して修復を行うことができます。 障害が発生する可能性があるため、hbase-2.x インストールに対して HBCK1 を実行しないでください。 この書き込み機能 (-fix) は削除されました。 hbase-2.x クラスターの状態を報告できますが、hbase-2.x の内部動作を理解していないため、評価は不正確です。

2 つのバージョン間でコマンドの名前が似ている場合でも、HBCK2 では HBCK1 で以前行っていたようには動作しません。

HBCK2 を取得する

リリースは HBase ディストリビューション ディレクトリにあります。 詳細については、HBase のダウンロード ページを参照してください。

マスター UI: HBCK レポート

/hbck.jsp で 2.1.6 にあるマスターに追加された HBCK レポート ページには、マスターによって実行される 2 つの検査からの出力が一定の間隔で表示されます。 1 つは、CatalogJanitor が実行されるたびに による出力です。 hbase:meta に重複または穴がある場合、CatalogJanitor は検出された内容を一覧表示します。 別のバックグラウンドの chore プロセスでは、hbase:meta とファイル システムのコンテンツが比較されます。 異常が見つかった場合、HBCK レポート セクションに書き留めます。

CatalogJanitor を実行するには、hbase シェルで コマンド catalogjanitor_run を実行します。

hbck chore を実行するには、hbase シェルで コマンド hbck_chore_run を実行します。

どちらのコマンドも入力を受け取りません。

HBCK2 を実行する

hbck コマンドは、$HBASE_HOME/bin/hbase スクリプトを使用して起動することで実行できます。 既定では、bin/hbase hbck を実行すると、組み込みの HBCK1 ツールが実行されます。 HBCK2 を実行するには、次の例のように -j オプションを使用して、ビルドされた HBCK2 jar を指定する必要があります。

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

このコマンドは、オプションまたは引数を渡さずに HBCK2 ヘルプを出力します。

HBCK2 コマンド

注意

運用環境で実行する前に、テスト クラスターでこれらのコマンドをテストして機能を理解してください。

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

オプション:

  • -o,--override: 別のプロシージャによって所有権をオーバーライドします。
  • -i,--inputFiles: 1 つ以上のエンコードされたリージョン名を受け取ります。

この raw 割り当ては、マスター初期化中でも使用できます (-skip フラグが指定されている場合)。 これはコプロセッサを回避し、1 つ以上のエンコードされたリージョン名を渡します。 de00010733901a05f5a2a3a382e27dd4 は、ユーザー空間でエンコードされたリージョン名の例です。 たとえば次のような点です。

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

作成された AssignProcedures の PID を返します。存在しない場合は -1 を返します。 -i or --inputFiles が指定されている場合は、1 つ以上の入力ファイル名を渡します。 各ファイルには、エンコードされたリージョン名が 1 行に 1 つずつ含まれています。 次に例を示します。

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

オプション:

  • -o,--override: 別のプロシージャによって所有権をオーバーライドします。
  • -i,--inputFiles: エンコードされた名前の 1 つ以上の入力ファイルを受け取ります。

この raw 割り当て解除は、マスター初期化中でも使用できます (-skip フラグが指定されている場合)。 これはコプロセッサを回避し、1 つ以上のエンコードされたリージョン名を渡します。 de00010733901a05f5a2a3a382e27dd4 は、ユーザー オーバーライド空間でエンコードされたリージョン名の例です。 たとえば次のような点です。

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

作成された UnassignProcedures の PID を返します。存在しない場合は -1 を返します。 -i or --inputFiles が指定されている場合は、1 つ以上の入力ファイル名を渡します。 各ファイルには、エンコードされたリージョン名が 1 行に 1 つずつ含まれています。 次に例を示します。

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

オプション:

  • -o,--override: プロシージャが実行またはスタックしている場合はオーバーライドします。
  • -r,--recursive: 親とその子をバイパスします。 "このオプションは低速でコストがかかります。"
  • -w,--lockWait: 中断する前に待機するミリ秒。 既定値 =1。
  • -i,--inputFiles: PID の 1 つ以上の入力ファイルを受け取ります。

1 つ以上のプロシージャ PID を渡して、プロシージャの終了にスキップします。 バイパスされたプロシージャの親は、終了までスキップします。 エンティティは不整合な状態のままであり、手動での修正が必要です。 保持されているロックをクリアするにはマスター再起動が必要な場合があります。 プロシージャに子がある場合、バイパスは失敗します。 親と子を終了する親 PID のみがある場合は、recursive を追加します。 このオプションは低速で危険なため、選択的に使用してください。 常に動作するとは限りません.

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

-i or --inputFiles が指定されている場合は、1 つ以上の入力ファイル名を渡します。 各ファイルには、1 行に 1 つずつ、PID が含まれています。 次に例を示します。

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

オプション:

  • i,--inputFiles: 名前空間またはテーブル名の 1 つ以上の入力ファイルを受け取ります。

このオプションは、hbase:meta からのリージョンが不足しているが、ディレクトリは HDFS にまだ存在している場合に使用します。 このコマンドはチェックメソッドにすぎません。 これはレポートを目的として設計されており、修正は実行されません。 hbase:meta に追加し直すリージョン (ある場合) が、各テーブルまたは名前空間でグループ化されたビューが提供されます。

meta でリージョンを効果的に追加し直すために、addFsRegionsMissingInMeta を実行します。 このコマンドでは hbase:meta がオンラインである必要があります。 パラメーターとして渡された各名前空間/テーブルについて、HDFS 上の既存のリージョンのディレクトリと比較して、hbase:meta で利用可能なリージョン間の差分を実行します。 一致のないリージョン ディレクトリは、関連するテーブル名の下にグループ化されて出力されます。 不足しているリージョンがないテーブルには、「不足しているリージョンがありません」というメッセージが表示されます。 名前空間またはテーブルが指定されていない場合は、既存のすべてのリージョンが検証されます。

複数の名前空間とテーブルの組み合わせが受け入れられます。 テーブル名には、既定の名前空間内のテーブルの場合でも、名前空間部分を含める必要があります。 そうしなければ、これは名前空間の値と見なされます。 この例では、既定の名前空間のテーブル table_1 と table_2 の不足しているリージョン レポートがトリガーされます。

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

この例では、既定の名前空間のテーブル table_1 と、名前空間 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

これは、パラメーターとして渡された各テーブル、またはパラメーターとして指定された名前空間のテーブルごとに、不足しているリージョンの一覧を返します。 -i or --inputFiles が指定されている場合は、1 つ以上の入力ファイル名を渡します。 各ファイルには、1 行に 1 つずつ、<NAMESPACE|NAMESPACE:TABLENAME> が含まれています。 次に例を示します。

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

オプション:

  • -i,--inputFiles: hbase:meta からのリージョンが不足しているが、ディレクトリは HDFS にまだ存在している場合に使用されるネームスペースのテーブル名の 1 つ以上の入力ファイルを受け取ります。 "hbase:meta はオンラインである必要があります。"

パラメーターとして渡されたテーブル名ごとに、hbase:meta で使用可能なリージョンと HDFS 上のリージョン ディレクトリの間の差分を実行します。 次に、hbase:meta に一致しないディレクトリについては、regioninfo メタデータ ファイルを読み取り、特定のリージョンを hbase:meta に再作成します。 リージョンは hbase:meta テーブルに「CLOSED」状態で再作成されますが、Masters キャッシュには再作成されません。 これらはどちらも割り当てられていません。 これらのリージョンをオンラインにするには、このコマンド実行が完了したときに出力される HBCK2 assigns コマンドを実行します。

2.3.0 より前の hbase リリースを使用する場合は、assigns 出力のセットを実行する前に HMasters のローリング再起動が必要です。 この例では、既定の名前空間のテーブル tbl_1、名前空間 n1 の tbl_2、および名前空間 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

HBCK2 と、再挿入されたすべてのリージョンを含む assigns コマンドが返されます。 -i or --inputFiles が指定されている場合は、1 つ以上の入力ファイル名を渡します。 各ファイルには、1 行に 1 つずつ、<NAMESPACE|NAMESPACE:TABLENAME> が含まれています。 次に例を示します。

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

オプション:

  • -f, --fix: 見つかったすべての追加リージョンを削除して meta を修正します。
  • -i,--inputFiles: 名前空間またはテーブル名の 1 つ以上の入力ファイルを受け取ります。

hbase:meta に存在するリージョンが報告されますが、ファイル システム上に関連するディレクトリはありません。 hbase:meta はオンラインである必要があります。 パラメーターとして渡されたテーブル名ごとに、hbase:meta で使用可能なリージョンと、特定のファイル システム上のリージョン ディレクトリの間の差分を実行します。 --fix オプションを渡すと、追加リージョンが Meta から削除されます。

注意

--fix オプションの使用を決定する前に、報告された追加リージョンが既存の有効なリージョンと重なっているかどうかを確認することをお勧めします。 そうである場合、extraRegionsInMeta --fix が最適な解決策です。 それ以外の場合、assigns コマンドが簡単なソリューションです。 これにより、リージョンのディレクトリがファイル システムに再作成されます (存在しない場合)。

次の例では、既定の名前空間の table_1 に対して、および名前空間 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

次の例では、既定の名前空間の table_1 に対して、および名前空間 ns1 のすべてのテーブルに対して、fix オプションを指定して追加リージョン レポートをトリガーします。

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

これは、パラメーターとして渡された各テーブル、またはパラメーターとして指定された名前空間のテーブルごとに、追加リージョンの一覧を返します。 -i or --inputFiles が指定されている場合は、1 つ以上の入力ファイル名を渡します。 各ファイルには、1 行に 1 つずつ、<NAMESPACE|NAMESPACE:TABLENAME> が含まれています。 次に例を示します。

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

注意

このオプションは HBase 2.1.6 ではうまく機能しません。 2.1.6 HBase クラスターでの使用はお勧めしません。

hbase:meta でサーバー側の不適切な状態または不整合な状態を修正します。 マスター UI には、catalogjanitor の最新の実行によって生成されたレポートと新しい hbck chore がダンプされる、一致する新しい HBCK Report タブがあります。

"他の修復を行う前に、hbase:meta を最初に正常にすることが重要です。" これにより、holes および overlaps が修正され、hbase:meta に追加されたリージョンと一致するように HDFS に (空の) リージョン ディレクトリが作成されます。

"このコマンドは、類似の名前が付けられた以前の hbck1 コマンドと同じではありません。" これは、最後の catalog_janitor および hbck chore の実行によって生成されたレポートに対して動作します。 修正するものが何もない場合、実行はループです。 それ以外では、HBCK Report UI が問題を報告した場合、fixMeta を実行すると 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>

このコマンドでは、不足しているテーブル記述子ファイルを生成して、孤立したテーブルを修正しようとします。 テーブル フォルダーが見つからない場合、または .tableinfo が存在する場合、このコマンドは効果がありません。 (既存のテーブル記述子はオーバーライドされません)。このコマンドは、最初に TableDescriptor が HBase Master にキャッシュされているかどうかを確認します。その場合は、それに応じて .tableinfo を復旧します。 TableDescriptor が Master にキャッシュされていない場合は、次の項目を含む既定の .tableinfo ファイルが作成されます。

  • テーブル名。
  • ファイル システムに基づいて決定された列ファミリ リスト。
  • TableDescriptor と ColumnFamilyDescriptors の両方の既定のプロパティ。 既定のパラメーターを使用して .tableinfo ファイルが生成された場合は、後でテーブルまたは列ファミリのプロパティを確認してください。 (必要に応じて変更してください)。この方法により、HBase では何も変更されません。 これにより、ファイル システムに新しい .tableinfo ファイルのみが書き込まれます。 孤立したテーブルの場合、たとえば、ServerCrashProcedures に従うには、不足しているテーブル情報ファイルを生成した後にエラーを修正する必要がある場合があります。
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>...]

オプション:

  • -f, --fix: 見つかったレプリケーションの問題を修正します。
  • -i,--inputFiles: テーブル名の 1 つ以上の入力ファイルを取得します。

削除されていないレプリケーション キューを検索し、--fix オプションが渡された場合は削除します。 レプリケーション バリアのチェックにテーブル名を渡し、--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

-i or --inputFiles が指定されている場合は、1 つ以上の入力ファイル名を渡します。 各ファイルには、1 行に 1 つずつ、<TABLENAME> が含まれています。 次に例を示します。

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

オプション:

  • -i,--inputFiles: エンコードされたリージョン名と状態の 1 つ以上の入力ファイルを取得します。

使用可能なリージョンの状態:

  • OFFLINE
  • OPENING
  • OPEN
  • CLOSIN
  • CLOSED
  • SPLITTING
  • SPLIT
  • FAILED_OPEN
  • FAILED_CLOSE
  • MERGING
  • MERGED
  • SPLITTING_NEW
  • MERGING_NEW
  • ABNORMALLY_CLOSED

警告

このリスクのあるオプションは、最後の手段として使用することを意図したものです。

シナリオの例としては、リージョンが hbase:meta の不整合な状態であるため、先に進めることができない unassigns または assigns が含まれます。 たとえば、unassigns コマンドは、SPLITTING、SPLIT、MERGING、OPEN、CLOSING のいずれかの状態でリージョンが渡された場合にのみ続行できます。

このコマンドを使用してリージョンの状態を手動で設定する前に、assign や split などの実行中のプロシージャによってこのリージョンが処理されないことを証明します。 list_procedures コマンドを使用して、hbase シェルで実行中のプロシージャのビューを取得できます。 次の使用例では、リージョン de00010733901a05f5a2a3a382e27dd4 を CLOSING に設定します。

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

リージョンの状態が変更された場合は 0 を返し、それ以外の場合は 1 を返します。 -i or --inputFiles が指定されている場合は、1 つ以上の入力ファイル名を渡します。 各ファイルには、1 行に 1 ペアずつ、<ENCODED_REGIONNAME> <STATE> が含まれています。 次に例を示します。

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

オプション:

  • -i,--inputFiles: テーブル名および状態の 1 つ以上の入力ファイルを取得します。

可能なテーブルの状態は、ENABLED、DISABLED、DISABLEDING、ENABLEDING です。

現在のテーブルの状態を読み取るために、hbase シェルで次を実行します。

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

x08x00 == ENABLED、x08x01 == DISABLED などの値。シェル プロンプトで describe <TABLENAME> を実行することもできます。 次の例では、テーブル名ユーザーを ENABLED にします。

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

これは前のテーブルの状態をそのまま返します。 -i or --inputFiles が指定されている場合は、1 つ以上の入力ファイル名を渡します。 各ファイルには、1 行に 1 ペアずつ、<TABLENAME> <STATE> が含まれています。 次に例を示します。

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

オプション:

  • -i,--inputFiles: サーバー名の 1 つ以上の入力ファイルを取得します。

RegionServers の一覧に対して ServerCrashProcedure(SCP) をスケジュールします。 サーバー名を <HOSTNAME>,<PORT>,<STARTCODE> として書式設定します。 (HBase UI/ログに関するページを参照してください)。

この例では、RegionServera.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

作成された ServerCrashProcedures の PID を返し、プロシージャが作成されていない場合は -1 を返します。 (行われない理由については、Master ログに関する記事を参照してください)。HBase バージョン 2.0.3、2.1.2、2.2.0 以降でのコマンド サポートが追加されています。 -i or --inputFiles が指定されている場合は、1 つ以上の入力ファイル名を渡します。 各ファイルには、1 行に 1 つずつ、<SERVERNAME> が含まれています。 次に例を示します。

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

問題を修正する

このセクションは、一般的な問題のトラブルシューティングに役立ちます。

一般的な原則

修復を行う場合は、ファイル システムの逸脱などの "他の種類の問題を修正する前に、hbase:meta が一貫していることを最初に確認してください。" ファイルシステムの逸脱または割り当てに関する問題は、hbase:meta を整理した後に対処する必要があります。 hbase:meta に問題がある場合、孤立ファイルシステム データを採用したり、リージョンの割り当てを行ったりするときに、マスターは適切な配置を行えません。

リージョンは、先に CLOSED 状態を経て遷移しなければ、CLOSING 状態の場合に割り当てを行ったり、または逆に OPENING 状態の場合に割り当て解除を行ったりすることができません。 リージョンは常に CLOSED から OPENING、OPEN、そして CLOSING、CLOSED へと移行する必要があります。

修復を行うときは、テーブルを一度に 1 つずつ修正してください。

テーブルが DISABLED の場合は、リージョンを割り当てできません。 マスター ログでは、テーブルが無効になっているため、マスター レポートがスキップされていることがわかります。 リージョンは現在 OPENING 状態であるため、リージョンを割り当てることができ、テーブルの DISABLED 状態と一致するようにリージョンを CLOSED 状態にする必要があります。 この状況では、割り当てを実行できるように、テーブルの状態を一時的に ENABLED に設定する必要がある場合があります。 それから、割り当て解除ステートメントの後に再び元の設定に戻します。 HBCK2 には、ユーザーがこの変更を行うための機能があります。 HBCK2 の使用状況の出力を参照してください。

割り当てと割り当て解除

通常、割り当て時にマスターは成功するまで保持されます。 割り当てでは、リージョンに対して排他的ロックが適用されます。 このロックにより、割り当てまたは割り当て解除の同時実行が禁止されます。 ロックされたリージョンに対する割り当ては、ロックが解除されるまで待機してから進行します。

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.

hbase:meta (または hbase:namespace) を割り当てるプロシージャがないため、マスターは起動を続行できません。 1 つを挿入するには、次の HBCK2 ツールを使用します。

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

この例で、1588230740 は、hbase:meta リージョンのエンコードされた名前です。 -skip オプションを渡して、HBCK2 がリモート マスターに対してバージョン チェックを実行しないようにします。 リモート マスターが起動していない場合、バージョン チェックでは Master is initializing response または PleaseHoldException のメッセージが出され、割り当て試行を中断します。 -skip コマンドはバージョン チェックを回避し、スケジュールされた割り当てを設定します。

同じことが hbase:namespace システム テーブルにも起こる可能性があります。 hbase:namespace リージョンのエンコードされたリージョン名を探し、hbase:meta で行ったことと同様の手順を行います。 この後者の場合、マスターは実際には次の例のような役に立つメッセージを出力します。

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.

上記のログ行に示されている hbase:namespace テーブルの割り当てをスケジュールするには、次の操作を行います。

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

名前空間リージョンのエンコードされた名前を渡します。 (エンコードされた名前はデプロイごとに異なります)。

hbase:meta リージョン/テーブルの復元/再構築での不足するリージョン

いくつかの珍しいケースで、テーブル リージョンが hbase:meta テーブルから削除されました。 これらのケースのトリアージにより、これらが演算子によって誘発されたことが明らかになりました。 ユーザーは、HBCK2 クラスターに対して以前の HBCK1 OfflineMetaRepair ツールを実行しました。 OfflineMetaRepair は、HBase 1.x バージョンの hbase:meta テーブル関連の問題を修正するためのよく知られているツールです。 元のバージョンは HBase 2.x 以降のバージョンと互換性がなく、いくつかの調整が行われています。 極端な状況は HBCK2 経由で実行できるようになりました。

これらのケースのほとんどでは、最終的に hbase:meta でリージョンがランダムに失われますが、hbase はまだ動作している可能性があります。 このような状況では、HBCK2 の addFsRegionsMissingInMeta コマンドを使用して、Master オンラインで問題に対処できます。 このコマンドは、後で説明する完全な hbase:meta 再構築よりも、hbase に対する中断が少なくなります。 名前空間テーブル領域の復旧にも使用できます。

hbase:meta リージョン/テーブルの復元/再構築での余分なリージョン

ファイル システムでテーブル領域が削除されても、hbase:meta テーブルに関連エントリがまだ残っている状況も考えられます。 このシナリオは、分割、手動操作の間違い (リージョン ディレクトリを手動で削除/移動するなど)、または HBASE-21843 などのメタ情報データ損失の問題が原因で発生する可能性があります。

このような問題は、HBCK2 の extraRegionsInMeta --fix コマンドを使用して、Master オンラインで対処できます。 このコマンドは、後で説明する完全な hbase:meta 再構築よりも、hbase に対する中断が少なくなります。 これは、fixMeta HBCK2 オプションをサポートしないバージョン (2.0.6、2.1.6、2.2.1、2.3.0、3.0.0 より前のバージョン) でこのことが発生する場合にも便利です。

オンライン hbase:meta リビルド レシピ

hbase:meta の破損があまり重大でない場合、hbase をオンラインにすることができます。 名前空間リージョンが不足しているリージョンの中にある場合でも、マスターが名前空間の割り当てを待っている初期化期間中に hbase:meta をスキャンすることができます。 この状況を確認するために、hbase:meta スキャン コマンドを実行できます。 タイムアウトにならないか、エラーが表示されない場合、hbase:meta はオンラインです。

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

メッセージにエラーが表示されない場合は、HBCK2 addFsRegionsMissingInMeta を使用できます。 hbase:meta にリージョンを再作成するために、FS リージョン ディレクトリで利用可能なリージョン メタデータ情報を読み取ります。 これは hbase が部分的に動作している状態でも実行できるため、報告された問題の影響を受けるオンライン テーブルを無効にしようとし、リージョンを hbase:meta に追加し直します。 特定のテーブルや名前空間、またはすべての名前空間のすべてのテーブルを確認できます。 この例では、既定の名前空間のテーブル tbl_1、名前空間 n1 の tbl_2、および名前空間 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

これはマスターとは独立して動作するため、正常に完了した後で、追加し直されたリージョンを割り当てるためのさらに多くの手順が必要になります。 これらのメッセージは次のようにリストされます。

  • addFsRegionsMissingInMeta は、読み取られたすべてのリージョンで assigns コマンドを出力します。 このコマンドは後で実行する必要があるため、利用しやすいようにコピーして保存します。
  • 2.3.0 より前の HBase バージョンの場合、addFsRegionsMissingInMeta が正常に完了し、出力が保存された後、実行中のすべての HBase マスターを再起動します。

マスターが再起動され、hbase:meta が既にオンラインになったら (Web UI にアクセスできるかどうかを確認してください)、前に保存した addFsRegionsMissingInMeta 出力から assigns コマンドを実行します。

注意

名前空間リージョンが、不足しているリージョンの中にある場合は、返された assigns コマンドの先頭に --skip フラグを追加する必要があります。

クラスターで hbase:meta テーブルの致命的な損失が発生した場合は、次のレシピを使用して大まかな再構築が可能です。 概要では、クラスターを停止します。 HBCK2 OfflineMetaRepair ツールを実行します。このツールは、ファイル システムにドロップされたディレクトリとメタデータを読み取り、実行可能な hbase:met テーブルの再構築に最善を尽くします。 クラスターを再起動します。 システム名前空間テーブルをオンラインにするために割り当てを挿入します。 最後に、有効にするユーザー空間テーブルを再割り当てします。 (再構築された hbase:meta によって、すべてのテーブルがオフラインで、リージョンが割り当てられていないテーブルが作成されます)。

詳細なリビルド レシピ

注意

このオプションは最終手段としてのみ使用します。 それは推奨されません。

  • クラスターを停止します。

  • HBCK2 からリビルド hbase:meta コマンドを実行します。 このコマンドは元の hbase:meta を脇に避けておき、新しく再構築されたものを配置します。 この例では、ツールを実行する方法を示します。 HDFS で検出されたリージョンに関する情報がツールによってダンプされるように、-details フラグが追加されます。

    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

  • クラスターを開始します。 完全には起動しません。 名前空間テーブルがオンラインではなく、このコンティンジェンシーのプロシージャ ストアに割り当てプロシージャがないため、スタックしています。 HBase Master ログには、この状態が表示されます。 次の例は、ログに記録される内容を示しています。

    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.

    名前空間テーブル領域を割り当てるには、シェルを使用できません。 シェルを使用すると、マスターがまだ起動していないため、PleaseHoldException で失敗します。 (シェルは、自身が "起動" していると宣言する前に、名前空間テーブルがオンラインになるのを待機しています)。HBCK2 割り当てコマンドを使用する必要があります。 割り当てるには、名前空間でエンコードされた名前が必要です。 引用符で囲まれたログに表示されます。 このケースでは 725a0fe6c2c869d3d0a9ed82bfa80fa3 です。 -skip コマンドを渡して、マスター バージョンのチェックをスキップする必要があります。 (それ以外の場合、マスターがまだ起動していないため、HBCK2 呼び出しは PleaseHoldException を引き出します)。次の例では、名前空間テーブルの割り当てが追加されます。

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

    呼び出しで Connection refused が返された場合、マスターは稼働していますか? マスターがそれ自体を初期化できない場合、しばらくするとシャットダウンします。 クラスター/マスターを再起動し、割り当てコマンドを再実行してください。

  • 割り当てが正常に実行されると、次の例のような出力が表示されます。 最後の 48 は、割り当てプロシージャ スケジュールの PID です。 返される PID が -1 である場合、マスター スタートアップは十分に進行していないため、再試行してください。 または、エンコードされたリージョン名が正しくない可能性があるため、この問題をチェックしてください。

    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]

  • マスター ログを確認します。 マスターは起動しているはずです。 PID=48 が正常に完了しました。 次の例のような行を探して、マスター起動が成功したことを確認します。

    master.HMaster: Master has completed initialization 132.515sec

    表示されるまでに時間がかかる場合があります。

    hbase:meta のリビルドにより、DISABLED 状態のユーザー テーブルと CLOSED モードのリージョンが追加されます。 シェルを使用してテーブルを再度有効にして、すべてのテーブル リージョンをオンラインに戻します。 これを一度に 1 つずつ実行するか、すべてを有効にする ".*" コマンドですべてのテーブルを 1 回で有効にします。

    リビルド メタには編集が不足しているため、この記事で以前記載した機能を使用して、その後の修復とクリーニングが必要になる場合があります。

参照ファイルの削除、hbase.version ファイルの不足、および破損したファイル

HBCK2 は、ハングした参照や破損したファイルを確認できます。 不良なファイルを外すように依頼できます。これは、リージョンがオンラインにならなかったり読み取りが失敗したりするという難関を乗り越えるのに必要になる場合があります。 HBCK2 の一覧で file-system コマンドを参照してください。 1 つ以上のテーブル名を渡します (または none を使用してすべてのテーブルをチェックします)。 不良なファイルが報告されます。 修復するには --fix オプションを渡します。

プロシージャの再起動

最後の手段として、マスターが混乱し、修復のすべての試みで、完了できない取り消し可能なロックまたはプロシージャのみが見つかる場合、または MasterProcWALs のセットが際限なく拡大する場合、マスター状態をクリーンにワイプできます。 HBase のインストールの下の /hbase/MasterProcWALs/ ディレクトリを脇に避けておき、マスター プロセスを再起動します。 メモリのない表形式として返されます。

消去時にすべてのリージョンが正常に割り当てられていたか、オフラインになっていた場合、マスターの再起動時に、マスターは何も起こっていないかのように起動して続行します。 しかし、その時点で移行中のリージョンがあった場合、オペレーターは未処理の割り当てまたは未割り当てがそれらの終点に来るように介入する必要があります。

説明に従って hbase:metainfo:state 列を読み、割り当てまたは割り当て解除する必要がある内容を判断します。 MasterProcWALs を脇に避けておいて、すべての履歴を消去した後は、すべてのエンティティがロックされないため、一括での割り当てや割り当て解除が自由にできるようになります。