これは、ApacheHBaseレプリケーションに関する2番目のブログ投稿です。以前のブログ投稿「HBaseレプリケーションの概要」では、HBaseレプリケーションでサポートされているユースケース、アーキテクチャ、さまざまなモードについて説明しました。このブログ投稿は運用の観点からのものであり、HBaseレプリケーション構成と、それを使用するための重要な概念（ブートストラップ、スキーマ変更、フォールトトレランスなど）に触れます。
構成
HBaseレプリケーションの概要で説明したように、マスタークラスターはWALEditsの出荷を1つ以上のスレーブクラスターに送信します。このセクションでは、マスタースレーブモードでレプリケーションを構成するために必要な手順について説明します。
- 複製されるすべてのテーブル/列ファミリーは、両方のクラスターに存在する必要があります。
- 両方のクラスターのすべてのノードの$HBASE_HOME/ conf/hbase-site.xmlに次のプロパティを追加します。 trueに設定します。
hbase.replication
true
マスタークラスターで、次の追加の変更を行います。
- レプリケーションスコープを設定します（ REPLICATION_SCOPE 属性）複製されるテーブル/列ファミリー：
hbaseshell>「テーブル」を無効にする
hbase shell> alter‘table’、{NAME =>‘column-family’、REPLICATION_SCOPE => 1}
hbaseshell>「テーブル」を有効にする
REPLICATION_SCOPEは列ファミリーレベルの属性であり、その値は0または1のいずれかです。値0はレプリケーションが無効であることを意味し、1はレプリケーションが有効であることを意味します。ユーザーは、複製するすべての列ファミリーについて、上記のようにalterコマンドを使用して各列ファミリーを変更する必要があります。
ユーザーがテーブルの作成中にレプリケーションを有効にする場合は、次のコマンドを使用する必要があります。
hbase shell> create‘table’、‘column-family1’、‘‘ column-family2’、{NAME =>‘column-family1’、REPLICATION_SCOPE => 1}
上記のコマンドは、上記のテーブルの「column-family1」でのレプリケーションを有効にします。
2. hbaseシェルで、スレーブピアを追加します。ユーザーは、peerIdとともに、スレーブクラスターのzookeeperクォーラム、そのクライアントポート、およびルートhbaseznodeを提供することになっています。
hbase shell> add_peer‘peerId’、“ ::”
peerIdは1文字または2文字の長さの文字列であり、前のブログで説明したように、対応するznodeがpeersznodeの下に作成されます。ユーザーがadd_peerコマンドを実行すると、レプリケーションコードはそのピアのReplicationSourceオブジェクトをインスタンス化し、すべてのマスタークラスターリージョンサーバーがスレーブクラスターのリージョンサーバーに接続しようとします。また、スレーブクラスターのClusterId（UUID、スレーブクラスターのzookeeperクォーラムに登録されている）もフェッチします。マスタークラスターのregionserverは、スレーブクラスターのzookeeperクォーラムで「/ hbase / rs」znodeとその子を読み取ることにより、スレーブの使用可能なリージョンサーバーを一覧表示し、それに接続します。マスタークラスターの各リージョンサーバーは、「replication.source.ratio」で指定された比率に応じて、スレーブリージョンサーバーからサブセットを選択します。デフォルト値は0.1です。これは、各マスタークラスターリージョンサーバーがスレーブクラスターリージョンサーバーの合計の10％に接続しようとすることを意味します。トランザクションバッチの送信中に、マスタークラスターのregionserverは、これらの接続されたregionserverからランダムなregionserverを選択します。 （注：カタログテーブル、.META。および_ROOT_のレプリケーションは実行されません。）
マスターマスターモードを設定するには、両方のクラスターで上記の手順を繰り返す必要があります。
スキームの変更
前のセクションで説明したように、複製されたテーブルと列のファミリは両方のクラスタに存在する必要があります。このセクションでは、レプリケーションがまだ進行中の場合にスキーマの変更中に何が起こるかについて、考えられるさまざまなシナリオについて説明します。
a）マスターの列ファミリーを削除します。列ファミリーを削除しても、そのファミリーの保留中のミューテーションの複製には影響しません。これは、レプリケーションコードがWALを読み取り、各WALEditの列ファミリのレプリケーションスコープをチェックするためです。各WALEditには、レプリケーションが有効な列ファミリーのマップがあります。チェックは、構成するすべてのキー値の列ファミリーに対して実行されます（スコープが設定されているかどうかは関係ありません）。マップに存在する場合は、貨物に追加されます。 WALEditオブジェクトは、列ファミリーが削除される前に作成されるため、その複製は影響を受けません。
b）スレーブの列ファミリーを削除します。WALEditsはマスタークラスターから特定のスレーブリージョンサーバーに送信され、通常のHBaseクライアントのように処理されます（HTablePoolオブジェクトを使用）。列ファミリーが削除されるため、put操作は失敗し、その例外はマスターリージョンサーバークラスターにスローされます。
レプリケーションの開始/停止
開始/停止コマンドはキルスイッチとして機能します。 stop_replicationコマンドをHBaseシェルで実行すると、/ hbase / Replication/stateの値がfalseに変更されます。すべてのレプリケーションソースオブジェクトがログを読み取るのを停止します。ただし、既存の読み取りエントリは出荷されます。ユーザーがレプリケーションの停止コマンドを使用した場合、新しくロールされたログはレプリケーションのためにキューに入れられません。同様に、start_replicationコマンドを発行すると、コマンドが発行された時点からではなく、現在のWAL（以前のトランザクションが含まれている可能性があります）からレプリケーションが開始されます。
図1は、一連のイベントが矢印の方向に流れる開始-停止スイッチの動作を説明しています。
バージョンの互換性
マスタークラスターリージョンサーバーは、通常のHBaseクライアントとしてスレーブクラスターリージョンサーバーに接続します。バージョンxxxのHBaseクライアントがバージョンyyyのHBaseサーバーでサポートされているかどうかについても、同じ互換性のルールが適用されます。
別の点では、レプリケーションはまだ進化しているため（ますます多くの機能が継続的に追加されます）、ユーザーは既存の機能に注意する必要があります。たとえば、HBase 0.92ブランチに基づくCDH4では、マスターマスターとサイクリックレプリケーションがサポートされています。ピアレベルでのレプリケーションソースの有効化/無効化は、HBase0.94ブランチに追加されています。
ブートストラップ
レプリケーションは、マスタークラスターリージョンサーバーのWALを読み取ることで機能します。ユーザーが古いデータを複製したい場合は、複製を有効にしながら、copyTableコマンド（開始タイムスタンプと終了タイムスタンプを定義）を実行できます。 copyTableコマンドは、開始/終了タイムスタンプによってスコープされたデータをコピーし、レプリケーションが現在のデータを処理します。全体的なアプローチは次のように要約できます。
- レプリケーションを開始します（タイムスタンプに注意してください）。
- 上記のタイムスタンプと等しい終了タイムスタンプを使用してcopyTableコマンドを実行します。
- レプリケーションは現在のWALから開始されるため、レプリケーションジョブとcopyTableジョブの両方によってスレーブにコピーされるいくつかのキー値が存在する可能性があります。べき等の操作であるため、これはまだ問題ありません。
マスターマスターレプリケーションの場合、レプリケーションを開始する前にcopyTableジョブを実行する必要があります。これは、ユーザーがレプリケーションを有効にした後でcopyTableジョブを開始すると、copyTableがミューテーションオブジェクトのclusterIdを編集しないため、2番目のマスターが最初のマスターにデータを再送信するためです。全体的なアプローチは次のように要約できます。
- copyTableジョブを実行します（ジョブの開始タイムスタンプに注意してください）。
- レプリケーションを開始します。
- 手順1でメモした開始時間と等しい開始時間でcopyTableを再度実行します。
これには、2つのクラスター間でデータが前後にプッシュされることも含まれます。ただし、サイズは最小化されます。
フォールトトレランス
マスタークラスターリージョンサーバーのフェイルオーバー
アーキテクチャのセクションで説明したように、マスタークラスター内のすべてのリージョンサーバーは「/ hbase / Replication/rs」の下にznodeを作成します。リージョンサーバーは、図1に示すように、レプリケーション階層のznodeの下にバイトオフセットを使用して、WALごとに子znodeを追加します。リージョンサーバーに障害が発生した場合、他のリージョンサーバーは、その下にリストされているデッドリージョンサーバーのログを処理する必要があります。 regionserverのznode。すべてのregionserverは、他のregionserver znode（“ / hbase / rs”）znodeを監視します。したがって、regionserverに障害が発生すると、マスターがこのregionserverを停止としてマークするため、他のregionserverがイベントを取得します。この場合、他のすべてのリージョンサーバーは、他の通常のログと区別するために、デッドリージョンサーバーznodeからそれらのznodeにWALを転送し、スレーブIDとデッドリージョンサーバー名をプレフィックスとして付加するために競合します。転送されたログに対して別のレプリケーションソース（NodeFailoverWorkerインスタンス）がインスタンス化され、これらの転送されたログの処理後に停止します。
HBaseレプリケーションの概要の図1をレプリケーションznode階層の基本図と見なすと、図2は、サーバーfoo1.bar.comが停止し、foo2.bar.comがキューを引き継いだ場合の新しいレプリケーションznode階層を示しています。 foo2.bar.comznodeの下に作成された新しいznode「1-foo1.bar.com,40020,1339435481973」に注意してください
/ hbase / hbaseid：b53f7ec6-ed8a-4227-b088-fd6552bd6a68…。 /hbase/rs/foo2.bar.com,40020,1339435481973：/hbase/rs/foo3.bar.com,40020,1339435486713：/ hbase / replication：/ hbase / replication / state：true / hbase / replication / peers： /hbase/replication/peers/1：zk.quorum.slave:281:/hbase /hbase/replication/rs：/hbase/replication/rs/foo1.bar.com.com,40020,1339435084846：/ hbase / replication / rs / foo1.bar.com、40020,1339435481973 / 1：/hbase/replication/rs/foo1.bar.com,40020、1339435481973/1 / foo1.bar.com.1339435485769：1243232 / hbase / replication / rs / foo3 .bar.com、40020,1339435481742：/hbase/replication/rs/foo3.bar.com,40020,1339435481742/1：/hbase/replication/rs/foo3.bar.com,40020、1339345481742/1 / foo3.bar ..com.1339435485769：1243232 /hbase/replication/rs/foo2.bar.com,40020,1339435089550：/hbase/replication/rs/foo2.bar.com,40020,1339435481742/1：/ hbase / replication / rs / foo2.bar.com、40020、1333435481742/1 / foo2.bar..com.13394354343443：1909033 /hbase/replication/rs/foo2.bar.com,40020,1339435481742/1- foo1.bar.com、40020,1339435481973 /foo1.bar.com.1339435485769：1243232
図2.リージョンサーバーのフェイルオーバーznode階層
一方、ログ分割が開始され、デッドリージョンサーバーログがアーカイブされる場合があります。レプリケーションソースは、通常のディレクトリとアーカイブされたディレクトリの両方でログを検索します。
低速/応答しないスレーブクラスター（またはリージョンサーバー）
スレーブクラスターがダウンしている場合、または一時的なネットワークパーティションがある場合、スレーブにまだレプリケートされていないログは、HBaseログクリーナーによって削除されません。
ログのクリーニングはLogCleanerクラスによって処理され、設定された時間の後も実行を続けます。レプリケーションコードは、ReplicationLogCleanerプラグインをLogCleanerクラスに追加します。後者が特定のログを削除しようとすると、ReplicationLogCleanerは、そのログがレプリケーションznode階層（/ hbase / Replication / rs / znodeの下）に存在するかどうかを確認します。ログが見つかった場合は、ログがまだ複製されていないことを意味し、ログの削除をスキップします。ログが複製されると、そのznodeは複製階層から削除されます。次回の実行では、ログファイルが複製されると、LogCleanerはログファイルを正常に削除します。
検証
少量のデータの場合は、スレーブクラスターでhbaseシェルを使用してテーブルの行を検索し、それらが複製されているかどうかを確認できます。検証する標準的な方法は、HBaseに付属しているverifyrepmapreduceジョブを実行することです。マスタークラスターで実行する必要があり、スレーブclusterIdとターゲットテーブル名が必要です。開始/停止タイムスタンプや列ファミリーなどの追加の引数を提供することもできます。 GOODROWSとBADROWSの2つのカウンターを出力し、それぞれ複製された行と複製されていない行の数を示します。
レプリケーションメトリクス
レプリケーションフレームワークは、レプリケーションの進行状況を確認するために使用できるいくつかの有用なメトリックを公開します。重要なもののいくつかは次のとおりです。
- sizeOfLogQueue：レプリケーションソースで処理するHLogの数（処理中のHLogを除く）
- shippedOpsRate：出荷された変異率
- logEditsReadRate：レプリケーションソースでHLogから読み取られたミューテーションの割合
- ageOfLastShippedOp：レプリケーションソースによって出荷された最後のバッチの経過時間
今後の作業
現在のHBaseレプリケーションに現在存在するすべての機能を使用しても、さらに改善の余地があります。これは、マスターとスレーブ間のレプリケーションのタイムラグを減らすなどのパフォーマンスから、リージョンサーバーの障害（HBase-2611）のより堅牢な処理までさまざまです。さらなる改善領域には、ピアレベルのテーブルレプリケーションの有効化とIncrementColumnValue（HBase-2804）の適切な処理が含まれます。
結論
この投稿では、（さまざまなモードの）構成、既存のクラスターのブートストラップ、スキーマ変更の影響、フォールトトレランスなど、オペレーターの観点からHBaseレプリケーションについて説明しました。