| Oracle® TimesTen In-Memory Database開発者および管理者ガイド 11gリリース2 (11.2.2) B66443-07 |
|
 前 |
 次 |
Oracle Clusterwareは、アプリケーションを監視および制御して高可用性を実現します。次の項では、Oracle Clusterwareを使用して、TimesTenアクティブ・スタンバイ・ペアの可用性を管理する方法を説明します。
|
注意: Oracle Clusterwareの詳細は、Oracle Databaseドキュメントの『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。 |
Oracle Clusterwareを使用して管理できるのは次の構成です。
読取り専用サブスクライバを持つ(または持たない)アクティブ・スタンバイ・ペア
AWTキャッシュ・グループ、読取り専用キャッシュ・グループおよびグローバル・キャッシュ・グループが構成された(読取り専用サブスクライバを持つ(または持たない))アクティブ・スタンバイ・ペア
図8-1に、同じローカル・ネットワークに1つの読取り専用サブスクライバを持つアクティブ・スタンバイ・ペアを示します。アクティブ・データベース、スタンバイ・データベースおよび読取り専用サブスクライバは異なるノードにあります。TimesTenを実行しているがアクティブ・スタンバイ・ペアの一部ではないノードが2つあります。アクティブ・データベースの更新は、アプリケーションによって行われます。スタンバイおよびサブスクライバからの読取りもアプリケーションによって行われます。すべてのノードは共有記憶域に接続されています。
Oracle Clusterwareを使用すると、ノード障害およびその他のイベントに対応して、TimesTenデータベースおよびアプリケーションの起動、監視および自動フェイルオーバーを行うことができます。詳細は、「Clusterwareによる管理」および「障害からのリカバリ」を参照してください。
Oracle Clusterwareは、TimesTenの2つの可用性レベルで実装できます。
基本的な可用性レベルでは、クラスタ内の2つのマスター・ノードおよび最大127の読取り専用サブスクライバ・ノードが管理されます。アクティブ・スタンバイ・ペアは、ローカル・ホスト名またはIPアドレスを使用して定義されます。両方のマスター・ノードに障害が発生すると、ユーザーが介入してアクティブ・スタンバイ・スキームを新しいホストに移行する必要があります。両方のマスター・ノードに障害が発生すると、Oracle Clusterwareによってユーザーへの通知が行われます。
高度な可用性レベルでは、アクティブ、スタンバイおよび読取り専用サブスクライバ・データベースの仮想IPアドレスが使用されます。初期アクティブ・スタンバイ・ペアの一部ではない追加のノードをクラスタに含めることもできます。障害が発生した場合、仮想IPアドレスを使用することで、追加のノードの1つが、障害の発生したノードの役割を自動的に引き継ぐことができます。
|
注意: アプリケーションがクライアント/サーバー構成のTimesTenに接続している場合、自動クライアント・フェイルオーバーによって、クライアントは、障害が発生した後にアクティブな役割を持つマスター・データベースに自動的に再接続できます。『Oracle TimesTen In-Memory Databaseリファレンス』のアクティブ・スタンバイ・ペアに対するクライアント・フェイルオーバーの使用に関する説明およびTTC_FailoverPortRangeの説明を参照してください。 |
ttCWAdminユーティリティを使用して、Oracle Clusterwareで管理されているクラスタ内のTimesTenアクティブ・スタンバイ・ペアを管理します。各アクティブ・スタンバイ・ペアの構成は、cluster.oracle.iniという初期化ファイルに手動で作成されます。このファイルの情報は、Oracle Clusterwareのリソースを作成する場合に使用されます。リソースは、TimesTenデーモン、TimesTenデータベース、TimesTenプロセス、ユーザー・アプリケーションおよび仮想IPアドレスの管理に使用されます。クラスタ内のホストからcluster.oracle.iniファイルへのアクセスおよび読取りが可能な間は、ttCWAdminユーティリティをこのホストから実行できます。ttCWAdminユーティリティの詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttCWAdminに関する説明を参照してください。cluster.oracle.iniファイルの詳細は、「cluster.oracle.iniファイルによるOracle Clusterware管理の構成」を参照してください。
ttCWAdminコマンドの実行に必要な権限の詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttCWAdminに関する説明を参照してください。
TimesTenでは、WindowsプラットフォームにおけるClusterwareはサポートされていません。
TimesTenは、TimesTenアクティブ・スタンバイ・ペア・レプリケーションを備えたOracle Clusterwareリリース11.2.0.2および11.2.0.3をサポートします。ネットワークと記憶域の要件およびOracle Clusterware構成ファイルの情報は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。
Oracle ClusterwareおよびTimesTenは、すべてのノードで同じ場所にインストールされている必要があります。TimesTenインスタンス管理者は、同じUNIXプライマリ・グループにOracle Clusterwareインストール所有者として属している必要があります。
各ホストのクロックの誤差が250ミリ秒以内であるように、すべてのホストがネットワーク・タイム・プロトコル(NTP)または同様のシステムを使用する必要があります。各ノードのシステム・クロックの同期がとられるように調整する場合は、時間をさかのぼって設定しないでください。
Oracle ClusterwareをTimesTenと組み合せて使用すると、アクティブ・マスター上で、アクティブ・スタンバイ・ペア・レプリケーション・スキームが作成(ttCWAdmin -createコマンドを使用)、および削除(ttCWAdmin -dropコマンドを使用)されます。ttCWAdmin -createコマンドとttCWAdmin -dropコマンドの間では、次のコマンドまたはSQL文のいずれも実行できません。ただし、これらのコマンドまたはSQLステートメントは、ttCWAdmin -beginAlterSchemaコマンドとttCWAdmin -endAlterSchemaコマンドを使用する場合に実行できます(「スキーマの変更」を参照)。
CREATE ACTIVE STANDBY PAIR、ALTER ACTIVE STANDBY PAIRおよびDROP ACTIVE STANDBY PAIRのSQL文によるアクティブ・スタンバイ・ペアの作成、変更または削除。
ttAdminユーティリティの-repStartオプションおよび-repStopオプション、またはttRepStartまたはttRepStopの組込みプロシージャのいずれかによる、レプリケーション・エージェントの起動または停止。
ttAdminユーティリティの-cacheStartオプションおよび-cacheStopオプション、またはttCacheStartおよびttCacheStopの組込みプロシージャのいずれかによる、アクティブ・スタンバイ・ペア作成後のキャッシュ・エージェントの起動または停止。
ttRepAdminユーティリティの-duplicateオプションによるデータベースの複製。
クラスタ内のアクティブ・スタンバイ・ペアがグリッドのメンバーである場合の、キャッシュ・グリッドを管理するための組込みプロシージャの実行。
また、ttCWAdmin -shutdownをコールする前にttDaemonAdmin -stopをコールしないでください。
Oracle Clusterwareと統合されたTimesTenでは、このような操作は、ttCWAdminユーティリティおよびcluster.oracle.iniファイルで指定された属性によって行われます。
組込みやユーティリティの詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』を参照してください。SQL文の詳細は、『Oracle TimesTen In-Memory Database SQLリファレンス・ガイド』を参照してください。
cluster.oracle.iniファイルの情報は、TimesTenデータベース、TimesTenプロセス、ユーザー・アプリケーションおよび仮想IPアドレスを管理するOracle Clusterwareリソースの作成に使用されます。cluster.oracle.iniという初期化ファイルをテキスト・ファイルとして作成します。
ttCWAdmin -createコマンドはこのファイルの構成情報を読り取るため、テキスト・ファイルの場所はttCWAdminからアクセス可能かつ読取り可能である必要があります。ttCWAdminユーティリティを使用して、Oracle Clusterwareで管理されているクラスタ内のTimesTenアクティブ・スタンバイ・ペアを管理します。
このファイルは、アクティブ・データベースのホストにあるTimesTenデーモン・ホーム・ディレクトリに置くことをお薦めします。ただし、ttCWAdmin -createコマンドを実行するホストと同じホストにある任意のディレクトリまたは共有ドライブにこのファイルを置くこともできます。
このファイルのデフォルトの場所は、install_dir/infoディレクトリです。このファイルを別の場所に置く場合は、-ttclusteriniオプションを指定して場所のパスを識別します。
cluster.oracle.iniファイルのエントリ名は、sys.odbc.iniファイルの既存のシステムDSNと同じである必要があります。たとえば、[basicDSN]は、「基本的な可用性の構成」で説明されているcluster.oracle.iniファイル内のエントリ名です。また、[basicDSN]は、各ホストのsys.odbc.iniファイル内のDataStoreおよびData Source Nameデータ・ストア属性である必要があります。たとえば、host1にあるDSN basicDSNのsys.odbc.iniファイルは次のようになります。
[basicDSN] DataStore=/path1/basicDSN LogDir=/path1/log DatabaseCharacterSet=AL32UTF8 ConnectionCharacterSet=AL32UTF8
host2にあるbasicDSNのsys.odbc.iniファイルには異なるパスを指定できますが、その他すべての属性は同じである必要があります。
[basicDSN] DataStore=/path2/basicDSN LogDir=/path2/log DatabaseCharacterSet=AL32UTF8 ConnectionCharacterSet=AL32UTF8
次の項では、cluster.oracle.iniファイルのサンプル構成を示します。
この例では、サブスクライバを持たないアクティブ・スタンバイ・ペアを示します。アクティブ・データベースのホストは、リストの最初のMasterHost (host1)で、スタンバイ・データベースのホストは、2つ目のMasterHost (host2)です。リスト内の各ホストはカンマで区切ります。必要に応じて、読みやすくするために空白を含めることができます。
[basicDSN] MasterHosts=host1,host2
次の例では、host3にある、1つのサブスクライバを持つアクティブ・スタンバイ・ペアのcluster.oracle.iniファイルを示します。
[basicSubscriberDSN] MasterHosts=host1,host2 SubscriberHosts=host3
高度な可用性を実現するには、予備のマスター・ホストまたはサブスクライバ・ホストを構成します。これらのホストは、アクティブ・スタンバイ・ペア・レプリケーション・スキームで使用されるマスター・ホストまたはサブスクライバ・ホストが予期しないシャットダウンやリカバリ不能なエラーの発生により置換えが必要になるまで、アイドル状態に維持されます。
「基本的な可用性の構成」で説明されているように、cluster.oracle.iniファイルのMasterHosts属性は、マスター・ノードとして使用されるホストを構成します。アクティブ・スタンバイ・ペアのレプリケーション・スキームでは、2つのマスター・ノードのみ必要です。障害が発生すると、停止していないホストがアクティブ・データベースとなり(すでにアクティブ・データベースでない場合)、停止したホストはリカバリ後にスタンバイ・マスターとなります。ただし、停止したホストをリカバリできず、cluster.oracle.iniファイルで3つ以上のホストをマスター・ホストとして指定している場合、リスト内の次のマスター・ホストがリカバリ不能なマスター・ポストを置き換えるようにインスタンス化されます。
たとえば、次の例は複数マスター・ホストの構成を示します。最初の2つのマスター・ホスト(host1およびhost2)はアクティブ・マスターおよびスタンバイ・マスターとして使用され、後半の2つのマスター・ホスト(host3およびhost4)はリカバリ不能な障害が発生した場合にhost1またはhost2のいずれかを置き換えるために使用されます。
MasterHosts=host1,host2,host3,host4
3つ以上のホストを構成する場合、TimesTenリソースを管理するOracle Clusterwareリソースのみで使用される2つの仮想IP (VIP)アドレスも構成する必要があります。これらのVIPアドレスを使用することにより、レプリケーションを管理するTimesTen内部プロセスは、リカバリ不能なホスト・エラーにより発生するいずれのマスター・ホスト変更の影響も受けなくなります。
|
注意: 高度な可用性で使用されるこれらのVIPアドレスを管理するOracle Clusterwareリソースは、ttCWAdmin -createVIPsコマンドを使用して作成されます(「仮想IPアドレスを管理するためのOracle Clusterwareリソースを作成する」を参照)。 |
これらのVIPアドレスは、Oracle Clusterwareで使用するために定義されている他のいずれのVIPアドレスまたはユーザー・アプリケーションにより使用されるいずれのVIPアドレスとも異なる必要があります。さらに、アプリケーションがこれらのVIPアドレスを使用すると、マスター・ホストで障害(リカバリ可能またはリカバリ不可能)が発生したときにアプリケーションでエラーが発生することがあります。ユーザー・アプリケーションは、クライアント・フェイルオーバーの方法として、またはアクティブ・データベースとスタンバイ・マスターが切り替わったときに自身を隔離するための方法として、これらのVIPアドレスを使用することはできません。
2つのVIPアドレスをMasterVIPパラメータに指定します。アクティブ・スタンバイ・ペアのレプリケーション・スキームの各マスター・ホストに1つずつです。TimesTenクラスタに指定されたVIPアドレスは、Oracle Clusterwareですでに定義および使用されているVIPアドレスとは異なる必要があります。特に、Oracle Clusterwareのインストール時に指定されたVIPアドレスをTimesTenで使用することはできません。
MasterVIP=192.168.1.1, 192.168.1.2
次のパラメータも、cluster.oracle.iniファイル内で高度な可用性に関連付けられます。
MasterHostsに類似するSubscriberHostsは、サブスクライバ・データベースを含むことができるホストの名前をリストします。
MasterVIPに類似するSubscriberVIPは、サブスクライバ・ノードを管理するためにTimesTenが内部で使用できるVIPアドレスを提供します。
VIPInterfaceは、パブリック・ネットワーク・アダプタの名前です。
VIPNetMaskは、仮想IPアドレスのネットマスクを定義します。
次の例では、アクティブ・データベースおよびスタンバイ・データベースのホストは、それぞれhost1およびhost2です。リカバリ不能なエラーが発生した場合にインスタンス化できるホストは、host3およびhost4です。サブスクライバ・ノードはありません。VIPInterfaceは、パブリック・ネットワーク・アダプタの名前です。VIPNetMaskは、仮想IPアドレスのネットマスクを定義します。
[advancedDSN] MasterHosts=host1,host2,host3,host4 MasterVIP=192.168.1.1, 192.168.1.2 VIPInterface=eth0 VIPNetMask=255.255.255.0
次の例では、単一のサブスクライバがhost4上に構成されます。SubscriberHostsには、マスター・データベースのフェイルオーバーに使用できる追加のホストが1つと、サブスクライバ・データベースのフェイルオーバーに使用できる追加のノードが1つ定義されます。MasterVIPおよびSubscriberVIPは、マスター・データベースおよびサブスクライバ・ホストに対して定義されている仮想IPアドレスを指定します。
[advancedSubscriberDSN] MasterHosts=host1,host2,host3 SubscriberHosts=host4,host5 MasterVIP=192.168.1.1, 192.168.1.2 SubscriberVIP=192.168.1.3 VIPInterface=eth0 VIPNetMask=255.255.255.0
追加のマスター・ノードが次のようになっていることを確認します。
TimesTenがインストールされている。
ダイレクト・リンクのアプリケーションがインストールされている(構成の一部である場合)。「アプリケーション・フェイルオーバーの実装」を参照してください。
アクティブ・スタンバイ・ペアが1つ以上のAWTまたは読取り専用キャッシュ・グループをレプリケートする場合、CacheConnect属性をyに設定します。
この例では、高度な可用性構成で1つのサブスクライバを持つアクティブ・スタンバイ・ペアを指定します。アクティブ・スタンバイ・ペアによって、1つ以上のキャッシュ・グループがレプリケートされます。
[advancedCacheDSN] MasterHosts=host1,host2,host3 SubscriberHosts=host4, host5 MasterVIP=192.168.1.1, 192.168.1.2 SubscriberVIP=192.168.1.3 VIPInterface=eth0 VIPNetMask=255.255.255.0 CacheConnect=y
アクティブ・スタンバイ・ペアがキャッシュ・グリッドのメンバーになっている場合、GridPort属性を設定して、アクティブ・データベースとスタンバイ・データベースにポート番号を割り当てます。
この例では、高度な可用性構成でサブスクライバを持たないアクティブ・スタンバイ・ペアを指定します。そのアクティブ・スタンバイ・ペアは、キャッシュ・グリッドのメンバーになっています。
[advancedGridDSN] MasterHosts=host1,host2,host3 MasterVIP=192.168.1.1, 192.168.1.2 VIPInterface=eth0 VIPNetMask=255.255.255.0 CacheConnect=y GridPort=16101, 16102
キャッシュ・グリッドとOracle Clusterwareの併用の詳細は、「TimesTenキャッシュ・グリッドとOracle Clusterwareの併用」を参照してください。
Oracle Clusterwareと統合されたTimesTenでは、アクティブ・スタンバイ・ペアの任意のデータベースにリンクされたTimesTenアプリケーションのフェイルオーバーを簡素化できます。TimesTenでは、ダイレクト・リンクのアプリケーションと、Oracle ClusterwareおよびTimesTenと同じホストにあるクライアント/サーバー・アプリケーションの両方を管理できます。
TimesTenアプリケーションのフェイルオーバーに必要なcluster.oracle.iniファイルの属性は、次のとおりです。
AppName: Oracle Clusterwareで管理されるアプリケーションの名前。
AppStartCmd: アプリケーションを起動するコマンドライン。
AppStopCmd: アプリケーションを停止するコマンドライン。
AppCheckCmd: AppNameで指定されたアプリケーションのステータスを確認するアプリケーションを実行するためのコマンドライン。
AppType: アプリケーションのリンク先となるデータベースを定義します。使用可能な値は、Active、Standby、DualMaster、Subscriber(すべて)およびSubscriber[index]です。
AppFailureThreshold、DatabaseFailoverDelay、AppScriptTimeoutなど、構成可能なオプションの属性が複数あります。すべてのオプションの属性(およびそのデフォルト値)については、表A-3「オプションの属性」を参照してください。
TimesTenアプリケーション・モニター・プロセスは、ユーザー指定のスクリプトまたはAppCheckCmdで指定されたプログラムを使用して、アプリケーションを監視します。アプリケーションのステータスを確認するスクリプトは、成功の場合は0を返し、失敗の場合は0以外を返すように記述されている必要があります。0(ゼロ)以外の値が検出されると、Oracle Clusterwareは、障害が発生したアプリケーションをリカバリするためのアクションを実行します。
この例では、サブスクライバを持たないアクティブ・スタンバイ・ペアに対して構成されている高度な可用性を示します。readerアプリケーションは、スタンバイ・データベースのデータを問い合せるアプリケーションです。AppStartCmd、AppStopCmdおよびAppCheckCmdには、start、stopおよびcheckコマンドなどの引数を含めることができます。
|
注意: AppStartCmd、AppStopCmdおよびAppCheckCmdの値に引用符を使用しないでください。 |
[appDSN] MasterHosts=host1,host2,host3,host4 MasterVIP=192.168.1.1, 192.168.1.2 VIPInterface=eth0 VIPNetMask=255.255.255.0 AppName=reader AppType=Standby AppStartCmd=/mycluster/reader/app_start.sh start AppStopCmd=/mycluster/reader/app_stop.sh stop AppCheckCmd=/mycluster/reader/app_check.sh check
2つ以上のアプリケーションのフェイルオーバーを構成できます。AppNameを使用してアプリケーションを指定し、AppName属性のすぐ後に続くAppType、AppStartCmd、AppStopCmdおよびAppCheckCmdの値を指定します。読みやすくするために空白行を含めることができます。次に例を示します。
[app2DSN] MasterHosts=host1,host2,host3,host4 MasterVIP=192.168.1.1, 192.168.1.2 VIPInterface=eth0 VIPNetMask=255.255.255.0 AppName=reader AppType=Standby AppStartCmd=/mycluster/reader/app_start.sh AppStopCmd=/mycluster/reader/app_stop.sh AppCheckCmd=/mycluster/reader/app_check.sh AppName=update AppType=Active AppStartCmd=/mycluster/update/app2_start.sh AppStopCmd=/mycluster/update/app2_stop.sh AppCheckCmd=/mycluster/update/app2_check.sh
AppTypeをDualMasterに設定すると、アプリケーションはアクティブ・ホストとスタンバイ・ホストの両方で起動します。アクティブ・ホストでアプリケーションが停止すると、そのホスト上のアクティブ・データベースおよびその他すべてのアプリケーションがスタンバイ・ホストにフェイルオーバーします。AppFailureInterval、AppRestartAttemptsおよびAppUptimeThreshold属性を設定することによって、障害間隔、再起動の試行回数および稼働時間のしきい値を構成できます。これらの属性にはデフォルト値があります。次に例を示します。
[appDualDSN] MasterHosts=host1,host2,host3,host4 MasterVIP=192.168.1.1, 192.168.1.2 VIPInterface=eth0 VIPNetMask=255.255.255.0 AppName=update AppType=DualMaster AppStartCmd=/mycluster/update/app2_start.sh AppStopCmd=/mycluster/update/app2_stop.sh AppCheckCmd=/mycluster/update/app2_check.sh AppRestartAttempts=5 AppUptimeThreshold=300 AppFailureInterval=30
両方のマスター・ノードに障害が発生し、その後復旧した場合、Oracle Clusterwareは、自動的にマスター・データベースをリカバリできます。一時的な二重の障害から自動リカバリするには、次の条件が満たされている必要があります。
アクティブ・スタンバイ・ペアにRETURN TWOSAFEが指定されていない。
AutoRecoverがyに設定されている。
RepBackupDirが共有記憶域のディレクトリを指定している。
RepBackupPeriodが0より大きい値に設定されている。
両方のマスター・ノードに永続的な障害が発生した場合、Oracle Clusterwareは、自動的にマスター・データベースを2つの新しいノードにリカバリできます。次の条件が満たされている必要があります。
高度な可用性(仮想IPアドレスおよび少なくとも4つのホスト)が構成されている。
アクティブ・スタンバイ・ペアがキャッシュ・グループをレプリケートしていない。
キャッシュ・グリッドが構成されていない。
RETURN TWOSAFEが指定されていない。
AutoRecoverがyに設定されている。
RepBackupDirが共有記憶域のディレクトリを指定している。
RepBackupPeriodが0より大きい値に設定されている。
TimesTenは最初にアクティブ・データベースの全体バックアップを実行し、次に増分バックアップを実行します。オプションの属性RepFullBackupCycleを指定すると、TimesTenがその後の全体バックアップを実行するタイミングを管理できます。デフォルトでは、TimesTenは、増分バックアップを5回実行するたびに完全バックアップを1回実行します。
RepBackupDirおよびRepBackupPeriodをバックアップに構成している場合、TimesTenは、アクティブになるすべてのマスター・データベースのバックアップを実行します。データベースが再度アクティブにならないかぎり、アクティブからスタンバイになったデータベースに対して実行されたバックアップは削除されません。2つの完全なデータベース・バックアップ用に十分な共有記憶域が必要です。ttCWAdmin -restoreコマンドによって、正しいバックアップ・ファイルが自動的に選択されます。
増分バックアップでは、トランザクション・ログ・ファイルのログ・レコードの量が増えます。RepBackupPeriodおよびRepFullBackupCycleの値を十分に小さくし、トランザクション・ログ・ファイルのログ・レコードが大量にならないようにします。
[autorecoveryDSN]
MasterHosts=host1,host2,host3,host4
MasterVIP=192.168.1.1, 192.168.1.2
VIPInterface=eth0
VIPNetMask=255.255.255.0
AutoRecover=y
RepBackupDir=/shared_drive/dsbackup
RepBackupPeriod=3600
アクティブ・スタンバイ・ペアにキャッシュ・グループがある場合、または両方のマスター・ホストの障害から手動でリカバリする場合は、AutoRecoverがn(デフォルト)に設定されていることを確認します。手動リカバリでは、次のこと必要です。
RepBackupDirが共有記憶域のディレクトリを指定している。
RepBackupPeriodが0より大きい値に設定されている。
この例では、手動リカバリの属性設定を示します。AutoRecoverのデフォルト値はnであるため、このファイルには含まれていません。
[manrecoveryDSN]
MasterHosts=host1,host2,host3
MasterVIP=192.168.1.1, 192.168.1.2
VIPInterface=eth0
VIPNetMask=255.255.255.0
RepBackupDir=/shared_drive/dsbackup
RepBackupPeriod=3600
RepDDL属性は、アクティブ・スタンバイ・ペアを作成するSQL文を表します。RepDDL属性はオプションです。これは、アクティブ・スタンバイ・ペアから表、キャッシュ・グループおよび順序を除外する場合に使用できます。
RepDDLをcluster.oracle.iniファイルに含める場合は、ReturnServiceAttribute、MasterStoreAttributeまたはSubscriberStoreAttributeをcluster.oracle.iniファイルに指定しないでください。これらのレプリケーション設定は、RepDDL属性に含めるようにしてください。
RepDDLの値を指定する場合、データベース・ファイル名の接頭辞に<DSN>マクロを使用します。マスター・ホスト名を指定するには、<MASTERHOST[1]>および<MASTERHOST[2]>マクロを使用します。TimesTenは、構成で仮想IPアドレスが使用されているかどうに応じて、MasterHostsまたはMasterVIP属性の正しい値に置換します。同様に、サブスクライバ・ホスト名を指定するには、<SUBSCRIBERHOST[n]>マクロを使用します(ここで、nは、1からSubscriberHosts属性値の合計数までの数値、仮想IPアドレスが使用されている場合は1からSubscriberVIP属性値の合計数までの数値です)。
RepDDL属性を使用して、アクティブ・スタンバイ・ペアから表、キャッシュ・グループおよび順序を除外します。
[excludeDSN] MasterHosts=host1,host2,host3,host4 SubscriberHosts=host5,host6 MasterVIP=192.168.1.1, 192.168.1.2 SubscriberVIP=192.168.1.3 VIPInterface=eth0 VIPNetMask=255.255.255.0 RepDDL=CREATE ACTIVE STANDBY PAIR \ <DSN> ON <MASTERHOST[1]>, <DSN> ON <MASTERHOST[2]> SUBSCRIBER <DSN> ON <SUBSCRIBERHOST[1]>\ EXCLUDE TABLE pat.salaries, \ EXCLUDE CACHE GROUP terry.salupdate, \ EXCLUDE SEQUENCE ttuser.empcount
レプリケーション・エージェントのトランスミッタは、次の方法でルート情報を取得します(優先順に示します)。
RepDDL設定のROUTE句から(ROUTE句が指定されている場合)。高度な可用性を構成している場合は、ROUTE句を指定しないでください。
ローカル・ホストとリモート・ホストのプライベート・ホスト名およびパブリック・ホスト名を提供するとともに、リモート・デーモンのポート番号を提供するOracle Clusterwareから。プライベート・ホスト名は、パブリック・ホスト名より優先されます。レプリケーション・エージェントのトランスミッタがIPCソケットに接続できない場合、Oracle Clusterwareがレプリケーション・スキームに関して保持している情報を使用してリモート・デーモンへの接続を試行します。
アクティブ・ホストおよびスタンバイ・ホストから。失敗した場合、レプリケーション・エージェントはホスト名に基づいた接続方法を選択します。
この例では、RepDDLにROUTE句を指定します。
[routeDSN] MasterHosts=host1,host2,host3,host4 RepDDL=CREATE ACTIVE STANDBY PAIR \ <DSN> ON <MASTERHOST[1]>, <DSN> ON <MASTERHOST[2]>\ ROUTE MASTER <DSN> ON <MASTERHOST[1]> SUBSCRIBER <DSN> ON <MASTERHOST[2]>\ MASTERIP "192.168.1.2" PRIORITY 1\ SUBSCRIBERIP "192.168.1.3" PRIORITY 1\ MASTERIP "10.0.0.1" PRIORITY 2\ SUBSCRIBERIP "10.0.0.2" PRIORITY 2\ MASTERIP "140.87.11.203" PRIORITY 3\ SUBSCRIBERIP "140.87.11.204" PRIORITY 3\ ROUTE MASTER <DSN> ON <MASTERHOST[2]> SUBSCRIBER <DSN> ON <MASTERHOST[1]>\ MASTERIP "192.168.1.3" PRIORITY 1\ SUBSCRIBERIP "192.168.1.2" PRIORITY 1\ MASTERIP "10.0.0.2" PRIORITY 2\ SUBSCRIBERIP "10.0.0.1" PRIORITY 2\ MASTERIP "140.87.11.204" PRIORITY 3\ SUBSCRIBERIP "140.87.11.203" PRIORITY 3\
クラスタを作成および初期化するには、次の手順を実行します。
クラスタで複数のアクティブ・スタンバイ・ペアを使用する予定の場合は、「クラスタへの複数のアクティブ・スタンバイ・ペアの挿入」を参照してください。
リモート障害時リカバリ・サブスクライバとしてOracle Databaseを構成する場合は、「障害時リカバリ・サブスクライバとしてのOracle Databaseの構成」を参照してください。
Oracle Clusterwareによって管理されていない読取り専用サブスクライバを設定する場合は、「Oracle Clusterwareによって管理されていない読取り専用サブスクライバの構成」を参照してください。
Oracle Clusterwareをインストールします。デフォルトでは、すべてのホストで同時にインストールが実行されます。ご使用のプラットフォーム用のOracle Clusterwareのインストール・ドキュメントを参照してください。
インストールが正常に完了すると、Oracle Clusterwareは自動的に起動します。
|
注意: 次を実行すると、Oracle Clusterwareがクラスタ内のすべてのホストで実行されているかどうかを確認できます。crsctl check crs -all |
TimesTenをクラスタ内の各ホスト(追加のホストを含む)の同じ場所にインストールします。インスタンス名は各ホストで同じである必要があります。インスタンス管理者のユーザー名は、すべてのホストで同じである必要があります。TimesTenインスタンス管理者は、同じUNIXプライマリ・グループにOracle Clusterwareインストール所有者として属している必要があります。
インストーラによって次の値の入力を求められ、それぞれの値はttcrsagent.optionsファイルに格納されます。
TimesTenクラスタ・エージェントに関連付けられているTCP/IPポート番号。ポート番号は、クラスタ内のすべてのノードで同じである必要があります。ポート番号を指定しない場合、TimesTenはデフォルトのTimesTenデーモンのポート番号に6を加えて、TimesTenクラスタ・エージェントに関連付けられたTCP/IPポート番号にします。したがって、TimesTenクラスタ・エージェントに関連付けられたデフォルトのデーモンのポート番号は、32ビット・システムでは53398に、64ビット・システムでは53402になります。
Oracle Clusterwareの場所。場所は各ホストで同じである必要があります。
スペア・ホストを含むクラスタ内のホスト(ホスト名はカンマで区切ります)。このリストは各ホストで同じである必要があります。
ttCWAdmin –initコマンドおよびttCWAdmin –shutdownコマンドでは、TimesTenクラスタを開始および停止するために、ttcrsagent.optionsファイルが使用されます。ttcrsagent.optionsファイルは、TimesTenデーモンのホーム・ディレクトリにあります。
ttcrsagent.optionsファイルを手動で変更しないでください。かわりに、TimesTenクラスタの開始後にttmodinstall -crsコマンドを使用して、このファイル内の情報を作成または変更します。また、setup.shに-recordオプションおよび-batchオプションを使用して、追加ホストに同じインストールを実行できます。
Oracle Clusterwareの現在のホーム・ロケーションはCRS_HOME環境変数に設定されています。また、ttmodinstall -crsコマンドは、プロンプトの一部としてOracle Clusterwareホームの現在の場所を示します。
|
注意: ttcrsagent.optionsファイルの詳細は、「TimesTenクラスタ・エージェントの起動」を参照してください。ttmodinstallの詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttmodinstallに関する説明を参照してください。 |
次の例は、ttcrsagent.optionsファイルの各項目を変更するときに表示されるttmodinstall -crsプロンプトを示しています。
% ttmodinstall -crs Cannot find instance_info file : /etc/TimesTen/instance_info Would you like to modify the existing TimesTen Replication with Oracle Clusterware configuration? [ no ] yes This TimesTen instance is configured to use an Oracle Clusterware installation located in : /mydir/oracle/crs/app/11.2.0/grid Would you like to change this value? [ no ] no The TimesTen Clusterware agent is configured to use port 54504 Would you like to change this value? [ no ] no The TimesTen Clusterware agent is currently configured with these nodes : node1 node2 node3 node4 Would you like to change these values? [ no ] Overwrite the existing TimesTen Clusterware options file? [ no ] no
TimesTenクラスタ情報は、Oracle Cluster Registry(OCR)に保存されます。rootユーザーとして、このコマンドを入力します。
ttCWAdmin -ocrConfig
Oracle ClusterwareおよびTimesTenがホストにインストールされている場合、この手順を繰り返す必要はありません。
ttCWAdmin -initコマンドを実行して、クラスタ内のすべてのホストで、TimesTenクラスタ・エージェントおよびTimesTenクラスタ・デーモン・モニターを起動します。このコマンドは、ttcrsagent.optionsファイルで定義された、クラスタ内のどのホストででも実行できます。
次に例を示します。
ttCWAdmin -init
ttCWAdmin -initコマンドによって、次の操作が実行されます。
ttcrsagent.optionsファイルを読み取り、このファイルに定義されている各ホストでTimesTenメイン・デーモンを起動します。
クラスタ内のすべてのホストで、TimesTenクラスタ・エージェント(ttCRSAgent)およびTimesTenクラスタ・デーモン・モニター(ttCRSDaemon)が開始および登録されます。各ホストには、TimesTenのインストールのために1つのTimesTenクラスタ・エージェントと1つのTimesTenクラスタ・デーモン・モニターがあります。TimesTenクラスタ・エージェントが起動すると、Oracle Clusterwareによって各ホストでのTimesTenデーモンの監視が開始され、障害が発生するとTimesTenデーモンが再起動されます。
TimesTenクラスタ・エージェント(ttCRSAgent)およびTimesTenクラスタ・デーモン・モニター(ttCRSDaemon)をクラスタ内の特定のホストで起動および登録するには、-hostsコマンドを使用して、クラスタ内の希望のホストを指定し、起動します。
ttCWAdmin -init -hosts "host1, host2"
アクティブ・データベースを配置するホストにデータベースを作成します。DSNはデータベース・ファイル名と同じである必要があります。
表、AWTキャッシュ・グループおよび読取り専用キャッシュ・グループなどのスキーマ・オブジェクトを作成し、適切なデータを使用して設定します。ただし、キャッシュ・グループを作成する前に、まず、キャッシャ・グループをロードするタイミングを決定する必要があります。
最高のパフォーマンスを達成するには、ttCWAdmin -createコマンドを実行する前に、キャッシュ・グループ表をOracle Database表からロードします。複製がアクティブ・マスター上で実行されてスタンバイ・マスター(およびサブスクライバ)が作成される前に初期データを使用してキャッシュ・グループをロードすると、パフォーマンスのオーバーヘッドがより小さくなります。
このオプションでは、次の手順を実行します。
キャッシュ・エージェントを次のように起動します。
Command> call ttCacheStart;
|
注意: この時点では、ttCWAdmin -startコマンドは実行されていないため、キャッシュ・エージェントを起動できます。ttCWAdmin -startコマンドを実行すると、キャッシュ・エージェントはすでに起動されており、処理を継続することを示すメッセージが表示されます。 |
LOAD CACHE GROUP文を使用し、Oracle Database表からキャッシュ・グループ表をロードします。
自動リフレッシュ・キャッシュ・グループを使用している場合、ALTER CACHE GROUP SET AUTOREFRESH STATE PAUSED文を使用して、自動リフレッシュ状態をPAUSEDに設定します。自動リフレッシュの状態は、ttCWAdmin -startコマンドの処理の一環として、ONに設定されます。
次の例は、読取り専用自動リフレッシュ・キャッシュ・グループを作成してデータをロードし、その後に自動リフレッシュの状態をpauseに設定する方法を示します。
Command> call ttCacheStart; Command> CREATE READONLY CACHE GROUP my_cg AUTOREFRESH MODE INCREMENTAL INTERVAL 60 SECONDS FROM t1 (c1 NUMBER(22) NOT NULL PRIMARY KEY, c2 DATE, c3 VARCHAR(30)); Command> LOAD CACHE GROUP my_cg COMMIT EVERY 100 ROWS PARALLEL 4; Command> ALTER CACHE GROUP my_cg SET AUTOREFRESH STATE PAUSED;
または、ttCWAdmin -startが実行されるまで、キャッシュ・グループ表のロードを待機します(「キャッシュ・グループのロード」を参照)。データは、スタンバイ・マスターおよびすべてのサブスクライバにレプリケートされます。
クラスタに含められるすべてのホストで、システムDSN (sys.odbc.ini)ファイルを作成します。DataStore属性とData Source Nameは、cluster.oracle.iniファイルのエントリ名として同じである必要があります。sys.odbc.iniファイルの内容の詳細は、「cluster.oracle.iniファイルによるOracle Clusterware管理の構成」を参照してください。
cluster.oracle.iniファイルをテキスト・ファイルとして作成します。ファイルの内容と許容可能な場所の詳細は、「cluster.oracle.iniファイルによるOracle Clusterware管理の構成」を参照してください。
高度な可用性を実現するには、予備のマスター・ホストまたはサブスクライバ・ホストを構成します。これらのホストは、アクティブ・スタンバイ・ペア・レプリケーション・スキームで使用されるマスター・ホストまたはサブスクライバ・ホストが予期しないシャットダウンやリカバリ不能なエラーの発生により置換えが必要になるまで、アイドル状態に維持されます。これはオプションの手順で、高度な可用性を構成することを決定した場合のみ実行する必要があります。
高度な可用性を実装するために追加のマスター・ホストまたはサブスクライバ・ホストを提供することを計画している場合、仮想IPアドレスを構成する必要があります(アクティブ・スタンバイ・ペアでアクティブに使用されている各マスター・ホストおよび各サブスクライバに1つずつ)。作成する必要のある仮想IPアドレスの数は、「高度な可用性の構成」を参照してください。
この場合、次の手順を実行します。
Oracle Clusterwareにより管理されているTimesTenレプリケーション環境の複数のホストを管理するためのみに使用される、ネットワーク上の新しい仮想IPアドレスを指定(または作成)します。
高度な可用性を構成する複数のホストを管理するために使用されるこれらのVIPアドレスを、cluster.oracle.iniファイルで構成します(「高度な可用性の構成」を参照)。
これらのVIPアドレスを管理するOracle Clusterwareリソースを、クラスタ内の任意のホストでrootユーザーとしてttCWAdmin -createVIPsコマンドを実行して作成します。
次に例を示します。
ttCWAdmin -createVIPs -dsn myDSN
このコマンドで作成されるVIPアドレスの名前は、network_で始まり、その後に、TimesTenインスタンス名、TimesTenインスタンス管理者およびDSNが続きます。一方、Oracle Clusterwareによる使用のために作成されるVIPアドレスは、oraで始まります。
|
注意: ttCWAdmin -createVIPsコマンドを実行した後に、ttCWAdmin -createコマンドを実行する必要があります。ttCWAdmin -createコマンドの実行後に、VIPアドレスを高度な可用性のために使用することを決定した場合、次の手順を実行する必要があります。
|
VIPアドレスを管理するOracle Clusterwareリソースを作成すると、これを削除するための唯一の方法は、ttCWAdmin -dropVIPsコマンドを実行することです。最初にttCWAdmin -dropコマンドを実行してから、仮想IPアドレスを削除します。
次に、仮想IPアドレスを削除する方法の例を示します。
ttCWAdmin -dropVIPs -dsn myDSN
ttCWAdmin -dropVIPsコマンドを使用する状況の例は、「クラスタからのアクティブ・スタンバイ・ペアの削除」を参照してください。
クラスタ内の任意のホストでttCWAdmin -createコマンドを実行し、アクティブ・スタンバイ・ペアのレプリケーション・スキームを作成します。
|
注意: cluster.oracle.iniファイルには、ttCWAdmin -createコマンドの実行に必要な構成がふくまれているため、ttCWAdmin実行可能ファイルによってアクセス可能である必要があります。詳細は、「cluster.oracle.iniファイルによるOracle Clusterware管理の構成」を参照してください。 |
次に例を示します。
ttCWAdmin -create -dsn myDSN
ttCWAdmin -createコマンドにより、次のプロンプトが表示されます。
ADMIN権限を持つTimesTenユーザーの名前を求めるプロンプト。キャッシュ・グループがOracle Clusterwareにより管理されている場合は、TimesTenキャッシュ・マネージャ・ユーザー名を入力します。
前の手順で入力したユーザー名のTimesTenパスワードを求めるプロンプト。
キャッシュ・グループが使用されている場合は、キャッシュ・マネージャ・ユーザーと同じ名前のOracleユーザーのパスワードが求められます。このパスワードは、キャッシュ・マネージャ・ユーザーが接続したときにOraclePWD接続属性で指定されます。
前の手順の情報を暗号化するために使用するランダム文字列を求めるプロンプト。
cluster.oracle.iniファイルとして使用するファイルのパスと名前を指定する場合は、-ttclusteriniコマンドを使用します。
ttCWAdmin -create -dsn myDSN -ttclusterini path/to/cluster/mycluster.ini
アクティブ・スタンバイ・ペアを削除するには、ttCWAdmin -dropコマンドを次のように使用します。
ttCWAdmin -drop -dsn myDSN
|
注意: アプリケーションが仮想IPアドレスを使用してTimesTenデータベースに接続する場合、仮想IPアドレスはOracle Clusterwareにより管理されるため、この接続はttCWAdmin -dropコマンドを使用して削除できます。ただし、アプリケーションがホスト名を使用してTimesTenデータベースに接続する場合、接続は削除されません。 |
ttCWAdmin -createコマンドとttCWAdmin -dropコマンドを使用する順序を示す例は、「クラスタでのアクティブ・スタンバイ・ペアの管理」および「アクティブ・スタンバイ・ペアでの読取り専用サブスクライバの管理」を参照してください。
ttCWAdmin -startコマンドを任意のホストで実行し、アクティブ・スタンバイ・ペアのレプリケーション・スキームでクラスタを起動します。これによって、アクティブ･データベースでキャッシュ・エージェント(すでに起動していない場合)およびレプリケーション・エージェントが起動され、複製を実行してスタンバイ・マスター(および任意のサブスクライバ)が作成され、スタンバイ・マスター(および任意のサブスクライバ)でキャッシュ・エージェントおよびレプリケーション・エージェントが起動されます。
-noAppを指定しないと、アプリケーションも起動されます。-noAppを指定しない場合にアプリケーションを起動および停止するには、それぞれ-startAppsおよび-stopAppsコマンドを使用します。
次に例を示します。
ttCWAdmin -start -dsn myDSN
このコマンドは、アクティブ・スタンバイ・ペアの次のプロセスを開始します。
アプリケーションAppNameの監視
次の例では、キャッシュ・エージェントおよびレプリケーション・エージェントを起動しますが、-noappコマンドが含まれているため、アプリケーションは起動しません。
ttCWAdmin -start -noapp -dsn myDSN
アプリケーションを起動および停止するには、次に示すとおり、-startAppsおよび-stopAppsコマンドを使用します。
ttCWAdmin -startapps -dsn myDSN ... ttCWAdmin -stopapps -dsn myDSN
キャッシュ・エージェントとレプリケーション・エージェントを停止し、アプリケーションを両方のデータベースから切断するには、ttCWAdmin -stopコマンドを実行します。
ttCWAdmin -stop -dsn myDSN
|
注意: アプリケーションが仮想IPアドレスを使用してTimesTenデータベースに接続する場合、仮想IPアドレスはOracle Clusterwareにより管理されるため、この接続はttCWAdmin -stopコマンドを使用して削除できます。ただし、アプリケーションがホスト名を使用してTimesTenデータベースに接続する場合、接続は削除されません。しかも、スタンバイ・マスターへのレプリケーションも発生しません。 |
ttCWAdmin -startコマンドとttCWAdmin -stopコマンドを使用する順序を示す例は、「クラスタでのアクティブ・スタンバイ・ペアの管理」および「アクティブ・スタンバイ・ペアでの読取り専用サブスクライバの管理」を参照してください。
アクティブ・スタンバイ・ペアにキャッシュ・グループが含まれており、キャッシュ・グループがすでにロードされていない場合(「1つのホストでのTimesTenデータベースの作成および移入」を参照)、LOAD CACHE GROUP文を使用し、Oracle Database表からキャッシュ・グループ表をロードします。
キャッシュ・グループをロードする状況の詳細は、「1つのホストでのTimesTenデータベースの作成および移入」を参照してください。
Oracle Clusterwareを使用してクラスタ内の複数のアクティブ・スタンバイ・ペアを管理する場合、cluster.oracle.iniファイルに追加の構成を含めます。すべてのTimesTenデータベースが単一ホストの同じTimesTenインスタンスに含まれる場合のみ、Oracle Clusterwareはクラスタ内の1つ以上のアクティブ・スタンバイ・ペアを管理できます。
たとえば、次のcluster.oracle.iniファイルには、同一ホストの2つのアクティブ・スタンバイ・ペアのレプリケーション・スキームの構成情報が含まれます。
[advancedSubscriberDSN] MasterHosts=host1,host2,host3 SubscriberHosts=host4, host5 MasterVIP=192.168.1.1, 192.168.1.2 SubscriberVIP=192.168.1.3 VIPInterface=eth0 VIPNetMask=255.255.255.0 [advSub2DSN] MasterHosts=host1,host2,host3 SubscriberHosts=host4, host5 MasterVIP=192.168.1.4, 192.168.1.5 SubscriberVIP=192.168.1.6 VIPInterface=eth0 VIPNetMask=255.255.255.0
追加のレプリケーション・スキームに対して次の手順を実行します。
データベースを作成および移入します。
仮想IPアドレスを作成します。ttCWAdmin -createVIPsコマンドを使用します。
アクティブ・スタンバイ・ペアのレプリケーション・スキームを作成します。ttCWAdmin -createコマンドを使用します。
アクティブ・スタンバイ・ペアを開始します。ttCWAdmin -startコマンドを使用します。
プライマリ・サイトにリモート障害時リカバリ・サブスクライバとしてOracle Databaseを持つアクティブ・スタンバイ・ペアを作成できます。「アクティブ・スタンバイ・ペアでの障害時リカバリ・サブスクライバの使用」を参照してください。Oracle Clusterwareは、アクティブ・スタンバイ・ペアは管理しますが、障害時リカバリ・サブスクライバは管理しません。プライマリ・サイトに障害が発生した場合、ユーザーが切替えを実行する必要があります。
Oracle Clusterwareを使用してリモート障害時リカバリ・サブスクライバを持つアクティブ・スタンバイ・ペアを管理するには、次の手順を実行します。
RepDDLまたはRemoteSubscriberHosts Clusterware属性を使用し、リモート障害時リカバリ・サブスクライバに関する情報を提供します。次に例を示します。
[advancedDRsubDSN] MasterHosts=host1,host2,host3 SubscriberHosts=host4, host5 RemoteSubscriberHosts=host6 MasterVIP=192.168.1.1, 192.168.1.2 SubscriberVIP=192.168.1.3 VIPInterface=eth0 VIPNetMask=255.255.255.0 CacheConnect=y
ttCWAdmin -createを使用し、プライマリ・サイトにアクティブ・スタンバイ・ペアのレプリケーション・スキームを作成します。この操作では障害時リカバリ・サブスクライバは作成されません。
ttCWAdmin -startを使用し、アクティブ・スタンバイ・ペアのレプリケーション・スキームを開始します。
アクティブ・スタンバイ・ペアによってレプリケートされるキャッシュ・グループをロードします。
「障害時リカバリ・サブスクライバのローリング・アウト」の手順に従って、障害時リカバリ・サブスクライバを設定します。
Oracle Clusterwareによって管理されていない読取り専用のTimesTenサブスクライバ・データベースを含めることができます。次のタスクを実行します。
cluster.oracle.iniファイルにRemoteSubscriberHosts Clusterware属性を含めます。次に例を示します。
[advancedROsubDSN] MasterHosts=host1,host2,host3 RemoteSubscriberHosts=host6 MasterVIP=192.168.1.1, 192.168.1.2 SubscriberVIP=192.168.1.3 VIPInterface=eth0 VIPNetMask=255.255.255.0
ttCWAdmin -createを使用し、プライマリ・サイトにアクティブ・スタンバイ・ペアのレプリケーション・スキームを作成します。
ttCWAdmin -startを使用し、アクティブ・スタンバイ・ペアのレプリケーション・スキームを開始します。これによって、読取り専用サブスクライバは作成されません。
ttRepStateGet組込みプロシージャを使用して、スタンバイ・データベースの状態がSTANDBYであることを確認します。
サブスクライバ・ホストで、ttRepAdmin -duplicateオプションを使用して、スタンバイ・データベースを読取り専用サブスクライバに複製します。「データベースの複製」を参照してください。
サブスクライバ・ホストでレプリケーション・エージェントを起動します。
既存の構成に読取り専用サブスクライバを追加または削除する場合は、「Oracle Clusterwareによって管理されていない読取り専用サブスクライバの追加または削除」を参照してください。
読取り専用サブスクライバを再作成する場合は、「Oracle Clusterwareによって管理されていない読取り専用サブスクライバの再作成」を参照してください。
各グリッド・メンバーがアクティブ・スタンバイ・ペアである場合にキャッシュ・グリッドを管理するために、Oracle ClusterwareのTimesTen実装を使用できます。TimesTenでは、Oracle Clusterwareを使用したスタンドアロンのグリッド・メンバーの管理をサポートしていません。
この項の内容は次のとおりです。
インストール要件については、「各ホストでのTimesTenのインストール」を参照してください。また、各グリッド・メンバーには、キャッシュ・グリッド内で一意のDSNが設定されている必要があります。
各グリッド・メンバーに対して、「クラスタの作成および初期化」で説明されているタスクを実行します。「キャッシュ・グリッドにアクティブ・スタンバイ・ペアを含める」で説明されているように、cluster.oracle.iniファイルにGridPort Clusterware属性を含めます。指定したポート番号が使用されていないことを確認します。
ttCWAdmin -startコマンドによって、キャッシュ・グリッドにグリッド・メンバーが自動的にアタッチされます。ttCWAdmin -stopコマンドによって、キャッシュ・グリッドからグリッド・メンバーが自動的にデタッチされます。
アクティブ・スタンバイ・ペア・グリッド・メンバーの両方のノードで障害が発生すると、グリッド・メンバーに障害が発生します。Oracle Clusterwareは障害が発生したグリッド・メンバーを自動的にグリッドから削除します。ただし、キャッシュ・グリッドが構成されている場合は、二重障害が発生した後、一時的であっても永続的であっても、それ以上の自動リカバリを実行することはできません。この場合、手動でのリカバリのみ許可されます。詳細は、「アクティブ・スタンバイ・ペア・グリッド・メンバーの両方のノードの手動リカバリ」を参照してください。
アクティブ・マスター・データベースがグリッドにアタッチされている間に、キャッシュ・グループを追加、削除または変更できます。
ttCWAdmin -beginAlterSchemaコマンドを使用して、これらのスキーマを変更します。このコマンドにより、アクティブとスタンバイの両方のマスター・ノードでレプリケーションは停止されますが、アクティブ・マスター・データベースはグリッドにアタッチされたままにすることができます。ttCWAdmin -endAlterSchemaコマンドは特定の変更をスタンバイ・マスター・データベース(およびすべてのサブスクライバ)に伝播するための複製を開始し、変更されたレプリケーション・スキームを登録し、両方のレプリケーション・エージェントを再起動し、Oracle Clustewareの制御を再び使用できるようにします。
|
注意: キャッシュ・グループがレプリケーション・スキーマに含まれているため、ttCWadmin -endAlterSchemaコマンドはこの場合に複製を開始しますが、キャッシュ・グループのDDL文はレプリケートされません。詳細は、「スキーマの変更」を参照してください。 |
アクティブ・スタンバイ・ペアにレプリケートされた表を追加または削除する場合は、「アクティブ・スタンバイ・ペアのDDLの変更」を参照してください。
各アクティブ・スタンバイ・ペア・グリッド・メンバーのアクティブ・データベースで、次の手順を実行します。
|
注意: これらの手順は、アクティブ・スタンバイ・ペアがキャッシュ・グリッドに含まれているかどうかにかかわらず同じです。 |
ttCWAdmin -beginAlterSchemaコマンドを使用して一時的にOracle Clusterwareの管理を停止し、レプリケーション・エージェントを停止することにより、キャッシュ・グループをアクティブ・スタンバイ・ペアに追加できるようにします。
ttCWAdmin -beginAlterSchema -dsn advancedDSN
キャッシュ・グループを作成します。
キャッシュ・グループが読取り専用の場合は、読取り専用キャッシュ・グループを含めるようにアクティブ・スタンバイ・ペアを変更します。
ALTER ACTIVE STANDBY PAIR INCLUDE CACHE GROUP samplecachegroup;
ttCWAdmin -endAlterSchemaコマンドを実行して変更を完了します。キャッシュ・グループ・オブジェクトを追加したため、これらのスキーマの変更をスタンバイ・マスター・データベースへ伝播するためのレプリケーションが発生します。
ttCWAdmin -endAlterSchema -dsn advancedDSN
キャッシュ・グループを作成すると、いつでもそのキャッシュ・グループをロードすることができます。
キャッシュ・グループを削除するには、次の手順を実行します。
|
注意: これらの手順は、アクティブ・スタンバイ・ペアがキャッシュ・グリッドに含まれているかどうかにかかわらず同じです。 |
キャッシュ・グループをアンロードします。キャッシュ・グリッドを使用する場合は、キャッシュ・グリッドのすべてのメンバーでキャッシュ・グループをアンロードする必要があります。
CALL ttOptSetFlag('GlobalProcessing', 1);
UNLOAD CACHE GROUP samplecachegroup;
アクティブ・スタンバイ・ペアのアクティブ・データベースで、キャッシュ・グループの削除を有効にします。
ttCWAdmin -beginAlterSchema -dsn advancedDSN
キャッシュ・グループが読取り専用の場合は、読取り専用キャッシュ・グループを除外するようにアクティブ・スタンバイ・ペアを変更します。
ALTER ACTIVE STANDBY PAIR EXCLUDE CACHE GROUP samplecachegroup;
キャッシュ・グループが読取り専用の場合は、自動リフレッシュの状態をPAUSEDに設定します。
ALTER CACHE GROUP samplecachegroup SET AUTOREFRESH STATE PAUSED;
キャッシュ・グループを削除します。
DROP CACHE GROUP samplecachegroup;
キャッシュ・グループが読取り専用の場合は、Oracle Databaseでキャッシュ管理ユーザーとしてSQL*PlusスクリプトTimesTen_install_dir/oraclescripts/cacheCleanUp.sqlを実行し、自動リフレッシュ操作を実装するために使用するOracle Databaseオブジェクトを削除します。
ttCWAdmin -endAlterSchemaコマンドを実行して変更を完了します。キャッシュ・グループ・オブジェクトを削除したため、これらのスキーマの変更をスタンバイ・マスター・データベースへ伝播するためのレプリケーションが発生します。
ttCWAdmin -endAlterSchema -dsn advancedDSN
各アクティブ・スタンバイ・ペア・グリッド・メンバーのアクティブ・データベースで、手順2から7までを繰り返します。
既存のキャッシュ・グループを変更するには、「キャッシュ・グループの削除」で説明されているように、まず既存のキャッシュ・グループを削除します。その後、「キャッシュ・グループの追加」で説明されているように、キャッシュ・グループに目的の変更を追加します。
Oracle Clusterwareは、様々な種類の障害から自動的にリカバリできます。次の項では、いくつかの障害の例と、Oracle Clusterwareによる障害の管理方法を示します。
TimesTenデータベース・モニター(ttCRSmasterプロセス)でリカバリを実行します。forceconnectオプションを使用せずに、障害の発生したデータベースへの接続を試行します。エラー994(Data store connection terminated)で接続に失敗した場合は、データベース・モニターは10回接続を試行します。エラー707(Attempt to connect to a data store that has been manually unloaded from RAM)で接続に失敗した場合には、データベース・モニターはRAMポリシーを変更して接続を再試行します。データベース・モニターが接続できないと、接続障害エラーを返します。
データベース・モニターがデータベースに接続できた場合、次のタスクが実行されます。
TTREP.REPLICATIONSレプリケーション表のCHECKSUM列を問い合せます。
CHECKSUM列の値がOracle Cluster Registryに保存されているチェックサムと一致する場合は、データベース・モニターはデータベースのロールを確認します。ロールが'ACTIVE'の場合、リカバリは完了です。
ロールが'ACTIVE'でない場合は、データベース・モニターは、ローカル・データベースのレプリケーションのコミット・チケット番号(CTN)とアクティブ・データベースのCTNを問い合せて、レプリケートされていないトランザクションがあるかどうかを確認します。すべてのトランザクションがレプリケートされていれば、リカバリは完了です。
チェックサムが一致しなかった場合、または一部のトランザクションがレプリケートされていない場合には、データベース・モニターはリモート・データベースから複製操作を実行し、ローカル・データベースを再作成します。
エラー8110または8111(マスター・キャッチアップが必要またはマスター・キャッチアップを実行中)により、データベース・モニターがデータベースへの接続に失敗した場合、forceconnect=1オプションを使用して接続を行い、マスター・キャッチアップを開始します。マスター・キャッチアップが完了すると、リカバリは完了です。エラー8112(Operation not permitted)によりマスター・キャッチアップが失敗した場合は、データベース・モニターはリモート・データベースから複製操作を実行します。マスター・キャッチアップの詳細は、「障害が発生したマスター・データベースの自動キャッチアップ」を参照してください。
その他のエラーにより接続に失敗した場合には、データベース・モニターはリモート・データベースから複製操作の実行を試みます。
複製操作では、次のことを確認します。
リモート・データベースが使用できる。
レプリケーション・エージェントが稼働している。
リモート・データベースに適切なロールが設定されている。スタンバイ・データベースの作成のために複製操作が試行される場合は、ロールは'ACTIVE'に設定されている必要があります。読取り専用サブスクライバの作成のために複製操作が試行される場合には、ロールは'STANDBY'または'ACTIVE'に設定されている必要があります。
複製操作の条件が満たされている場合は、障害が発生した既存のデータベースは破棄され、複製操作が開始されます。
アクティブ・データベースが存在するノードで障害が発生した場合、Oracle Clusterwareでは、スタンバイ・データベースの状態が自動的にACTIVEに変更されます。アプリケーション・フェイルオーバーが構成されている場合は、アプリケーションによって新しいアクティブ・データベースの更新が開始されます。
図8-2では、スタンバイ・データベースの状態がACTIVEに変更され、アプリケーションによって新しいアクティブ・データベースが更新されています。
Oracle Clusterwareによって、障害が発生したデータベースまたはホストの再起動が試行されます。成功すると、そのデータベースがスタンバイ・データベースになります。
図8-3に、前のアクティブ・ノードがスタンバイ・ノードになったクラスタを示します。
前のアクティブ・ノードの障害が永続的であり、高度な可用性が構成されている場合は、追加のノードの1つでスタンバイ・データベースが起動されます。
図8-4に、追加のノードの1つでスタンバイ・データベースが起動されたクラスタを示します。
これらのアクションが自動で実行されるまで待機しない場合は、「アクティブ・データベースまたはそのホストで障害が発生した場合の強制的なスイッチオーバーの実行」を参照してください。
スタンバイ・ノードで障害が発生した場合、Oracle Clusterwareによって、まず、そのデータベースまたはホストの再起動が試行されます。スタンバイ・データベースを同じホストで再起動できず、高度な可用性が構成されている場合は、追加のノードでスタンバイ・データベースが起動されます。
図8-5に、追加のノードの1つでスタンバイ・データベースが起動されたクラスタを示します。
サブスクライバ・ノードで障害が発生した場合、Oracle Clusterwareによって、まず、そのデータベースまたはホストの再起動が試行されます。データベースを同じホストで再起動できず、高度な可用性が構成されている場合は、追加のノードでサブスクライバ・データベースが起動されます。
この項の内容は次のとおりです。
Oracle Clusterwareでは、次のような場合に、両方のマスター・ノードで一時的な障害が発生し、その後ノードが復旧した後に自動リカバリを実行できます。
アクティブ・スタンバイ・ペアにRETURN TWOSAFEが指定されていない。
AutoRecoverがyに設定されている。
RepBackupDirが共有記憶域のディレクトリを指定している。
RepBackupPeriodが0より大きい値に設定されている。
Oracle Clusterwareでは、次のような場合に、両方のマスター・ノードで発生した永続的な障害からの自動リカバリを実行できます。
高度な可用性(仮想IPアドレスおよび少なくとも4つのホスト)が構成されている。
アクティブ・スタンバイ・ペアがキャッシュ・グループをレプリケートしていない。
キャッシュ・グリッドが構成されていない。
アクティブ・スタンバイ・ペアにRETURN TWOSAFEが指定されていない。
AutoRecoverがyに設定されている。
RepBackupDirが共有記憶域のディレクトリを指定している。
RepBackupPeriodが0より大きい値に設定されている。
cluster.oracle.iniファイルの例は、「両方のマスター・ノードの永続的な障害からのリカバリ」を参照してください。
アクティブ・スタンバイ・ペア・グリッド・メンバーの両方のノードで障害が発生すると、グリッド・メンバーに障害が発生します。Oracle Clusterwareは障害が発生したグリッド・メンバーを自動的にグリッドから削除します。障害が発生したグリッド・メンバーがグリッドから削除されると、そのメンバーを手動でリカバリできます。ただし、キャッシュ・グリッドが構成されている場合は、二重障害が発生した後、一時的であっても永続的であっても、それ以上の自動リカバリを実行することはできません。
アクティブ・スタンバイ・ペア・グリッド・メンバーが非同期レプリケーション・スキーム内にある場合、グリッド・メンバーは自動的にリカバリされ、グリッドに再アタッチされます。アクティブ・スタンバイ・ペア・グリッド・メンバーがRETURN TWOSAFEで構成されたレプリケーション・スキーム内にある場合は、次の手順を実行して、グリッド・メンバーをリカバリし、グリッドに再アタッチします。
レプリケーション・エージェントとキャッシュ・エージェントを停止し、アプリケーションを両方のデータベースから切断します。この手順により、グリッド・メンバーがグリッドからデタッチされます。
ttCWAdmin -stop advancedGridDSN
アクティブ・スタンバイ・ペアを削除します。
ttCWAdmin -drop advancedGridDSN
アクティブ・スタンバイ・ペアのレプリケーション・スキームを作成します。
ttCWAdmin -create advancedGridDSN
アクティブ・スタンバイ・ペアのレプリケーション・スキームを開始します。この手順により、グリッド・メンバーがグリッドにアタッチされます。
ttCWAdmin -start advancedGridDSN
この項では、障害が発生したマスター・ノードが、TimesTenおよびOracle Clusterwareがインストールされている新しいホストにリカバリされることを想定しています。次の手順では、例としてmanrecoveryDSNデータベースおよびcluster.oracle.iniファイルを使用します。
高度な可用性構成で手動リカバリを実行するには、次の手順を実行します。
TimesTenクラスタ・エージェントがローカル・ホストで実行されていることを確認します。
ttCWAdmin -init -hosts localhost
バックアップ・データベースをリストアします。リストアするデータベースと同じDSNを持つデータベースがホストにないことを確認します。
ttCWAdmin -restore -dsn manrecoveryDSN
データベースにキャッシュ・グループがある場合、そのキャッシュ・グループを削除して再度作成します。
新しいホストがcluster.oracle.iniファイルのMasterHostsおよびSubscriberHostsで指定されていない場合、新しいホストが含まれるようにファイルを変更します。
この手順では、manrecoveryDSNを使用します。cluster.oracle.iniファイルにはすでに追加のホストが指定されているため、manrecoveryDSNにはこの手順は必要はありません。
アクティブ・スタンバイ・ペアのレプリケーション・スキームを再度作成します。
ttCWAdmin -create -dsn manrecoveryDSN
アクティブ・スタンバイ・ペアのレプリケーション・スキームを開始します。
ttCWAdmin -start -dsn manrecoveryDSN
この項では、障害が発生したマスター・ノードが、TimesTenおよびOracle Clusterwareがインストールされている新しいホストにリカバリされることを想定しています。次の手順では、例としてbasicDSNデータベースおよびcluster.oracle.iniファイルを使用します。
基本的な可用性構成で手動リカバリを実行するには、次の手順を実行します。
アクティブ・スタンバイ・ペアのデータベース用に新しいホストを取得します。
TimesTenクラスタ・エージェントがローカル・ホストで実行されていることを確認します。
ttCWAdmin -init -hosts localhost
バックアップ・データベースをリストアします。リストアするデータベースと同じDSNを持つデータベースがホストにないことを確認します。
ttCWAdmin -restore -dsn basicDSN
データベースにキャッシュ・グループがある場合、そのキャッシュ・グループを削除して再度作成します。
cluster.oracle.iniファイルのMasterHostsおよびSubscriberHostsエントリを更新します。この例では、basicDSNデータベースを使用します。MasterHostsエントリはhost1からhost10に変更されます。SubscriberHostsエントリはhost2からhost20に変更されます。
[basicDSN] MasterHosts=host10,host20
アクティブ・スタンバイ・ペアのレプリケーション・スキームを再度作成します。
ttCWAdmin -create -dsn basicDSN
アクティブ・スタンバイ・ペアのレプリケーション・スキームを開始します。
ttCWAdmin -start -dsn basicDSN
両方のマスター・ノードで障害が発生し、データベースが破損する場合があります。同じマスター・ノードにリカバリするには、次の手順を実行します。
レプリケーション・エージェントおよびキャッシュ・エージェントが停止し、アプリケーションが両方のデータベースから切断されていることを確認します。この例では、basicDSNデータベースを使用します。
ttCWAdmin -stop -dsn basicDSN
ttDestroyユーティリティを使用し、新しいアクティブ・データベースを配置するノードでデータベースを破棄します。
ttDestroy basicDSN
バックアップ・データベースをリストアします。
ttCWAdmin -restore -dsn basicDSN
データベースにキャッシュ・グループがある場合、そのキャッシュ・グループを削除して再度作成します。
アクティブ・スタンバイ・ペアのレプリケーション・スキームを再度作成します。
ttCWAdmin -create -dsn basicDSN
アクティブ・スタンバイ・ペアのレプリケーション・スキームを開始します。
ttCWAdmin -start -dsn basicDSN
cluster.oracle.iniファイルでReturnServiceAttribute Clusterware属性を使用し、RETURNサービスRETURN TWOSAFEを利用できるようにアクティブ・スタンバイ・ペアを構成できます。RETURN TWOSAFEが構成されている場合、両方のノードで障害が発生した後、いずれかまたは両方のノードでデータベース・ログを利用できることがあります。
次のcluster.oracle.iniの例では、データベース・ログを利用できなかった場合のバックアップ構成を示します。
[basicTwosafeDSN]
MasterHosts=host1,host2
ReturnServiceAttribute=RETURN TWOSAFE
RepBackupDir=/shared_drive/dsbackup
RepBackupPeriod=3600
次のリカバリ手順を実行します。
レプリケーション・エージェントおよびキャッシュ・エージェントが停止し、アプリケーションが両方のデータベースから切断されていることを確認します。
ttCWAdmin -stop -dsn basicTwosafeDSN
アクティブ・スタンバイ・ペアを削除します。
ttCWAdmin -drop -dsn basicTwosafeDSN
前のアクティブ・データベースまたはスタンバイ・データベースのどちらがより新しいかを判断し、新しい方のデータベースを使用してアクティブ・スタンバイ・ペアを再度作成します。アクティブ・データベースを配置するホストを選択するように要求されます。
ttCWAdmin -create -dsn basicTwosafeDSN
どちらのデータベースも使用できない場合、バックアップからデータベースをリストアします。
ttCWAdmin -restore -dsn basicTwosafeDSN
アクティブ・スタンバイ・ペアのレプリケーション・スキームを開始します。
ttCWAdmin -start -dsn basicTwosafeDSN
二重のホスト障害のより極端なケースとして、3つ以上のマスター・ホストの障害対応について説明します。次のガイドラインを使用します。
停電やネットワーク障害などの場合は、障害の根本原因に対処します。
アクティブ・データベースおよびスタンバイ・データベース用の少なくとも2つの正常なホストを識別または取得します。
cluster.oracle.iniファイルのMasterHostsおよびSubscriberHostsエントリを更新します。
その後実行するアクションのガイドラインは、「高度な可用性の場合の手動リカバリ」および「基本的な可用性の場合の手動リカバリ」を参照してください。
TimesTenおよびOracle Clusterwareによって自動リカバリが実行されるまで待機せずに、スタンバイ・データベースに強制的にスイッチオーバーする場合は、Oracle Clusterwareコマンドを使用してアプリケーションを作成します。
次のことを行います。
アクティブ・データベースでttCRSmasterリソースを停止するには、crsctl stop resourceコマンドを使用します。これにより、スタンバイ・データベースのロールがアクティブに変更されます。
以前のアクティブ・データベースでttCRSmasterリソースを再起動するには、crsctl start resourceコマンドを使用します。これにより、データベースがリカバリされ、スタンバイ・データベースになります。
次の例は、host1のアクティブ・データベースからhost2のスタンバイ・データベースへの強制スイッチオーバーを示しています。
crsctl status resourceコマンドを使用して、すべてのTimesTenリソースを検索します。
% crsctl status resource | grep TT NAME=TT_Activeservice_tt1122_ttadmin_REP1 NAME=TT_Agent_tt1122_ttadmin_HOST1 NAME=TT_Agent_tt1122_ttadmin_HOST2 NAME=TT_App_tt1122_ttadmin_REP1_updateemp NAME=TT_Daemon_tt1122_ttadmin_HOST1 NAME=TT_Daemon_tt1122_ttadmin_HOST2 NAME=TT_Master_tt1122_ttadmin_REP1_0 NAME=TT_Master_tt1122_ttadmin_REP1_1 NAME=TT_Subservice_tt1122_ttadmin_REP1
ttCRSActiveServiceリソースのステータスを取得して、アクティブ・データベースが存在するホストを検索します。
% crsctl status resource TT_Activeservice_tt1122_ttadmin_REP1 NAME=TT_Activeservice_tt1122_ttadmin_REP1 TYPE=application TARGET=ONLINE STATE=ONLINE on host1
初期ステータス・レポートには2つのttCRSmasterリソースがリストされています。どのttCRSmasterリソースがアクティブ・データベースと同じホストにあるかを確認します。
% crsctl status resource TT_Master_tt1122_ttadmin_REP1_0 NAME=TT_Master_tt1122_ttadmin_REP1_0 TYPE=application TARGET=ONLINE STATE=ONLINE on host1 % crsctl status resource TT_Master_tt1122_ttadmin_REP1_1 NAME=TT_Master_tt1122_ttadmin_REP1_1 TYPE=application TARGET=ONLINE STATE=ONLINE on host2
アクティブ・データベースが存在するホストのttCRSmasterリソースを停止します。
% crsctl stop resource TT_Master_tt1122_ttadmin_REP1_0 CRS-2673: Attempting to stop 'TT_Master_tt1122_ttadmin_REP1_0' on 'host1' CRS-2677: Stop of 'TT_Master_tt1122_ttadmin_REP1_0' on 'host1' succeeded
最初のアクティブ・データベースでttCRSmasterリソースを再起動します。
% crsctl start resource TT_Master_tt1122_ttadmin_REP1_0 CRS-2672: Attempting to start 'TT_Master_tt1122_ttadmin_REP1_0' on 'host1' CRS-2676: Start of 'TT_Master_tt1122_ttadmin_REP1_0' on 'host1' succeeded
ttCRSActiveServiceおよびttCRSsubserviceリソースがある場所を確認して、強制スイッチオーバーが成功していることを確認します。
% crsctl status resource TT_Activeservice_tt1122_ttadmin_REP1 NAME=TT_Activeservice_tt1122_ttadmin_REP1 TYPE=application TARGET=ONLINE STATE=ONLINE on host2 % crsctl status resource TT_Subservice_tt1122_ttadmin_REP1 NAME=TT_Subservice_tt1122_ttadmin_REP1 TYPE=application TARGET=ONLINE STATE=ONLINE on host1
crsctl start resourceおよびcrsctl stop resourceコマンドの詳細は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。
この項の内容は次のとおりです。
『Oracle TimesTen In-Memory Databaseインストレーション・ガイド』のOracle Clusterware使用時のTimesTenオンライン・アップグレードの実行に関する説明を参照してください。
次の項では、クラスタ使用時のホストの追加または削除方法を説明します。
ホストを追加するには、クラスタが高度な可用性用に構成されている必要があります。この項の例では、advancedSubscriberDSNを使用しています。
クラスタに2つのスペア・マスター・ホストを追加するには、次のようなコマンドを入力します。
ttCWAdmin -addMasterHosts -hosts "host8,host9" -dsn advancedSubscriberDSN
クラスタに1つのスペア・サブスクライバ・ホストを追加するには、次のようなコマンドを入力します。
ttCWAdmin -addSubscriberHosts -hosts "subhost1" -dsn advancedSubscriberDSN
ホストをクラスタから削除するには、クラスタが高度な可用性用に構成されている必要があります。マスター・ホストの1つを削除するには、MasterHostsに3つ以上のホストがリストされている必要があります。サブスクライバ・ホストの1つを削除するには、サブスクライバ・データベースの数よりも少なくとも1つ多いホストがSubscriberHostsにリストされている必要があります。
この項の例では、advancedSubscriberDSNを使用しています。
クラスタから2つのスペア・マスター・ホストを削除するには、次のようなコマンドを入力します。
ttCWAdmin -delMasterHosts "host8,host9" -dsn advancedSubscriberDSN
クラスタから1つのスペア・サブスクライバ・ホストを削除するには、次のようなコマンドを入力します。
ttCWAdmin -delSubscriberHosts "subhost1" -dsn advancedSubscriberDSN
次の項では、クラスタに対するアクティブ・スタンバイ・ペアの追加または削除方法を説明します。
すでにアクティブ・スタンバイ・ペアを管理しているクラスタに(サブスクライバを持つ(または持たない))アクティブ・スタンバイ・ペアを追加するには、次の手順を実行します。
最初にアクティブ・データベースを配置するホストに、データベースを作成して移入を行います。「1つのホストでのTimesTenデータベースの作成および移入」を参照してください。
cluster.oracle.iniファイルを変更します。この例では、advancedSubscriberDSNの構成がすでに含まれたcluster.oracle.iniファイルに、advSub2DSNを追加します。新しいアクティブ・スタンバイ・ペアは、元のアクティブ・スタンバイ・ペアとは異なるホストにあります。
[advancedSubscriberDSN] MasterHosts=host1,host2,host3 SubscriberHosts=host4, host5 MasterVIP=192.168.1.1, 192.168.1.2 SubscriberVIP=192.168.1.3 VIPInterface=eth0 VIPNetMask=255.255.255.0 [advSub2DSN] MasterHosts=host6,host7,host8 SubscriberHosts=host9, host10 MasterVIP=192.168.1.4, 192.168.1.5 SubscriberVIP=192.168.1.6 VIPInterface=eth0 VIPNetMask=255.255.255.0
rootユーザーとして、新しい仮想IPアドレスを作成します。
ttCWAdmin -createVIPs -dsn advSub2DSN
新しいアクティブ・スタンバイ・ペアのレプリケーション・スキームを作成します。
ttCWAdmin -create -dsn advSub2DSN
新しいアクティブ・スタンバイ・ペアのレプリケーション・スキームを開始します。
ttCWAdmin -start -dsn advSub2DSN
(サブスクライバを持つ(または持たない))アクティブ・スタンバイ・ペアをクラスタから削除するには、次の手順を実行します。
アクティブ・スタンバイ・ペアのすべてのデータベースで、レプリケーション・エージェントを停止します。この例では、「クラスタへのアクティブ・スタンバイ・ペアの追加」で追加されたadvSub2DSNを使用します。
ttCWAdmin -stop -dsn advSub2DSN
アクティブ・スタンバイのレプリケーション・スキームを削除します。
ttCWAdmin -drop -dsn advSub2DSN
アクティブ・スタンバイ・ペアの仮想IPアドレスを削除します。
ttCWAdmin -dropVIPs -dsn advSub2DSN
cluster.oracle.iniファイルを変更します(オプション)。advSub2DSNのエントリを削除します。
データベースを破棄する場合、このアクティブ・スタンバイ・ペアの構成に含まれる各ホストにログオンし、ttDestroyユーティリティを使用します。
ttDestroy advSub2DSN
ttDestroyの詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』のttDestroyに関する説明を参照してください。
次の項では、Oracle Clusterwareが管理するアクティブ・スタンバイ・ペアでの読取り専用サブスクライバの管理方法を説明します。
Oracle Clusterwareによって管理される読取り専用サブスクライバをアクティブ・スタンバイ・ペアのレプリケーション・スキームに追加するには、次の手順を実行します。
すべてのデータベースでレプリケーション・エージェントを停止します。この例では、すでにサブスクライバが含まれており、高度な可用性が構成されているadvancedSubscriberDSNを使用します。
ttCWAdmin -stop -dsn advancedSubscriberDSN
アクティブ・スタンバイ・ペアを削除します。
ttCWAdmin -drop -dsn advancedSubscriberDSN
cluster.oracle.iniファイルを変更します。
SubscriberHosts属性にサブスクライバを追加します。
クラスタが高度な可用性用に構成されている場合、仮想IPアドレスをSubscriberVIP属性に追加します。
これらの属性を使用する例については、「高度な可用性の構成」を参照してください。
アクティブ・スタンバイ・ペアのレプリケーション・スキームを作成します。
ttCWAdmin -create -dsn advancedSubscriberDSN
アクティブ・スタンバイ・ペアのレプリケーション・スキームを開始します。
ttCWAdmin -start -dsn advancedSubscriberDSN
Oracle Clusterwareによって管理される読取り専用サブスクライバをアクティブ・スタンバイ・ペアから削除するには、次の手順を実行します。
すべてのデータベースでレプリケーション・エージェントを停止します。この例では、サブスクライバが含まれており、高度な可用性が構成されているadvancedSubscriberDSNを使用します。
ttCWAdmin -stop -dsn advancedSubscriberDSN
アクティブ・スタンバイ・ペアを削除します。
ttCWAdmin -drop -dsn advancedSubscriberDSN
cluster.oracle.iniファイルを変更します。
SubscriberHosts属性からサブスクライバを削除するか、アクティブ・スタンバイ・ペアにサブスクライバが残っていない場合は属性全体を削除します。
SubscriberVIP属性から仮想IPアドレスを削除するか、アクティブ・スタンバイ・ペアにサブスクライバが残っていない場合は属性全体を削除します。
アクティブ・スタンバイ・ペアのレプリケーション・スキームを作成します。
ttCWAdmin -create -dsn advancedSubscriberDSN
アクティブ・スタンバイ・ペアのレプリケーション・スキームを開始します。
ttCWAdmin -start -dsn advancedSubscriberDSN
Oracle Clusterwareによって管理されている既存のアクティブ・スタンバイ・ペアのレプリケーション・スキームに、Oracle Clusterwareによって管理されていない読取り専用サブスクライバを追加または削除できます。ttCWAdmin -beginAlterSchemaコマンドを使用すると、レプリケーション・スキームを削除および再作成せずに、サブスクライバを追加できます。サブスクライバはOracle Clusterware管理用に設定された構成の一部ではないため、Oracle Clusterwareでは管理されません。
次の手順を実行します。
ttCWAdmin -beginAlterSchemaコマンドを実行し、アクティブ・データベースとスタンバイ・データベースでレプリケーション・エージェントを停止します。
ttIsqlを使用してアクティブ・データベースに接続し、ALTER ACTIVE STANDBY PAIR文を使用して、レプリケーション・スキームにサブスクライバを追加、または削除します。たとえば、サブスクライバを追加するには次のコマンドを実行します。
ALTER ACTIVE STANDBY PAIR ADD SUBSCRIBER ROsubDSN ON host6;
サブスクライバを削除するには、次のコマンドを実行します。
ALTER ACTIVE STANDBY PAIR DROP SUBSCRIBER ROsubDSN ON host6;
変更したレプリケーション・スキームを登録するttCWAdmin -endAlterSchemaコマンドを実行して、レプリケーションを開始します。サブスクライバを追加する場合は、これにより、スタンバイ・マスター・データベースへの複製も開始されます。
ttIsql repschemesコマンドを入力して、読取り専用サブスクライバがレプリケーション・スキームに追加、または削除されていることを確認します。
ttRepStateGet組込みプロシージャを使用して、スタンバイ・データベースの状態がSTANDBYであることを確認します。
サブスクライバを追加した場合は、サブスクライバ・ホストでttRepAdmin -duplicateを実行し、スタンバイ・データベースを読取り専用サブスクライバに複製します。「データベースの複製」を参照してください。
サブスクライバを追加した場合は、サブスクライバ・エージェントでレプリケーション・エージェントを起動します。
サブスクライバを追加した場合は、「Oracle Clusterwareによって管理されていない読取り専用サブスクライバの構成」の手順1の説明に従って、cluster.oracle.iniファイルの読取り専用サブスクライバにRemoteSubscriberHosts Clusterware属性を追加し、クラスタが削除されて再作成された場合に、読取り専用サブスクライバを確実に含むようにします。また、サブスクライバを削除した場合は、cluster.oracle.iniファイル内の、削除されたサブスクライバのRemoteSubscriberHosts Clusterware属性を削除します(構成されている場合)。
次のタスクを実行して、Oracle Clusterwareによって管理されない読取り専用サブスクライバを破棄および再作成します。
サブスクライバ・ホストでレプリケーション・エージェントを停止します。
ttDestroyユーティリティを使用して、サブスクライバ・データベースを破棄します。
サブスクライバ・ホストで、ttRepAdmin -duplicateを使用して、スタンバイ・データベースを読取り専用サブスクライバに複製します。「データベースの複製」を参照してください。
Oracle Clusterwareを使用してアクティブ・スタンバイ・ペアを管理する場合は、Oracle Clusterwareですべてのレプリケーション・エージェントを起動および停止する必要があることを除いて、通常のレプリケーション環境と同様に必要に応じてDDL文を実行しスキーマを変更できます。
したがって、スキーマを変更する際には次のことに気をつけてください。
自動的にレプリケートされるオブジェクトに対するDDL文については、レプリケーション・エージェントを停止する必要はありません。この場合、DDLステートメントが自動的に伝播され、スタンバイ・マスターとすべてのサブスクライバに適用されるため、これ以上のアクションは必要ありません。DDLReplicationLevel接続属性によって、レプリケートされるDDL文を制御します。
レプリケーション・スキームの一部であるが、DDL文が実行されないオブジェクト(「アクティブ・スタンバイ・ペアへのその他の変更」でリストされているオブジェクト)については、アクティブ・マスターでOracle Clusterware ttCWAdmin -beginAlterSchemaコマンドを実行すると、レプリケーション・スキームの各ノード上のレプリケーション・エージェントが停止します。その後、レプリケーション・スキームのアクティブ・マスターでDDL文を実行します。最後に、アクティブ・マスターでOracle Clusterware ttCWAdmin -endAlterSchemaコマンドを実行して、レプリケーション・エージェントを再起動します。
これらのオブジェクトはレプリケーション・スキームの一部ですが、DDL文がレプリケートされないため、ttCWAdmin -endAlterSchemaコマンドの後に複製が発生して、これらのスキーマの変更がマスターおよびすべてのサブスクライバに伝播されます。これは、複製がスキーマの変更を伝播するために使用される唯一のシナリオです。
手順については、「Oracle Clusterwareのスキーマ変更の簡素化」を参照してください。
自動的にレプリケートされず、レプリケーション・スキームの一部ではないオブジェクトに対するDDL文については、アクティブ・マスターでOracle Clusterware ttCWAdmin -beginAlterSchemaコマンドを実行すると、すべてのノード上のレプリケーション・エージェントが停止されます。次に、「アクティブ・スタンバイ・ペアのDDLの変更」での指示に従って、手動でこれらのDDL文を実行して、すべてのノードを同期できます。最後に、アクティブ・マスターでOracle Clusterware ttCWAdmin -endAlterSchemaコマンドを実行し、すべてのレプリケーション・エージェントを再起動します。
手順については、「Oracle Clusterwareのスキーマ変更の簡素化」を参照してください。
|
注意: 「アクティブ・スタンバイ・ペアのDDLの変更」および「アクティブ・スタンバイ・ペアへのその他の変更」という項では、どのDDL文がアクティブ・スタンバイ・ペア用に自動的にレプリケートされるか、どの文がレプリケートされないかを説明しています。これらの項では、どのオブジェクトがレプリケーション・スキームの一部かも説明しています。 |
ttCWAdmin -beginAlterSchemaおよび-endAlterSchemaコマンドを使用して、レプリケーション・エージェントを停止する必要のあるアクティブおよびスタンバイのマスター・データベースでのスキーマ変更を簡素化します。
ttCWAdmin -beginAlterSchemaコマンドは、スキーマ変更の準備として、アクティブおよびスタンバイの両方のマスター・ノードでレプリケーション・エージェントを停止することによって、スキーマ変更に備えます。
すべてのスキーマ変更が完了した後、ttCWAdmin -endAlterSchemaコマンドを実行します。レプリケーション・スキームの一部であるオブジェクトで、これらのオブジェクトに対して実行されるDDL文が自動的にレプリケートされない場合は、ttCWAdmin -endAlterSchemaコマンドの後に複製が発生して、これらのスキーマの変更のみがマスターおよびすべてのサブスクライバに伝播されます。このコマンドは変更されたレプリケーション・スキームを登録し、アクティブおよびスタンバイ・マスター・ノードのレプリケーション・エージェントを再起動し、Oracle Clustewareの制御を再び使用できるようにします。
Oracle Clusterwareの使用時にアクティブ・スタンバイ・ペアのスキーマを変更するには、次のタスクを実行します。
アクティブおよびスタンバイの両方のマスターでレプリケーション・エージェントを停止して、アクティブ・スタンバイ・ペアのスキーマへの変更を有効にします。
ttCWAdmin -beginAlterSchema -dsn advancedDSN
必要なスキーマ変更を行います。
オブジェクトのDDL文がレプリケートされないオブジェクトを作成、変更または削除する場合は、レプリケーション・エージェントが無効な状態でその同じオブジェクトがレプリケーション・スキームのすべてのデータベースに存在することを確認し、同じオブジェクトをスタンバイ・マスターおよびサブスクライバで手動で作成、変更または削除する必要もあります。たとえば、アクティブ・データベースでマテリアライズド・ビューを作成する場合は、スタンバイ・マスターのデータベースとサブスクライバ・ノードでも同時にマテリアライズド・ビューを作成します。
レプリケーション・スキームの一部であるが、自動的にはレプリケートされないオブジェクト(順序など)をアクティブ・スタンバイ・ペアのレプリケーション・スキームに含める場合は、アクティブ・スタンバイ・ペアを変更します。
ALTER ACTIVE STANDBY PAIR INCLUDE samplesequence;
オブジェクトがキャッシュ・グループの場合は、「グリッドのアクティブ・スタンバイ・ペアへのスキーマ変更」のキャッシュ・グループの作成、変更または削除の手順を参照してください。
ttCWAdmin -endAlterSchemaコマンドを実行して、アクティブおよびスタンバイのマスター・ノードでレプリケーション・エージェントを再起動します。レプリケーション・スキームの一部であるオブジェクトを変更したが、これらのオブジェクトに対して実行されるDDL文が自動的にレプリケーションされない場合は、ttCWAdmin -endAlterSchemaコマンドの後に複製が発生して、これらのスキーマの変更のみがマスターおよびすべてのサブスクライバに伝播されます。
ttCWAdmin -endAlterSchema -dsn advancedDSN
サブスクライバ・データベースを追加または削除したり、データベース属性を変更するには、次のタスクを実行します。
アクティブ・スタンバイ・ペアのデータベースでレプリケーション・エージェントを停止します。これらのコマンドでは、例としてadvancedCacheDSNを使用します。
ttCWAdmin -stop -dsn advancedCacheDSN
アクティブ・スタンバイ・ペアを削除します。
ttCWAdmin -drop -dsn advancedCacheDSN
必要に応じて、スキーマを変更します。
アクティブ・スタンバイ・ペアのレプリケーション・スキームを再度作成します。
ttCWAdmin -create -dsn advancedCacheDSN
アクティブ・スタンバイ・ペアのレプリケーション・スキームを開始します。
ttCWAdmin -start -dsn advancedCacheDSN
フェイルオーバー後、アクティブ・データベースおよびスタンバイ・データベースはフェイルオーバー前とは異なるホストに配置されます。元の構成をリストアするには、ttCWAdminユーティリティの-switchオプションを使用します。オプションで、-timeoutオプションと-switchオプションを使用して、アクティブおよびスタンバイのデータベースの切替えが完了するまで待機するタイムアウト(秒)を設定できます。
次に例を示します。
ttCWAdmin -switch -dsn basicDSN
-switchオプションを使用する前に、オープン・トランザクションが存在しないことを確認してください。オープン・トランザクションが存在する場合、コマンドは失敗します。
|
注意: -switchおよび-timeoutオプションの詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』の「ttCWAdmin」を参照してください。 |
図8-6に、アクティブ・スタンバイ・ペアのホストを示します。アクティブ・データベースはホストAに存在し、スタンバイ・データベースはホストBに存在します。
ttCWAdmin -switchコマンドによって次のタスクが実行されます。
ホストA (アクティブ・ノード)でTimesTenクラスタ・エージェント(ttCRSAgent)を解除する。
ホストAでデータベース・モニター(ttCRSmaster)を無効にする。
ホストAで組込みプロシージャttRepSubscriberWait、ttRepStopおよびttRepDeactivateをコールする。
ホストAでアクティブ・サービス(ttCRSActiveService)を停止し、Oracle ClusterwareのCRSDプロセスに失敗イベントをレポートする。
ホストAで監視を有効にし、アクティブ・サービスをホストBに移動する。
ホストAでレプリケーション・エージェントを開始し、ホストBでスタンバイ・サービス(ttCRSsubservice)を停止して、ホストBでOracle ClusterwareのCRSDプロセスに失敗イベントをレポートする。
ホストAでスタンバイ・サービス(ttCRSsubservice)を開始する。
クラスタが高度な可用性用に構成されている場合、ttCWAdminユーティリティの-relocateオプションを使用して、ローカル・ホストから、cluster.oracle.iniファイルのMasterHosts属性で指定されている次に利用可能なスペア・ホストに、データベースを移動できます。ローカル・ホストのデータベースがアクティブな役割を持っている場合、-relocateオプションでは、まず役割の入替えが行われます。したがって、新しく移行されたアクティブ・データベースはスタンバイに、スタンバイ・データベースはアクティブになります。
-relocateオプションは、ホストをオフラインにする場合にデータベースを移動するために有効です。このコマンドを使用する前に、オープン・トランザクションが存在しないことを確認してください。
-relocateオプションにロール・スイッチが必要な場合は、オプションで-timeoutオプションと-relocateオプションを使用して、役割の切替えが完了するまで待機するタイムアウト(秒)を設定することもできます。
次に例を示します。
ttCWAdmin -relocate -dsn advancedDSN
|
注意: -relocateおよび-timeoutオプションの詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』の「ttCWAdmin」を参照してください。 |
ホストのオペレーティング・システムまたはハードウェアをアップグレードしたり、ネットワーク・メンテナンスを実行する場合は、Oracle Clusterwareを停止して自動スタートアップを無効にします。rootまたはOS管理者として、次のOracle Clusterwareコマンドを実行します。
# crsctl stop crs # crsctl disable crs
TimesTenを停止します。『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』のTimesTenアプリケーションの停止に関する説明を参照してください。
ホストのメンテナンスを実行します。その後、自動スタートアップを有効にしてOracle Clusterwareを開始します。
# crsctl enable crs # crsctl start crs
これらのコマンドの詳細は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。
クラスタ内のすべてのホストを停止する必要がある場合、各ホストでOracle Clusterwareを個々に停止します。rootまたはOS管理者として、次のOracle Clusterwareコマンドを実行します。
# crsctl stop crs # crsctl disable crs
TimesTenを停止します。『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』のTimesTenアプリケーションの停止に関する説明を参照してください。
メンテナンスを実行します。その後、自動スタートアップを有効にしてOracle Clusterwareを開始します。
# crsctl enable crs # crsctl start crs
これらのコマンドの詳細は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。
ttCWAdmin -createコマンドでアクティブ・スタンバイ・ペアのレプリケーション・スキームを作成する場合、TimesTen環境を管理するために必要なユーザー名とパスワードを求めるプロンプトがOracle Clusterwareで表示されます。Oracle Clusterwareはこれらのユーザー名とパスワードを保存します。ユーザー名やパスワードを変更した後には、ttCWAdmin -reauthenticateコマンドを実行して、これらの新しいユーザー名とパスワードをOracle Clusterwareが保存できるようにする必要があります。
DDLReplicationLevel接続属性が3に設定されていることを確認します。この値であれば、アクティブ・マスター上のユーザー名やパスワードへの変更がスタンバイ・マスターにレプリケートされます。
同じ方法(および同じ制限)を使用して、ユーザー名やパスワードを変更します(「レプリケーションで使用されるユーザー名またはパスワードの変更」を参照)。
アクティブ・マスター・データベースで、スタンバイ・マスター・データベースのDSNおよびホストを使用してttRepSubscriberWait組込みプロシージャ(またはttRepAdmin -waitコマンド)をコールし、すべてのパスワード変更がスタンバイ・マスターにレプリケートされていることを確認します。たとえば、すべてのトランザクションがホストhost2のスタンバイ・マスターmaster2にレプリケートされるようにするには、次のようにします。
Command> CALL ttRepSubscriberWait(NULL, NULL, 'master2', 'host2', -1);
ttCWAdmin -reauthenticateコマンドを実行して、Oracle Clusterwareに新しいパスワードを保存します。
ttCWAdmin -reauthenticate -dsn myDSN
このコマンドを実行すると、ttCWAdmin -createコマンドで要求される情報と同じ情報を求めるプロンプトが表示されます(「アクティブ・スタンバイ・ペアのレプリケーション・スキームの作成」を参照)。
Oracle ClusterwareによりTimesTenデータベースを管理する際には、TimesTenデータベースのRAMポリシーはデフォルトで「Always」に設定されています。ただし、Oracle Clusterware管理を停止する場合、TimesTenデータベースのRAMポリシーは「In Use」に設定されます。
TimesTenの管理にOracle Clusterwareをもう使用しない場合は、ご使用の環境に適切なTimesTen RAMポリシーに設定する必要があります。一般的に推奨される設定は「Manual」です。
TimesTenデータベースのRAMポリシーの詳細は、『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』のRAMポリシーの指定に関する説明を参照してください。
次の項では、クラスタのステータスの取得方法を説明します。
ttCWAdminユーティリティの-statusオプションでは、同じインスタンス管理者によって管理されているインスタンスのすべてのアクティブ・スタンバイ・ペアに関する情報がレポートされます。DSNを指定すると、ユーティリティによってそのDSNとアクティブ・スタンバイ・ペアに関する情報がレポートされます。
例8-1 アクティブ・スタンバイ・ペアの作成後のステータス
アクティブ・スタンバイ・ペアのレプリケーション・スキームを作成しても、レプリケーションを開始していない場合は、ttCWAdmin -statusによって次のような情報が返されます。キャッシュ・グリッドがあるかどうかに関係なく、レプリケーションが開始される前にこれらのグリッドの状態が表示されることに注意してください。
$ ttCWAdmin -status TimesTen Cluster status report as of Thu Nov 11 13:54:35 2010 ==================================================================== TimesTen daemon monitors: Host:HOST1 Status: online Host:HOST2 Status: online ==================================================================== ==================================================================== TimesTen Cluster agents Host:HOST1 Status: online Host:HOST2 Status: online ==================================================================== Status of Cluster related to DSN MYDSN: ==================================================================== 1. Status of Cluster monitoring components: Monitor Process for Active datastore:NOT RUNNING Monitor Process for Standby datastore:NOT RUNNING Monitor Process for Master Datastore 1 on Host host1: NOT RUNNING Monitor Process for Master Datastore 2 on Host host2: NOT RUNNING 2.Status of Datastores comprising the cluster Master Datastore 1: Host:host1 Status:AVAILABLE State:ACTIVE Grid:NO GRID Master Datastore 2: Host:host2 Status:UNAVAILABLE State:UNKNOWN Grid:UNKNOWN ==================================================================== The cluster containing the replicated DSN is offline
例8-2 アクティブ・データベースが稼働している場合のステータス
レプリケーション・スキームを開始した後、アクティブ・データベースが稼働していてもスタンバイ・データベースが稼働していない場合、キャッシュ・グリッドが構成されていないと、ttCWAdmin -statusによって次のような情報が返されます。
$ ttcwadmin -status TimesTen Cluster status report as of Thu Nov 11 13:58:25 2010 ==================================================================== TimesTen daemon monitors: Host:HOST1 Status: online Host:HOST2 Status: online ==================================================================== ==================================================================== TimesTen Cluster agents Host:HOST1 Status: online Host:HOST2 Status: online ==================================================================== Status of Cluster related to DSN MYDSN: ==================================================================== 1. Status of Cluster monitoring components: Monitor Process for Active datastore:RUNNING on Host host1 Monitor Process for Standby datastore:RUNNING on Host host1 Monitor Process for Master Datastore 1 on Host host1: RUNNING Monitor Process for Master Datastore 2 on Host host2: RUNNING 2.Status of Datastores comprising the cluster Master Datastore 1: Host:host1 Status:AVAILABLE State:ACTIVE Grid:NO GRID Master Datastore 2: Host:host2 Status:AVAILABLE State:IDLE Grid:NO GRID ==================================================================== The cluster containing the replicated DSN is online
キャッシュ・グリッドが構成されている場合は、最後のセクションは次のように表示されます。
2.Status of Datastores comprising the cluster Master Datastore 1: Host:host1 Status:AVAILABLE State:ACTIVE Grid:AVAILABLE Master Datastore 2: Host:host2 Status:AVAILABLE State:IDLE Grid:NO GRID
例8-3 アクティブ・データベースとスタンバイ・データベースが稼働している場合のステータス
レプリケーション・スキームを開始した後、アクティブ・データベースとスタンバイ・データベースの両方が稼働している場合に、キャッシュ・グリッドが構成されていないと、ttCWAdmin -statusによって次のような情報が返されます。
$ ttcwadmin -status TimesTen Cluster status report as of Thu Nov 11 13:59:20 2010 ==================================================================== TimesTen daemon monitors: Host:HOST1 Status: online Host:HOST2 Status: online ==================================================================== ==================================================================== TimesTen Cluster agents Host:HOST1 Status: online Host:HOST2 Status: online ==================================================================== Status of Cluster related to DSN MYDSN: ==================================================================== 1. Status of Cluster monitoring components: Monitor Process for Active datastore:RUNNING on Host host1 Monitor Process for Standby datastore:RUNNING on Host host2 Monitor Process for Master Datastore 1 on Host host1: RUNNING Monitor Process for Master Datastore 2 on Host host2: RUNNING 2.Status of Datastores comprising the cluster Master Datastore 1: Host:host1 Status:AVAILABLE State:ACTIVE Grid:NO GRID Master Datastore 2: Host:host2 Status:AVAILABLE State:STANDBY Grid:NO GRID ==================================================================== The cluster containing the replicated DSN is online
キャッシュ・グリッドが構成されている場合は、最後のセクションは次のように表示されます。
2.Status of Datastores comprising the cluster Master Datastore 1: Host:host1 Status:AVAILABLE State:ACTIVE Grid:AVAILABLE Master Datastore 2: Host:host2 Status:AVAILABLE State:STANDBY Grid:AVAILABLE
監視プロセスでは、ttcwerrors.logおよびttcwmsg.logファイルにイベントとエラーがレポートされます。これらのファイルはdaemon_home/infoディレクトリにあります。これらのファイルのデフォルト・サイズはユーザー・ログのデフォルトの最大サイズと同じです。ログ・ファイルの最大数はユーザー・ログのデフォルトのファイル数と同じです。ファイルの最大数が書き込まれると、その他のエラーおよびメッセージによってファイルが上書きされ、最も古いファイルで開始されます。
ログ・ファイル数およびログ・ファイル・サイズのデフォルト値は、『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』の情報メッセージの変更に関する説明を参照してください。
