高可用性システムの設計

すべてのレプリケーション・スキームの主要な目的をいくつか示します。

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

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

次のクラシック・レプリケーション・スキームを構成できます(「レプリケーション・スキームのタイプ」を参照)。

単方向
双方向の分割ワークロード
双方向の分散ワークロード
伝播

データベース全体をレプリケートするか、データベースの要素を選択してレプリケートするかについても検討してください。また、レプリケーション・スキームにおけるサブスクライバの数についても検討してください。単方向および伝播レプリケーション・スキームでは、サブスクライバの数を選択できます。

この項の後半では、次の内容について説明します。

『Oracle TimesTen In-Memory Databaseインストレーション、移行およびアップグレード・ガイド』のクラシック・レプリケーションを使用したオンライン・アップグレードの実行を参照してください。

フェイルオーバーおよびリカバリの使用例の検討

クラシック・レプリケーション・スキームを計画する場合は、すべてのフェイルオーバーおよびリカバリの使用例を検討してください。

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

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

図9-1に示す、単方向にレプリケートされるデータベースの障害例について考えてみます。マスターで障害が発生した場合、アプリケーションは、サブスクライバからリカバリされるまでデータベースにアクセスできません。ALTER REPLICATION文を使用してサブスクライバ・データベースをマスターとして再定義しないかぎり、アプリケーションの接続またはユーザー・ロードをサブスクライバに切り替えることはできません。「クラシック・レプリケーション・スキームでのマスター・データベースの交換」を参照してください。

図9-1 単方向スキームでのマスターのリカバリ

「図9-1 単方向スキームでのマスターのリカバリ」の説明

図9-2に、データベース全体がレプリケートされる双方向の分散ワークロード・スキームを示します。このタイプのクラシック・レプリケーション・スキームでフェイルオーバーが発生した場合、障害が発生したデータベース上のアプリケーションを使用していたユーザーは、影響を受けなかったデータベース上のアプリケーションに移動されます。リカバリが完了すると、リカバリしたデータベース上のアプリケーションにワークロードを再分散できます。

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

「図9-2 分散ワークロード・スキームでのマスターのリカバリ」の説明

同様に、分割ワークロード・スキームのユーザーは、障害が発生したデータベースから影響を受けなかったデータベースに移動する必要があります。分割ワークロード・スキームではデータベース・レベルでレプリケーションが行われないため、ALTER REPLICATION文を使用して新しいマスター・データベースを設定する必要があります。「クラシック・レプリケーション・スキームでのマスター・データベースの交換」を参照してください。リカバリが完了すると、リカバリしたマスター・データベースにユーザーを戻すことができます。

伝播クラシック・レプリケーション・スキームでも、マスターまたはプロパゲータで障害が発生した場合は、ALTER REPLICATION文を使用して新しいマスターまたは新しいプロパゲータを設定する必要があります。レプリケーション・スキームで2つのプロパゲータが定義されていると、高可用性が実現されます。2つのプロパゲータが構成された伝播レプリケーション・スキームの例は、図1-11を参照してください。

パフォーマンスとリカバリのトレードオフについての判断

クラシック・レプリケーション・スキームの設計時に、フェイルオーバーおよびリカバリの複雑さとパフォーマンスの効率を比較してください。フェイルオーバーおよびリカバリを複雑にする要因には、マスターをそのサブスクライバと接続するネットワーク・トポロジ、レプリケーション・スキームの複雑さなどがあります。

たとえば、選択した要素が異なるサブスクライバにレプリケートされるマスターをリカバリするより、1つのサブスクライバに完全にレプリケートされるマスターをリカバリする方がより簡単です。

クラシック・レプリケーションは、非同期(デフォルト)、RETURN RECEIPTサービスによる「半同期」、またはRETURN TWOSAFEサービスによる完全同期で動作するように構成できます。データがマスターおよびサブスクライバの両方のデータベースで一貫していることをより高いレベルの信頼性を持って保証するには、RETURNサービスを選択します。非同期モード(デフォルト)を使用するか、RETURN RECEIPTモードまたはRETURN TWOSAFEモードを構成するかは、必要とする信頼性の程度および許容できるパフォーマンスのトレードオフによって決まります。

表9-1に、非同期のレプリケーション、RETURN RECEIPTサービスおよびRETURN TWOSAFEサービスにおけるパフォーマンスおよびリカバリのトレードオフの概要を示します。

表9-1 パフォーマンスとリカバリのトレードオフ

動作のタイプ	非同期のレプリケーション(デフォルト)	RETURN RECEIPT	RETURN TWOSAFE
コミット順序	各トランザクションは最初にマスター・データベースでコミットされます。	各トランザクションは最初にマスター・データベースでコミットされます。	各トランザクションは最初にサブスクライバ・データベースでコミットされます。
マスターでのパフォーマンス	トランザクション間の待機時間またはマスターでコミットされるまでの待機時間がないため、レスポンス時間が最も短く、スループットも最適になります。	非同期と比較すると、レスポンス時間は長くなり、スループットは低くなります。コミット後のネットワークのラウンドトリップ中にアプリケーションはブロックされます。レプリケート対象のトランザクションがシリアライズされる程度は、非同期レプリケーションでの場合より大きいため、結果としてスループットが低くなります。	レスポンス時間が最も長く、スループットも最も低くなります。マスターでのコミットに先立って行われるネットワークのラウンドトリップおよびサブスクライバでのリモート・コミットの期間中に、アプリケーションがブロックされます。トランザクションは完全にシリアライズされ、結果としてスループットが最も低くなります。
実行時エラーの影響	トランザクションは最初にマスター・データベースでコミットされるため、サブスクライバでのコミット時にエラーが発生した場合は、サブスクライバを手動で修正するか、または破棄してからマスター・データベースからリカバリするかのいずれかの処理を行う必要があります。	トランザクションは最初にマスター・データベースでコミットされるため、サブスクライバでのコミット時にエラーが発生した場合は、サブスクライバを手動で修正するか、または破棄してからマスター・データベースからリカバリするかのいずれかの処理を行う必要があります。	トランザクションは最初にサブスクライバ・データベースでコミットされるため、マスターでのコミット時にエラーが発生した場合は、マスターを手動で修正するか、または破棄してからサブスクライバ・データベースからリカバリする必要があります。
マスターでの障害発生後のフェイルオーバー	マスターで障害が発生し、サブスクライバに処理が受け継がれた場合、サブスクライバがマスターの背後に存在していることがあるため、サブスクライバでデータ・フィードを再処理して重複データを削除できる必要があります。	マスターで障害が発生し、サブスクライバに処理が受け継がれた場合、サブスクライバがマスターの背後に存在していることがあるため、サブスクライバでデータ・フィードを再処理して重複データを削除できる必要があります。	マスターで障害が発生し、サブスクライバに処理が受け継がれた場合、サブスクライバは少なくともマスターの最新の状態になります。また、サブスクライバにレプリケートされたトランザクションをマスターでコミットする前にマスターで障害が発生した場合は、サブスクライバをマスターより先行させることもできます。

2つのRETURNサービス間のパフォーマンスとリカバリのトレードオフに加えて、次のことも検討する必要があります。

RETURN RECEIPTは多くの構成で使用できますが、RETURN TWOSAFEは双方向構成またはアクティブ・スタンバイ・ペアでのみ使用できます。
RETURN TWOSAFEでは、サブスクライバ・データベースへのトランザクションのレプリケート時にタイムアウトなどのエラーが発生した場合にマスター・データベースで実行されるローカル・アクションを指定できます。

アプリケーションでRETURN RECEIPTまたはRETURN TWOSAFEのいずれかに構成された表を更新する場合、トランザクションはRETURN RECEIPTまたはRETURN TWOSAFEとして分類されます。RETURN RECEIPTまたはRETURN TWOSAFEとして分類されたトランザクションは、終了前にレプリケーション・スキームが変更された場合でも、そのままの状態が維持されます。

「クラシック・レプリケーション・スキームでのRETURNサービスの使用」を参照してください。

ワークロードの分散

アプリケーションのワークロードを分散し、限られた数のサーバーを最大限利用できるようにデータベースを構成することを検討してください。

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