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/ログに関するページを参照してください)。
この例では、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
作成された 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:meta
info:state
列を読み、割り当てまたは割り当て解除する必要がある内容を判断します。 MasterProcWALs
を脇に避けておいて、すべての履歴を消去した後は、すべてのエンティティがロックされないため、一括での割り当てや割り当て解除が自由にできるようになります。