持続サービス

障害が発生したブローカを復元するには、メッセージの配信処理の状態を作成し直す必要があります。この操作を行うには、ブローカが持続データストアに状態情報を保存する必要があります。ブローカの再起動時、ブローカは保存されたデータを使用して、送信先と永続サブスクリプションを再作成し、持続メッセージを復元して、開いているトランザクションをロールバックし、配信されていないメッセージのルーティングテーブルを再構築します。このあとに、メッセージの配信を再開できます。

Message Queue は、ファイルベースの持続モジュールと JDBC ベースの持続モジュールの両方をサポートしています (図 4–1 を参照)。ファイルベースの持続は、持続データを保存するために個別のファイルを使用し、JDBC ベースの持続では、JDBC™ (Java Database Connectivity) インタフェースを使用し、JDBC 互換のデータストアにブローカを接続します。ファイルベースの持続は一般に JDBC ベースより高速ですが、JDBC 互換ストアによって実現される冗長性や管理者による制御を好むユーザーもいます。ブローカ設定プロパティー imq.persist.store (表 14–4 を参照) は 2 つの持続形式のどちらを使用するかを指定します。

図 4–1 持続データストレージ

ファイルベースの持続

デフォルトで、Message Queue はファイルベースの持続データストアを使用します。これは、メッセージ、送信先、永続サブスクリプション、およびトランザクションなどの持続データを個別のファイルに保存します。ファイルベースの持続に関連するブローカ設定プロパティーについては、「ファイルベースの持続」に示しています。

ファイルベースのストアは、そのデータストアが属するブローカインスタンスの名前 (instanceName) によって識別されるディレクトリに配置されます。

…/instances/instanceName
/fs350/

instances ディレクトリの場所については、付録 A 「プラットフォームごとの Message Queue^TM データの場所」を参照してください。ブローカの各送信先には、その送信先に配信されるメッセージを保持する個別のサブディレクトリがあります。

持続データストアには機密事項を扱うメッセージや財産的価値のあるメッセージが含まれることがあるため、…/instances/ instanceName/fs350/ ディレクトリは承認されていないアクセスから保護するようにしてください。「持続データの保護」を参照してください。

メッセージ以外の持続データは、すべて個別のファイルに格納されます。送信先、永続サブスクリプション、トランザクション状態情報のファイルがあります。大半のメッセージは、可変長レコードから構成されるシングルファイルに格納されます。可変長レコードファイルを圧縮し、メッセージが追加および削除されたときの断片化を緩和することができます (「物理的送信先の圧縮」を参照)。さらに、特定のしきい値を超えるサイズのメッセージは、可変長レコードファイルではなく、個別のファイルに格納されます。このしきい値のサイズは、ブローカプロパティー imq.persist.file.message.max_record_size で設定できます。

ブローカは、これらの各メッセージファイル用のファイルプールを維持します。ファイルは必要なくなった場合にも削除されず、送信先ディレクトリの空きファイルのプールに戻されるため、あとで別のメッセージに再利用できます。ブローカプロパティー imq.persist.file.destination.message.filepool.limit はプール内のファイルの最大数を指定します。送信先の各メッセージファイル数がこの制限を超えた場合、ファイルが不要になると、プールに戻されずに削除されます。

ファイルをファイルプールに戻すと、ブローカは前の内容を削除せずに、再利用可能なファイルとしてタグ付けすることにより、保存領域と引き換えに時間を節約できます。imq.persist.file.message.filepool.cleanratio ブローカプロパティーを使用して、単に再利用可能とマークするだけでなく、「クリーン」(空き) 状態で維持する必要がある各送信先のファイルプール内のファイルのパーセンテージを指定します。この値を大きくするほど、ファイルプールに必要な領域は少なくなりますが、ファイルをプールに戻す際にファイルの内容を空にするために必要なオーバーヘッドが大きくなります。ブローカの imq.persist.file.message.cleanup プロパティーが true の場合、ブローカのシャットダウン時にプール内のすべてのファイルが空にされ、クリーン状態のままにされるため、保存領域は節約できますが、シャットダウンの処理速度が遅くなります。

持続ストアへのデータの書き込みにおいて、オペレーティングシステムには、データを同時に書き込むか、または「レイジー」(非同期的) に書き込むかを選択できます。レイジーストレージでは、システムクラッシュの発生時に、ブローカが持続ストレージにデータが書き込まれていなくても書き込まれたものと考えた場合に、データが損失する可能性があります。パフォーマンスと引き換えに、完全な信頼性を確保するために、ブローカプロパティー imq.persist.file.sync.enabled を true に設定して、すべてのデータを同時に書き込むように要求できます。この場合、システムがクラッシュ後に回復した際に、データの利用が保証されるため、ブローカは確実に処理を再開できます。ただし、データは失われませんが、クラスタ構成のブローカでは現在データを共有していないため、クラスタ内のほかのブローカからは使用できません。

JDBC ベースの持続

ファイルベースの持続を使用する代わりに、JDBC 互換ドライバを介してアクセスが可能な任意のデータストアにアクセスするように、ブローカを設定できます。この作業には、該当する JDBC 関連のブローカ設定プロパティーの設定、データベースマネージャーユーティリティー (imqdbmgr) を使用した適切なスキーマでのデータストアの作成が含まれます。仕様については、「JDBC ベースのストアの設定」を参照してください。

JDBC データベースを使用するように、ブローカを設定するプロパティーについては、「JDBC ベースの持続」を参照してください。これらのプロパティーを指定するには、各ブローカインスタンスのインスタンス設定ファイル (config.properties) を使用するか、ブローカユーティリティー (imqbrokerd) またはデータベースマネージャーユーティリティー (imqdbmgr) に -D コマンド行オプションを使用します。

imq.persist.jdbc.driver プロパティーは、データベースへの接続に使用する JDBC ドライバの Java クラス名を指定します。既存のデータベースへの接続 (imq.persist.jdbc.opendburl)、新しいデータベースの作成 (imq.persist.jdbc.createdburl)、およびデータベース接続のクローズ (imq.persist.jdbc.closedburl) のための URL を指定するプロパティーもあります。

imq.persist.jdbc.user および imq.persist.jdbc.password プロパティーは、データベースにアクセスするためのユーザー名とパスワードを指定し、imq.persist.jdbc.needpassword はパスワードが必要かどうかを指定するブール型のフラグです。セキュリティー上の理由から、パスワードは、-passfile コマンド行オプションで指定するパスワードファイルにのみ指定する必要があります。そうしたパスワードファイルを指定しないと、imqbrokerd および imqdbmgr コマンドではインタラクティブにパスワードの入力が要求されます。同様に、imqbrokerd コマンドに -dbuser オプション、または imqdbmgr コマンドに -u オプションを使用して、コマンド行からユーザー名を指定できます。

複数のブローカインスタンスによって共有される JDBC データベースでは、設定プロパティー imq.persist.jdbc.brokerid は、データベーステーブル名に追加される各データベースの一意のインスタンス識別子を指定します。このプロパティーは、1 つのブローカインスタンスのデータのみを格納する組み込みデータベースでは、一般に必要ありません。その他の JDBC 関連の設定プロパティーは、データベーススキーマを作成する SQL コードをカスタマイズするために使用し、1 つのプロパティーが 1 つのデータベーステーブルに対応します。たとえば、imq.persist.jdbc.table.IMQSV35 プロパティーはバージョンテーブル、imq.persist.jdbc.table.IMQCCREC35 は設定変更レコードテーブル、imq.persist.jdbc.table.IMQDEST35 は送信先テーブルを作成するための SQL コマンドを指定します。すべてのリストについては、表 14–6 を参照してください。

データベースシステムによって、必要とされる正確な SQL 構文が異なるため、詳細についてはデータベースベンダーのマニュアルを参照してください。