データベース間の更新のコピー

デフォルトでは、更新はデータベース間で非同期にコピーされます。

非同期レプリケーションでは、最高のパフォーマンスが実現しますが、レプリケート対象の更新がサブスクライバ・データベースでコミットされたことを示す確認応答はアプリケーションに送信されません。マスター・データベースとサブスクライバ・データベース間でのレプリケート・データの一貫性をより高いレベルで保証する必要があるアプリケーションでは、RETURN RECEIPTサービスまたはRETURN TWOSAFEサービスのいずれかを有効にできます。

  • RETURN RECEIPTサービスでは、サブスクライバが更新を受信したことがレプリケーションで確認されるまでアプリケーションをブロックすることによって、アプリケーションをレプリケーション・メカニズムと緩やかに同期化します。

  • RETURN TWOSAFEサービスでは、マスターでコミットされる前にサブスクライバが更新を受信およびコミットしたことがレプリケーションで確認されるまでアプリケーションをブロックすることによって、完全な同期化が行われます。

RETURN RECEIPTレプリケーションでは、同期性を低くすることによって、RETURN TWOSAFEレプリケーションよりパフォーマンスへの影響が小さくなっています。非同期、RETURN RECEIPTおよびRETURN TWOSAFEのレプリケーションの動作の詳細は、次の項を参照してください。

デフォルトのレプリケーション

デフォルトのTimesTen Classicレプリケーションを使用した場合、アプリケーションはマスター・データベースを更新すると、サブスクライバがその更新を受信および適用するのを待機せずに処理を続行します。

マスターおよびサブスクライバのデータベースには、サブスクライバが更新を正常に受信およびコミットしたことを確認するための内部メカニズムがあります。これらのメカニズムは、更新がサブスクライバで1回のみ適用されることを保証しますが、アプリケーションからは完全に独立しています。

デフォルトのTimesTen Classicレプリケーションは最大限のパフォーマンスを実現しますが、アプリケーションは、サブスクライバ上のレプリケート対象の要素の受信プロセスと完全に切り離されます。

図1-1 基本的な非同期レプリケーション・サイクル

図1-1の説明が続きます。
「図1-1 基本的な非同期レプリケーション・サイクル」の説明

デフォルトのTimesTen Classicレプリケーション・サイクルは次のとおりです。

  1. アプリケーションは、ローカル・トランザクションをマスター・データベースにコミットし、他のトランザクションを続行できます。

  2. コミット時に、TimesTenデーモンがトランザクションの更新レコードをトランザクション・ログ・バッファに書き込みます。

  3. マスター・データベースのレプリケーション・エージェントは、コミット済トランザクションの更新レコードのバッチをログ・バッファからトランザクション・ログ・ファイルにフラッシュするようにデーモンに指示します。マスターで障害が発生して、チェックポイント・ファイルおよびトランザクション・ログ・ファイルからデータベースをリカバリする必要がある場合は、このステップによって、リカバリされたマスターにサブスクライバにレプリケートしたすべてのデータが含まれていることが保証されます。

  4. マスター・レプリケーション・エージェントは、トランザクション更新レコードのバッチをサブスクライバ・レプリケーション・エージェントに転送し、サブスクライバ・レプリケーション・エージェントは、それらをサブスクライバ・データベースに適用します。更新レコードは、マスター・データベースのトランザクション・ロードに応じて256KB以下のバッチでファイル・システムにフラッシュされ、サブスクライバに転送されます。バッチは、トランザクション・ログ・バッファにログ・データがなくなった場合、または現在のバッチがほぼ256KBの場合に作成されます。

  5. サブスクライバ・レプリケーション・エージェントは、更新レコードのバッチを受信したことを示す確認応答をマスター・レプリケーション・エージェントに返信します。確認応答には、サブスクライバが最後にファイル・システムにフラッシュしたレコードのバッチに関する情報が含まれます。これで、マスター・レプリケーション・エージェントは、すべてのサブスクライバが受信、適用およびファイル・システムへのフラッシュを完了した更新レコードをトランザクション・ログからパージし、別の更新レコードのバッチを転送できるようになり、サブスクライバ・レプリケーション・エージェントは、非同期でステップ6の処理に進みます。

  6. サブスクライバ・レプリケーション・エージェントは、データベースを更新し、デーモンにトランザクション更新レコードをトランザクション・ログ・バッファに書き込むように指示します。

  7. サブスクライバ・データベースのレプリケーション・エージェントは、個別のスレッドを使用して、トランザクション・ログ・ファイルに更新レコードをフラッシュするようにデーモンに指示します。

RETURN RECEIPTレプリケーション

RETURN RECEIPTサービスは、マスターでのコミット後、コミットされたトランザクションの更新をサブスクライバが受信するまでアプリケーションをブロックして、マスター・データベースとサブスクライバ・データベース間に特定のレベルの同期を提供します。

RETURN RECEIPTをリクエストするアプリケーションは、基本的な非同期の場合と同じ方法でマスター・データベースを更新します。ただし、レプリケート対象の要素を更新するトランザクションをアプリケーションでコミットすると、マスター・データベースは、そのトランザクションの更新がサブスクライバで受信されたことを示す確認応答を受信するまでアプリケーションをブロックします。

RETURN RECEIPTレプリケーションでは、パフォーマンスは低下しますが、マスター・データベースとサブスクライバ・データベース間でのより高いレベルのデータの整合性および一貫性がアプリケーションで保証されます。このアプリケーションでは、マスターで障害が発生した場合でも、マスターでコミットされたトランザクションがサブスクライバ・データベースに保持されることが高度なレベルで保証されます。

図1-2 RETURN RECEIPTレプリケーション

図1-2の説明が続きます。
「図1-2 RETURN RECEIPTレプリケーション」の説明

図1-2は、RETURN RECEIPTレプリケーション・サイクルが図1-1に示した基本的な非同期サイクルと同じであることを示していますが、マスター・レプリケーション・エージェントは、トランザクションをコミットした後でアプリケーション・スレッドをブロックし(ステップ1)、サブスクライバが更新バッチの受信を確認する(ステップ5)までそのスレッドを制御します。サブスクライバからRETURN RECEIPTの確認応答を受信した時点で、マスター・レプリケーション・エージェントはスレッドの制御をアプリケーションに返し(ステップ6)、アプリケーションでトランザクションを続行できるようにします。

構成可能なタイムアウト時間(デフォルトは10秒)内にサブスクライバがトランザクションの受信を確認できない場合、マスター・レプリケーション・エージェントは、サブスクライバから更新の確認応答を受信しなかったことを示す警告を返し、スレッドの制御をアプリケーションに返します。その後、アプリケーションは、マスターに対して別のトランザクションをコミットできるようになり、マスターは以前と同様にサブスクライバへのレプリケーションを続行します。

RETURN RECEIPTトランザクションでタイムアウトが発生する原因は多数考えられます。最も可能性の高い原因は、ネットワークの問題、レプリケーション・エージェントの障害、またはマスター・レプリケーション・エージェントでトランザクション・ロードに対して大幅な遅延が発生しているため、タイムアウトが発生する前にRETURN RECEIPTトランザクションをレプリケートできない場合です。「RETURNサービスのタイムアウト時間の設定」および「RETURN RECEIPT」を参照してください。

RETURN TWOSAFEレプリケーション

RETURN TWOSAFEサービスは、マスターとサブスクライバ間の完全な同期レプリケーションを実現します。

トランザクションがマスターでコミットされた後にサブスクライバに送信される前述のレプリケーション・モードとは異なり、TWOSAFEモードのトランザクションは、マスターでコミットされる前に、まずサブスクライバでコミットされます。

図1-3 RETURN TWOSAFEレプリケーション

図1-3の説明が続きます。
「図1-3 RETURN TWOSAFEレプリケーション」の説明

RETURN TWOSAFEレプリケーションに構成された、マスターとサブスクライバ間でのレプリケーションの動作を次に説明します。

  1. アプリケーションが、マスター・データベースでトランザクションをコミットします。

  2. マスター・レプリケーション・エージェントが、トランザクション・レコードをログに書き込み、特殊なプリコミット・ログ・レコードをコミット・レコードの前に挿入します。このプリコミット・レコードは、サブスクライバでのコミットのステータスを示す確認応答をマスター・レプリケーションが受信するまで、ログ内でプレース・ホルダとして機能します。

    ノート:

    RETURN TWOSAFEトランザクションの送信は非永続的です。このため、マスター・レプリケーション・エージェントにより、サブスクライバへの送信前のログ・レコードがファイル・システムにフラッシュされることはありません。この処理は、レプリケーションが非同期またはRETURN RECEIPTレプリケーション用に構成されている場合にはデフォルトで実行されます。

  3. マスター・レプリケーション・エージェントが、更新レコードのバッチをサブスクライバに送信します。

  4. サブスクライバ・レプリケーション・エージェントが、サブスクライバ・データベースでトランザクションをコミットします。

  5. サブスクライバ・レプリケーション・エージェントが、サブスクライバでトランザクションがコミットされたかどうか、およびコミットが成功したかどうかについての通知とともに確認応答を返します。

  6. サブスクライバでコミットが成功した場合、マスター・レプリケーション・エージェントが、マスター・データベースでトランザクションをコミットします。

  7. マスター・レプリケーション・エージェントが、制御をアプリケーションに返します。

    構成可能なタイムアウト時間(デフォルトは10秒)内にサブスクライバがトランザクションのコミットを確認できない場合、またはサブスクライバからの確認応答がコミットの失敗を示している場合、レプリケーション・エージェントは、マスター・データベースでトランザクションをコミットせずに制御をアプリケーションに返します。その後、アプリケーションは、無条件にコミットするか、コミットを再試行するかを決定できます。必要に応じて、マスター・レプリケーション・エージェントに指示してタイムアウトしたすべてのトランザクションをコミットするようにレプリケーション・スキームを構成できます。

    「RETURN TWOSAFE」を参照してください。