ログ転送サービスの概要

フィジカル・スタンバイ・データベースは、ログ転送サービスを通じてプライマリテナントとスタンバイテナント間でRedoログをリアルタイムで同期します。特に、プライマリテナントはスタンバイテナントに対して積極的にログをプッシュすることはなく、スタンバイテナントがプライマリテナントからログをプルすることにのみ依存します。

ログ転送サービスは、ログの位置情報を自動的に特定し、ログの遅延やプライマリテナントが存在するクラスタノードの障害などの高可用性問題を処理します。スタンバイテナントは、プライマリテナントのログアーカイブからログを取得することも、ネットワーク経由でプライマリテナントが存在するクラスタに直接接続してログを取得することも可能です。

ログ転送サービスは2種類の異なる使用モードを提供しており、これら2つの使用モードによってフィジカル・スタンバイ・データベースの2種類の異なるデプロイメントソリューションが決定されます：ログアーカイブに基づくフィジカル・スタンバイ・データベースとネットワークに基づくフィジカル・スタンバイ・データベースです。

ログアーカイブに基づくフィジカル・スタンバイ・データベース

ログアーカイブに基づくフィジカル・スタンバイ・データベースでは、フィジカル・スタンバイ・データベースのRedoログはプライマリテナントまたは他のスタンバイテナントのログアーカイブから取得されます。これはOracleデータベースのFar Syncと類似しており、スタンバイテナントはログアーカイブとのみやり取りを行い、上流のプライマリテナントや他のスタンバイテナントとは一切他の形式でのやり取りを行いません。

このデプロイモードでは、スタンバイテナントと上流のテナント間でネットワーク接続は不要ですが、同期性能と可用性はログアーカイブメディアの影響を受けます。

ログアーカイブに基づくフィジカル・スタンバイ・データベースモードのデプロイアーキテクチャ図は以下のとおりです。図中、Log Archive（ログアーカイブ）、Log Archive Dest（ログアーカイブ宛先）、およびLog Restore（ログ復元）は、このデプロイモードにおけるログ転送サービスを共同で構成します。

ネットワークに基づくフィジカル・スタンバイ・データベース

ネットワークに基づくフィジカル・スタンバイ・データベースでは、スタンバイテナントはネットワークを介してプライマリテナントまたは他のスタンバイテナントから直接ログを読み取ります。これは、MySQLデータベースのレプリケーションと類似しています。

このデプロイモードでは、スタンバイテナントとプライマリテナントのネットワークが接続されている必要があります。スタンバイテナントは、ネットワークを通じてRPCリクエストを送信し、プライマリテナントクラスタ内のRedoログを読み取ります。また、プライマリテナントノードの障害やログ回収などのシナリオでスタンバイテナントの高可用性をサポートするため、スタンバイテナントにはプライマリテナントの一部のシステムビューへのクエリ権限も必要です。

特に、このデプロイモードでは、スタンバイテナントはプライマリテナントのログ転送サービスに対してログの送信を継続的にリクエストします。ログ転送サービスが返すログは、プライマリテナントのオンラインログでも、ログアーカイブモードが有効な場合のアーカイブログでも構いません。両方のログソース間での自動切り替えが可能であり、スタンバイテナントおよび業務ユーザーにとって透過的です。

ネットワークに基づくフィジカル・スタンバイ・データベースのデプロイアーキテクチャ図は以下のとおりです。図中、Primary Tenant1はログアーカイブを有効にしておらず、Standby Tenant1はログ転送サービスを通じてPrimary Tenant1のオンラインログのみを同期できます。一方、Primary Tenant2はログアーカイブを有効にしており、Standby Tenant2はログ転送サービスを通じてPrimary Tenant2のオンラインログを同期できます。オンラインログが回収されると、ログ転送サービスは自動的にログソースをアーカイブログに切り替え、スタンバイテナントは引き続きログ転送サービスを通じてPrimary Tenant2のアーカイブログを同期できるため、ログ同期の中断をできるだけ防ぐことができます。

2つのデプロイモードの比較

ログアーカイブに基づくフィジカル・スタンバイ・データベースとネットワークに基づくフィジカル・スタンバイ・データベースでは、機能の使用方法にいくつかの違いがあります。具体的な違いは以下の表に示されています。