| Oracle® TimesTen In-Memory Database Kubernetesオペレータ・ユーザーズ・ガイド リリース18.1 F33742-03 |
|
 前 |
 次 |
この章では、アクティブ・スタンバイ・ペアの各ポッドの状態およびアクティブ・スタンバイ・ペア自体の状態を監視する方法について説明します。BothDownおよびManualInterventionRequired状態の詳細を示し、これらの各状態でのオペレータの動作に重点を置いています。この章では、オペレータによるTimesTenClassicオブジェクトの管理を一時停止する方法について説明します。最後に、TimesTenデータベースで実行できる様々な手動操作について説明します。
トピック:
オペレータは、アクティブ・スタンバイ・ペア・オブジェクトの各ポッドの状態を追跡します。オペレータが状態をチェックする頻度は、pollingIntervalの値で定義します。pollingIntervalの詳細は、表11-3「TimesTenClassicSpecSpec」を参照してください。
各ポッドには、Kubernetesの各種なコンポーネントの状態とTimesTenの状態に基づいて概要レベルの状態が割り当てられます。これに該当する状態は次のとおりです。
スタンバイは、アクティブからデータベースを複製するプロセスを完了しました。新しく作成されたスタンバイは、複製操作の実行中にアクティブで実行されたすべてのトランザクションにキャッチアップします。
TimesTenClassicオブジェクトがReexamine状態の場合、オペレータは両方のTimesTenインスタンスの状態を調べます。オペレータは、どちらのインスタンス(ある場合)に適切に構成されたアクティブ・データベース(または適切に構成されたスタンバイ・データベース)が含まれるかを認識しません。オペレータは、確認するために両方のインスタンスを調べる必要があります。正常なインスタンスが見つかり、そのインスタンスに適切に構成されたアクティブ・データベースが含まれている場合、ポッドの状態はHealthyActiveと報告されます。
TimesTenClassicオブジェクトがReexamine状態の場合、オペレータは両方のTimesTenインスタンスの状態を調べます。オペレータは、どちらのインスタンス(ある場合)に適切に構成されたスタンバイ・データベース(または適切に構成されたアクティブ・データベース)が含まれるかを認識しません。オペレータは、確認するために両方のインスタンスを調べる必要があります。正常なインスタンスが見つかり、そのインスタンスに適切に構成されたスタンバイ・データベースが含まれている場合、ポッドの状態はHealthyStandbyと報告されます。
ポッドとポッド内のTimesTenコンポーネントは正常な状態ですが、このポッド内のTimesTenは別のポッド内のTimesTenに障害があると判定しています。特に、OtherDown状態は、このポッドにアクティブなデータベースが含まれていて、そのデータベースのピアがfailThresholdに達したことを示します。このポッド内のデータベースは、ピアが遠すぎるためにピアのトランザクション・ログを保持しなくなっています。ピアをリカバリするには、アクティブ・データベースを再複製する必要があります(オペレータが自動的に実行します)。
このポッドのTimesTenで自動アップグレードが試行され、アップグレードに失敗しました。アップグレード・プロセスの詳細は、アップグレード・プロセスの概要を参照してください。
オペレータは、アクティブ・スタンバイ・ペアのそれぞれの状態を監視および管理します。オペレータは、監視および確認が可能なTimesTenClassicオブジェクトに高レベルの状態を割り当てます。たとえば、kubectl getコマンドを使用して、TimesTenClassicオブジェクトの高レベルの状態を返すことができます。具体的には、この例では、STATEフィールドに返される値はNormalであり、アクティブ・データベースとスタンバイ・データベースが稼働中で、正常に動作していることを示しています。
% kubectl get ttc sample NAME STATE ACTIVE AGE sample Normal sample-0 15h
状態:
アクティブ・データベースを含むポッドのTimesTenが失敗したことがオペレータによって検出された場合、TimesTenClassicオブジェクトはすぐにActiveDown状態になります。
unreachableTimeoutタイムアウト値は、TimesTenClassicオブジェクトの状態がActiveDownになる前に、アクティブ・データベースを含むポッドの状態をUnknownにできる期間を制御します。
TimesTenClassicオブジェクトの状態がActiveDownになると、スタンバイ・データベースはただちにアクティブになり、TimesTenClassicオブジェクトの状態はStandbyDownになります。
TimesTenClassicオブジェクトがNormal状態であるときに、スタンバイ・データベースが停止すると、状態はActiveTakeoverに一時的に変更されます。
通常、AWTキャッシュ・グループを使用する場合、スタンバイはTimesTenからOracle Databaseへの更新のプッシュを担当します。ただし、スタンバイが失敗した場合、アクティブ・データベースはこの責任を引き継ぎます。これは、ActiveTakeover状態で発生します。
アクティブ・データベースもスタンバイ・データベースも正常に動作していません。オペレータは、データベースのペアの起動を試行します。
アクティブ・スタンバイ・ペアの両方のポッドで障害が発生した場合、オペレータはTimesTenClassicStatusの情報を使用してデータ損失を最小限に抑えます。詳細は、BothDown状態の理解を参照してください。
TimesTenClassicオブジェクトがWaitingForActive状態であるときに、アクティブ・データベースにする必要があるデータベースが起動すると、TimesTenClassicオブジェクトはConfiguringActive状態になります。その後、オペレータは、このデータベースがアクティブになるように構成します。データベースがアクティブとして構成されると、TimesTenClassicオブジェクトはStandbyDown状態になります。詳細は、BothDown状態の理解を参照してください。
TimesTenClassicオブジェクトがInitializingの間に問題が発生した場合、オブジェクトはFailed状態に移行します。この状態になると、オペレータはオブジェクトの修復を試行しません。削除する必要があります。kubectl describeコマンドを使用して、オペレータ・ログを調べて問題の原因を特定し、オブジェクトを再作成します。
この状態は、2つのポッドが初めて起動するときに報告されます。アクティブ・スタンバイ・ペア構成では、名前が-0で終わるポッドが最初にアクティブ・データベースとして構成され、名前が-1で終わるポッドが最初にスタンバイ・データベースとして構成されます。具体的には、TimesTenClassicの名前をsampleに指定すると、sample-0ポッドがアクティブ・データベースとして構成され、sample-1ポッドがスタンバイ・データベースとして構成されます。アクティブ/スタンバイ・ペアが完全にデプロイされると、TimesTenClassicオブジェクトはNormal状態に移行します。
TimesTenClassicオブジェクトがManualInterventionRequired状態になると、オペレータはオブジェクトに対するそれ以上の処理を実行しません。TimesTenの状態を判断するためにオブジェクトに関連付けられたTimesTenエージェントは問合せされず、TimesTenは何も実行しません。詳細は、ManualInterventionRequired状態の理解および1つのデータベースの起動を参照してください。
TimesTenClassicオブジェクトがManualInterventionRequired状態の場合、reexamine CRD構文要素を指定すると、オペレータがオブジェクトの管理を再度引き継ぐことができます。オペレータはオブジェクトをReexamine状態にします。その後、オペレータはTimesTenの状態を調べます。TimesTenを正しく修復した場合、TimesTenClassicオブジェクトは、修復の性質に応じてNormalまたはStandbyDown状態になります。TimesTenを正しく修復しなかった場合、TimesTenClassicオブジェクトは再度ManualInterventionRequired状態になります。詳細は、ManualInterventionRequired状態の理解を参照してください。
この状態になるのは、StandbyStarting状態の後です。StandbyStarting状態の場合、スタンバイはアクティブ・データベースをスタンバイ・ポッドにコピーします。複製プロセスが完了すると、状態がStandbyStartingからStandbyCatchupに変わります。StandbyStarting状態の詳細は、StandbyStartingを参照してください。StandbyCatchup状態の場合、複製プロセスが完了しています。この複製プロセス中に実行されたトランザクションをスタンバイにコピーする必要があります。したがって、StandbyCatchup状態は、新しく作成されたスタンバイが、複製操作の実行中にアクティブで実行されたトランザクションにキャッチアップするときの状態です。アプリケーションは、制限なしにアクティブを引き続き使用できます。
アクティブ・データベースは適切に機能していますが、スタンバイ・データベースは機能していません。オペレータは、スタンバイ・データベースの再起動および再構成を自動的に試行します。アプリケーションは、制限なしにアクティブ・データベースを引き続き使用できます。
スタンバイがアクティブからデータベースを複製しています。StandbyStarting状態は、複製操作が完了すると完了します。次に、StandbyCatchup状態になります。StandbyCatchup状態の詳細は、StandbyCatchupを参照してください。アプリケーションは、制限なしにアクティブを引き続き使用できます。
TimesTenClassicオブジェクトがBothDown状態の場合、オペレータが最新のデータを含むデータベースを判別できると、TimesTenClassicオブジェクトはWaitingForActive状態になります。オブジェクトは、データベースを含むポッドが実行中で、(そのポッド内の) ttコンテナにあるTimesTenエージェントがオペレータに応答するまで、この状態のままです。詳細は、BothDown状態の理解を参照してください。
オペレータは、TimesTenデータベースのアクティブ・スタンバイ・ペアをプロビジョニング、監視および管理します。アクティブ・データベースまたはスタンバイ・データベースの障害を検出して対応します。たとえば、アクティブ・スタンバイ・ペアの1つのデータベースが停止している場合、オペレータは次のことを実行します。
アクティブ・データベースで障害が発生した場合、オペレータはスタンバイをアクティブに昇格させます。
スタンバイ・データベースに障害が発生した場合、オペレータはアクティブの実行を維持し、スタンバイを修復します。
ただし、両方のデータベースが同時に失敗した場合は、データベースが適切にバックアップされることが不可欠です。TimesTenレプリケーションでは、両方のデータベースで同時にトランザクションをアトミックにコミットしません。トランザクションは1つのデータベースでコミットされ、その後に別のデータベースでコミットされます。(トランザクションが最初にコミットされるデータベースは、先行するデータベースとみなされます。)レプリケーションの構成方法によっては、アクティブ・データベースのトランザクションがスタンバイより先行する場合や、スタンバイがアクティブより先行する可能性があります。データ損失を回避するには、障害の修正後に、先行するデータベースがアクティブ・データベースになる必要があります。
ほとんどの場合、オペレータは、障害発生時にどのデータベースが先行していたかを判断できます。ただし、どのデータベースが先行していたかをオペレータが判断できない場合があります。特に、次の条件がすべて発生した場合、オペレータはどのデータベースが先行するかを判断できません。
ポーリング間隔中に両方のデータベースに障害が発生しました。具体的には、オペレータが両方のデータベースを調べて、TimesTenポッドはHealthy状態でした。オペレータがpollingInterval秒待機し、オペレータが(このpollingIntervalの後)データベースを再度調べたとき、両方のデータベースが停止しており、かつ
RETURN TWOSAFEレプリケーションが構成されており、かつ
DISABLE RETURNまたはLOCAL COMMIT ACTION COMMIT (あるいはその両方)が構成されていました。
pollingInterval CRD構文要素と、RETURN TWOSAFEおよびDISABLE RETURNレプリケーション構成オプションの詳細は、TimesTenClassicSpecSpecを参照してください。また、Oracle TimesTen In-Memory Database SQLリファレンスのCREATE ACTIVE STANDBY PAIRおよびOracle TimesTen In-Memory Databaseレプリケーション・ガイドのアクティブ・スタンバイ・ペアのレプリケーション・スキームの定義も参照してください。
このイベントの組合せは、一部のトランザクションがスタンバイでコミットされて、アクティブではコミットされていない可能性があること、または一部のトランザクションがアクティブでコミットされて、スタンバイではコミットされていない可能性があること(あるいはその両方)を示します。この場合、オペレータは処理を行いません。
両方のデータベースに障害が発生した場合、TimesTenClassicオブジェクトはBothDown状態になります。BothDown状態の詳細は、BothDownを参照してください。次に、オペレータは、実行する適切な処理を決定する必要があります。オペレータは、最初にbothDownBehavior CRD構文要素の値を調べ、何をするかを決定します。詳細は、TimesTenClassicSpecSpecを参照してください。
bothDownBehaviorがManualに設定されている場合、TimesTenClassicオブジェクトはすぐにManualInterventionRequired状態になります。TimesTenコンテナが後で使用可能になった場合でも、オペレータはそれ以上の処理を行いません。ManualInterventionRequired状態の詳細は、ManualInterventionRequired状態の理解を参照してください。
bothDownBehaviorがBest (デフォルト設定)に設定されている場合、オペレータは、障害発生時にどのデータベースが先行していたかを判断しようとします。
どのデータベースが先行するかをオペレータが判断できない場合、TimesTenClassicオブジェクトはすぐにManualInterventionRequired状態になります。詳細は、ManualInterventionRequired状態の理解を参照してください。
どのデータベースが先行するかをオペレータが判断できる場合は、次のようになります。
TimesTenClassicオブジェクトはWaitingForActive状態になります。オブジェクトは、そのデータベースを含むポッドが実行中で、そのポッド内のttコンテナにあるTimesTenエージェントがオペレータに応答するまで、この状態のままです。この時点で、TimesTenClassicオブジェクトはConfiguringActive状態になります。
TimesTenClassicオブジェクトがConfiguringActive状態である間、このポッドのTimesTenが起動され、データベースがロードされ、新しいアクティブ・データベースとして使用されるように構成されます。これらのステップに問題がある場合、TimesTenClassicオブジェクトはManualInterventionRequired状態になります。データベースが正常にロードされ、新しいアクティブとして正常に構成された場合、TimesTenClassicオブジェクトはStandbyDown状態になります。TimesTenClassicオブジェクトの状態の詳細は、データベースのアクティブ・スタンバイ・ペアの状態の監視を参照してください。
waitingForActiveTimeout CRD構文要素の値を指定することで、TimesTenClassicオブジェクトがWaitingForActive状態のままになる最大時間(秒単位)を指定できます。この期間の後、オブジェクトがまだWaitingForActive状態の場合、オブジェクトは自動的にManualInterventionRequired状態に移行します。デフォルトは0で、これはタイムアウトがないことを示し、オブジェクトは無期限にこの状態のままになります。waitingForActiveTimeout CRD構文要素の詳細は、TimesTenClassicSpecSpecを参照してください。
データベースのリカバリにかかる時間は、データベースのサイズによって異なります。waitingForActiveTimeoutの値を決定するときは、データベースのサイズを考慮する必要があります。
先行するデータベースをロードできない場合、TimesTenClassicオブジェクトはManualInterventionRequired状態になります。詳細は、ManualInterventionRequired状態の理解を参照してください。
TimesTenClassicオブジェクトがManualInterventionRequired状態になると、オペレータはこのオブジェクトに対してそれ以上の処理を実行しません。TimesTenの状態を判断するためにオブジェクトに関連付けられたTimesTenエージェントは問合せされず、TimesTenは何も実行しません。TimesTenClassicオブジェクトがこの状態である理由に対処することが重要です。
TimesTenClassicオブジェクトがManualInterventionRequired状態であり、それが最初にBothDown状態であったことの結果ではない場合、いずれかのデータベースを手動で修復するために必要な操作を実行します。次に、このデータベースを起動するステップを実行します。これらのステップについては、この章の後半の1つのデータベースの起動で説明します。
ただし、TimesTenClassicオブジェクトが最初にBothDown状態になった結果としてManualInterventionRequired状態である場合は、次のとおりです。
どちらのデータベースが(ある場合)、新しいアクティブに適しているか明確でない可能性があります。スタンバイ・データベースにはコミットされておらず、アクティブ・データベースにコミットされているトランザクションがある可能性があり、同時にアクティブ・データベースにはコミットされておらず、スタンバイ・データベースにコミットされているトランザクションがある可能性があります。
両方のデータベースを手動で調べる必要があります。また、どのデータベースを新規アクティブにするかを選択する前に、データを調整する必要がある場合もあります。
データを調整でき、データベースの1つを手動で修正できる場合は、1つのデータベースを起動するためのステップを実行できます。これらのステップについては、この章の後半の1つのデータベースの起動で説明します。データを調整できない場合は、Oracleサポートに連絡してください。
TimesTenClassicオブジェクトをManualInterventionRequired状態から移動するようオペレータに指示するには、次のいずれかを行う必要があります。
データベースを1つのみ起動: オペレータはこのデータベースをアクティブ・データベースとして扱います。次のすべての条件を満たす必要があります。
コンテナのTimesTenエージェントが実行中です。
コンテナ内のTimesTenインスタンスが実行中です。
TimesTenデータベースがロードされています。
データベースにレプリケーション・スキームがありません。
レプリケーション・エージェントは稼働していません。
レプリケーションの状態はIDLEです。
これらの条件が満たされると、オペレータはTimesTenClassicオブジェクトをStandbyDown状態にします。これらの条件のいずれかが満たされていない場合、TimesTenClassicオブジェクトはManualInterventionRequired状態のままです。データベースにレプリケーション・スキームが存在しない場合でも、オペレータはTimesTenClassicオブジェクト定義でレプリケーション・スキームがどのように定義されているかに基づいて適切なレプリケーション・スキームを作成します。1つのデータベースが起動して実行されるとオペレータに処理を指示できるようになる例は、1つのデータベースの起動を参照してください。
両方のデータベースを起動します。この場合、アクティブ・スタンバイ・ペアを構成する必要があります。具体的には、各データベースが次のすべての条件を満たしている必要があります。
コンテナのTimesTenエージェントが実行中です。
コンテナのTimesTenインスタンスが実行中です。
データベースがロードされています。
レプリケーション・スキームが両方のデータベースで定義されています。
レプリケーション・エージェントが起動し、実行中です。
1つのデータベースがACTIVE状態であり、もう1つのデータベースがSTANDBY状態である必要があります。
これらの条件が満たされると、オペレータはTimesTenClassicオブジェクトをNormal状態にします。これらの条件のいずれかが満たされていない場合、TimesTenClassicオブジェクトはManualInterventionRequired状態のままです。
いずれのデータベースも起動できない場合は、TimesTenClassicオブジェクトはManualInterventionRequired状態のままです。
reexamine CRD構文要素を指定して、データベースを調べるようオペレータに指示します。pollingIntervalごとに、オペレータはreexamineの値を調べます。このTimesTenClassicオブジェクトの最後の反復以降にreexamine値が変更された場合、オペレータはこのオブジェクトのTimesTenコンテナの状態を調べます。pollingIntervalおよびreexamine CRD構文要素の詳細は、TimesTenClassicSpecSpecを参照してください。
データベースの調査は、reexamine値を変更した後に1回のみ実行されます。必要な条件を満たさなかった場合は、再度条件を満たすことを試行できます。その場合、オペレータがデータベースを再調査するように、reexamine値を再度変更する必要があります。
TimesTenClassicオブジェクトの状態が変更されると、常にKubernetesイベントが作成されることに注意してください。このような状態遷移が通知されるように、kubectl describeコマンドを使用してこれらのイベントを監視できます。
この項では、TimesTenClassicオブジェクトに関連付けられたデータベースの1つで、手動で修復またはメンテナンスを実行したことを前提としています。TimesTenClassicオブジェクトは現在ManualInterventionRequired状態です。次に、修復されたデータベースをアクティブとして処理し、このデータベースをスタンバイに複製するために必要なステップを実行し、両方のデータベースが正常に実行されて動作するように両方のデータベースを起動することをオペレータに指示します。
データベースでは、次の条件をすべて満たす必要があります。
コンテナのTimesTenエージェントが実行中です。
コンテナのTimesTenデーモン(インスタンス)が実行中です。
TimesTenデータベースがロードされています。
データベースにレプリケーション・スキームがありません。
レプリケーション・エージェントは稼働していません。
レプリケーションの状態はIDLEです。
次の各項では、データベースの条件が満たされていることの確認方法と、reexamine値を設定する方法について説明します。
データベース(アクティブになるデータベース)の条件が満たされていることを確認するには、次のステップを実行します。この例では、sample-1が新しいアクティブになります。
ノート: これらのステップでは、TimesTenユーティリティおよびTimesTen組込みプロシージャを使用する必要があります。詳細は、Oracle TimesTen In-Memory Databaseリファレンスのユーティリティおよび組込みプロシージャを参照してください。
TimesTenClassicオブジェクト(この例ではsample)がManualInterventionRequired状態であることを確認します(太字で表示)。
% kubectl get ttc sample
NAME STATE ACTIVE AGE
sample ManualInterventionRequired sample-0 12h
kubectl exec -itコマンドを使用して、TimesTenデータベースを含むsample-1ポッド内のシェルを起動します。(このデータベースが新しいアクティブになります。)
残りの手順はこのシェル内で実行されます。
% kubectl exec -it sample-1 -c tt -- /usr/bin/su - oracle
ttDaemonAdminユーティリティを使用して、TimesTenデーモンを起動します(まだ起動していない場合)。次に、ttAdminユーティリティを使用して、TimesTenデータベースをメモリーにロードします(まだロードされていない場合)。
% ttDaemonAdmin -start TimesTen Daemon (PID: 5948, port: 6624) startup OK. % ttAdmin -ramLoad sample RAM Residence Policy : manual Manually Loaded In RAM : True Replication Agent Policy : manual Replication Manually Started : False Cache Agent Policy : manual Cache Agent Manually Started : False Database State : Open
ttIsqlユーティリティを使用して、sampleデータベースに接続します。次に、ttRepStop組込みプロシージャをコールして、レプリケーション・エージェントを停止します。
% ttIsql sample Copyright (c) 1996, 2021, Oracle and/or its affiliates. All rights reserved. Type ? or "help" for help, type "exit" to quit ttIsql. connect "DSN=sample"; Connection successful: DSN=sample;UID=oracle;DataStore=/tt/home/oracle/datastore/sample; DatabaseCharacterSet=AL32UTF8;ConnectionCharacterSet=US7ASCII;AutoCreate=0; PermSize=200;DDLReplicationLevel=3;ForceDisconnectEnabled=1; (Default setting AutoCommit=1) Command> call ttRepStop;
ttIsql内から、SQL DROP ACTIVE STANDBY PAIR文を使用して、アクティブ・スタンバイ・ペアのレプリケーション・スキームを削除します。次に、ttIsql repschemesコマンドを使用して、データベースにレプリケーション・スキームがないことを確認します。ttIsqlを終了します。
Command> DROP ACTIVE STANDBY PAIR; Command> repschemes; 0 replication schemes found.
ttStatusユーティリティを使用して、TimesTenデーモンが実行中であり、レプリケーション・エージェントが実行されていないことを確認します。
% ttStatus TimesTen status report as of Sat Apr 24 02:14:15 2021 Daemon pid 5948 port 6624 instance instance1 TimesTen server pid 5955 started on port 6625 ------------------------------------------------------------------------ ------------------------------------------------------------------------ Data store /tt/home/oracle/datastore/sample Daemon pid 5948 port 6624 instance instance1 TimesTen server pid 5955 started on port 6625 There are 15 connections to the data store Shared Memory KEY 0x0a100c60 ID 196609 PL/SQL Memory Key 0x0b100c60 ID 229378 Address 0x5000000000 Type PID Context Connection Name ConnID Process 10418 0x000000000218a6e0 sample 2 Process 8338 0x0000000001cbb6e0 sample 1 Subdaemon 5953 0x00000000015075f0 Manager 2047 Subdaemon 5953 0x0000000001588540 Rollback 2046 Subdaemon 5953 0x0000000001607210 Checkpoint 2041 Subdaemon 5953 0x00007f132c0008c0 Flusher 2045 Subdaemon 5953 0x00007f132c080370 Log Marker 2040 Subdaemon 5953 0x00007f13340008c0 Monitor 2044 Subdaemon 5953 0x00007f133407f330 HistGC 2037 Subdaemon 5953 0x00007f13380008c0 Aging 2042 Subdaemon 5953 0x00007f133807f330 AsyncMV 2039 Subdaemon 5953 0x00007f133c0008c0 Deadlock Detector 2043 Subdaemon 5953 0x00007f133c07f330 IndexGC 2038 Subdaemon 5953 0x00007f135c0008c0 Garbage Collector 2035 Subdaemon 5953 0x00007f13600e8e20 XactId Rollback 2036 Open for user connections RAM residence policy: Manual Data store is manually loaded into RAM Replication policy : Manual Cache Agent policy : Manual PL/SQL enabled. ------------------------------------------------------------------------ Accessible by group oracle End of report
データベースの条件を正常に確認しました。データベースは稼働中です。オペレータはこのデータベースをアクティブとして扱います。reexamine CRD構文要素の値を設定する準備が整いました。
この例では、TimesTenClassicオブジェクト定義(この例ではsample)でreexamine値を設定する方法を示します。この例は、reexamine値が変更された後にオペレータが実行する処理も示しています。
reexamine値を設定します。値は、TimesTenClassicオブジェクトの現在の値と異なる必要があります。オペレータは、この値を調べて最後の反復以降に変更されたことに気付くと、適切な処理を実行します。
kubectl editコマンドを使用して、TimesTenClassicオブジェクトを編集します。
ファイル内にreexamineの行がある場合は、その値を変更します。現在の値と異なる必要があります。
ファイル内にreexamineの行がない場合は、行を追加して値を指定します。
この例では、reexamine行はありません。この例では、reexamine行を追加し、reexamineの値をApril22reexamine1に設定します(太字で表示)。
ノート: 出力のすべては示していません。
% kubectl edit timestenclassic sample
# Please edit the object below. Lines beginning with a '#' will be ignored,
# and an empty file will abort the edit. If an error occurs while saving this
# file will be reopened with the relevant failures.
#
apiVersion: timesten.oracle.com/v1
kind: TimesTenClassic
metadata:
...
name: sample
namespace: mynamespace
...
repCreateStatement: |
create active standby pair
"{{tt-name}}" on "{{tt-node-0}}",
"{{tt-name}}" on "{{tt-node-1}}"
RETURN TWOSAFE
store "{{tt-name}}" on "{{tt-node-0}}"
PORT {{tt-rep-port}} FAILTHRESHOLD 0 TIMEOUT 999
store "{{tt-name}}" on "{{tt-node-1}}"
PORT {{tt-rep-port}} FAILTHRESHOLD 0 TIMEOUT 999
spec:
ttspec:
bothDownBehavior: Best
dbConfigMap:
- sample
image: phx.ocir.io/youraccount/tt1814110:3
imagePullPolicy: Always
imagePullSecret: sekret
storageClassName: oci
storageSize: 250G
reexamine: April22reexamine1
...
timestenclassic.timesten.oracle.com/sample edited
kubectl getコマンドを使用して、sample TimesTenClassicオブジェクトの状態を評価します。複数のkubectl getコマンドを発行して、状態がどのように変化するかを確認します。また、オペレータはsample-1をアクティブとして正常に構成しました。
% kubectl get ttc sample NAME STATE ACTIVE AGE sample Reexamine None 68m % kubectl get ttc sample NAME STATE ACTIVE AGE sample ConfiguringActive None 68m % kubectl get ttc sample NAME STATE ACTIVE AGE sample StandbyDown sample-1 68m % kubectl get ttc sample NAME STATE ACTIVE AGE sample Normal sample-1 71m
kubectl describeコマンドを使用して、オペレータの処理をさらにレビューします(太字で表示)。
出力のすべては示していません。
% kubectl describe ttc sample
Name: sample
Namespace: mynamespace
...
Kind: TimesTenClassic
...
Rep Create Statement: create active standby pair
"{{tt-name}}" on "{{tt-node-0}}",
"{{tt-name}}" on "{{tt-node-1}}"
RETURN TWOSAFE
store "{{tt-name}}" on "{{tt-node-0}}"
PORT {{tt-rep-port}} FAILTHRESHOLD 0 TIMEOUT 999
store "{{tt-name}}" on "{{tt-node-1}}"
PORT {{tt-rep-port}} FAILTHRESHOLD 0 TIMEOUT 999
Spec:
Ttspec:
Both Down Behavior: Best
Db Config Map:
sample
Image: phx.ocir.io/youraccount/tt1814110:3
Image Pull Policy: Always
Image Pull Secret: sekret
Reexamine: April22reexamine1
Stop Managing: April21Stop1
Storage Class Name: oci
Storage Size: 250G
Status:
Classic Upgrade Status:
Active Start Time: 0
Active Status:
Image Update Pending: false
Last Upgrade State Switch: 0
Prev Reset Upgrade State:
Prev Upgrade State:
Standby Start Time: 0
Standby Status:
Upgrade Start Time: 0
Upgrade State:
Active Pods: sample-1
High Level State: Normal
Last Event: 54
Last High Level State Switch: 1619230912
Pod Status:
Cache Status:
Cache Agent: Not Running
Cache UID Pwd Set: true
N Cache Groups: 0
Db Status:
Db: Loaded
Db Id: 475
Db Updatable: No
Initialized: true
Last High Level State Switch: ?
Pod Status:
Agent: Up
Last Time Reachable: 1619231126
Pod IP: 10.244.7.89
Pod Phase: Running
Prev High Level State: Healthy
Prev Image:
Replication Status:
Last Time Rep State Changed: 0
Rep Agent: Running
Rep Peer P State: start
Rep Scheme: Exists
Rep State: STANDBY
Times Ten Status:
Daemon: Up
Instance: Exists
Release: 18.1.4.11.0
Admin User File: false
Cache User File: false
Cg File: false
Disable Return: false
High Level State: Healthy
Intended State: Standby
Local Commit: false
Name: sample-0
Schema File: false
Using Twosafe: false
Cache Status:
Cache Agent: Not Running
Cache UID Pwd Set: true
N Cache Groups: 0
Db Status:
Db: Loaded
Db Id: 476
Db Updatable: Yes
Initialized: true
Last High Level State Switch: ?
Pod Status:
Agent: Up
Last Time Reachable: 1619231126
Pod IP: 10.244.6.149
Pod Phase: Running
Prev High Level State: Healthy
Prev Image:
Replication Status:
Last Time Rep State Changed: 1619228670
Rep Agent: Running
Rep Peer P State: start
Rep Scheme: Exists
Rep State: ACTIVE
Times Ten Status:
Daemon: Up
Instance: Exists
Release: 18.1.4.11.0
Admin User File: false
Cache User File: false
Cg File: false
Disable Return: false
High Level State: Healthy
Intended State: Active
Local Commit: false
Name: sample-1
Schema File: false
Using Twosafe: false
Prev High Level State: StandbyDown
Prev Reexamine: April22reexamine1
Prev Stop Managing: April21Stop1
Rep Create Statement: create active standby pair "sample" on
"sample-0.sample.mynamespace.svc.cluster.local", "sample" on
"sample-1.sample.mynamespace.svc.cluster.local" NO RETURN store "sample" on
"sample-0.sample.mynamespace.svc.cluster.local" PORT 4444 FAILTHRESHOLD 0 store
"sample" on "sample-1.sample.mynamespace.svc.cluster.local" PORT 4444
FAILTHRESHOLD 0
Rep Port: 4444
Status Version: 1.0
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
- StateChange 58m ttclassic TimesTenClassic was Normal, now ManualInterventionRequired
- StateChange 46m ttclassic Pod sample-0 Daemon Down
- StateChange 41m ttclassic Pod sample-1 Daemon Down
- StateChange 41m ttclassic Pod sample-1 Daemon Up
- StateChange 41m ttclassic Pod sample-1 Database Unloaded
- StateChange 40m ttclassic Pod sample-1 Database Loaded
- StateChange 40m ttclassic Pod sample-1 RepState IDLE
- StateChange 40m ttclassic Pod sample-1 RepAgent Not Running
- StateChange 17m ttclassic Pod sample-1 Database Updatable
- StateChange 17m ttclassic Pod sample-1 RepScheme None
- StateChange 4m21s ttclassic TimesTenClassic was
ManualInterventionRequired, now Reexamine
- Error 4m16s ttclassic Active error: Daemon Down
- StateChange 4m16s ttclassic TimesTenClassic was Reexamine, now
ConfiguringActive
- StateChange 4m10s ttclassic Pod sample-1 RepState ACTIVE
- StateChange 4m10s ttclassic Pod sample-1 RepScheme Exists
- StateChange 4m10s ttclassic Pod sample-1 RepAgent Running
- StateChange 4m8s ttclassic TimesTenClassic was ConfiguringActive,
now StandbyDown
- StateChange 4m3s ttclassic Pod sample-0 Daemon Up
- StateChange 4m3s ttclassic Pod sample-0 Database Unloaded
- StateChange 3m56s ttclassic Pod sample-0 Database None
- StateChange 3m42s ttclassic Pod sample-0 Database Loaded
- StateChange 3m42s ttclassic Pod sample-0 Database Not Updatable
- StateChange 3m42s ttclassic Pod sample-0 RepAgent Not Running
- StateChange 3m42s ttclassic Pod sample-0 RepState IDLE
- StateChange 3m36s ttclassic Pod sample-0 RepAgent Running
- StateChange 3m36s ttclassic Pod sample-0 RepState STANDBY
- StateChange 3m36s ttclassic TimesTenClassic was StandbyDown, now
Normal
kubectl exec -itコマンドを使用して、TimesTenデータベースを含むsample-1ポッド内のシェルを起動します。次に、アクティブ・データベースに接続できることを確認します。
% kubectl exec -it sample-1 -c tt -- /usr/bin/su - oracle
$ ttIsql sample
Copyright (c) 1996, 2021, Oracle and/or its affiliates. All rights reserved.
Type ? or "help" for help, type "exit" to quit ttIsql.
connect "DSN=sample";
Connection successful: DSN=sample;UID=oracle;DataStore=/tt/home/oracle/datastore/sample;
DatabaseCharacterSet=AL32UTF8;ConnectionCharacterSet=US7ASCII;
AutoCreate=0;PermSize=200;DDLReplicationLevel=3;ForceDisconnectEnabled=1;
(Default setting AutoCommit=1)
Command> call ttRepStateGet;
< ACTIVE >
1 row found.
kubectl exec -itコマンドを使用して、TimesTenデータベースを含むsample-0ポッド内のシェルを起動します。次に、スタンバイ・データベースに接続できることを確認します。
% kubectl exec -it sample-0 -c tt -- /usr/bin/su - oracle
% ttIsql sample
Copyright (c) 1996, 2021, Oracle and/or its affiliates. All rights reserved.
Type ? or "help" for help, type "exit" to quit ttIsql.
connect "DSN=sample";
Connection successful: DSN=sample;UID=oracle;DataStore=/tt/home/oracle/datastore/sample;
DatabaseCharacterSet=AL32UTF8;ConnectionCharacterSet=US7ASCII;AutoCreate=0;
PermSize=200;DDLReplicationLevel=3;ForceDisconnectEnabled=1;
(Default setting AutoCommit=1)
Command> call ttRepStateGet;
< STANDBY >
1 row found.
オペレータがTimesTenClassicオブジェクトを管理および監視するようになりました。TimesTenClassicオブジェクトはNormal状態です。いずれのデータベースも稼働中で、すぐに使用できます。
これらのセクションでは、オペレータによるTimesTenClassicオブジェクトの管理を一時停止する理由と、その方法について説明します。
オペレータは、TimesTenインスタンスおよび各TimesTenClassicオブジェクトに関連付けられたデータベースの状態を定期的に調べます。機能しないものがあれば、修復するための処理を実行します。メンテナンス操作を手動で実行する必要がある場合があります。このような状況では、オペレータが干渉して修復操作を実行しようとしないようにする必要があります。
(timestenclassic-operatorのデプロイメントを削除することで)オペレータを停止できます。この処理により、オペレータが干渉しなくなります。詳細は、手動制御に戻すを参照してください。ただし、複数のTimesTenClassicオブジェクトがある場合にオペレータを削除すると、1つのオブジェクトのみを手動で操作する必要があるときにすべてのTimesTenClassicオブジェクトの管理が妨げられます。
または、このTimesTenClassicオブジェクトに対してstopManaging CRD構文要素を指定することで、1つのTimesTenClassicオブジェクトに対する処理を実行しないようにオペレータに指示することもできます。この要素の詳細は、TimesTenClassicSpecSpecを参照してください。オペレータは、stopManagingの値を調べ、最後に調べてから変更されている場合は、TimesTenClassicオブジェクトの状態をManualInterventionRequiredに変更します。これにより、オペレータは、TimesTenポッド、コンテナ、インスタンスおよびTimesTenClassicオブジェクトに関連付けられたデータベースのステータスを調べなくなります。オペレータは、オブジェクトまたはそのポッドに対して処理を行いません。
オペレータでTimesTenClassicオブジェクトを再度管理する場合は、reexamine CRD構文要素の値を変更します。ManualInterventionRequired状態およびreexamine CRD構文要素の詳細は、ManualInterventionRequired状態の理解を参照してください。
この方法では、timestenclassic-operatorのデプロイメントを削除せずに、TimesTenに対して手動操作を実行できます。
この例では、stopManaging CRD構文要素を使用して、Kubernetesクラスタで実行されているTimesTenClassicオブジェクトのいずれかの管理を停止するようオペレータに指示する方法を示します。この例では、実行中の2つのTimesTenClassicオブジェクト(sampleおよびsample2)があります。オブジェクトの1つ(この例ではsample)に関連付けられているTimesTenデータベースで手動メンテナンス操作を実行する必要があります。オペレータによるこのsample TimesTenClassicオブジェクトの管理を停止させる必要があります。ただし、オペレータでもう1つのTimesTenClassicオブジェクト(この例ではsample2)の管理を続行する必要があります。
次のステップを実行します。
実行中のポッドを確認します。
% kubectl get pods NAME READY STATUS RESTARTS AGE sample-0 2/2 Running 0 6m33s sample-1 2/2 Running 0 6m32s sample2-0 2/2 Running 0 6m32s sample2-1 2/2 Running 0 6m32s timestenclassic-operator-846cb5c97c-cxbl2 1/1 Running 0 4d20h
sample TimesTenClassicオブジェクトがNormal状態であることを確認します。このオブジェクトに関連付けられたTimesTenデータベースでメンテナンスを実行する必要があります。
% kubectl get ttc sample
NAME STATE ACTIVE AGE
sample Normal sample-0 13m
stopManaging値を設定します。値は、TimesTenClassicオブジェクトの現在の値と異なる必要があります。オペレータは、この値を調べて最後の反復以降に変更されたことに気付くと、適切な処理を実行します。
kubectl editコマンドを使用して、TimesTenClassicオブジェクトを編集します。
ファイル内にstopManagingの行がある場合は、その値を変更します。現在の値と異なる必要があります。
ファイル内にstopManagingの行がない場合は、行を追加して値を指定します。
この例では、stopManagingの行はありません。この例では、stopManagingの行を追加し、stopManagingの値をApril21Stop1に設定します(太字で表示)。
ノート: 出力のすべては示していません。
% kubectl edit timestenclassic sample
# Please edit the object below. Lines beginning with a '#' will be ignored,
# and an empty file will abort the edit. If an error occurs while saving this
# file will be reopened with the relevant failures.
#
apiVersion: timesten.oracle.com/v1
kind: TimesTenClassic
metadata:
...
name: sample
namespace: mynamespace
...
repCreateStatement: |
create active standby pair
"{{tt-name}}" on "{{tt-node-0}}",
"{{tt-name}}" on "{{tt-node-1}}"
RETURN TWOSAFE
store "{{tt-name}}" on "{{tt-node-0}}"
PORT {{tt-rep-port}} FAILTHRESHOLD 0 TIMEOUT 999
store "{{tt-name}}" on "{{tt-node-1}}"
PORT {{tt-rep-port}} FAILTHRESHOLD 0 TIMEOUT 999
spec:
ttspec:
bothDownBehavior: Best
dbConfigMap:
- sample
image: phx.ocir.io/youraccount/tt1814110:3
imagePullPolicy: Always
imagePullSecret: sekret
storageClassName: oci
storageSize: 250G
stopManaging: April21Stop1
...
timestenclassic.timesten.oracle.com/sample edited
kubectl getコマンドを使用して、sample TimesTenClassicオブジェクトの状態を確認します。sample TimesTenClassicオブジェクトがManualInterventionRequired状態に移行していることに注意してください。これは、stopManaging値を新しい値に変更した後の予想される動作です。
% kubectl get ttc sample
NAME STATE ACTIVE AGE
sample ManualInterventionRequired sample-0 15m
sample TimesTenClassicオブジェクトはManualInterventionRequired状態です。オペレータが、sample TimesTenClassicオブジェクトの監視および管理を一時停止しました。このTimesTenClassicオブジェクトまたはそのポッドに対してそれ以上の処理は実行されません。これで、TimesTenデータベースで手動操作を実行できます。このような操作を完了し、オペレータによる管理を再開する準備ができたら、1つのデータベースの起動に進んでプロセスを完了します。
オペレータは、デプロイメントを使用してKubernetesクラスタ内に構成します。Kubernetesはオペレータを自動的に監視し、障害が発生した場合は再起動します。オペレータはポッドで実行され、オペレータ名はtimestenclassic-operatorで始まり、任意の文字を続けることで名前が一意になります。オペレータのデプロイ時に複数のレプリカを指定した場合、複数のポッドが存在します。一度にアクティブにできるポッドは1つのみです。残りのポッドはアクティブで障害が発生するまで待機し、障害が発生した場合はポッドの1つがアクティブになります。オペレータによってプロビジョニングされたTimesTenデータベースのアクティブ・スタンバイ・ペアは、オペレータで障害が発生した場合も引き続き機能します。Kubernetesによって新しいオペレータが起動されると、データベースの既存のアクティブ・スタンバイ・ペアがすべて自動的に監視および管理されます。
オペレータを実行しているポッドを表示するには、kubectl get podsコマンドを使用します。この例では、オペレータに対してポッドが1つあります。オペレータをデプロイしたときに、replicasフィールドに1の値を指定しました。そのため、Kubernetesによりポッドが1つ作成されました。オペレータのデプロイメントの詳細は、オペレータのデプロイを参照してください。
% kubectl get pods NAME READY STATUS RESTARTS AGE timestenclassic-operator-5d7dcc7948-8mnz4 1/1 Running 0 3m21s
オペレータは、データベースのアクティブ・スタンバイ・ペアがデプロイされると、実行し続けようとします。Kubernetesでは、ポッドのライフサイクルが管理されます。ポッドに障害が発生した場合、ポッドは再作成されます。また、ポッドを実行しているノードで障害が発生した場合、使用可能なKubernetesクラスタ・ノード上にポッドが再作成されます。オペレータはポッドで実行されているTimesTenを監視し、データベースのペアを動作させておくための適切な操作を開始します。これらの操作はオペレータによって自動的に行われるため、管理者操作が最小限に抑えられます。
次の各項では、実行できる手動操作について説明します。
kubectl exec -itコマンドを使用して、TimesTenインスタンスでTimesTenユーティリティを手動で起動できます。このコマンドを使用すると、ポッドのシェルを起動し、ポッドでのTimesTenの実行を制御できます。
TimesTenは、ttコンテナでoracleユーザーとして実行されます。ポッドでシェルを確立したら、su - oracleコマンドを使用してoracleユーザーに切り替えます。これによって、環境が自動的に構成され、TimesTenユーティリティを実行できます。
|
ノート: オペレータは引き続き、ポッドのステータスおよびポッド内のTimesTenのステータスを問い合せています。ポッドまたはTimesTenの機能を妨げるコマンドを起動すると、オペレータは実行された操作の修正を試みることがあります。 |
次の例は、kubectl exec -itコマンドを使用して、TimesTenデータベースを含むsample-0ポッド内のシェルを起動する方法を示しています。その後、ttIsqlユーティリティを実行できます。
% kubectl exec -it sample-0 -c tt -- /usr/bin/su - oracle % ttIsql sample Copyright (c) 1996, 2020, Oracle and/or its affiliates. All rights reserved. Type ? or "help" for help, type "exit" to quit ttIsql. connect "DSN=sample"; Connection successful: DSN=sample;UID=oracle;DataStore=/tt/home/oracle/datastore/sample; DatabaseCharacterSet=AL32UTF8;ConnectionCharacterSet=US7ASCII;PermSize=200; DDLReplicationLevel=3; (Default setting AutoCommit=1) Command>
TimesTenでは、データベースの属性を定義するために接続属性を使用します。接続属性には次の3つのタイプがあります。
データ・ストア属性: データベースを破棄して再作成することでのみ変更できるデータベースの特性を定義します。
初期接続属性: データベースをアンロードしてメモリーにリロードすることで変更できるデータベースの特性を定義します。
一般接続属性: アプリケーションがデータベースにアクセスする方法を制御します。このような属性は、接続中は保持されます。
TimesTen接続属性の詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』の属性のリストに関する項および『Oracle TimesTen In-Memory Databaseオペレーション・ガイド』のデータ・マネージャDSNまたはサーバーDSNの接続属性に関する項を参照してください。
Kubernetes環境の場合:
データ・ストア属性を変更するには、TimesTenClassicオブジェクトとTimesTenClassicオブジェクトに関連付けられたPersistentVolumeClaimsを削除する必要があります。そうすることで、TimesTenデータベースを削除します。削除プロセスの詳細は、TimesTenデータベースのアクティブ・スタンバイ・ペアの削除およびクリーン・アップを参照してください。
初期接続属性と一般接続属性の変更には、TimesTenClassicオブジェクトの削除(それによるデータベースの削除)とTimesTenClassicオブジェクトに関連付けられたPersistentVolumeClaimsの削除は不要です。一部の初期接続属性を変更する場合に、TimesTenの制限がある点に注意してください。詳細は、『Oracle TimesTen In-Memory Databaseリファレンス』の属性のリストに関する項を参照してください。
初期接続属性または一般接続属性を変更するには:
まず、db.iniファイルを編集する必要があります。「db.iniファイルの手動編集」の項に示した手順を完了します。このセクションは、最初に完了しておく必要があります。
その後で、次のステップを実行します。
初期接続属性を変更する場合は、「初期接続属性の変更」の項に示した手順を実行します。
一般接続属性を変更する場合は、「一般接続属性の変更」の項に示した手順を実行します。
このセクションは、初期接続属性と一般接続属性のどちらか(または両方)を変更する場合に完了します。この項は、「初期接続属性の変更」または「一般接続属性の変更」の項を続ける前に完了しておく必要があります。
初期接続属性または一般接続属性を変更するには、sys.odbc.iniファイルを変更する必要があります。
TimesTenClassicオブジェクトを作成してTimesTenデータベースのアクティブ・スタンバイ・ペアをすでに作成していたときに、sys.odbc.iniファイル内の初期接続属性または一般接続属性を変更する場合は、db.iniファイルを変更する必要があります。
db.iniファイルの変更方法の詳細は、db.iniファイルを収容するために最初に使用した機能によって異なります。(その可能性のある機能には、ConfigMap、Secretまたは初期化コンテナが含まれます。詳細は、「/ttconfigディレクトリの移入」を参照してください)。
この例では、最初にdb.iniファイルを収容してTimesTenコンテナの/ttconfigディレクトリを移入するためにConfigMap機能が使用されました。この例では、sample ConfigMapを変更します。
そのステップは次のとおりです。
kubectl describeコマンドを使用して、元のsample ConfigMapにあるdb.iniファイル(太字で表示)の内容を確認します。
5 kubectl describe configmap sample Name: sample Namespace: mynamespace Labels: <none> Annotations: <none> Data ==== adminUser: ---- scott/tiger db.ini: ---- PermSize=200 DatabaseCharacterSet=AL32UTF8 schema.sql: ---- create sequence scott.s; create table scott.emp (id number not null primary key, name char (32)); Events: <none>
kubectl editコマンドを使用して、元のsample ConfigMapのdb.iniファイルを変更します。初期接続属性のPermSizeを600 (太字で表示)に変更します。初期接続属性のTempSizeを追加して、その値を300 (太字で表示)に設定します。一般接続属性のConnectionCharacterSetを追加して、その値をAL32UTF8 (太字で表示)に設定します。
% kubectl edit configmap sample
# Please edit the object below. Lines beginning with a '#' will be ignored,
# and an empty file will abort the edit. If an error occurs while saving this
# file will be reopened with the relevant failures.
#
apiVersion: v1
data:
adminUser: |
scott/tiger
db.ini: |
PermSize=600
TempSize=300
ConnectionCharacterSet=AL32UTF8
DatabaseCharacterSet=AL32UTF8
schema.sql: |
create sequence scott.s;
create table scott.emp (id number not null primary key, name char (32));
kind: ConfigMap
metadata:
creationTimestamp: "2020-09-15T19:23:59Z"
name: sample
namespace: mynamespace
resourceVersion: "71907255"
selfLink: /api/v1/namespaces/mynamespace/configmaps/sample
uid: 0171ff7f-f789-11ea-82ad-0a580aed0453
...
configmap/sample edited
kubectl describeコマンドを使用して、sample ConfigMapに対する変更内容を検証します。(変更箇所は太字で表示しています)。
% kubectl describe configmap sample Name: sample Namespace: mynamespace Labels: <none> Annotations: <none> Data ==== schema.sql: ---- create sequence scott.s; create table scott.emp (id number not null primary key, name char (32)); adminUser: ---- scott/tiger db.ini: ---- PermSize=600 TempSize=300 ConnectionCharacterSet=AL32UTF8 DatabaseCharacterSet=AL32UTF8 Events: <none>
sample ConfigMapの変更が完了しました。初期接続属性を変更する場合は、「初期接続属性の変更」の項に進んでください。一般接続属性を変更する場合は、「一般接続属性の変更」の項に進んでください。
db.iniファイルを変更していない場合は、「db.iniファイルの手動編集」の項に進みます。ここでは、スタンバイ・ポッドを削除してから、アクティブ・ポッドを削除する必要があります。TimesTenを実行しているコンテナを収容するポッドを削除すると、オペレータは削除したポッドを置き換えるために新しいポッドを作成します。この新しいポッドには、/ttconfigディレクトリにあるdb.iniファイルの内容から作成された新しいsys.odbc.iniファイルが収容されます。
次のステップを実行して、スタンバイ・データベースを削除します。
kubectl getコマンドを使用して、どのポッドがsample TimesTenClassicオブジェクトのスタンバイ・ポッドであるかを確認します。アクティブ・ポッドは、ACTIVE列に示されるポッドです。スタンバイ・ポッドは、それ以外のポッド(ACTIVE列に示されないもの)です。そのため、sample TimesTenClassicオブジェクトの場合、アクティブ・ポッドはsample-0 (太字で表示)で、スタンバイ・ポッドはsample-1です。
% kubectl get ttc sample NAME STATE ACTIVE AGE sample Normal sample-0 47h
スタンバイ・ポッド(この例ではsample-1)を削除します。この結果として、オペレータは削除されたポッドを置き換えるための新しいスタンバイ・ポッドを作成します。新しいスタンバイ・ポッドが作成されるときに、そのポッドは新しく変更されたsample ConfigMapを使用するようになります。(このConfigMapは、「db.iniファイルの手動編集」の項で変更したものです)。
% kubectl delete pod sample-1 pod "sample-1" deleted
kubectl getコマンドを使用して、スタンバイ・ポッドが稼働中であり、状態がNormalになっていることを確認します。
状態はStandbyDown (太字で表示)になっている点に注目してください。
% kubectl get ttc sample
NAME STATE ACTIVE AGE
sample StandbyDown sample-0 47h
数分間待機してから、コマンドを再実行します。状態がNormal (太字で表示)に変化した点に注目してください。
% kubectl get ttc sample
NAME STATE ACTIVE AGE
sample Normal sample-0 47h
kubectl exec -itコマンドを使用して、スタンバイ・ポッド(この例ではsample-1)のシェルを呼び出します。その次に、ttIsqlユーティリティを実行してsampleデータベースに接続します。この接続の出力では、新しいPermSize値の600と、新しいTempSize値の300に注目してください(太字で表示)。
% kubectl exec -it sample-1 -c tt -- /usr/bin/su - oracle % ttIsql sample Copyright (c) 1996, 2020, Oracle and/or its affiliates. All rights reserved. Type ? or "help" for help, type "exit" to quit ttIsql. connect "DSN=sample"; Connection successful: DSN=sample;UID=oracle;DataStore=/tt/home/oracle/datastore/sample; DatabaseCharacterSet=AL32UTF8;ConnectionCharacterSet=AL32UTF8; AutoCreate=0;PermSize=600;TempSize=300;DDLReplicationLevel=3; ForceDisconnectEnabled=1; (Default setting AutoCommit=1)
アクティブ・ポッドからスタンバイ・ポッドにフェイルオーバーします。フェイルオーバー・プロセスの詳細は、フェイルオーバーを参照してください。このステップを開始する前に、アクティブ・データベースで実行されていたすべてのトランザクションがスタンバイ・データベースにレプリケートされるように、アプリケーションを静止し、ttRepAdmin -waitコマンドを使用してレプリケーションの遅れが回復されるまで待機します。スタンバイの遅れが回復されたら、アクティブ・ポッドを削除して、アクティブ・データベースからスタンバイにフェイルオーバーします。アクティブ・ポッドを削除すると、オペレータは自動的に障害を検出して、スタンバイ・データベースをアクティブに昇格させます。
アクティブ・ポッド(この例ではsample-0)を削除します。
% kubectl delete pod sample-0 pod "sample-0" deleted
数分間待機してから、kubectl getコマンドを使用して、sample TimesTenClassicオブジェクトのアクティブ・ポッドがsample-1で、状態がNormalになっていることを確認します(太字で表示)。
% kubectl get ttc sample NAME STATE ACTIVE AGE sample Normal sample-1 47h
kubectl exec -itコマンドを使用して、アクティブ・ポッド(この例ではsample-1)のシェルを呼び出します。その次に、ttIsqlユーティリティを実行してsampleデータベースに接続します。この接続の出力では、新しいPermSize値の600と、新しいTempSize値の300に注目してください(太字で表示)。
% kubectl exec -it sample-1 -c tt -- /usr/bin/su - oracle Last login: Sun Oct 11 15:50:29 UTC 2020 on pts/0 [oracle@sample-1 ~]$ ttIsql sample Copyright (c) 1996, 2020, Oracle and/or its affiliates. All rights reserved. Type ? or "help" for help, type "exit" to quit ttIsql. connect "DSN=sample"; Connection successful: DSN=sample;UID=oracle;DataStore=/tt/home/oracle/datastore/sample; DatabaseCharacterSet=AL32UTF8;ConnectionCharacterSet=AL32UTF8; AutoCreate=0;PermSize=600;TempSize=300;DDLReplicationLevel=3; ForceDisconnectEnabled=1; (Default setting AutoCommit=1)
kubectl exec -itコマンドを使用して、スタンバイ・ポッド(この例ではsample-0)のシェルを呼び出します。その次に、ttIsqlユーティリティを実行してsampleデータベースに接続します。この接続の出力では、新しいPermSize値の600と、新しいTempSize値の300に注目してください(太字で表示)。
% kubectl exec -it sample-0 -c tt -- /usr/bin/su - oracle % ttIsql sample Copyright (c) 1996, 2020, Oracle and/or its affiliates. All rights reserved. Type ? or "help" for help, type "exit" to quit ttIsql. connect "DSN=sample"; Connection successful: DSN=sample;UID=oracle;DataStore=/tt/home/oracle/datastore/sample; DatabaseCharacterSet=AL32UTF8;ConnectionCharacterSet=AL32UTF8; AutoCreate=0;PermSize=600;TempSize=300;DDLReplicationLevel=3; ForceDisconnectEnabled=1; (Default setting AutoCommit=1)
初期接続属性のPermSizeとTempSizeの変更が正常に完了しました。
db.iniファイルを変更していない場合は、「db.iniファイルの手動編集」の項に進みます。アクティブTimesTenデータベースのsys.odbc.iniファイルとスタンバイTimesTenデータベースのsys.odbc.iniファイルは直接変更することも、「初期接続属性の変更」のステップに従って変更することもできます。最初の方法(sys.odbc.iniファイルの直接的な変更)のほうが、問題の発生が少なくなります。
この項では、sys.odbc.iniファイルを直接変更する手順について説明します。
sys.odbc.iniファイルは、アクティブTimesTenデータベースを収容するポッドのTimesTenコンテナと、スタンバイTimesTenデータベースを収容するポッドのTimesTenコンテナにあります。sys.odbc.iniファイルの変更を完了していると、それ以降のアプリケーションは該当する一般接続属性を使用してデータベースに接続できるようになります。
この例では、sys.odbc.iniファイルの編集方法について説明します。
kubectl exec -itコマンドを使用して、アクティブ・ポッドのシェルを呼び出します。(この例では、sample-0がアクティブ・ポッドです)。
% kubectl exec -it sample-0 -c tt -- /usr/bin/su - oracle Last login: Sat Oct 10 22:43:26 UTC 2020 on pts/8
現在のディレクトリ(/tt/home/oracle)を確認します。
% pwd /tt/home/oracle
sys.odbc.iniファイルが格納されているディレクトリに移動します。sys.odbc.iniファイルは、/tt/home/oracle/instances/instance1/confディレクトリにあります。したがって、instances/instance1/confディレクトリに移動します。
% cd instances/instance1/conf
DSN (この例ではsample)の一般接続属性を追加、変更または削除することで、sys.odbc.iniファイルを編集します。一般接続属性のリストは、『Oracle TimesTen In-Memory Databaseリファレンス』の接続属性に関する項を参照してください。
|
ノート: TimesTenの一般接続属性にのみ変更を加えるようにしてください。データ・ストア属性と初期接続属性は、sys.odbc.iniファイルを直接編集して変更することはできません。 |
この例では、sample DSNを変更し、一般接続属性のConnectionCharacterSetを追加して、その値をAL32UTF8に設定します(太字で表示)。
vi sys.odbc.ini
[ODBC Data Sources]
sample=TimesTen 18.1 Driver
tt=TimesTen 18.1 Driver
[sample]
Datastore=/tt/home/oracle/datastore/sample
PermSize=200
DatabaseCharacterSet=AL32UTF8
ConnectionCharacterSet=AL32UTF8
DDLReplicationLevel=3
AutoCreate=0
ForceDisconnectEnabled=1
...
ttIsqlユーティリティを使用して、sampleデータベースに接続し、ConnectionCharacterSet属性の値がAL32UTF8になっていることを確認します(太字で表示)。
% ttIsql sample
Copyright (c) 1996, 2020, Oracle and/or its affiliates. All rights reserved.
Type ? or "help" for help, type "exit" to quit ttIsql.
connect "DSN=sample";
Connection successful:
DSN=sample;UID=oracle;DataStore=/tt/home/oracle/datastore/sample;
DatabaseCharacterSet=AL32UTF8;ConnectionCharacterSet=AL32UTF8;
AutoCreate=0;PermSize=200;DDLReplicationLevel=3;ForceDisconnectEnabled=1;
(Default setting AutoCommit=1)
アクティブ・ポッド(この例ではsample-0)のTimesTenコンテナにあるsys.odbc.iniファイルの変更が完了しました。同じ手順を使用して、スタンバイ・ポッド(この例ではsample-1)のTimesTenコンテナにあるsys.odbc.iniファイルを変更します。
次に例を示します。
kubectl exec -itコマンドを使用して、スタンバイ・ポッド(この例ではsample-1)のシェルを呼び出します。
% kubectl exec -it sample-1 -c tt -- /usr/bin/su - oracle Last login: Sat Oct 10 23:08:08 UTC 2020 on pts/0
現在のディレクトリ(/tt/home/oracle)を確認します。
% pwd /tt/home/oracle
sys.odbc.iniファイルが格納されているディレクトリに移動します。sys.odbc.iniファイルは、/tt/home/oracle/instances/instance1/confディレクトリにあります。したがって、instances/instance1/confディレクトリに移動します。
% cd instances/instance1/conf
sys.odbc.iniファイルを編集して、アクティブ・データベースで変更したものと同じ一般接続属性を追加、変更または削除します。したがって、この例では、sample DSNを変更し、一般接続属性のConnectionCharacterSetを追加して、その値をAL32UTF8に設定します(太字で表示)。
vi sys.odbc.ini
[ODBC Data Sources]
sample=TimesTen 18.1 Driver
tt=TimesTen 18.1 Driver
[sample]
Datastore=/tt/home/oracle/datastore/sample
PermSize=200
DatabaseCharacterSet=AL32UTF8
ConnectionCharacterSet=AL32UTF8
DDLReplicationLevel=3
AutoCreate=0
ForceDisconnectEnabled=1
...
ttIsqlユーティリティを使用して、sampleデータベースに接続し、ConnectionCharacterSet属性の値がAL32UTF8になっていることを確認します(太字で表示)。
% ttIsql sample
Copyright (c) 1996, 2020, Oracle and/or its affiliates. All rights reserved.
Type ? or "help" for help, type "exit" to quit ttIsql.
connect "DSN=sample";
Connection successful:
DSN=sample;UID=oracle;DataStore=/tt/home/oracle/datastore/sample;
DatabaseCharacterSet=AL32UTF8;ConnectionCharacterSet=AL32UTF8;
AutoCreate=0;PermSize=200;DDLReplicationLevel=3;ForceDisconnectEnabled=1;
(Default setting AutoCommit=1)
アクティブ・ポッド(sample-0)のTimesTenコンテナにあるsys.odbc.iniファイルと、スタンバイ・ポッド(sample-1)のTimesTenコンテナにあるsys.odbc.iniファイルの変更が完了しました。また、一般接続属性ConnectionCharacterSetも変更されました。
アクティブ・スタンバイ・ペアを手動で操作する場合は、timestenclassic-operatorデプロイメントを削除できます。オペレータは停止し、再起動しません。これは、Kubernetesクラスタで実行されているすべてのTimesTenClassicオブジェクトに影響します。オペレータですべてのTimesTenClassicオブジェクトの管理を停止しない場合は、個々のTimesTenClassicオブジェクトの管理を一時停止できます。詳細は、TimesTenClassicオブジェクトの管理の一時停止を参照してください。
TimesTenデータベースのアクティブ・スタンバイ・ペアを表すTimesTenClassicオブジェクトは、それらに関連付けられた他のKubernetesオブジェクトと同様にKubernetesに残ります。kubectl exec -itコマンドを使用してポッドのシェルを起動し、それらのポッドで実行されているTimestenを制御できます。
アクティブ・スタンバイ・ペアの1つまたは両方のポッドで障害が発生した場合、Kubernetesは新しいポッドを作成して置き換えます。これは、オペレータが以前にKubernetesで作成したStatefulSetオブジェクトによるものです。ただし、オペレータは新しいポッドを実行していないため、TimesTenを自動的に起動できません。この場合、アクティブ・スタンバイ・ペアを構成または起動することはできません。ユーザーがポッドでTimesTenの操作を行う必要があります。
再びオペレータで制御を行う場合は、オペレータを再デプロイする必要があります。オペレータを再デプロイすると、オペレータはKubernetesクラスタ内のTimesTenClassicオブジェクトを自動的に識別し、それらの管理を再試行します。
この例は、TimesTenを手動で制御する方法を示しています。
オペレータおよびTimesTenデータベースが実行されていることを確認します。
% kubectl get pods NAME READY STATUS RESTARTS AGE sample-0 2/2 Running 0 18h sample-1 2/2 Running 0 18h timestenclassic-operator-5d7dcc7948-pzj58 1/1 Running 0 18h
operator.yamlが存在する/deployディレクトリに移動します。(この例ではkube_files/deploy。)
% cd kube_files/deploy
kubectl deleteコマンドを使用してオペレータを削除します。オペレータは停止し、デプロイされなくなります。
% kubectl delete -f operator.yaml deployment.apps "timestenclassic-operator" deleted
オペレータは実行されていないが、TimesTenデータベースが実行されていることを確認します。
% kubectl get pods NAME READY STATUS RESTARTS AGE sample-0 2/2 Running 0 19h sample-1 2/2 Running 0 19h
kubectl exec -itコマンドを使用して、TimesTenを実行するポッドのシェルを起動します。
% kubectl exec -it sample-0 -c tt -- /usr/bin/su - oracle Last login: Wed Apr 8 14:30:45 UTC 2020 on pts/0
ttStatusユーティリティを実行します。
% ttStatus TimesTen status report as of Wed Apr 8 14:36:31 2020 Daemon pid 183 port 6624 instance instance1 TimesTen server pid 190 started on port 6625 ------------------------------------------------------------------------ ------------------------------------------------------------------------ Data store /tt/home/oracle/datastore/sample Daemon pid 183 port 6624 instance instance1 TimesTen server pid 190 started on port 6625 There are 20 connections to the data store Shared Memory KEY 0x02200bbc ID 32769 PL/SQL Memory Key 0x03200bbc ID 65538 Address 0x5000000000 Type PID Context Connection Name ConnID Replication 263 0x00007f99fc0008c0 LOGFORCE:140299698493184 2029 Replication 263 0x00007f9a040008c0 XLA_PARENT:140300350273280 2031 Replication 263 0x00007f9a080008c0 REPLISTENER:140300347123456 2030 Replication 263 0x00007f9a080acd60 RECEIVER:140299429472000 2028 Replication 263 0x00007f9a0c0008c0 FAILOVER:140300353423104 2032 Replication 263 0x00007f9a2c0009b0 TRANSMITTER(M):140299695343360 2034 Replication 263 0x00007f9a300008c0 REPHOLD:140300356572928 2033 Subdaemon 187 0x00000000023365b0 Manager 2047 Subdaemon 187 0x00000000023b57f0 Rollback 2046 Subdaemon 187 0x0000000002432cf0 Log Marker 2041 Subdaemon 187 0x000000000244fc00 Garbage Collector 2035 Subdaemon 187 0x00007f90c80008c0 Aging 2038 Subdaemon 187 0x00007f90d00008c0 Deadlock Detector 2044 Subdaemon 187 0x00007f90d001d7d0 HistGC 2039 Subdaemon 187 0x00007f90d40008c0 Checkpoint 2042 Subdaemon 187 0x00007f90d401d7d0 AsyncMV 2036 Subdaemon 187 0x00007f90d80008c0 Monitor 2043 Subdaemon 187 0x00007f90f808b360 IndexGC 2037 Subdaemon 187 0x00007f90fc0008c0 Flusher 2045 Subdaemon 187 0x00007f910004efd0 XactId Rollback 2040 Open for user connections RAM residence policy: Always Replication policy : Manual Replication agent is running. Cache Agent policy : Manual PL/SQL enabled. ------------------------------------------------------------------------ Accessible by group oracle End of report
ttIsqlユーティリティを実行してsampleデータベースに接続し、様々な操作を実行します。
% ttIsql sample
Copyright (c) 1996, 2020, Oracle and/or its affiliates. All rights reserved.
Type ? or "help" for help, type "exit" to quit ttIsql.
connect "DSN=sample";
Connection successful:
DSN=sample;UID=oracle;DataStore=/tt/home/oracle/datastore/sample;
DatabaseCharacterSet=AL32UTF8;ConnectionCharacterSet=US7ASCII;PermSize=200;
DDLReplicationLevel=3;
(Default setting AutoCommit=1)
Command> describe scott.emp;
Table SCOTT.EMP:
Columns:
*ID NUMBER NOT NULL
NAME CHAR (32)
1 table found.
(primary key columns are indicated with *)
Command> INSERT INTO scott.emp VALUES (1,'This is a test.');
1 row inserted.
Command> SELECT * FROM scott.emp;
< 1, This is a test. >
1 row found.
TimesTenデータベースのアクティブ・スタンバイ・ペアを表すTimesTenClassicオブジェクトを削除すると、Kubernetesは自動的にすべてのKubernetesオブジェクトとそのオブジェクトが使用しているリソースを削除します。ペアに関連付けられているStatefulSet、サービスおよびポッドは、すべてKubernetesから削除されます。ただし、(TimesTenデータベースが格納されている) PersistentVolumeClaimsは削除されません。TimesTenClassicオブジェクトを削除した後、PersistentVolumeClaims (PVC)を手動で削除する必要があります。PVCを手動で削除した後、データベースを保持しているPersistentVolumesはKubernetesで再利用されます。(これはKubernetesボリューム保存ポリシーを使用して制御できますが、オペレータでは制御されません)。
例として、kubectl deleteコマンドを使用して、sampleデータベースのPVCを削除します。
% kubectl delete pvc tt-persistent-sample-0 persistentvolumeclaim "tt-persistent-sample-0" deleted % kubectl delete pvc tt-persistent-sample-1 persistentvolumeclaim "tt-persistent-sample-1" deleted
