ヘッダーをスキップ

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

前へ | 次へ |

## 高可用性システムの設計

「TimesTenレプリケーション」で説明されているように、すべてのレプリケーション・スキームの主要目的は次のとおりです。

- データをアプリケーションで常に使用できるように1つ以上のバックアップ・データ・ストアを提供すること。
- 障害が発生したデータ・ストアをそれらのバックアップ・データ・ストアからリカバリするための方法を提供すること。
- 可能なかぎり最速でデータにアクセスできるアプリケーションを提供するために、ワークロードを効率的に分散すること。
- ユーザーへのサービスを中断せずに、ソフトウェアのアップグレードおよびメンテナンスを実行できるようにすること。

## ホストの物理的な構成

高可用性システムを設計する場合、マスター・データ・ストアに影響を与える可能性がある障害が発生しても、サブスクライバ・データ・ストアは影響を受けないようにする必要があります。最低限、マスターとサブスクライバは別々のマシンに配置する必要があります。一部のアプリケーションでは、個別の電源を供給できる環境にサブスクライバを配置する必要がある場合もあります。場合によっては、完全に別のサイトにサブスクライバを配置する必要もあります。

## 効率性および経済性

アプリケーションのワークロードを最も効率的に分散し、限られた数のサーバー・マシンを最大限利用できるようにデータ・ストアを設定します。たとえば、各サーバーがホット・スタンバイ構成で個別にマスターおよびサブスクライバとして機能するのではなく、マスターおよびサブスクライバの両方として機能するように分散ワークロード方式で双方向にデータ・ストアを設定するほうが、より効率的で経済的です。ただし、分散ワークロード・スキームは、主にデータ・ストアから読取りを行うアプリケーションで最も効率的に機能します。データ・ストアの同じ要素に頻繁に書込みを行うアプリケーションに対して分散ワークロード・スキームを実装すると、パフォーマンスが低下し、更新競合を回避または管理するための解決方法を実装するように要求される可能性があります（「レプリケーション競合の検出および解消」を参照）。

## フェイルオーバーおよびリカバリ

レプリケーション・スキームを計画する場合は、想定可能なすべてのフェイルオーバーおよびリカバリの使用例を検討してください。たとえば、通常、サブスクライバで発生した障害は、マスター・データ・ストアに接続しているアプリケーションには影響が及ばないため、ユーザー・サービスを中断せずにリカバリできます。一方、マスター・データ・ストアで障害が発生した場合は、アプリケーションのロードをサブスクライバにリダイレクトし、中断なしまたは最小限の中断でサービスを続行するための方法が必要です。通常、この処理は、クラスタ・マネージャまたはカスタム・ソフトウェアによって行われます。このソフトウェアは、障害を検出し、障害が発生したデータ・ストアからそのサブスクライバの1つにユーザーまたはアプリケーションをリダイレクトして、障害が発生したデータ・ストアのリカバリを管理するように設計されています。

フェイルオーバー方法を計画する場合は、マスターの役割を引き受けるサブスクライバおよび対象ユーザーまたはアプリケーションについて検討してください。また、障害が発生したマスターがそのデータ・ストアを最新のサブスクライバからリカバリできる必要があること、すべてのサブスクライバをそのマスターからリカバリできる必要があることなどのリカバリの要件についても検討してください。

図3.1に示す、単方向にレプリケートされるデータ・ストアの障害例について考えてみます。マスターで障害が発生した場合、アプリケーションは、サブスクライバからリカバリされるまでデータ・ストアにアクセスできません。ALTER REPLICATION文を使用してサブスクライバ・データ・ストアをマスターとして再定義しないかぎり、アプリケーションの接続またはユーザー・ロードをサブスクライバに切り替える方法はありません。単方向スキームは、サブスクライバからのマスター・データ・ストアのリカバリ中に、データ・ストアのブラックアウトに対応できるアプリケーションでのみ使用する必要があります。

図3.1 単方向スキームでのマスターのリカバリ

図3.2に示すホット・スタンバイ・スキームなどの双方向一般ワークロード・スキームでデータ・ストアが設定されている場合、フェイルオーバーおよびリカバリはより効率的に実行されます。ホット・スタンバイ・スキームでは、マスター・データ・ストアで障害が発生した場合、クラスタ・マネージャで、ユーザー・ロードをサブスクライバ・データ・ストアのホット・スタンバイ・アプリケーションに切り替える必要のみがあります。障害が発生したデータ・ストアがリカバリされると、サービスへの割込みを最小限に抑えてマスター/サブスクライバの役割を入れ替え、レプリケーションを再開できます。

図3.2 ホット・スタンバイ・スキームでのマスターのリカバリ

図3.3に示すような分散ワークロード・スキームを使用して設定したデータ・ストアのフェイルオーバー手順は、ホット・スタンバイで使用した手順と類似しています。ただし、障害が発生したデータ・ストアによって影響を受けたユーザーを移動して、影響を受けなかったデータ・ストア上のアプリケーションの他のユーザーに追加する必要があります。リカバリが完了すると、リカバリしたデータ・ストア上のアプリケーションにワークロードを再分散できます。

図3.3 分散ワークロード・スキームでのマスターのリカバリ

## パフォーマンスとリカバリのトレードオフ

レプリケーション・スキームの設計時に、フェイルオーバーおよびリカバリの複雑さとパフォーマンスの効率を比較する必要があります。フェイルオーバーおよびリカバリを複雑にする要因には、マスターをそのサブスクライバと接続するネットワーク・トポロジ、レプリケーション・スキームの複雑さなどがあります。たとえば、選択した要素が異なるサブスクライバにレプリケートされるマスターをリカバリするより、1つのサブスクライバに完全にレプリケートされるマスターをリカバリするほうがより簡単です。

レプリケーションは、非同期、RETURN RECEIPTサービスによる半同期、またはRETURN TWOSAFEサービスによる完全同期で動作するように設定できます（「レプリケーションの動作」を参照）。次の項では、非同期、RETURN RECEIPTおよびRETURN TWOSAFEモードの動作の概要を示し、それらの動作によるレプリケーションのパフォーマンスおよび障害からのリカバリ機能への影響を比較します。ここでは、双方向のホット・スタンバイ・レプリケーションおよびデータ・ストア全体のレプリケーションに設定された2つのデータ・ストアがあることを想定しています。

- コミット順序
- マスターでのパフォーマンス
- 実行時エラーの影響
- フェイルオーバー（マスターでの障害発生後）
- TRANSMIT DURABLE/NONDURABLEがマスター・データ・ストア・リカバリに及ぼす影響
- サブスクライバ・データ・ストアのリカバリ

フェイルオーバーおよびリカバリの詳細は、「データ・ストアのフェイルオーバーおよびリカバリの管理」を参照してください。

### コミット順序

- 非同期およびRETURN RECEIPT: 各トランザクションは最初にマスター・データ・ストアでコミットされます。
- RETURN TWOSAFE: 各トランザクションは最初にサブスクライバ・データ・ストアでコミットされます。

### マスターでのパフォーマンス

- 非同期: トランザクション間の待機時間またはマスターでコミットされるまでの待機時間が短いため、レスポンス時間が最も短く、スループットも最適になります。
- RETURN RECEIPT: 非同期と比較すると、レスポンス時間は長くなり、スループットは低くなります。レスポンス時間は、コミット後のネットワークのラウンドトリップ中にアプリケーションがブロックされるため長くなります。マスターでコミットされるまでの待機時間はありませんが、レプリケート対象のトランザクションがシリアライズされる程度は、非同期レプリケーションでの場合より大きいため、結果としてスループットが低くなります。
- RETURN TWOSAFE: レスポンス時間が最も長く、スループットも最も低くなります。応答時間が長くなる理由は、マスターでのコミットに先立って行われるネットワークのラウンドトリップおよびサブスクライバでのコミットの期間中に、アプリケーションがブロックされることにあります。サブスクライバでコミットしてからマスターでコミットするという順番になるので、トランザクションは完全にシリアル化され、結果としてスループットが最も低くなります。

### 実行時エラーの影響

- 非同期およびRETURN RECEIPT: トランザクションは最初にマスター・データ・ストアでコミットされるため、サブスクライバでのコミット時にエラーが発生した場合は、サブスクライバに対して次のいずれかの処理を行う必要があります。

- 手動で修正する
- 破棄し、マスター・データ・ストアからリカバリする

- RETURN TWOSAFE: トランザクションは最初にサブスクライバ・データ・ストアでコミットされるため、マスターでのコミット時にエラーが発生した場合は、マスターに対して次のいずれかの処理を実行する必要があります。

- 手動で修正する
- 破棄し、サブスクライバ・データ・ストアからリカバリする

注意: TWOSAFEモードでは、コミットがサブスクライバで成功し、マスターで失敗するという状況はほとんどの場合発生しません。これは、この状況がコミット・エラーを意味するためです。コミット・エラーが発生した場合、そのエラーは致命的である可能性が高いため、マスターを破棄した後、サブスクライバ・データ・ストアからリカバリする必要があります。

### フェイルオーバー（マスターでの障害発生後）

- 非同期およびRETURN RECEIPT: マスターで障害が発生し、サブスクライバに処理が受け継がれた場合、サブスクライバがマスターの背後に存在している場合があるため、サブスクライバでデータ・フィードを再処理して重複データを削除できる必要があります。
- RETURN TWOSAFE: マスターで障害が発生し、サブスクライに処理が受け継がれた場合、サブスクライバは少なくともマスターの最新の状態になります。また、サブスクライバにレプリケートされたトランザクションをマスターでコミットする前にマスターで障害が発生した場合は、サブスクライバをマスターより先行させることもできます。

### TRANSMIT DURABLE/NONDURABLEがマスター・データ・ストア・リカバリに及ぼす影響

マスター・データ・ストアは、永続的または非永続的のいずれかになります（「レプリケーション・エージェントによって更新をデータ・ストア間でコピーする方法」および「送信永続性の設定」を参照）。非同期またはRETURN RECEIPTのレプリケーションで設定されたマスター・データ・ストアはデフォルトでは永続的になりますが、CREATE REPLICATION文のTRANSMIT NONDURABLEオプションを使用して非永続的に設定することもできます。RETURN TWOSAFEレプリケーションで設定されたマスター・データ・ストアはデフォルトでは非永続的になり、永続的にすることはできません。

通常、マスター・データ・ストアで障害が発生した場合は、ttRepAdmin -duplicate処理（「障害が発生したデータ・ストアのリカバリ」を参照）を開始して、障害が発生したマスターをサブスクライバ・データ・ストアからリカバリする必要があります。

TRANSMIT NONDURABLEで設定されたデータ・ストアは、特定のタイプのホット・スタンバイ・スキームで設定されている場合、マスター・レプリケーション・エージェントによって自動的にリカバリされます（「障害が発生したマスター・データ・ストアの自動キャッチアップ」を参照）。そうでない場合は、「NONDURABLEなデータ・ストアのリカバリ」の手順に従って、障害が発生した非永続的データ・ストアをリカバリする必要があります。

### サブスクライバ・データ・ストアのリカバリ

いずれのタイプのレプリケーション設定のサブスクライバで障害が発生した場合でも、そのサブスクライバをリカバリしてレプリケーションを再開することができます。リカバリされたサブスクライバで一部のトランザクション・レコードが欠落している場合がありますが、確認応答が行われていないトランザクションに関連付けられているすべてのレコードがマスターからサブスクライバに再送信されます（これは、RETURNサービスによって有効にされたアプリケーション・レベルの確認応答ではなく、サブスクライバ・レプリケーション・エージェントがマスター・レプリケーション・エージェントに送信する確認応答です）。サブスクライバは、重複レコードを自動的に削除します。

別の方法として、ttRepAdmin -duplicate処理（「障害が発生したデータ・ストアのリカバリ」を参照）を開始して、障害が発生したサブスクライバをリカバリする方法もあります。

詳細は、「サブスクライバの障害」を参照してください。