ヘッダーをスキップ
Oracle® TimesTen In-Memory Database TimesTen to TimesTen開発者および管理者ガイド
リリース11.2.1
B56053-02
  目次
目次		 索引
索引
戻る
戻る 		 次へ
次へ		  

4 キャッシュ・グループが構成されていないアクティブ・スタンバイ・ペアの管理

この章では、キャッシュ・グループをレプリケートしないアクティブ・スタンバイ・ペアを管理する方法について説明します。

キャッシュ・グループをレプリケートするアクティブ・スタンバイ・ペアの管理については、第5章「キャッシュ・グループが構成されたアクティブ・スタンバイ・ペアの管理」を参照してください。

フェイルオーバーとリカバリの自動管理については、第7章「Oracle Clusterwareを使用したアクティブ・スタンバイ・ペアの管理」を参照してください。

この章の内容は次のとおりです。

マスター・データベースの状態の概要

この項では、マスター・データベースの可能性のある状態の概要を示します。これらの状態は、章の後半で説明するタスクで参照されています。

マスター・データベースは、次のいずれかの状態になります。

ttRepStateGet組込みプロシージャを使用して、マスター・データベースの状態を検出できます。

データベースの複製

レプリケーション・スキームの設定またはリカバリの管理における共通のタスクは、データベースの複製です。ttRepAdmin -duplicateユーティリティまたはttRepDuplicateEx C関数を使用して、データベースを複製できます。

データベースを複製する場合は、次の条件を満たす必要があります。

ソース・データベースで、次のように入力してユーザーを作成し、そのユーザーにADMIN権限を付与します。

CREATE USER ttuser IDENTIFIED BY ttuser;
User created.

GRANT admin TO ttuser;

インスタンス管理者のユーザー名がtimestenであるとします。timestenとしてログインし、次のように入力してhost1のデータベースdsn1をdsn2に複製します。

ttRepAdmin -duplicate -from dsn1 -host host1 dsn2

Enter internal UID at the remote datastore with ADMIN privileges: ttuser 
Enter password of the internal Uid at the remote datastore:

リモート・データベースの内部ユーザーのパスワードを入力するよう要求されたら、ttuserと入力します。

キャッシュ・グループが含まれるアクティブ・データベースを複製している場合は、-keepCGオプションを使用します。また、-cacheUidおよび-cachePwdオプションを使用して、キャッシュ管理ユーザーIDおよびパスワードを指定する必要もあります。キャッシュ管理ユーザー・パスワードを指定しない場合、ttRepAdminによってパスワードが要求されます。キャッシュ管理ユーザーIDがorauser、パスワードがorapwdの場合、次のように入力してhost1のデータベースdsn1を複製します。

ttRepAdmin -duplicate -from dsn1 -host host1 -keepCG "DSN=dsn2;UID=;PWD="

Enter internal UID at the remote datastore with ADMIN privileges: ttuser 
Enter password of the internal Uid at the remote datastore:

パスワードを入力するよう要求されたら、ttuserと入力します。次に、ttRepAdminによってキャッシュ管理ユーザーとパスワードを入力するよう要求されます。

Enter cache administrator UID: orauser
Enter cache administrator password:

キャッシュ管理パスワードを要求されたら、orapwdと入力します。

dsn2のUIDおよびPWDは、インスタンス管理者である現在のOSユーザーとして接続が確立されるように、接続文字列でNULL値として指定されます。インスタンス管理者のみがttRepAdmin -duplicateを実行できます。dsn2がPWDではなくPWDCryptで構成されている場合、接続文字列は"DSN=dsn2;UID=;PWDCrypt="にする必要があります。

キャッシュ・グループが構成されたスタンバイ・データベースを読取り専用サブスクライバに複製する場合は、-nokeepCGオプションを使用します。この例では、dsn2がスタンバイ・データベース、sub1が読取り専用サブスクライバです。

ttRepAdmin -duplicate -from dsn2 -host host2 -nokeepCG "DSN=sub1;UID=;PWD="

ttRepAdminによって-uidおよび-pwdの値を入力するよう要求されます。

ttRepAdminユーティリティの詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttRepAdminに関する説明を参照してください。ttRepDuplicateEx C関数の詳細は、『Oracle TimesTen In-Memory Database C開発者ガイド』のttRepDuplicateExに関する説明を参照してください。

キャッシュ・グループが構成されていないアクティブ・スタンバイ・ペアの設定

アクティブ・スタンバイ・ペアを設定するには、この項のタスクを実行します。例については、「1つのサブスクライバを持つアクティブ・スタンバイ・ペアの構成」を参照してください。

読取り専用キャッシュ・グループまたはASYNCHRONOUS WRITETHROUGH（AWT）キャッシュ・グループをレプリケートする場合は、第5章「キャッシュ・グループが構成されたアクティブ・スタンバイ・ペアの管理」を参照してください。

  1. データベースを作成します。

  2. CREATE ACTIVE STANDBY PAIR文を使用して、レプリケーション・スキームを作成します。第3章「アクティブ・スタンバイ・ペアのレプリケーション・スキームの定義」を参照してください。

  3. レプリケーション・エージェントを起動します。「レプリケーション・エージェントの起動および停止」を参照してください。

  4. アクティブ・データベースでttRepStateSet('ACTIVE')をコールします。

  5. アクティブ・データベースでユーザーを作成し、そのユーザーにADMIN権限を付与します。

  6. アクティブ・データベースをスタンバイ・データベースに複製します。

  7. スタンバイ・データベースでレプリケーション・エージェントを起動します。「レプリケーション・エージェントの起動および停止」を参照してください。

  8. スタンバイ・データベースがSTANDBY状態になるまで待機します。スタンバイ・データベースの状態を確認するには、ttRepStateGetプロシージャを使用します。

  9. スタンバイ・データベースからすべてのサブスクライバを複製します。詳細は、「サブスクライバへのマスター・データベースのコピー」を参照してください。

  10. レプリケーション・エージェント・ポリシーを設定し、各サブスクライバ・データベースでレプリケーション・エージェントを起動します。「レプリケーション・エージェントの起動および停止」を参照してください。

アクティブ・データベースの障害からのリカバリ

この項の内容は次のとおりです。

スタンバイ・データベースが使用可能な場合のリカバリ

この項では、スタンバイ・データベースが使用可能で、アクティブ・データベースと同期されている場合にアクティブ・データベースをリカバリする方法について説明します。内容は次のとおりです。

レプリケーションがRETURN RECEIPTまたは非同期の場合

次のタスクを実行します。

  1. 障害が発生したデータベースで、レプリケーション・エージェントがまだ停止されていない場合は停止します。

  2. スタンバイ・データベースで、ttRepStateSet('ACTIVE')を実行します。これによって、データベースの役割がSTANDBYからACTIVEに変更されます。

  3. 新しいアクティブ・データベースで、ttRepStateSave('FAILED', 'failed_database','host_name')を実行します。ここで、failed_databaseは、障害が発生する前のアクティブ・データベースです。この手順は、新しいアクティブ・データベースがサブスクライバ・データベースに直接レプリケートされるようにするために必要です。通常動作時は、スタンバイ・データベースのみがサブスクライバにレプリケートされます。

  4. 障害が発生したデータベースを破棄します。

  5. 新しいアクティブ・データベースを新しいスタンバイ・データベースに複製します。

  6. レプリケーション・エージェント・ポリシーを設定し、レプリケーション・エージェントを起動します。「レプリケーション・エージェントの起動および停止」を参照してください。

スタンバイ・データベースは、アクティブ・データベースに通信します。アクティブ・データベースは、サブスクライバへの更新の送信を停止します。スタンバイ・データベースがアクティブ・データベースと完全に同期している場合、スタンバイ・データベースはSTANDBY状態になり、サブスクライバへの更新の送信を開始します。AWTキャッシュ・グループをレプリケートしている場合、新しいスタンバイ・データベースは、STANDBY状態になると自動的にキャッシュ・グループの処理を引き継ぎます。


注意:

スタンバイ・データベースがSTANDBY状態になったことは、ttRepStateGet組込みプロシージャを使用して確認できます。

レプリケーションがRETURN TWOSAFEの場合

次のタスクを実行します。

  1. スタンバイ・データベースで、ttRepStateSet('ACTIVE')を実行します。これによって、データベースの役割がSTANDBYからACTIVEに変更されます。

  2. 新しいアクティブ・データベースで、ttRepStateSave('FAILED', 'failed_database','host_name')を実行します。ここで、failed_databaseは、障害が発生する前のアクティブ・データベースです。この手順は、新しいアクティブ・データベースがサブスクライバ・データベースに直接レプリケートされるようにするために必要です。通常動作時は、スタンバイ・データベースのみがサブスクライバにレプリケートされます。

  3. 障害が発生したデータベースに接続します。これによって、ローカル・トランザクション・ログからのリカバリがトリガーされます。データベースのリカバリが正常に行われなかったときは、レプリケーションがRETURN RECEIPTまたは非同期の場合のリカバリ方法の手順5から処理を続けてください。詳細は、「レプリケーションがRETURN RECEIPTまたは非同期の場合」を参照してください。

  4. 障害が発生したデータベースのレプリケーション・エージェントが再起動されたことを確認します。再起動されていない場合は起動します。「レプリケーション・エージェントの起動および停止」を参照してください。

スタンバイ・データベースと完全に同期されているとアクティブ・データベースで判断された場合、スタンバイ・データベースはSTANDBY状態になり、サブスクライバへの更新の送信を開始します。AWTキャッシュ・グループをレプリケートしている場合、新しいスタンバイ・データベースは、STANDBY状態になると自動的にキャッシュ・グループの処理を引き継ぎます。


注意:

スタンバイ・データベースがSTANDBY状態になったことは、ttRepStateSet組込みプロシージャを使用して確認できます。

スタンバイ・データベースが使用可能でない場合のリカバリ

次の例を考えてみます。

  • スタンバイ・データベースで障害が発生しました。スタンバイが再起動する前、またはスタンバイがアクティブ・データベースと同期される前に、アクティブ・データベースで障害が発生しました。

  • アクティブ・データベースで障害が発生しました。スタンバイ・データベースがACTIVEになり、リカバリ・プロセスの残りが開始されます。（「アクティブ・データベースの障害からのリカバリ」を参照してください。）新しいスタンバイ・データベースが新しいアクティブ・データベースと完全に同期される前に、そのアクティブ・データベースで障害が発生しました。

両方の例で、スタンバイ・データベースの場合より多くの変更がサブスクライバに適用されている可能性があります。

アクティブ・データベースで障害が発生し、アクティブ・データベースから最後に送信された変更の一部のみがスタンバイ・データベースで適用された場合、リカバリの方法として次の2つの方法があります。

  • ローカル・トランザクション・ログからアクティブ・データベースをリカバリする方法

  • ローカル・トランザクション・ログからスタンバイ・データベースをリカバリする方法

いずれのデータベースが使用可能かまたはいずれのデータベースがより新しいかに応じて、使用する方法を選択します。

アクティブ・データベースのリカバリ

  1. 障害が発生したアクティブ・データベースに接続します。これによって、ローカル・トランザクション・ログからのリカバリがトリガーされます。

  2. 障害が発生したアクティブ・データベースのレプリケーション・エージェントが再起動されたことを確認します。再起動されていない場合は起動します。「レプリケーション・エージェントの起動および停止」を参照してください。

  3. 新しくリカバリされたデータベースで、ttRepStateSet('ACTIVE')を実行します。

  4. 「キャッシュ・グループが構成されていないアクティブ・スタンバイ・ペアの設定」の手順6を実行します。

スタンバイ・データベースのリカバリ

  1. 障害が発生したスタンバイ・データベースに接続します。これによって、ローカル・トランザクション・ログからのリカバリがトリガーされます。

  2. スタンバイ・データベースのレプリケーション・エージェントが自動的に再起動された場合は、そのレプリケーション・エージェントを停止する必要があります。「レプリケーション・エージェントの起動および停止」を参照してください。

  3. DROP ACTIVE STANDBY PAIR文を使用して、レプリケーション構成を削除します。

  4. CREATE ACTIVE STANDBY PAIR文を使用して、レプリケーション構成を再作成します。

  5. レプリケーション・エージェント・ポリシーを設定し、レプリケーション・エージェントを起動します。「レプリケーション・エージェントの起動および停止」を参照してください。

  6. マスター・データベースで、ttRepStateSet('ACTIVE')を実行して、そのデータベースにACTIVEの役割を割り当てます。

  7. 「キャッシュ・グループが構成されていないアクティブ・スタンバイ・ペアの設定」の手順6から実行します。

元のノードへのフェイルバック

フェイルオーバーに成功した後、アクティブ・データベースおよびスタンバイ・データベースが元のノードに存在するようにフェイルバックする必要がある場合があります。詳細は、「アクティブ・データベースとスタンバイ・データベースの役割の入替え」を参照してください。

スタンバイ・データベースの障害からのリカバリ

スタンバイ・データベースの障害からリカバリするには、次のタスクを実行します。

  1. スタンバイ・データベースの障害を検出します。

  2. RETURN TWOSAFEサービスが有効になっている場合にスタンバイ・データベースで障害が発生すると、処理中のトランザクションはアクティブ・データベースでコミットされなくなり、エラー8170「Receipt or commit acknowledgement not returned in the specified timeout interval」が発生します。このような状況が発生した場合は、localActionパラメータを2（COMMIT）に指定してttRepSyncSetプロシージャをコールして、トランザクションを再度コミットします。次に例を示します。

    call ttRepSyncSet( null, null, 2);
commit;

  3. アクティブ・データベースで、ttRepStateSave('FAILED','standby_database','host_name')を実行します。その後は、スタンバイ・データベースが使用できない間は、アクティブ・データベースへの更新は、サブスクライバ・データベースに直接レプリケートされます。サブスクライバ・データベースは、アクティブから直接複製することもできます。

  4. スタンバイ・データベースのレプリケーション・エージェントが自動的に再起動された場合は、レプリケーション・エージェントを停止します。「レプリケーション・エージェントの起動および停止」を参照してください。

  5. 次のいずれかの方法で、スタンバイ・データベースをリカバリします。

    • スタンバイ・データベースに接続します。これによって、ローカル・トランザクション・ログからのリカバリがトリガーされます。

    • アクティブ・データベースからスタンバイ・データベースを複製します。

    スタンバイ・データベースが停止していた時間、およびアクティブ・データベースから適用する必要があるトランザクション・ログの量によって、使用するリカバリの方法が決まります。

  6. レプリケーション・エージェント・ポリシーを設定し、レプリケーション・エージェントを起動します。「レプリケーション・エージェントの起動および停止」を参照してください。

スタンバイ・データベースは、アクティブ・データベースで2つのマスター・データベースの同期が確認された後でSTANDBY状態になります。


注意:

スタンバイ・データベースがSTANDBY状態になったことは、ttRepStateGetプロシージャを使用して確認できます。

サブスクライバ・データベースの障害からのリカバリ

サブスクライバ・データベースで障害が発生した場合は、次のいずれかの方法を使用してリカバリすることができます。

スタンバイ・データベースが停止しているか、またはリカバリ中の場合は、アクティブ・データベースからサブスクライバを複製します。

サブスクライバ・データベースがリカバリされた後、レプリケーション・エージェント・ポリシーを設定し、レプリケーション・エージェントを起動します。「レプリケーション・エージェントの起動および停止」を参照してください。

アクティブ・データベースとスタンバイ・データベースの役割の入替え

アクティブ・データベースの役割をスタンバイ・データベースに変更する場合、およびその逆の変更を実行する場合は、次の手順を実行します。

  1. 現行のアクティブ・データベースで更新を生成しているすべてのアプリケーションを一時停止します。

  2. 現行のスタンバイ・データベースのDSNおよびホストを入力パラメータとして使用して、アクティブ・データベースでttRepSubscriberWaitを実行します。これによって、すべての更新が現行のスタンバイ・データベースに送信されます。

  3. 現行のアクティブ・データベースでレプリケーション・エージェントを停止します。「レプリケーション・エージェントの起動および停止」を参照してください。

  4. 現行のアクティブ・データベースでttRepDeactivateを実行します。これによって、このデータベースはIDLE状態になります。

  5. 現行のスタンバイ・データベースでttRepStateSet('ACTIVE')を実行します。これによって、このデータベースがアクティブ・スタンバイ・ペアのアクティブ・データベースとして機能するようになります。

  6. レプリケーション・エージェント・ポリシーを設定し、元のアクティブ・データベースでレプリケーション・エージェントを起動します。ttRepStateGetプロシージャを使用して、データベースの状態がIDLEからSTANDBYに変更されたタイミングを確認します。これによって、このデータベースがアクティブ・スタンバイ・ペアのスタンバイ・データベースとして機能するようになります。

  7. 手順1で一時停止したアプリケーションを再開します。

二重のアクティブ・データベースの検出

通常、アクティブ・スタンバイ・ペアのアクティブ・データベースおよびスタンバイ・データベースの指定は、ユーザーによって明示的に制御されます。ただし、状況によっては、スタンバイ・データベースの役割をアクティブ・データベースに変更するときに、ユーザーがアクティブ・データベースとスタンバイ・データベースの両方を変更できない場合があります。

たとえば、アクティブ・データベースのサイトへのネットワーク通信が中断された場合、異なるサイトのスタンバイ・データベースがアクティブ・データベースの役割を引き継ぐ必要があるが、現行のアクティブ・データベースでのレプリケーションの停止やその役割の手動での変更ができないことがあります。最初にアクティブ・データベースでレプリケーションを停止せずにスタンバイ・データベースをアクティブに変更すると、両方のマスター・データベースがACTIVE状態となり、トランザクションを受け入れる状況となります。このような例では、TimesTenは、データベース間のネットワーク通信がリストアされたときに、マスター・データベースのアクティブ/スタンバイの役割を自動的に決定できます。

データベース間の初期ハンドシェイク中に、TimesTenでアクティブ・スタンバイ・ペアのレプリケーション・スキームのマスター・データベースが両方ともACTIVE状態であると判別された場合、自動的に次の処理が実行されます。

  戻る
戻る 		 次へ
次へ
  目次
目次		 索引
索引