ヘッダーをスキップ

Oracle TimesTen Replication - TimesTen to TimesTen開発者および管理者ガイド リリース6.0 B25769-01 |
| 目次 | 索引

前へ | 次へ |

## マスター/サブスクライバ関係

レプリケーション・スキームを作成して、マスターおよびサブスクライバのデータ・ストアの特定の設定を定義できます。この項では、スキームの作成時に、マスター・データ・ストアとサブスクライバ・データ・ストア間に定義可能な関係について説明します。レプリケーション・スキームの作成方法については、「レプリケーション・スキーム」を参照してください。

マスターとサブスクライバ間の関係を定義する場合は、次に示す内容のいくつかについて考慮する必要があります。

- 全体レプリケーションまたは選択レプリケーション
- 単方向レプリケーションまたは双方向レプリケーション
- 直接レプリケーションまたはプロパゲータ
- アクティブなスタンバイ・マスター・データ・ストアおよび読取り専用サブスクライバ

## 全体レプリケーションまたは選択レプリケーション

図1.1に、マスター・データ・ストア全体をサブスクライバにレプリケートする全体レプリケーション・スキームを示します。また、マスター・データ・ストアとサブスクライバ・データ・ストアを様々な組合せで設定して、マスター・データ・ストア内の一部の表要素を選択してサブスクライバにレプリケートできます。

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

図1.5 複数サブスクライバへの選択要素のレプリケート

また、図1.6に示すように、選択レプリケーションの別の使用方法として、1つのサブスクライバに要素をレプリケートするように複数のマスター・データ・ストアを設定する方法もあります。このサブスクライバ・データ・ストアは共通のバックアップ・データ・ストアとして使用されます。

図1.6 複数のマスターによる1つのサブスクライバへのレプリケート

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

ここまでは、マスター・データ・ストアが1つ以上のサブスクライバ・データ・ストアに更新を送信する単方向レプリケーションについて説明してきましたが、データ・ストアを双方向に動作させて、各データ・ストアがマスターおよびサブスクライバの両方であるように設定することもできます。

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

- 分割ワークロード設定
- 一般ワークロード設定

### 分割ワークロード設定

分割ワークロード設定では、各データ・ストアが一部の表要素に対してはマスターとして、他の表要素に対してはサブスクライバとして機能します。

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

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

注意: ワークロードの明確な分割が難しい場合があります。図1.7では、ChicagoおよびNew Yorkの両方のトランザクションで更新する必要がある行があることを想定しています。この場合、共有される行で更新競合が発生する可能性があります。

### 一般ワークロード設定

一般ワークロード設定では、各データ・ストアが同じ表要素に対してマスターおよびサブスクライバの両方として機能します。いずれのデータ・ストアのアプリケーションでも要素の更新が可能で、行った更新は他方のデータ・ストアにレプリケートされます。このタイプの設定は、マルチマスターと呼ばれる場合があります。

一般ワークロード・スキームには次の2つの基本タイプがあります。

- ホット・スタンバイ: このスキームでは、ユーザーは、複製バックアップ・アプリケーション/データ・ストアの組合せに更新をレプリケートする、特定のアプリケーション/データ・ストアの組合せにアクセスします。障害が発生した場合は、ユーザー・ロードをバックアップ・アプリケーション/データ・ストアに即時に移動することができます。
- 分散ワークロード: このスキームでは、ユーザーのアクセスは、すべての要素に対する更新を互いにレプリケートする複製アプリケーション/データ・ストアの組合せに分散されます。障害が発生した場合、その影響を受けたユーザーをアプリケーション/データ・ストアの組合せに切り替えることができます。

図1.8に、ホット・スタンバイ構成を示します。この構成は、単方向レプリケーションと同様に単純ですが、データ・ストアの障害が発生した場合に簡単で高速なリカバリを可能にします。2つのマスター・データ・ストアが存在しますが、アプリケーションは、障害が発生するまで一方のデータ・ストアのみを更新します。障害が発生した時点で、他方のデータ・ストアに切り替えます。

ユーザーはデータ・ストアAで処理を行い、サブスクライバとして機能するデータ・ストアBに更新がレプリケートされます。データ・ストアAで障害が発生した場合、ユーザーは、データ・ストアBにすでに設定されているアプリケーションのコピーにリダイレクトすることができます。データ・ストアAは、リカバリ後、サブスクライバとして機能できます。

図1.8 ホット・スタンバイ構成

図1.9に、分散ワークロード設定を示します。ユーザーは、他方のデータ・ストアでマスターおよびサブスクライバの両方として機能する、各データ・ストアの複製アプリケーションにアクセスします。

図1.9 分散ワークロード設定

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

## 直接レプリケーションまたはプロパゲータ

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

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

図1.10 マスターによるネットワーク上の複数サブスクライバへのレプリケート

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

図1.11 マスターによるネットワーク上の単一プロパゲータへのレプリケート

また、プロパゲータは、多数のサブスクライバにレプリケートする必要があるマスター・データ・ストアを含む設定でレプリケーション・ロードを分散する場合にも有効です。例えば、図1.12に示すように、マスターで、12のサブスクライバに直接レプリケートするより、3つのプロパゲータにレプリケートするほうがより効率的です。

図1.12 プロパゲータを使用した多数のサブスクライバへのレプリケート

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

## アクティブなスタンバイ・マスター・データ・ストアおよび読取り専用サブスクライバ

図1.13に、アクティブ・スタンバイ・ペア構成を示します。

図1.13 アクティブ・スタンバイ構成

アクティブ・スタンバイ・ペアは、SQL文CREATE ACTIVE STANDBY PAIRによって作成します。CREATE ACTIVE STANDBY PAIR文では、アクティブ・マスター・データ・ストア、スタンバイ・マスター・データ・ストア、サブスクライバ・データ・ストア、およびデータ・ストアを構成する表とキャッシュ・グループを指定します。

注意: この章で説明する他のレプリケーション・スキームは、CREATE REPLICATION文を使用して作成します。

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

1つのマスター・データ・ストアのみが、特定の時間にアクティブ・マスター・データ・ストアとして機能できます。アクティブ・ロールは、ttRepStateSetプロシージャを使用して指定します。アクティブ・データ・ストアで障害が発生した場合、ユーザーは、ttRepStateSetプロシージャを使用して、障害が発生したデータ・ストアをスタンバイ・データ・ストアとしてリカバリする前に、スタンバイ・マスター・データ・ストアのロールをアクティブに変更できます。新しいスタンバイ・マスター・データ・ストアで、レプリケーション・エージェントを起動する必要があります。

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

アクティブ・スタンバイ・ペアの設定の詳細は、「アクティブ・スタンバイ・ペア」を参照してください。アクティブ・スタンバイ・ペアの管理方法の詳細は、「アクティブ・スタンバイ・ペアの管理」を参照してください。