| Oracle® TimesTen In-Memory Database TimesTen to TimesTen開発者および管理者ガイド リリース11.2.1 B56053-02 |
|
 戻る |
 次へ |
| Oracle® TimesTen In-Memory Database TimesTen to TimesTen開発者および管理者ガイド リリース11.2.1 B56053-02 |
|
戻る |
次へ |
この章では、高可用性システムの設計方法およびレプリケーション・スキームの定義方法について説明します。内容は次のとおりです。
レプリケーションに必要な帯域幅の量を減らす方法については、「レプリケートの通信量の圧縮」を参照してください。
アクティブ・スタンバイ・ペアを計画する場合は、次の制限に注意してください。
サブスクライバ・データベースは、最大127まで指定できます。
高可用性を実現するには、マスター・データベースおよびサブスクライバ・データベースがそれぞれ異なるノードにある必要があります。
アクティブ・データベースとスタンバイ・データベースは、同じLAN上に存在する必要があります。
アクティブ・ノードとスタンバイ・ノード間の時間誤差は、250ミリ秒を超えることはできません。
初期設定の場合、スタンバイ・データベースの作成は、ttRepAdmin -duplicateユーティリティまたはttRepDuplicateEx C関数を使用してアクティブ・データベースを複製する方法でのみ行うことができます。
読取り専用サブスクライバは、スタンバイ・データベースを複製することでのみ作成できます。スタンバイ・データベースを使用できない場合は、アクティブ・データベースを複製することで読取り専用サブスクライバを作成できます。「データベースの複製」を参照してください。
フェイルオーバー後は、アクティブ・データベースを複製することでのみ、アクティブ・データベースから新しいスタンバイ・データベースをリカバリできます（アクティブ・データベースとスタンバイ・データベース間でRETURN TWOSAFEレプリケーションが使用されていない場合）。RETURN TWOSAFEレプリケーションが使用されている場合は、かわりにマスターの自動キャッチアップ機能を使用できます。「障害が発生したマスター・データベースの自動キャッチアップ」を参照してください。
スタンバイ・データベースおよびサブスクライバ・データベースでは、レプリケーション表に対して処理を実行できません。ただし、順序およびXLAブックマークに対する処理は実行できます。
スタンバイ・データベースから読取り専用サブスクライバへのレプリケーションが非同期で実行されます。
ALTER ACTIVE STANDBY PAIR文は、アクティブ・データベースでのみ実行できます。アクティブ・データベースでALTER ACTIVE STANDBY PAIRを実行する場合は、アクティブ・データベースを複製してスタンバイ・データベースを再生成する必要があります。また、すべてのサブスクライバを、スタンバイ・データベースから再生成する必要があります。詳細は、「アクティブ・データベースとスタンバイ・データベースの役割の入替え」を参照してください。
アクティブ・スタンバイ・ペアを定義する前に、アクティブ・データベース、スタンバイ・データベースおよび読取り専用サブスクライバ・データベースのDSNを定義する必要があります。LinuxまたはUNIXの場合は、odbc.iniファイルを作成します。Windowsの場合は、ODBCアドミニストレータを使用し、データベースを指定して接続属性を設定します。例については、「手順1: マスター・データベースおよびサブスクライバ・データベースのDSNの作成」を参照してください。
レプリケーション・スキームで指定された各データベースの名前は、そのデータベースのDSN定義内のDataStoreデータ・ストア属性で指定された、パスを除くデータベース・ファイル名の接頭辞と一致する必要があります。Data Source Nameデータ・ストア属性で指定された名前を使用しているレプリケーション・スキームは機能しません。混乱を避けるには、各DSN定義内のDataStoreデータ・ストア属性とData Source Nameデータ・ストア属性に同じ名前を使用します。たとえば、データベースのパスがdirectory/subdirectory/foo.ds0の場合、使用するデータベース名はfooになります。
アクティブ・スタンバイ・ペアのレプリケーション・スキームは、SQL文CREATE ACTIVE STANDBY PAIRを使用して作成します。CREATE ACTIVE STANDBY PAIR文の完全な構文については、『Oracle TimesTen In-Memory Database SQLリファレンス・ガイド』を参照してください。
CREATE ACTIVE STANDBY PAIR文を使用して他のレプリケーション処理を実行するには、ADMIN権限が必要です。
表3-1に、アクティブ・スタンバイ・ペアのレプリケーション・スキームのコンポーネントおよびこの章の内容に関連するパラメータを示します。
表3-1 アクティブ・スタンバイ・ペアのレプリケーション・スキームのコンポーネント
| コンポーネント | 参照先 |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
「レプリケーションに対するデータベース・オブジェクトの挿入または除外」 |
「データベースのDSNの定義」で説明されている完全なデータベース名を使用します。最初のデータベース名は、アクティブ・データベースを指定します。2番目のデータベース名は、スタンバイ・データベースを指定します。読取り専用サブスクライバ・データベースは、SUBSCRIBER句によって識別されます。
また、IPアドレスまたは二重引用符で囲まれたホストのリテラル名を使用して、データベースが存在するホストを指定できます。
高可用性システムを実現するには、アクティブ・データベースとスタンバイ・データベースは別々のホストに存在する必要があります。読取り専用のサブスクライバは、ローカルまたはリモートのいずれにもできます。リモート・サブスクライバによって、サイト固有の障害から保護されます。
FullDatabaseNameの一部としてオプションのホストIDを指定できます。
DatabaseName [ON Host]
Hostには、IPアドレスまたはホストのリテラル名を使用します。ホスト名は二重引用符で囲むことをお薦めします。
RETURNサービスを指定してレプリケーション・スキームを構成すると、レプリケーション・データが、アクティブ・データベースおよびスタンバイ・データベース上で一貫していることをより高いレベルの信頼性を持って保証できます。「データベース間の更新のコピー」を参照してください。この項では、RETURN RECEIPTおよびRETURN TWOSAFEサービスの構成方法および管理方法について説明します。デフォルトはNO RETURN（非同期レプリケーション）で、最高のパフォーマンスが実現します。
次の各項では、次に示すRETURNサービス句について説明します。
TimesTenでは、アプリケーションをレプリケーション・メカニズムと疎結合または同期するためにオプションのRETURN RECEIPTサービスが提供されています。
RETURN RECEIPT句を指定して、スタンバイ・データベースのRETURN RECEIPTサービスを有効にできます。RETURN RECEIPTが有効になっている場合、アプリケーションがアクティブ・データベースの要素に対するトランザクションをコミットすると、スタンバイがトランザクション更新の受信を確認するまでブロックされたままになります。
構成可能なタイムアウト時間内にスタンバイでトランザクションの受信を確認できない場合、アプリケーションは、コミット・リクエストに対するtt_ErrRepReturnFailed (8170)警告を受信します。RETURNサービス・タイムアウト時間の詳細は、「RETURNサービス・タイムアウト時間の設定」を参照してください。
ttRepXactStatusプロシージャを使用してRETURN RECEIPTトランザクションのステータスを確認できます。詳細は、「RETURNサービス・トランザクションのステータスの確認」を参照してください。
また、タイムアウトが特定の回数発生した後、RETURN RECEIPTサービスを無効にするようにレプリケーション・エージェントを構成できます。詳細は、「RETURNサービス・タイムアウト・エラーの管理」を参照してください。
RETURN RECEIPTは、すべてのトランザクションに対して受信の通知を有効にします。BY REQUEST句を指定してRETURN RECEIPTを使用すると、アプリケーションで識別される特定のトランザクションに対してのみ受信通知を有効にできます。
RETURN RECEIPT BY REQUESTを指定する場合は、ttRepSyncSetプロシージャを使用して、トランザクションに対してRETURN RECEIPTサービスを有効にする必要があります。RETURN RECEIPTサービスを有効にするコールは、トランザクションの一部である必要があります（AutoCommitは無効である必要があります）。
構成可能なタイムアウト時間内にスタンバイ・データベースでトランザクション更新の受信を確認できない場合、アプリケーションは、コミット・リクエストに対するtt_ErrRepReturnFailed (8170)警告を受信します。RETURNサービス・タイムアウト時間の詳細は、「RETURNサービス・タイムアウト時間の設定」を参照してください。
ttRepSyncGetを使用して、RETURNサービスが有効になっているかどうかを確認し、タイムアウト値を取得できます。次に例を示します。
Command> CALL ttRepSyncGet(); < 01, 45, 1> 1 row found.
TimesTenでは、アプリケーションをレプリケーション・メカニズムと完全に同期するために、RETURN TWOSAFEサービスが提供されています。RETURN TWOSAFEサービスの場合、各レプリケーション・トランザクションは、アクティブ・データベースでコミットされる前にスタンバイ・データベースでコミットされます。スタンバイでトランザクションがコミットされたかどうかをレプリケーションで確認できなかった場合は、エラー通知が返されます。エラー受信後、アプリケーションで、障害のタイプに応じて、固有のアクションまたは事前に構成されているアクションのいずれかを実行できます。
レプリケーションがRETURN TWOSAFEで構成されている場合は、自動コミット・モードを無効にする必要があります。
構成可能なタイムアウト時間内にスタンバイでトランザクション更新のコミットを確認できない場合、アプリケーションは、コミット・リクエストに対するtt_ErrRepReturnFailed (8170)警告を受信します。RETURNサービス・タイムアウト時間の詳細は、「RETURNサービス・タイムアウト時間の設定」を参照してください。
RETURN TWOSAFEは、すべてのトランザクションに対してスタンバイ・データベースでのコミットの通知を有効にします。BY REQUEST句を指定してRETURN TWOSAFEを使用すると、アプリケーションで識別される特定のトランザクションのみに関するスタンバイでのコミットの通知を有効にできます。
スタンバイ・データベースにRETURN TWOSAFE BY REQUESTを指定する場合は、ttRepSyncSetプロシージャを使用して、トランザクションに対してRETURN TWOSAFEサービスを有効にする必要があります。RETURN TWOSAFEサービスを有効にするコールは、トランザクションの一部である必要があります（autocommitは無効である必要があります）。
タイムアウト時間内にスタンバイでトランザクションのコミットを確認できない場合、アプリケーションは、コミット・リクエストに対するtt_ErrRepReturnFailed (8170)警告を受信します。その後、アプリケーションは、「RETURN TWOSAFE」で説明されている方法と同じ方法でタイムアウトを処理することを選択できます。
ALTER TABLE文を使用して、TWOSAFE BY REQUESTトランザクションの一部であるレプリケート表を変更することはできません。DDLCommitBehavior=1の場合、この処理によってエラー8051が発生します。DDLCommitBehavior=0の場合、ALTER TABLE処理の前にコミットが実行されるため、この処理は成功します。これにより、ALTER TABLE処理は、TWOSAFE BY REQUESTトランザクションの一部ではない新規トランザクションとなりまます。
RETURNサービス・タイムアウト時間の設定の詳細は、「RETURNサービス・タイムアウト時間の設定」を参照してください。
ttRepSyncGetを使用して、RETURNサービスが有効になっているかどうかを確認し、タイムアウト値を取得できます。次に例を示します。
Command> CALL ttRepSyncGet(); < 01, 45, 1> 1 row found.
表3-2に、CREATE ACTIVE STANDBY PAIR文のオプションのSTORE属性を示します。
表3-2 STORE属性の説明
| STORE属性 | 説明 |
|---|---|
|
|
「RETURNサービス障害/リカバリ・ポリシーの設定」を参照してください。 |
|
|
レプリケーションが無効になっている場合のRETURNサービスのオンまたはオフを設定します。 「RETURNサービス障害/リカバリ・ポリシーの設定」を参照してください。 |
|
|
RETURNサービス・ブロッキングが 「RETURNサービス障害/リカバリ・ポリシーの設定」を参照してください。 |
|
|
RETURNサービスの応答を待機する時間（秒）を指定します。値が0（ゼロ）の場合は、待機なしを意味します。デフォルト値は10秒です。 このタイムアウト設定は、アプリケーションから 「RETURNサービス・タイムアウト時間の設定」を参照してください。 |
|
|
「DURABLE COMMIT」を参照してください。 |
|
|
タイムアウト発生時にRETURNサービス・トランザクションで実行されるデフォルトのアクションを指定します。オプションは次のとおりです。
「LOCAL COMMIT ACTION」を参照してください。 |
|
|
レプリケートの通信量を圧縮して、ネットワーク帯域幅の使用量を減らします。 「レプリケートの通信量の圧縮」を参照してください。 |
|
|
別のデータベースからの更新をリスニングするためにデータベースで使用されるポート番号を設定します。 アクティブ・スタンバイ・ペアでは、スタンバイ・データベースは、アクティブ・データベースからの更新をリスニングします。読取り専用サブスクライバは、スタンバイ・データベースからの更新をリスニングします。
「ポート割当て」を参照してください。 |
|
|
応答のないデータベースにメッセージを再送信する前にデータベースが待機する最大時間（秒）を設定します。 アクティブ・スタンバイ・ペアでは、アクティブ・データベースは、スタンバイ・データベースにメッセージを送信します。スタンバイ・データベースは、読取り専用サブスクライバにメッセージを送信します。 「RETURNサービス・タイムアウト時間の設定」を参照してください。 |
|
|
ログ障害しきい値を設定します。 「ログ障害しきい値の設定」を参照してください。 |
この項の後半では、次の内容について説明します。
レプリケーション・スキームが「RETURNサービスの使用」で説明されているいずれかのRETURNサービスで構成されていると、TIMEOUTで指定した時間内にスタンバイ・データベースがアクティブ・データベースに確認応答を送信できない場合にタイムアウトが発生します。
デフォルトのRETURNサービス・タイムアウト時間は10秒です。異なるRETURNサービス・タイムアウト時間は、次の方法で指定できます。
CREATE ACTIVE STANDBY PAIR文またはALTER ACTIVE STANDBY PAIR文にRETURN WAIT TIMEを指定します。RETURN WAIT TIMEが0（ゼロ）の場合は、待機なしを示します。
returnWaitパラメータの新しい値を指定してttRepSyncSetプロシージャをコールし、異なるRETURNサービス・タイムアウト時間をプログラムで指定します。
タイムアウト時間は、設定後、再設定するか、またはアプリケーション・セッションが終了するまで、後続のすべてのRETURNサービス・トランザクションに適用されます。
RETURNサービスは、レプリケーション障害が発生した場合、またはレプリケーションに時間がかかりすぎて、レプリケートされる前にRETURNサービス・トランザクションがタイムアウトした場合にタイムアウトします。ただし、レプリケーション障害が同時に発生しないかぎり、スタンバイからRETURNサービスの確認を取得することに失敗しても、トランザクションがレプリケートされていないこと、または将来レプリケートされないことを意味しない場合もあります。
他のSTORE属性を設定して、タイムアウトが過剰に発生する場合にRETURNサービス・ブロッキングを自動的に無効にし、状況が改善されるとRETURNサービス・ブロッキングを再度有効にするポリシーを設定できます。詳細は、「RETURNサービス・タイムアウト・エラーの管理」を参照してください。
タイムアウト時間内にスタンバイ・データベースでアクティブ・データベースからのトランザクションの更新を確認できない場合、アプリケーションは、コミット・リクエストに対するerrRepReturnFailed警告を受信します。
デフォルトのRETURNサービス・タイムアウト時間は10秒です。異なるタイムアウト時間は、次の方法で指定できます。
CREATE ACTIVE STANDBY PAIR文のSTORE句で、RETURN WAIT TIME句を使用します。
RETURNサービスは、レプリケーション障害が発生した場合、またはレプリケーションに時間がかかりすぎて、レプリケートされる前にRETURNサービス・トランザクションがタイムアウトした場合にタイムアウトまたは失敗します。ただし、レプリケーション障害が同時に発生しないかぎり、サブスクライバからRETURNサービスの確認を取得することに失敗しても、トランザクションがレプリケートされていないこと、または将来レプリケートされないことを意味しません。
RETURNサービス・タイムアウトには次の方法で応答できます。
レプリケーションが停止した場合、またはレプリケート・システムのパフォーマンスにRETURNサービス・タイムアウト障害が悪影響を及ぼし始めた場合は、なんらかの方法で対処する必要があります。RETURNサービス・タイムアウトの許容しきい値は、特定のアプリケーションのタイムアウトの履歴頻度およびパフォーマンス/可用性の関係によって異なります。問題に対処する場合、これらの両方の要素について考慮する必要があります。
RETURN RECEIPTサービスを使用している場合、次の方法で手動により対処できます。
ALTER ACTIVE STANDBY PAIR文を使用して、RETURN RECEIPTブロッキングを無効にします。
ttDurableCommit組込みプロシージャをコールし、スタンバイで受信されたかどうかを確認できなくなったアクティブ・データベースのトランザクションを永続的にコミットします。
RETURN RECEIPTブロッキングを無効にすると決めた場合、これを再度有効にするという判断は、RETURN RECEIPTトランザクションがタイムアウトしないと確信できるレベルに基づいて行います。
手動でRETURNサービス・タイムアウト障害に対処するかわりに、RETURNサービス障害およびリカバリ・ポリシーをレプリケーション・スキームに設定して対処することもできます。これらのポリシーは、レプリケーション状態の変化の検出およびRETURNサービス・タイムアウトの追跡を行い、事前に設定した方法で自動的に対処するようにレプリケーション・エージェントに直接指示します。
RETURN RECEIPTまたはRETURN TWOSAFEサービスを使用する場合は、CREATE ACTIVE STANDBY PAIR文の次の属性によって障害/リカバリ・ポリシーを設定します。
これらの属性によって設定したポリシーは、データベースの存続期間中、または変更されるまで適用されます。これらのポリシーが施行されるには、レプリケーション・エージェントが稼働している必要があります。
レプリケーションが停止した場合は、RETURN SERVICES {ON | OFF} WHEN [REPLICATION] STOPPED属性によって、RETURN RECEIPTまたはRETURN TWOSAFEサービスを継続して有効にするか、無効にするかが決定されます。このコンテキストでの停止とは、（ttAdmin -repStop activeなどによって）アクティブ・レプリケーション・エージェントが停止されたこと、または（ttRepAdmin -state stop standbyなどによって）スタンバイ・データベースのレプリケーション状態がアクティブ・データベースに対してStopまたはPauseに設定されることを意味しています。指定したFAILTHRESHOLD値を超えている障害が発生したスタンバイは、Failed状態に設定されますが、最終的にはマスター・レプリケーション・エージェントによってStop状態に設定されます。
|
注意: スタンバイ・データベースは、RETURN WAIT TIMEで指定されたタイムアウト時間を超えるとその期間中は使用できなくなりますが、マスター・レプリケーション・エージェントでは継続してStart状態であるとみなされます。タイムアウトに関連する障害ポリシーは、DISABLE RETURN属性によって設定されます。 |
RETURN SERVICES OFF WHEN REPLICATION STOPPEDは、レプリケーションが停止すると、RETURNサービスを無効にします。これは、RETURN RECEIPTサービス使用時のデフォルト設定です。RETURN SERVICES ON WHEN REPLICATION STOPPEDは、レプリケーションが停止した場合でもRETURNサービスを継続して有効にできます。これは、RETURN TWOSAFEサービス使用時のデフォルト設定です。
DISABLE RETURN値を設定すると、データベースは、RETURN WAIT TIMEで設定されたタイムアウト時間を超えているRETURN RECEIPTトランザクションおよびRETURN TWOSAFEトランザクションの数を追跡します。タイムアウト数がDISABLE RETURNで設定した最大値を超えると、アプリケーションは、デフォルトのレプリケーション・サイクルに戻り、レプリケート対象の更新に対するスタンバイからの確認応答を待機しなくなります。
SUBSCRIBERを指定することは、ALLを指定することと同じです。どちらの設定でも、スタンバイ・データベースが参照されます。
DISABLE RETURN障害ポリシーは、レプリケーション・エージェントが稼働している場合にのみ有効になります。DISABLE RETURNが指定され、RESUME RETURNが指定されない場合、データベースのレプリケーション・エージェントが再起動されるまでRETURNサービスはオフのままです。この障害ポリシーを停止するには、レプリケーション・エージェントを停止し、NumFailuresの値を0（ゼロ）にしてDISABLE RETURNを指定します。障害ポリシーをトリガーするタイムアウトのカウントは、レプリケーション・エージェントを再起動したとき、DISABLE RETURN値を0に設定したとき、またはRETURNサービス・ブロッキングがRESUME RETURNによって再度有効にされたときにリセットされます。
RETURNサービス・ブロッキングが無効であるとは、マスター・データベースのアプリケーションが、レプリケーション更新を受信またはコミットしたサブスクライバからの確認応答を待機している間、実行をブロックしないことを意味します。ただし、マスターは、レプリケート対象の更新の各バッチについてスタンバイ・データベースからの確認応答をリスニングしていることに注意してください。
RETURNサービス・リカバリ・ポリシーは、RESUME RETURN属性を設定し、再開待機時間の値を指定して設定できます。この属性が設定され、スタンバイ・データベースに対するRETURNサービス・ブロッキングが無効になっている場合に、トランザクションのコミット確認応答時間がRESUME RETURNで設定した値より小さくなると、RETURN RECEIPTまたはRETURN TWOSAFEサービスが再開されます。コミット確認応答時間とは、アプリケーションがコミットを実行してから、マスターがサブスクライバから更新の確認応答を受信するまでの待機時間のことです。
RESUME RETURNポリシーは、レプリケーション・エージェントが稼働している場合にのみ有効になります。RETURN RECEIPT再開ポリシーは、レプリケーション・エージェントを停止した後、ALTER ACTIVE STANDBY PAIRを使用してRESUME RETURNを0（ゼロ）に設定して取り消すことができます。
DURABLE COMMIT属性を設定して、DISABLE RETURNでRETURNサービス・ブロッキングを無効にしたアプリケーションに永続コミット・ポリシーを指定できます。DURABLE COMMITをONに設定すると、マスター・データベースのDurableCommits一般接続属性が上書きされ、RETURNサービス・ブロッキングを無効にしたトランザクションに対して永続コミットが強制実行されます。
RETURN SERVICES ON WHEN REPLICATION STOPPEDを指定してレプリケーション・スキームを構成した場合、DURABLE COMMITポリシーが施行されるには、レプリケーション・エージェントが稼働している必要があります。
RETURN TWOSAFEサービスを使用している場合、LOCAL COMMIT ACTIONを設定して、タイムアウト時のマスター・レプリケーション・エージェントの応答方法を指定できます。ttRepSyncSetプロシージャでlocalActionパラメータをコールすることによって、特定のトランザクションに対して設定を無効にすることができます。
RETURN TWOSAFEトランザクションのレプリケーション中にタイムアウトを受信した場合に、実行可能なアクションは次のとおりです。
COMMIT: タイムアウト発生時に、アクティブ・データベース上のレプリケーション・エージェントがトランザクションをコミットし、トランザクションでそれ以上の処理ができなくなります。
NO ACTION: タイムアウト発生時に、アクティブ・データベース上のレプリケーション・エージェントはトランザクションをコミットしません。プロセス・リカバリがトランザクションをコミットします。これは、強制コミットに相当します。
低帯域幅のネットワークを介してレプリケーションを行う場合、または大量のデータのレプリケーションを行う場合は、レプリケーションに必要な帯域幅の量を減らすCOMPRESS TRAFFIC属性を設定できます。COMPRESS TRAFFIC属性を使用すると、CREATE ACTIVE STANDBY PAIR文またはALTER ACTIVE STANDBY PAIR文のSTOREパラメータで指定されたデータベースからレプリケートされたデータが圧縮されます。TimesTenでは、他のデータベースからの通信量は圧縮されません。
圧縮アルゴリズムは速度に関しては最適化されますが、COMPRESS TRAFFIC属性を有効にすると、レプリケーションのスループットおよび待機時間になんらかの影響があります。
PORT属性を割り当てない場合、TimesTenデーモンが動的にポートを選択します。ポートがこの方法でレプリケーション・エージェントに動的に割り当てられる場合は、TimesTenデーモンのポートも一致させる必要があります。
ポートを静的に割り当てる場合は、CREATE ACTIVE STANDBY PAIR文のSTORE属性に完全なホスト名、DSNおよびポートを指定する必要があります。
しきい値を設定できます。この値を超えると、使用可能なログ領域を使い果たす前に、使用不可能なスタンバイ・データベースまたは読取り専用サブスクライバがFailed状態に設定されます。
ログしきい値を設定するには、CREATE ACTIVE STANDBY PAIR文またはALTER ACTIVE STANDBY PAIR文のSTORE句にFAILTHRESHOLD値を指定します。デフォルトのしきい値は0（ゼロ）で、「制限なし」を意味します。
アクティブ・データベースは、スタンバイ・データベースまたは読取り専用サブスクライバをFailed状態に設定すると、障害が発生したデータベースのすべてのデータをログから削除し、障害が発生したデータベースにメッセージを送信します。アクティブ・レプリケーション・エージェントが障害の発生したデータベースのレプリケーション・エージェントと通信できる場合、メッセージはすぐに送信されます。そうでない場合、メッセージは接続の再開時に送信されます。
障害が発生したデータベースに接続中のアプリケーションは、データベースがレプリケーション・ピアによってFailedとマークされたことを示すtt_ErrReplicationInvalid (8025)警告を受信します。データベースにその障害状態が通知されると、アクティブ・データベースでのその状態はFailedからStopに変更されます。
アプリケーションでは、ODBCのSQLGetInfo関数を使用して、アプリケーションが接続中のデータベースがFailed状態に設定されているかどうかを確認できます。
レプリケーション・ホストにネットワーク・インタフェースが複数ある場合は、デフォルト以外のインタフェースを使用するようにレプリケーションを構成することもできます。データベース名を指定するときに、オペレーティング・システムのhostnameコマンドが返すホスト名を指定する必要はありますが、ROUTE句を使用することで、別のインタフェースでトラフィックを送受信するようにレプリケーションを構成できます。
ROUTE句の構文は次のようになります。
ROUTE MASTER FullDatabaseName SUBSCRIBER FullDatabaseName {{MASTERIP MasterHost | SUBSCRIBERIP SubscriberHost} PRIORITY Priority} [...]
ROUTE句のコンテキストでは、各マスター・データベースは他のマスター・データベースのサブスクライバであり、各読取り専用サブスクライバは両方のマスター・データベースのサブスクライバです。
例3-4 複数のネットワーク・インタフェースの構成
ホストmachine1にはホスト名machine1fastでアクセス可能な2つ目のインタフェースが構成されており、machine2にはIPアドレス192.168.1.100でアクセス可能な2つ目のインタフェースが構成されている場合、次のようにすると、2つ目のインタフェースをレプリケーション・スキームで使用するように指定できます。
CREATE ACTIVE STANDBY PAIR dns1, dsn2
ROUTE MASTER dsn1 ON "machine1" SUBSCRIBER dsn2 ON "machine2"
MASTERIP "machine1fast" PRIORITY 1
SUBSCRIBERIP "192.168.1.100" PRIORITY 1
ROUTE MASTER dsn2 ON "machine2" SUBSCRIBER dsn1 ON "machine1"
MASTERIP "192.168.1.100" PRIORITY 1
SUBSCRIBERIP "machine1fast" PRIORITY 1;
また、インタフェースが複数あるレプリケーション・ホストでは、プライマリ・インタフェースに障害が発生したり、そのインタフェースと受信ホストとの間の接続が切断した場合に備えて、1つ以上のインタフェースをバックアップとして使用するようにレプリケーションを構成できます。ROUTE句を使用すると、それぞれのマスターおよびサブスクライバに対して複数のインタフェースを指定し、優先順位に従ってレプリケーションで使用することができます。
マスター・ホストのレプリケーションが、優先順位の最も高いMASTERIPにバインドできなかった場合は、次の優先順位のMASTERIPアドレスを使用して接続が試行されます。ただし、サブスクライバへの接続がなんらかの理由で失敗した場合は、次に優先順位の高いMASTERIPアドレスを試す前に、それぞれのSUBSCRIBERIPアドレスを優先順に使用して接続が試行されます。
例3-5 ネットワーク優先順位の構成
ホストmachine1に2つのネットワーク・インタフェース（IPアドレスは192.168.1.100と192.168.1.101）が構成され、ホストmachine2に2つのインタフェース（IPアドレスは192.168.1.200と192.168.1.201）が構成されている場合は、まずIPアドレス192.168.1.100と192.168.1.200を使用してトラフィックの送受信を行い、その接続に障害が発生したときにIPアドレス192.168.1.101または192.168.1.201を試行するようにレプリケーションを設定できます。
CREATE ACTIVE STANDBY PAIR dns1, dns2 ROUTE MASTER dsn1 ON "machine1" SUBSCRIBER dsn2 ON "machine2" MASTERIP "192.168.1.100" PRIORITY 1 MASTERIP "192.168.1.101" PRIORITY 2 SUBSCRIBERIP "192.168.1.200" PRIORITY 1 SUBSCRIBERIP "192.168.1.201" PRIORITY 2;
デフォルトでは、アクティブ・スタンバイ・ペアはデータベース全体をレプリケートします。INCLUDE句を使用すると、INCLUDE句に指定される表、キャッシュ・グループおよび順序のみをレプリケートします。INCLUDE句が定義されたアクティブ・スタンバイ・ペアの他のデータベース・オブジェクトはレプリケートされません。たとえば、このINCLUDE句では、アクティブ・スタンバイ・ペアによってレプリケートされる3つの表が指定されています。
INCLUDE TABLE employees, departments, jobs
CREATE ACTIVE STANDBY PAIR文のEXCLUDE句を使用することによって、レプリケーションから除外する特定の表、キャッシュ・グループまたは順序を選択できます。オブジェクト・タイプごとに1つのEXCLUDE句を使用します。次に例を示します。
EXCLUDE TABLE ttuser.tab1, ttuser.tab2 EXCLUDE CACHE GROUP ttuser.cg1, ttuser.cg2 EXCLUDE SEQUENCE ttuser.seq1, ttuser.seq2
