sql >> データベース >  >> NoSQL >> HBase

ApacheHBaseレプリケーションの概要

    Apache HBaseレプリケーションは、あるHBaseクラスターから別のおそらく離れたHBaseクラスターにデータをコピーする方法です。これは、元のクラスターからのトランザクションが別のクラスターにプッシュされるという原則に基づいて機能します。 HBaseの専門用語では、プッシュを実行するクラスターはマスターと呼ばれ、トランザクションを受信するクラスターはスレーブと呼ばれます。このトランザクションのプッシュは非同期で実行され、これらのトランザクションは構成可能なサイズ(デフォルトは64 MB)でバッチ処理されます。非同期モードではマスターのオーバーヘッドが最小限に抑えられ、編集をバッチで送信すると全体的なスループットが向上します。

    このブログ投稿では、CDH4(0.92に基づく)でサポートされているHBaseレプリケーションの可能なユースケース、基盤となるアーキテクチャ、およびモードについて説明しています。フォローアップのブログ投稿で、レプリケーションの構成、ブートストラップ、およびフォールトトレランスについて説明します。

    ユースケース

    HBaseレプリケーションは、データセンター間でのデータのレプリケーションをサポートします。これは、マスターサイトがダウンした場合に、スレーブクラスターにリアルタイムトラフィックを提供させることができるディザスタリカバリシナリオに使用できます。 HBaseレプリケーションは自動フェイルオーバーを目的としていないため、トラフィックの処理を開始するためにマスタークラスターからスレーブクラスターに切り替える操作はユーザーが行います。その後、マスタークラスターが再び起動すると、CopyTableブログ投稿で説明されているように、CopyTableジョブを実行してデルタをマスタークラスターにコピーできます(開始/停止タイムスタンプを指定することにより)。

    別のレプリケーションのユースケースは、ユーザーがHBaseクラスターで負荷の高いMapReduceジョブを実行したい場合です。マスタークラスターのパフォーマンスがわずかに低下する一方で、スレーブクラスターでもこれを行うことができます。

    アーキテクチャ

    HBaseレプリケーションの基本原則は、マスターからスレーブへのすべてのトランザクションを再生することです。これは、次のセクションで説明するように、マスタークラスターからWAL(先行書き込みログ)のWALEdits(先行書き込みログエントリ)を再生することによって行われます。これらのWALEditは、フィルタリング(特定の編集がレプリケーションのスコープであるかどうかに関係なく)およびカスタマイズされたバッチサイズ(デフォルトは64MB)で出荷された後、スレーブクラスターリージョンサーバーに送信されます。 WALリーダーが現在のWALの最後に到達した場合、それまでに読み取られたWALEditsがすべて出荷されます。これはレプリケーションの非同期モードであるため、書き込みの多いアプリケーションでは、スレーブクラスターがマスターから数分遅れる可能性があります。

    WAL / WALEdits / Memstore

    HBaseでは、すべてのミューテーション操作(Puts / Deletes)は、特定のリージョンに属するmemstoreに書き込まれ、WALEditの形式で先行書き込みログファイル(WAL)にも追加されます。 WALEditは、1つのトランザクションを表すオブジェクトであり、複数のミューテーション操作を持つことができます。 HBaseは単一行レベルのトランザクションをサポートしているため、1つのWALEditは1行のみのエントリを持つことができます。 WALは、設定された期間(デフォルトは60分)の後に繰り返しロールされるため、リージョンサーバーごとにアクティブなWALは常に1つだけです。

    CAS(チェックおよび置換)操作であるIncrementColumnValueも、WALに書き込まれるときにPutに変換されます。

    memstoreは、構成領域のキー値を含む、メモリ内の並べ替えられたマップです。リージョンごとの各列ファミリごとに1つのmemstoreがあります。 memstoreは、構成されたサイズ(デフォルトは64MB)に達すると、HFileとしてディスクにフラッシュされます。

    WALへの書き込みはオプションですが、リージョンサーバーがクラッシュした場合、HBaseがそのリージョンサーバーでホストされているすべてのmemstoreを失う可能性があるため、データの損失を回避する必要があります。リージョンサーバーに障害が発生した場合、そのWALはログ分割プロセスによって再生され、WALに保存されているデータが復元されます。

    レプリケーションを機能させるには、WALへの書き込みを有効にする必要があります。

    ClusterId

    すべてのHBaseクラスターには、HBaseによって自動生成されたUUIDタイプであるclusterIDがあります。再起動のたびに変更されないように、基盤となるファイルシステム(通常はHDFS)に保持されます。これは/hbase/hbaseidznode内に保存されます。このIDは、マスターマスター/非サイクリックレプリケーションを実現するために使用されます。 WALには、regionserverでホストされているいくつかのリージョンのエントリが含まれています。レプリケーションコードは、すべてのキー値を読み取り、レプリケーションのスコープとなるキー値を除外します。これは、キー値の列ファミリー属性を調べ、それをWALEditの列ファミリーマップデータ構造と照合することによって行われます。特定のキー値がレプリケーションのスコープになっている場合は、キー値のclusterIdパラメーターをHBaseクラスターIDに編集します。

    ReplicationSource

    ReplicationSourceは、regionserverプロセスのJavaスレッドオブジェクトであり、WALエントリを特定のスレーブクラスターに複製する役割を果たします。複製されるログファイルを保持する優先キューがあります。ログが処理されるとすぐに、キューから削除されます。優先キューは、作成タイムスタンプ(ログファイル名に追加されます)に基づいてログファイルを比較するコンパレータを使用します。そのため、ログは作成時と同じ順序で処理されます(古いログが最初に処理されます)。優先キューにログファイルが1つしかない場合は、現在のWALを表すため、削除されません。

    動物園管理人の役割

    Zookeeperは、HBaseレプリケーションで重要な役割を果たします。ここでは、スレーブクラスターの登録、レプリケーションの開始/停止、新しいWALのキューイング、リージョンサーバーのフェイルオーバーの処理など、ほとんどすべての主要なレプリケーションアクティビティを管理/調整します。 Zookeeperクォーラム(少なくとも3つ以上のノード)を常に稼働させるため。 Zookeeperは、(HBaseではなく)独立して実行する必要があります。次の図は、マスタークラスター内のレプリケーション関連のznodes構造のサンプルを示しています(コロンの後のテキストはデータです znodeの):

    /hbase/hbaseid: b53f7ec6-ed8a-4227-b088-fd6552bd6a68
    ….
    /hbase/rs/foo1.bar.com,40020,1339435481742:
    /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,1339435481742/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,1339435481742/1/foo2.bar..com.13394354343443: 1909033

    図1.レプリケーションznode階層

    図1のように、マスタークラスターには3つのリージョンサーバー、つまりfoo[1-3].bar.comがあります。レプリケーションに関連する3つのznodeがあります:

    1. 状態 :このznodeは、レプリケーションが有効かどうかを示します。すべての基本的な手順(新しくロールされたログをレプリケーションキューにエンキューするかどうか、ログファイルを読み取ってWALEditsの出荷を行うかどうかなど)、処理する前にこのブール値を確認します。これは、hbase-conf.xmlで「hbase.replication」プロパティをtrueに設定することで設定されます。その値を変更する別の方法は、hbaseシェルで「レプリケーションの開始/停止」コマンドを使用することです。これについては、2番目のブログ投稿で説明します。
    2. ピア :このznodeには、子として接続されたピア/スレーブがあります。この図では、peerId =1のスレーブが1つあり、その値は接続文字列(Zookeeper_quorum_of_slave:Zookeeper_client_port:root_hbase_znode)です。ここで、Zookeeper_quorum_of_slaveはコンマで区切られたZookeeperサーバーのリストです。 peerId znode名は、ピアの追加時に指定した名前と同じです。
    3. rs :このznodeには、マスタークラスター内のアクティブなリージョンサーバーのリストが含まれています。各regionserverznodeには、複製されるWALのリストがあり、これらのログznodeの値はnull(ログがまだ複製用に開かれていない場合)、またはログが読み取られたポイントへのバイトオフセットのいずれかです。 WAL znodeのバイトオフセット値は、それが読み取られて複製された、対応するWALファイルのバイトオフセットを示します。複数のスレーブクラスターが存在する可能性があり、レプリケーションの進行状況はクラスター間で異なる可能性があるため(たとえば、1つがダウンしている可能性があります)、すべてのWALはrsの下のpeerIdznodeに自己完結しています。したがって、上の図では、WALのznodeはare / rs // 1の下にあり、「1」はpeerIdです。

    レプリケーションモード

    HBaseレプリケーションの設定には3つのモードがあります:

    1. マスタースレーブ:このモードでは、レプリケーションは一方向で実行されます。つまり、あるクラスターからのトランザクションが別のクラスターにプッシュされます。スレーブクラスターは他のクラスターとまったく同じであり、独自のテーブルやトラフィックなどを持つことができることに注意してください。
    2. マスター-マスター:このモードでは、レプリケーションは、異なるテーブルまたは同じテーブルに対して両方向に送信されます。つまり、両方のクラスターがマスターとスレーブの両方として機能します。それらが同じテーブルを複製している場合、無限ループにつながる可能性があると思われるかもしれませんが、これは、ミューテーション(Put / Delete)のclusterIdを元のクラスターのclusterIdに設定することで回避できます。図2は、太陽と地球という2つのクラスターを使用してこれを説明しています。図2には、2つのHBaseクラスターを表す2つのブロックがあります。それぞれclusterId100と200があります。各クラスターには、複製先のスレーブクラスターに対応するReplicationSourceのインスタンスがあります。両方のクラスターのクラスター#Idを認識しています。

      図2.太陽と地球、2つのHBaseクラスター

      cluster#Sunが、両方のクラスターでの複製のスコープとなるテーブルおよび列ファミリーで、新しく有効なミューテーションMを受け取ったとします。デフォルトのclusterID(0L)があります。レプリケーションソースインスタンスReplicationSrc-Eは、そのcluster#IdをオリジネーターID(100)に等しく設定し、cluster#Earthに送信します。 cluster#Earthがミューテーションを受信すると、それを再生し、通常のフローに従って、ミューテーションがWALに保存されます。ミューテーションのcluster#Idは、cluster#Earthのこのログファイルにそのまま保持されます。cluster#Earthのレプリケーションソースインスタンス(ReplicationSrc-Sは、ミューテーションを読み取り、そのcluster#IDをslaveCluster#(100、 cluster#Sunに等しい)。等しいため、このWALEditエントリをスキップします。

    3. Cyclic:このモードでは、レプリケーションのセットアップに参加しているHBaseクラスターが3つ以上あり、任意の2つのクラスター間にマスタースレーブとマスターマスターのさまざまな組み合わせをセットアップできます。上記の2つは、これらのケースをうまくカバーしています。 1つのコーナーの状況は、サイクルを設定したときです

      図3.循環レプリケーションのセットアップ

    図3は、cluster#Sunがcluster#Earthに複製し、cluster#Earthがcluster#Venusに複製し、cluster#Venusがcluster#Sunに複製する循環複製セットアップを示しています。
    cluster#Sunとしましょう。新しいミューテーションMを受け取り、上記のすべてのクラスター間でのレプリケーションにスコープされます。上記のマスターマスターレプリケーションで説明したように、cluster#Earthにレプリケートされます。 cluster#EarthのレプリケーションソースインスタンスであるReplicationSrc-Vは、WALを読み取り、ミューテーションを確認して、cluster#Venusにレプリケートします。ミューテーションのcluster#Idは、cluster#Venusで(cluster#Sunの時点で)そのまま保持されます。このクラスターでは、cluster#SunのレプリケーションソースインスタンスであるReplicationSrc-Sは、ミューテーションがそのslaveCluster#と同じclusterId(cluster#Sunの時点)を持っていることを確認するため、レプリケーションをスキップします。

    結論

    HBaseレプリケーションは、ディザスタリカバリシナリオで使用できる強力な機能です。 0.90リリースでプレビュー機能として追加され、マスターマスターレプリケーション、非サイクリックレプリケーション(両方とも0.92で追加)、ピアレベルでのレプリケーションの有効化と無効化などの機能が追加され、HBase全般とともに進化してきました。 (0.94で追加)

    次のブログ投稿では、構成などのさまざまな運用機能や、HBaseレプリケーションに関するその他の落とし穴について説明します。


    1. DarkShieldを使用したMongoDB、Cassandra、ElasticsearchでのPIIのマスキング:…

    2. 文字列をobjectIDforeignFieldにルックアップするための回避策が必要です

    3. Mongodb、シャーディング、および複数のWindowsサービス

    4. Redisに代わる埋め込み可能なJavaはありますか?