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オペレーション・ガイド』の情報メッセージの変更に関する説明を参照してください。