目次
高可用性サービス・レベルを実現するにはソフトウェア・コンポーネントの監視が不可欠ですが、ハードウェアの監視や障害分離、さらには障害コンポーネントの交換や、その障害からのリカバリ方法も同じように重要です。次の各項で、監視対象のコンポーネントおよび考えられるハードウェア障害の検出方法に関するガイドラインについて説明します。また、障害ハードウェア・コンポーネントの交換手順と、(交換されたコンポーネントを使用していた) Oracle NoSQL Databaseコンポーネントをオンラインに戻す方法についても説明します。
Oracle NoSQL Databaseの環境を監視する際には、複数の種類のハードウェア・シナリオおよび障害を考慮する必要があります。次の各項では、ネットワーク、ディスクおよびマシンの障害の監視について説明し、これらの障害とOracle NoSQL Databaseのログ・イベントの相関関係について説明します。さらに、これらの障害シナリオからのリカバリ方法について説明します。
パケット・ロス、ラウンド・トリップ平均待機時間およびネットワーク使用率を監視すると、パフォーマンスに影響を与える可能性のある重要なネットワーク・アクティビティや、Oracle NoSQL Databaseで実行中の機能を確認できます。Oracle NoSQL Databaseには、2つの重要なタイプのネットワーク・アクティビティがあります。クライアント・ドライバは、TCP/IP経由でJava RMIを使用して、アプリケーションを実行するマシンと、NoSQL Databaseクラスタのノードを実行するマシンの間で通信します。次に、クラスタの各ノードが互いに通信できる必要があります。レプリケーション・ノードはTCP/IP経由でJava RMIを使用し、さらにTCP/IPでのストリームベース通信も使用します。管理ノードとストレージ・ノード・エージェントは、TCP/IP経由でRMIのみを使用します。予測可能な遅延時間とスループットを維持できる操作ストアを実現するために重要な問題は、これらのノードが通信するネットワークの状態を監視することです。
Oracle NoSQL Databaseが依存するネットワーク・インタフェースの状態を監視する際には、次のツールをお薦めします。
sar、ping、iptraf: これらのオペレーティング・システム・ツールを使用すると、失われたパケット数、ラウンド・トリップ待機時間、ネットワーク使用率などのクリティカルなネットワーク統計が表示されます。ラウンド・トリップ待機時間とパケット・ロスを監視する場合は、スクリプト形式でping
を使用することをお薦めします。ネットワーク使用率を監視する場合は、スクリプト形式でsar
またはiptraf
を使用することをお薦めします。目安としては、ネットワーク使用率が80%を上回ったらアラートを発生させます。
Oracle NoSQL Pingコマンド: Oracle NoSQL管理コンソールには、クラスタの各ノードとの通信を試行するpingコマンドが含まれています。このコマンドの実行方法およびスクリプト記述方法の手順は、http://docs.oracle.com/cd/NOSQL/html/AdminGuide/cli_command_reference.html#commands_subcommandsを参照してください。
NoSQL Databaseのランタイム操作に影響を与えるネットワーク障害は、最終的にJavaランタイム例外のインスタンスとして記録されます。ログ・ファイル監視を使用して、クリティカル・イベントとして認識される正規表現のリストに次の例外文字列が追加されます。これらのイベントのタイムスタンプと任意のネットワーク監視ツールのタイムスタンプとの関連付けが使用されています。
次に示す例外をログ・ファイルで検索する際に、SEVEREのログ・レベルのみが考慮されるようにログ・レベルを確認する必要もあります。これらの例外は、アプリケーションでエラーが検出されないことを示すINFOのレベルで記録されます。
UnknownHostException – NoSQL Databaseの構成が不適切であるか、DNSエラーが発生したため、NoSQL DatabaseのノードのDNSルックアップが失敗しました。NoSQLクラスタがしばらく動作していた後でこのエラーが発生した場合は、アプリケーションとDNSサーバーの間にネットワーク障害が発生した可能性があります。
ConnectException: クライアント・ドライバはNoSQL Databaseノードへの接続をオープンできません。ノードが接続を受けたポートをリスニングしていないか、ファイアウォールによりポートがブロックされています。
ConnectIOException: クライアントとサーバーの間にハンドシェイク・エラーが発生したか、ネットワーク・レイヤーでI/Oエラーが発生した可能性があります。
MarshalException: ネットワーク・レイヤーでI/Oエラーが発生した可能性があります。
UnmarshalException: ネットワーク・レイヤーでI/Oエラーが発生した可能性があります。
NoSuchObjectException: ネットワーク・レイヤーでI/Oエラーが発生した可能性があります。
RemoteException: ネットワーク・レイヤーでI/Oエラーが発生した可能性があります。
デプロイされたOracle NoSQL Databaseインスタンス(KVStoreとも呼ばれる)の管理中に頻繁に発生する障害シナリオは、ディスクに障害が発生して交換が必要になるという状況です。この場合のディスクは通常、ハード・ディスク・ドライブ(HDD)またはソリッド・ステート・ドライブ(SSD)です。HDDには連動する多数の可動部品が採用されているため、ストアが大量の書込みと読取りを実行してディスクとの間で大量のバイト数を移動するときに、ディスクの一部が磨耗しやすくなり、障害が発生することがあります。SSDの場合は可動部品がないため、HDDより障害は発生しにくくなりますが、負荷が非常に高ければ同じように頻繁に障害が発生します。実際、このようなストアでノード(マシン)の数が非常に多くなると、ノードを構成する他のハードウェア・コンポーネントよりもはるかに高い確率で、ディスク障害がほぼ避けられないレベルに到達することがあります。たとえば、このようなシステムに関連するディスクの障害発生頻度は、一般に、システムのマザー・ボードやメモリー・チップ、ネットワーク・インタフェース・カード(NIC)よりも大幅に高くなります。
ディスク障害は頻繁に発生するため、ストアの実行を継続してデータ可用性を維持しながら障害ディスクを交換するための手順が明確に定義されています。
永続ストレージ・デバイスの障害を検出するためのベンダー固有ツールや、同様の機能を実行するSNMP監視エージェントが多数あります。このドキュメントでは、ベンダー固有のメカニズムやSNMPベースの監視メカニズムをお薦めしていません。ただし、障害のある永続ストレージ・デバイスを特定するために実行できる一般的な手順がいくつかあります。
ログ・ファイル監視を使用して、クリティカル・イベントとして認識する必要のある正規表現のリストに次の例外文字列を追加できます。これらのイベントのタイムスタンプと任意のストレージ・デバイス監視ツールのタイムスタンプとの関連付けが使用されています。次に示す例外をログ・ファイルで検索する際に、SEVEREのログ・レベルのみが考慮されるようにログ・レベルを確認する必要もあります。
/var/log/messages内のI/Oエラー: /var/log/messages内のI/Oエラーを監視すると、デバイスに問題があり、障害が発生する可能性があることを確認できます。
smartctl: 使用可能な場合は、smartctlツールを使用すると、永続ストレージ・デバイスに関連する障害が検出され、障害のある特定デバイスのシリアル番号が表示されます。
EnvironmentFailureException: NoSQL Database (Berkeley DB Java Edition)のストレージ・レイヤーによって、ストレージ・デバイスから検出されたJava IOExceptionsがEnvironmentFailureExceptionに変換され、この例外がログ・ファイルに書き込まれます。
次の各項では、2つの一般的なマシン構成の手順について説明します。
KVStoreを実行しながら障害ディスクを交換する方法を理解するために、KVStoreにより格納されるデータとその格納場所を確認します。これは、各マシンのディスク構成や、ストアの容量およびストレージ・ディレクトリの場所がどのように構成されているかによって異なります。たとえば、あるKVStoreが3台のマシン(ストレージ・ノード(SN))に分散されており、レプリケーション係数(RF)が3、各SNの容量が2、KVROOTが/opt/ondb/var/kvroot、ストア名がstore-nameとして設定されているとします。各SNの容量は2であるため、各マシンは2つのレプリケーション・ノード(RN)をホストします。つまり、各SNは2つのJava VMを実行します。それぞれのJava VMは、ストアで管理されているキーと値のデータのレプリケート済インスタンスを格納および取得する役割を持つソフトウェア・サービス(RNサービス)を実行します。
一方のデプロイメントでは、マシン自体(SN)がそれぞれ3つのディスクで構成されており、もう一方のデプロイメントでは、それぞれのSNにデータの書込みと読取りを行うディスクが1つのみあるとします。実験目的で調べる場合であれば2番目の(単一ディスク)シナリオでも問題ありませんが、本番環境では、ディスクの障害や交換が発生する可能性が高いため、この構成はお薦めしません。特に、デプロイヤは、本番環境では、複数のRNサービスによりデータが同じディスクに書き込まれることがないようにする必要があります。ただし、場合によっては、デプロイヤがこのルールをあえて破るような状況もあります。たとえば、(RAIDデバイスのように)ディスクの信頼性が非常に高く、高パフォーマンスで大容量であるために、このディスクを単一のRNサービスで使用すると、推奨される32GBヒープ制限を必ず超えてしまう場合などです。したがって、このような例外的な条件を満たすディスクを使用する環境でないかぎり、デプロイヤは常に、各RNサービスを専用のディスクで構成し、構成や管理のすべての情報、およびシステムで実行されている他のRNサービスにより格納されたデータとは別にできるような環境を選びます。
以下に説明するように、各SNで複数のディスクを使用するようにKVStoreを構成するには、storagedirパラメータを採用して使用可能な個別メディアを利用する必要があります。ここでは、複数ディスク・シナリオだけでなく単一ディスク・シナリオの説明においても、デプロイヤに対してstoragedirパラメータの使用をお薦めしています。ただし、単一ディスクの場合にこのパラメータを使用しても、(共通のデプロイメント・スクリプトを開発できるという点を除いて)デフォルトの場所を使用する場合と比較して大きな利点はありません。これを理解するために、まず、デフォルトのストレージの場所を使用する場合と、storagedirパラメータで指定したデフォルト以外の場所を使用する場合とを比較してみます。
たとえば、(複数ディスク・シナリオまたは単一ディスク・シナリオで)デフォルトの場所を使用して(storagedirパラメータを指定せずに) KVStoreをデプロイしたとします。この場合、どちらのシナリオにおいても、データはKVROOTの下(下の例では/opt/ondb/var/kvroot
)に格納されます。どちらのシナリオでも、次のようなディレクトリ構造が作成されて移入されます。
- Machine 1 (SN1) - - Machine 2 (SN2) - - Machine 3 (SN3) - /opt/ondb/var/kvroot /opt/ondb/var/kvroot /opt/ondb/var/kvroot log files log files log files /store-name /store-name /store-name /log /log /log /sn1 /sn2 /sn3 config.xml config.xml config.xml /admin1 /admin2 /admin3 /env /env /env /rg1-rn1 /rg1-rn2 /rg1-rn3 /env /env /env /rg2-rn1 /rg2-rn2 /rg2-rn3 /env /env /env
この構造を、KVStoreを複数ディスク・マシンにデプロイした場合に作成される構造と比較します(各マシンの3つのディスクの名前は/opt、/disk1および/disk2です)。makebootconfigユーティリティ(『Oracle NoSQL Database管理者ガイド』の第2章のインストール構成に関する項を参照)を使用して、次のようなパラメータで初期ブート構成を作成したとします。
> java -jar KVHOME/lib/kvstore.jar makebootconfig \ -root /opt/ondb/var/kvroot \ -port 5000 \ -admin 5001 \ -host <host-ip> -harange 5010,5020 \ -num_cpus 0 \ -memory_mb 0 \ -capacity 2 \ -storagedir /disk1/ondb/data \ -storagedir /disk2/ondb/data
上に示したブート構成では、各マシンに作成および移入されるディレクトリ構造は次のようになります。
- Machine 1 (SN1) - - Machine 2 (SN2) - - Machine 3 (SN3) - /opt/ondb/var/kvroot /opt/ondb/var/kvroot /opt/ondb/var/kvroot log files log files log files /store-name /store-name /store-name /log /log /log /sn1 /sn2 /sn3 config.xml config.xml config.xml /admin1 /admin2 /admin3 /env /env /env /disk1/ondb/data /disk1/ondb/data /disk1/ondb/data /rg1-rn1 /rg1-rn2 /rg1-rn3 /env /env /env /disk2/ondb/data /disk2/ondb/data /disk2/ondb/data /rg2-rn1 /rg2-rn2 /rg2-rn3 /env /env /env
この場合、構成情報と管理データは、すべてのレプリケーション・データとは別の場所に格納されます。さらに、レプリケーション・データ自体も、それぞれ個別のRNサービスによって別々の物理メディアに格納されます。つまり、各レプリケーション・グループ(またはシャード)のあるメンバーによって格納されるデータは、グループの他のメンバーによって採用されたディスクとは別のディスクに格納されます。
前述のようにこれらの異なる場所にデータを格納すると、障害の分離を実現でき、通常はディスク交換を簡単かつ短時間で行うことができます。つまり、小さいディスクのほうが再移入にかかる時間が少ないため、小さいディスクの使用数を増やすことで、単一ディスク障害からのリカバリにかかる時間を大幅に短縮することが可能になります。ここだけでなく『Oracle NoSQL Database管理者ガイド』の第2章のインストール構成に関する項においても、上に示したような個別の物理メディアまたはディスク・パーティションを利用する構成を強くお薦めしているのは、このような理由からです。
マシンに単一ディスクしか存在しない場合でも、デプロイヤは、複数ディスクの場合と同様の方法でstoragedirパラメータを使用して、レプリケートされたデータが格納される親ディレクトリとは別の親ディレクトリに構成データと管理データを格納できます。この方針はデフォルトではありませんが、単一ディスク・システムと複数ディスク・システムの間で簡単に共有できるデプロイメント・スクリプトを作成できるため、デフォルトの場所(KVROOT)を使用する方法よりも好まれたり、推奨手順とみなされることもあります。このデフォルトでない方針を採用するかどうかは単に好みの問題であり、複数ディスクの間で統一を図れること以外のメリットはありません。
したがって、単一ディスク・システムにこのような方針を適用しても、ディスク交換が簡単になるとはかぎりません。これは、その単一ディスクに障害が発生して交換が必要になった場合、RNにより書き込まれたすべてのデータが使用不可能になるだけでなく、構成(および管理)データも使用不可能になるためです。その結果、ディスクの交換後に(RN)リカバリ・プロセスで構成情報が必要になるため、以前に取得したバックアップからそのデータをリストアする必要があり、ディスク交換プロセスがはるかに複雑になることがあります。本番環境において一般に複数ディスク・システムが推奨されるのは、この理由からです。構成データやその他のシステム・データのみを格納するディスクよりもデータ・ディスクのほうが障害発生の確率がはるかに高いためです。
前述のstoragedirパラメータを使用して、KVStoreを(それぞれ3つのディスクで構成された)一連のマシンにデプロイしたとします。SN3のdisk2に障害が発生し、交換が必要になったとします。この場合、管理者は次の手順を実行します。
正常な管理サービスの1つを介して接続して、KVStore管理コマンドライン・インタフェース(CLI)を実行します。
CLIから次のコマンドを実行します。
kv-> plan stop-service-service rg2-rn3
これによってサービスが停止します。その結果、システムがその特定サービスとの通信を試行する必要がなくなり、管理者がすでに認識している障害に関連するエラー出力量が減ります。
OS、ディスク製品、ハードウェア・プラットフォームに指定されている手順を使用して、disk2を削除します。
適切な手順を使用して新しいディスクをインストールします。
新しいディスクをフォーマットして、前と同じストレージ・ディレクトリ(/disk2/ondb/var/kvroot
)を設定します。
CLIから次のコマンドを実行します。verify configuration
コマンドは、単に対象のRNが動作しているかを確認するためのものです。
kv-> plan start-service -service rg2-rn3 -wait kv-> verify configuration
リカバリ済のRNデータ・ファイルの内容(/disk2/ondb/var/kvroot/rg2-rn3/env/*.jdb
)が正しいことを確認します。
手順2で、id2のレプリケーション・グループに属するidが3のRNサービスは停止されます(rg2-rn3)。前述の手順を使用したときに停止される特定のRNサービスを判別するには、管理者は、どのマシンのどのディスクに障害が発生したか、およびKVStoreのデプロイ中に作成されたディレクトリ構造を把握している必要があります。この場合、管理者はまず標準システムの監視および管理メカニズムを使用して、idが3のSNに対応するマシンでdisk2に障害が発生し、交換が必要であると判断しました。前に示したディレクトリ構造を前提とすると、このデプロイメントでは、ストアによりSN3のdisk2の/disk2b/data/rg2-rn3/en
の下にあるファイルを使用してレプリケート済データが書き込まれることが管理者にはわかっています。その結果、管理者は、障害ディスクを交換する前に名前がrg2-rn3のRNサービスを停止する必要があると判断しました。
手順6でverify configuration
コマンドを実行したときに、すでに停止していたRNサービスが正常に再起動された場合、このコマンドの出力にサービスが正常に動作中であると示されますが、再起動されたRNでそのRNのデータが新しいディスクに完全に移入されたとはかぎりません。これは、障害発生前にディスクに存在していたデータ量によっては、ディスクですべてのデータをリカバリするのに非常に時間がかかることがあるためです。新しいディスクへの再移入中に、追加のネットワーク・トラフィックおよび負荷が発生することがあります。
最後に、手順7は単なる健全性チェックであるため、オプションです。つまり、RNサービスが正常に再起動され、verify configuration
コマンドでRNが正常であると報告された場合、このコマンドの結果は、ディスク交換が成功したことを示す十分な証拠としてみなされます。前述のように、新しいディスクで一部のデータがまだ使用可能になっていなくても、リカバリ対象のRNのレプリケーション・グループ(シャード)の他のメンバーはそのデータを引き続き使用でき、最終的にそのデータは新しいディスクにレプリケートされて使用可能になります。
次に、前述のディスク交換手順を使用した実践的な経験を得ることができる例を示します。この例では、単一ディスクを含む単一マシンを使用した複数ディスク・シナリオをシミュレートします。したがって、ディスクに実際に障害が発生したり、ディスクを物理的に交換することはありません。ディスクの交換時にデータが自動的にリカバリされる仕組みを学習してください。
簡略化するために、KVStoreが/opt/ondb/kv
の下にインストールされているとし(KVHOME=/opt/ondb/kv
)、さらにKVROOT=/opt/ondb/var/kvroot
であるとします(まだこのディレクトリを作成していない場合は作成します)。
> mkdir -p /opt/ondb/var/kvroot
データ・ディスクをシミュレートするために、次のディレクトリを作成します。
> mkdir -p /tmp/sn1/disk1/ondb/data > mkdir -p /tmp/sn1/disk2/ondb/data > mkdir -p /tmp/sn2/disk1/ondb/data > mkdir -p /tmp/sn2/disk2/ondb/data > mkdir -p /tmp/sn3/disk1/ondb/data > mkdir -p /tmp/sn3/disk2/ondb/data
次に、3つのウィンドウ(Win_A、Win_BおよびWin_C)を開きます。これらは3台のマシン(SN)を表します。各ウィンドウでmakebootconfig
コマンドを実行し、構成するSNごとに類似するブート構成を別々に作成します。
Win_A
java -jar /opt/ondb/kv/lib/kvstore.jar makebootconfig \ -root /opt/ondb/var/kvroot \ -host <host-ip> \ -config config1.xml \ -port 13230 \ -harange 13232,13235 \ -admin 13231 \ -memory_mb 100 \ -capacity 2 \ -storagedir /tmp/sn1/disk1/ondb/data \ -storagedir /tmp/sn1/disk2/ondb/data
Win_B
java -jar /opt/ondb/kv/lib/kvstore.jar makebootconfig \ -root /opt/ondb/var/kvroot \ -host <host-ip> \ -config config2.xml \ -port 13240 \ -harange 13242,13245 \ -admin 13241 \ -memory_mb 100 \ -capacity 2 \ -storagedir /tmp/sn2/disk1/ondb/data \ -storagedir /tmp/sn2/disk2/ondb/data
Win_C
java -jar /opt/ondb/kv/lib/kvstore.jar makebootconfig \ -root /opt/ondb/var/kvroot \ -host <host-ip> \ -config config3.xml \ -port 13250 \ -harange 13252,13255 \ -admin 13251 \ -memory_mb 100 \ -capacity 2 \ -storagedir /tmp/sn3/disk1/ondb/data \ -storagedir /tmp/sn3/disk2/ondb/data
これにより、次の3つの構成ファイルが生成されます。
/opt/ondb/var/kvroot /config1.xml /config2.xml /config3.xml
生成された別々の構成を使用して、各ウィンドウからKVStoreストレージ・ノード・エージェント(SNA)の対応するインスタンスを起動します。
Win_A
> nohup java -jar /opt/ondb/kv/lib/kvstore.jar start \ -root /opt/ondb/var/kvroot -config config1.xml &
Win_B
> nohup java -jar /opt/ondb/kv/lib/kvstore.jar start \ -root /opt/ondb/var/kvroot -config config2.xml &
Win_C
> nohup java -jar /opt/ondb/kv/lib/kvstore.jar start \ -root /opt/ondb/var/kvroot -config config3.xml &
最後に、任意のウィンドウ(Win_A、Win_B、Win_Cまたは新しいウィンドウ)から、KVStore管理CLIを使用してストアを構成およびデプロイします。
管理CLIを起動するには、次のコマンドを実行します。
> java -jar /opt/ondb/kv/lib/kvstore.jar runadmin \ -host <host-ip> -port 13230
ストアを構成およびデプロイするには、管理CLIプロンプトから次のコマンドを入力します(文字列<host-ip>を実際のIPアドレスまたはホスト名に置き換えることを忘れないでください)。
configure -name store-name plan deploy-zone -name Zone1 -rf 3 -wait plan deploy-sn -zn 1 -host <host-ip> -port 13230 -wait plan deploy-admin -sn 1 -port 13231 -wait pool create -name snpool pool join -name snpool -sn sn1 plan deploy-sn -zn 1 -host <host-ip> -port 13240 -wait plan deploy-admin -sn 2 -port 13241 -wait pool join -name snpool -sn sn2 plan deploy-sn -zn 1 -host <host-ip> -port 13250 -wait plan deploy-admin -sn 3 -port 13251 -wait pool join -name snpool -sn sn3 change-policy -params "loggingConfigProps=oracle.kv.level=INFO;" change-policy -params cacheSize=10000000 topology create -name store-layout -pool snpool -partitions 100 plan deploy-topology -name store-layout -plan-name RepNode-Deploy -wait
前述のコマンドのリストでは、CLIのコマンド・プロンプト(kv->
)を省いて、コマンドをCLIロード・スクリプトにカット・アンド・ペーストしやすくしています。
前述のコマンドが完了すると(show plans
を使用)、ストアが稼働し、ストアへのデータ書込みの準備が整います。続行する前に、複数ディスク・シナリオの説明で示したディレクトリが展開されていることを確認します。次のようになります。
- Win_A - - Win_B - - Win_C - /opt/ondb/var/kvroot /opt/ondb/var/kvroot /opt/ondb/var/kvroot log files log files log files /example-store /example-store /example-store /log /log /log /sn1 /sn2 /sn3 config.xml config.xml config.xml /admin1 /admin2 /admin3 /env /env /env /tmp/sn1/disk1/ondb/data /tmp/sn2/disk1/ondb/data /tmp/sn3/disk1/ondb/data /rg1-rn1 /rg1-rn2 /rg1-rn3 /env /env /env 00000000.jdb 00000000.jdb 00000000.jdb
キー/値ペアは、ストアに書き込まれるときに、特定のレプリケーション・グループ(シャード)に属する00000000.jdbという名前の(rf=3)ファイルそれぞれに格納されます。たとえば、単一のキー/値ペアがストアに書き込まれるとき、そのペアは次のいずれかのファイルに格納されます。
/tmp/sn1/disk2/ondb/data/rg2-rn1/env/00000000.jdb /tmp/sn2/disk2/ondb/data/rg2-rn2/env/00000000.jdb /tmp/sn3/disk2/ondb/data/rg2-rn3/env/00000000.jdb
あるいは、次のファイルに書き込まれます。
/tmp/sn1/disk1/ondb/data/rg1-rn1/env/00000000.jdb /tmp/sn2/disk1/ondb/data/rg1-rn2/env/00000000.jdb /tmp/sn3/disk1/ondb/data/rg1-rn3/env/00000000.jdb
この時点で、各ファイルにキー/値ペアは含まれていません。データは、最も便利な方法でストアに書き込むことができます。しかし、これを行うための便利なユーティリティの1つに、KVStoreクライアント・シェル・ユーティリティがあります。これは、目的のストアに接続して、対話型コマンドによってキー/値ペアの入力や取得を行うコマンドライン・インタフェースを表示するプロセスです。KVStoreシェルを起動するには、ウィンドウから次のように入力します。
> java -jar /opt/ondb/kv/lib/kvstore.jar runadmin\ -host <host-ip> -port 13230 -store store-name kv-> get -all 0 Record returned. kv-> put -key /FIRST_KEY -value "HELLO WORLD" Put OK, inserted. kv-> get -all /FIRST_KEY HELLO WORLD
キー/値ペアがどのファイルに格納されているかを判別するには、文字列"HELLO WORLD"をgrepで検索する方法が簡単です。これは、ほとんどのLinuxシステムのバイナリ・ファイルに対して実行できます。データの量が少ない例では、この方法でgrep
コマンドを使用するのが実用的です。
> grep "HELLO WORLD" /tmp/sn1/disk1/ondb/data/rg1-rn1/env/00000000.jdb > grep "HELLO WORLD" /tmp/sn2/disk1/ondb/data/rg1-rn2/env/00000000.jdb > grep "HELLO WORLD" /tmp/sn3/disk1/ondb/data/rg1-rn3/env/00000000.jdb > grep "HELLO WORLD" /tmp/sn1/disk2/ondb/data/rg2-rn1/env/00000000.jdb Binary file /tmp/sn1/disk2/ondb/data/rg2-rn1/env/00000000.jdb matches > grep "HELLO WORLD" /tmp/sn2/disk2/ondb/data/rg2-rn2/env/00000000.jdb Binary file /tmp/sn2/disk2/ondb/data/rg2-rn2/env/00000000.jdb matches > grep "HELLO WORLD" /tmp/sn3/disk2/ondb/data/rg2-rn3/env/00000000.jdb Binary file /tmp/sn3/disk2/ondb/data/rg2-rn3/env/00000000.jdb matches
上の例では、ストアに書き込まれたキー/値ペアは、2番目のシャードに属する各RNに格納されています。つまり、各RNは、idが2のレプリケーション・グループ(rg2-rn1、rg2-rn2およびrg2-rn3)のメンバーです。
ある特定のキーがどのシャードに関連付けられているかは、キーの値(具体的にはキーの値のハッシュ)と、ストアで管理されているシャードの数によって決まります。また、この例には00000000.jdbという名前のログ・ファイルが示されていますが、これらのファイルは、対応するRNサービスにより書き込まれたデータを含むこのような(多数存在する可能性がある)ログ・ファイルの最初の一部にすぎません。
現在のログ・ファイルが最大容量に達すると、書き込まれる新しいすべてのデータを格納するための新しいファイルが作成されます。その新規ファイルには、前のファイルの接頭辞を増分することで前のファイルから導出された名前が付けられます。たとえば、00000997.jdb、00000998.jdb、00000999.jdb、00001000.jdb、00001001.jdbなどの名前のファイルが作成されます。
データがストアに書き込まれた後は、障害ディスクをシミュレートし、ディスク交換プロセスを実行できるようになります。障害ディスクをシミュレートするには、コマンド・ウィンドウから、キー/値ペアが書き込まれたストレージ・ディレクトリの1つを選択して、そのストレージ・ディレクトリを削除します。次に例を示します。
> rm -rf /tmp/sn3/disk2
この時点で、SN3のログ・ファイルを調べると、例外が繰り返し記録されていることがわかります。次のようになります。
> tail /opt/ondb/var/kvroot/store-name/log/sn3_0.log rg2-rn3: ProcessMonitor: java.lang.IllegalStateException: Error occurred accessing statistic log file /tmp/sn3/disk2/ondb/data/rg2-rn3/env/je.stat.csv. .......
しかし、クライアント・シェルを使用して、以前に格納されたキー/値ペアを取得する場合、ストアは動作を継続し、書き込まれたデータも引き続き使用可能です。次のようになります。
kvshell-> get -all /FIRST_KEY HELLO WORLD
これで、ディスク交換プロセスを実行できるようになります。KVStore管理CLIが実行されているコマンド・ウィンドウから、次のコマンドを実行します(前述の手順2)。
kv-> plan stop-service -service rg2-rn3 Executed plan 9, waiting for completion... Plan 9 ended successfully kv-> verify configuration ......... Rep Node [rg2-rn3] Status: UNREACHABLE
停止したRNサービスを再起動しようとすると、失敗します。このことは、SN3のログ(file/opt/ondb/var/kvroot/store-name/log/sn3_0.log
)の内容を確認するとわかります。このファイルの内容は、サービスの再起動が繰り返し試行されたが、ディレクトリがないため(つまり、障害ディスクが原因で)、サービスの起動を試行するたびに失敗して、プロセスがERROR状態になったことを示しています。次に例を示します。
kv-> show plans 1 Deploy Zone (1) SUCCEEDED ...... 9 Stop RepNodes (9) SUCCEEDED 10 Start RepNodes (10) ERROR
ここで、ディスクを交換する必要があります。ディスクの交換をシミュレートするために、交換ディスクをインストールしてフォーマットするのと同じ結果にする目的で、rg2-rn3の元の親ディレクトリを作成する必要があります。
> mkdir -p /tmp/sn3/disk2/ondb/data
ディスクが交換されたことになるため、管理CLIからRNサービスを再起動すると成功します。
kv-> plan start-service -service rg2-rn3 -wait Executed plan 11, waiting for completion... Plan 11 ended successfully kv-> verify configuration ......... Rep Node [rg2-rn3] Status: RUNNING,REPLICA at sequence number 327 haPort:13254
データのリカバリが正常に完了したことを確認するには、再度"HELLO WORLD"をgrepで検索します。
> grep "HELLO WORLD" /tmp/sn3/disk2/ondb/data/rg2-rn3/env/00000000.jdb Binary file /tmp/sn3/disk2/ondb/data/rg2-rn3/env/00000000.jdb matches
前述のディスク交換プロセスは、複数ディスクの場合よりデフォルト(および拡大解釈して単一ディスク)の場合のほうが複雑になる可能性があります。その理由を確認するために、デフォルトのストレージ・ディレクトリを使用して上の例を実行してみます。つまり、上のmakebootconfig
コマンドの呼出しからstoragedirパラメータを削除します。これにより、ディレクトリ構造は次のようになります。
/opt/ondb/var/kvroot /opt/ondb/var/kvroot /opt/ondb/var/kvroot log files log files log files /store-name /store-name /store-name /log /log /log /sn1 /sn2 /sn3 config.xml config.xml config.xml /admin1 /admin2 /admin3 /rg1-rn1 /rg1-rn2 /rg1-rn3 /rg2-rn1 /rg2-rn2 /rg2-rn3
同様の例で、この場合の障害ディスクをシミュレートするために、ディレクトリ/opt/ondb/var/kvroot/sn3
(/admin3
データベース、/rg1-rn3
データベースおよび/rg2-rn3
データベースの親)を削除します。
このディレクトリにはSN3の構成も含まれていることに注意してください。SN3の構成情報はレプリケーション・ノード・データベースと同じ親(同じディスクに格納されたその情報と同じ)に含まれているため、前の例で行ったように障害ディスクが交換されると、SN3の構成は使用不可能になり、RNサービスの再起動を試行すると失敗します。レプリケート済データはディスクの交換時にシステム内の他のノードから自動的にリカバリできますが、SNの構成情報は自動的にリカバリできません。このデータは、以前にバックアップしたコピーから手動でリストアする必要があります。このことは、別々のstoragedirパラメータを使用してKVROOTを各RNデータベースの場所から分離する、デフォルトでない単一ディスクの場合にも当てはまります。この場合は、レプリケート済データが別々の場所に格納されても、そのデータは同じ物理ディスクに格納されています。したがって、そのディスクに障害が発生した場合、手動で構成情報を交換ディスクに再インストールするまで、再起動しても構成情報は使用できません。