レプリケーション・スキームのタイプ

レプリケーション・スキームを作成して、マスターおよびサブスクライバのデータベースの特定の構成を定義できます。

この項では、レプリケーション・スキームの作成時に、マスター・データベースとサブスクライバ・データベース間に定義可能な関係について説明します。

マスターとサブスクライバ間の関係を定義する場合、次のレプリケーション・スキームついて考慮する必要があります。

読取り専用サブスクライバがあるアクティブ・スタンバイ・ペア

1つのアクティブ・マスター、1つのスタンバイ・マスターおよび複数の読取り専用サブスクライバ・データベースを使用するアクティブ・スタンバイ・ペア・レプリケーション・スキームを作成できます。

図1-4は、1つのアクティブ・マスター、1つのスタンバイ・マスター、そして4つの読取り専用サブスクライバ・データベースのアクティブ・スタンバイ・ペアのレプリケーション・スキームを示しています。

図1-4 アクティブ・スタンバイ・ペア

図1-4の説明が続きます。
「図1-4 アクティブ・スタンバイ・ペア」の説明

アクティブ・スタンバイ・ペアはデータベース全体をレプリケートすることも、表およびキャッシュ・グループなどの要素を選択することもできます。

アクティブ・スタンバイ・ペアでは、2つのデータベースがマスター・データベースとして定義されます。1つは、アクティブ・マスターで、もう1つはスタンバイ・マスターです。アクティブ・マスター・ディレクトリは、アプリケーションで直接更新されます。スタンバイ・マスターは、アプリケーションで更新することはできません。アクティブ・マスターからの更新を受信し、それらの変更を最大127の読取り専用サブスクライバ・データベースに伝播します。この構成では、スタンバイ・マスターがサブスクライバ・データベースより常に先行し、アクティブ・マスターで障害が発生した場合は、スタンバイ・マスターに即時にフェイルオーバーできます。

1つのマスター・データベースのみが、特定の時間にアクティブ・マスターとして機能できます。Oracle Clusterwareを使用して、アクティブ・スタンバイ・ペアのフェイルオーバーおよびリカバリを管理できます。Oracle Clusterwareを使用したアクティブ・スタンバイ・ペアの管理を参照してください。また、フェイルオーバーおよびリカバリを手動で管理することもできます。「キャッシュ・グループがないアクティブ・スタンバイ・ペアの管理」または「キャッシュ・グループがあるアクティブ・スタンバイ・ペアの管理」を参照してください。

スタンバイ・マスターで障害が発生した場合は、アクティブ・マスターから読取り専用サブスクライバに変更を直接レプリケートします。スタンバイ・データベースは、リカバリ後、アクティブ・マスターに接続し、スタンバイ・マスターの停止またはリカバリ中にサブスクライバに送信された更新を受信します。アクティブ・マスターとスタンバイ・マスターで同期が取られている場合、スタンバイ・マスターは、サブスクライバへの変更の伝播を再開します。

アクティブ・スタンバイ・ペアの設定の詳細は、「アクティブ・スタンバイ・ペア・レプリケーション・スキームの定義」「キャッシュ・グループがないアクティブ・スタンバイ・ペアの設定」「読取り専用キャッシュ・グループが構成されたアクティブ・スタンバイ・ペアの設定」または「AWTキャッシュ・グループが構成されたアクティブ・スタンバイ・ペアの設定」を参照してください。

クラシック・レプリケーション

クラシック・レプリケーション・スキームでは、マスターとサブスクライバとの間の関係を設計できます。

次の各項では、クラシック・レプリケーション・スキームについて説明します。

データベース全体のレプリケーションまたは選択レプリケーション

サブスクライバ・データベースにマスター・データベース全体をレプリケートするかマスター・データベース内の一部の要素を選択してレプリケートすることができます。

図1-5に、マスター・データベース全体をサブスクライバにレプリケートする全体レプリケーション・スキームを示します。

図1-5 マスター・データベース全体のレプリケート



また、マスター・データベースとサブスクライバ・データベースを構成して、マスター・データベース内の一部の要素を選択してサブスクライバにレプリケートできます。図1-6に、選択レプリケーションの例を示します。図の左側のマスター・データベースでは、同じ要素を選択して複数のサブスクライバにレプリケートしている一方で、右側のマスターでは、サブスクライバごとに異なる要素をレプリケートしています。

図1-6 複数サブスクライバへの選択した要素のレプリケート

図1-6の説明が続きます。
「図1-6 複数サブスクライバへの選択した要素のレプリケート」の説明

単方向レプリケーションまたは双方向レプリケーション

単方向レプリケーションは、1つ以上のサブスクライバ・データベースに更新を送信する1つのマスター・データベースで構成されます。双方向レプリケーションは、双方向に動作する2つのデータベースで構成され、各データベースが互いにマスターとサブスクライバになります。

双方向レプリケーションには、次の基本的な使用方法があります。

  • 分割ワークロード構成: 分割ワークロード構成では、各データベースが一部の要素に対してはマスターとして、他の要素に対してはサブスクライバとして機能します。

    図1-7の例について考えてみます。ここでは、ChicagoのアカウントはデータベースAで処理され、New YorkのアカウントはデータベースBで処理されます。

    図1-7 分割ワークロードの双方向レプリケーション

    図1-7の説明が続きます。
    「図1-7 分割ワークロードの双方向レプリケーション」の説明
  • 分散ワークロード: 分散ワークロード・レプリケーション・スキームでは、ユーザーのアクセスは、すべての要素に対する更新を互いにレプリケートする複製アプリケーションとデータベースの組合せに分散されます。障害が発生した場合、その影響を受けたユーザーを任意のアプリケーションとデータベースの組合せに簡単に切り替えることができます。図1-8に、分散ワークロード構成を示します。ユーザーは、他方のデータベースでマスターおよびサブスクライバの両方として機能する、各データベースの複製アプリケーションにアクセスします。

    図1-8 分散ワークロード構成

    図1-8の説明が続きます。
    「図1-8 分散ワークロード構成」の説明

    データベースが分散ワークロード構成でレプリケートされる場合、個々のユーザーが同じ行を同時に更新し、互いにその更新をレプリケートする可能性があります。アプリケーションでは、このような競合が発生しないこと、発生した場合でもその競合が許容可能であること、またはレプリケーション競合の解消で説明している競合解消メカニズムを利用して、競合を適切に解消できることが保証されている必要があります。

    ノート:

    RETURN TWOSAFE戻りサービスを構成して分散ワークロードを使用しないでください。

直接レプリケーションまたは伝播

サブスクライバは、レプリケート対象の更新をマスターから受信して自身のサブスクライバに渡すプロパゲータとして機能するように定義できます。

プロパゲータは、より低い帯域幅のネットワーク接続(イントラネットでのサーバー間の接続など)でのレプリケーション・パフォーマンスの最適化に有効です。たとえば、図1-9に示す、マスターがイントラネット接続を介して4つのサブスクライバに直接レプリケートする直接レプリケーション構成について考えてみます。この方法でネットワーク接続を介して各サブスクライバにレプリケートすると、ネットワークの帯域幅が効率的に使用されません。

図1-9 ネットワークを介して複数のサブスクライバに直接レプリケートされるマスター

図1-9の説明が続きます。
「図1-9 ネットワークを介して複数のサブスクライバに直接レプリケートされるマスター」の説明

最適なパフォーマンスを実現するために、図1-10に示す、マスターがネットワーク接続を介して1つのプロパゲータにレプリケートする構成について考えてみます。その後、このプロパゲータが、自身のローカル・エリア・ネットワーク上の各サブスクライバに更新を転送します。

図1-10 ネットワークを介して単一のプロパゲータにレプリケートされるマスター

図1-10の説明が続きます。
「図1-10 ネットワークを介して単一のプロパゲータにレプリケートされるマスター」の説明

また、プロパゲータは、多数のサブスクライバにレプリケートする必要があるマスター・データベースを含む構成でレプリケーション・ロードを分散する場合にも有効です。たとえば、図1-11に示すとおり、マスターで、12のサブスクライバに直接レプリケートするより、3つのプロパゲータにレプリケートする方がより効率的です。

図1-11 複数のプロパゲータの使用による多数のサブスクライバへのレプリケート

図1-11の説明が続きます。
「図1-11 複数のプロパゲータの使用による多数のサブスクライバへのレプリケート」の説明

ノート:

各プロパゲータはワン・ホップであるため、更新を1回のみ転送できます。プロパゲータを階層化して、プロパゲータ間で更新を転送することはできません。