Caché のアップグレード

この章は、Caché 4.1 以降からアップグレードするユーザを対象としています。この章は、以下のトピックで構成されています。

Important:

アップグレードする前に、以下のドキュメントを参照してください。

"Caché リリース・ノートおよびアップグレード・チェックリスト"。一般的なアップグレード情報や推奨事項、目的のサイトに該当する可能性のあるリリース固有の問題を確認できます。
また、"Caché リリース・ノートおよびアップグレード・チェックリスト・アーカイブ" の参照が必要になることもあります
このリリース用のオンライン・ドキュメントの "インターシステムズでサポートされるプラットフォームOpens in a new tab"。サポートされるテクノロジについての最新情報を確認できます。

Caution:

Caché または Ensemble インスタンスのアップグレードを始める前に、インスタンスを完全にシャットダウンすることが必要です。シャットダウンが完全に行われたことを確認するには、シャットダウンの終了後に、cconsole.log ファイルを検証します。ログに次のようなエントリが含まれていれば、シャットダウンが完全に行われたことなります。

...
05/03/11-14:24:13:234 (5204) 0 Journal restore not required at next startup
05/03/11-14:24:13:234 (5204) 0 Transaction rollback not required at next startup
...

これらのエントリがない場合、インスタンスのシャットダウンが不完全だったことになります。アップグレードを続行する前に、インターシステムズのサポート窓口Opens in a new tabにお問い合わせください。

Note:

Caché MultiValue を実行すると、アップグレード中に一部のファイルが上書きされる場合があります。詳細は、"Caché の MultiValue 機能の使用" の “Caché のインストール” の章にある “アップグレード中に上書きされるファイルに関する注意事項” を参照してください。

サポート対象アップグレード・パス

2009.1 以降のリリースの場合は、今回のリリースの Caché に直接アップグレードできます。ただし、2K ブロック・サイズのデータベースが含まれている 2012.1 より前のインスタンスをアップグレードする場合は、該当するデータベースを 8K 形式に変換してからバージョン 2012.x 以降にアップグレードする必要があります。このような場合、以下の手順を使用します。

インスタンスをバージョン 2011.1.x にアップグレードする (必要な場合)。
SYS.Database.Copy()Opens in a new tab メソッドを使用して、すべての 2K データベースを 8K 形式に変換する。

Note:

このメソッドでは、データベースをマウントする必要があります。2014.1 より前のバージョンのみが 2K データベースのマウントをサポートしています。2014.1 以降のバージョンはこの操作をサポートしていません。詳細は、"はじめに" ガイドの “Caché 2014.1 アップグレード・チェックリスト” のセクションの "操作上の変更" を参照してください。
インスタンスを 2011.1 から現行リリースにアップグレードする。

データベースのブロック・サイズの詳細は、"Caché システム管理ガイド" の “Caché の構成” の章にある "データベースの構成" を参照してください。

Note:

2009.1 より前のバージョンからアップグレードするには、まず、2009.1 以降にアップグレードしてから、現行リリースにアップグレードする必要があります。該当する場合は、2K ブロック・サイズのデータベースを変換する手順を使用します。旧バージョンからのアップグレードに支援が必要な場合は、インターシステムズのサポート窓口Opens in a new tabまでお問い合わせください。

メンテナンス・リリースへのアップグレード

この章の情報の大半は、Caché の新規メジャー・バージョンへのアップグレードに当てはまります。インストール済みバージョンの Caché のメンテナンス・リリースにアップグレードする場合には、以下を確認してください。

"アップグレード・タスク" の最初にあるタスクのリスト (一部のみが該当)。
Caché ミラーをアップグレードする場合は、"最小ダウンタイムでのミラーリングのアップグレード"。
メンテナンス・リリースのインストール後のタスク。

アップグレード・タスクの実行

Caché をアップグレードおよび実行するプラットフォームにかかわらず、以下のアップグレード・タスクが必要になります。以下のタスクは、Caché のインストール手順を実行する前に実行してください。

更新されたライセンス・キーの入手 — Caché 5.1 ではキー構造が変更されています。したがって、Caché 5.0 以前のバージョンからアップグレードするには新しいキーが必要です。
システムのバックアップ — アップグレードの前に、システムの完全バックアップの実行をお勧めします。通常使用している、完全なオペレーティング・システム・バックアップ・プロシージャを使用してください。
システムの整合性チェック — データベース内部エラーが発生していないことを確認するため、既存のディレクトリでシステム整合性チェックを実行します。
カスタムのクラス、ルーチン、およびグローバルの保存 — %SYS ネームスペースにある独自のクラス、ルーチン、およびグローバルがアップグレードによって影響を受けないようにするため、これらの名前の先頭文字を “Z”、“z”、“%Z”、または “%z” にします。.int ルーチンと .obj ルーチン (Z*、z*、%Z*、%z* を除く) はすべて、アップグレード時に %SYS ネームスペースから削除されます。
また、アップグレードの際に、CACHELIB、CACHETEMP、DOCBOOK、CACHE、および SAMPLES データベースは完全に置換されます。
.mac ルーチンや .inc ルーチンはいずれも、アップグレードによる影響を受けません。
ユーザ・ファイルの保存 — アップグレード中にユーザ・ファイルの削除や置換が発生しないように、これらを install-dir\Mgr\User ディレクトリに保存します。このディレクトリは、アップグレードでも変更されることがない唯一のディレクトリです (つまり、install-dir\Mgr\User ディレクトリを除き、Caché インストール・ディレクトリにあるすべてのファイルおよびディレクトリは、アップグレードの際に削除または置換される可能性があります)。
暗号化設定の確認 — リリース 2010.1 以前からアップグレードする際に、そのリリースでの制限により、ユーザ名、パスワード、およびキー・ファイルをインタラクティブに要求するように暗号化が設定されていた場合、アップグレード前に一時的にこの設定を変更して、暗号化情報が自動的にロードされるようにする必要があります (詳細は、"Caché セキュリティ管理ガイド" の “マネージド・キー暗号化” の章にある "無人でキーを有効化する起動の構成" を参照)。アップグレードの実施後は、インタラクティブ設定を再び有効にします。(無人でキーを有効化する起動の構成を怠ると、アップグレードが失敗する恐れがあります。このようになった場合は、システムを通常起動して、自動モードに起動構成を変更した後、新規バージョンを再インストールします。)
.rpm ファイルを使用してアップグレードする場合、アップグレードの前にデータベース暗号化を無効にして、アップグレード完了時に再び有効化する必要があります。

また、環境やコンポーネントに応じて必要となる可能性のあるその他のタスクについても、以下のセクションで説明します。

クラスタのアップグレード

このセクションでは、Caché フェイルオーバー・クラスタ ("Caché 高可用性ガイド" の “Caché での Windows クラスタの使用” など、フェイルオーバー・クラスタの説明を参照) で Caché をアップグレードするときの一般的な考慮事項について説明します。

Note:

このセクションの情報は、ECP アプリケーション・サーバが配置されているシステムには適用されません。ECP 構成のアップグレードの詳細は、"ECP 構成のアップグレード" を参照してください。

Important:

一般的に、以下のことが重要になります。

Caché のアップグレード中に、共有ディスクのリソースが影響を受けたり、オフラインになったりしないようにする。
フェイルオーバー・クラスタで Caché をアップグレードしているときにクラスタ・フェイルオーバーが起こらないようにする。
フェイルオーバー・クラスタでアップグレードをしているときに Caché が自動的に起動しないようにする。

例えば、Windows でクラスタのフェイルオーバーや Caché の自動起動が起こらないようにするため、アップグレードの前に Caché クラスタ・リソースをオフラインにして、操作を再開する準備ができたらクラスタ・リソースをオンラインに戻します。他のすべてのプラットフォームで同様の手順を実行する必要があります。実際の環境で使用されているフェイルオーバー・ソフトウェア製品のドキュメントを参照してください。

プラットフォーム固有の情報については、以下を参照してください。

Windows フェイルオーバー・クラスタにおける Caché のアップグレード

Microsoft Windows のクラスタでは、以下の手順で Caché をアップグレードします。

Important:

Caché ランチャーから Caché の開始と停止を実行しないでください。代わりに、Caché を停止するには、[フェールオーバークラスタ管理] を使用して Caché クラスタ・リソースをオフラインにします。また、Caché を起動するには Caché クラスタ・リソースをオンラインにします。

クラスタの動作再開前に、Caché を Windows クラスタの両方のシステムでアップグレードして、適切なレジストリ設定が維持されるようにする必要があります。そのため、クラスタを一定時間使用不可にすることなしに、Windows クラスタをアップグレードすることはできません。

クラスタ・フェイルオーバーが自動的に実行されないようにした後、Caché クラスタ・リソースをオフラインにすることで、現在実行中 (プライマリ) のシステム (システム A とします) の Caché をシャットダウンします。アップグレード前にシステムを停止するには、この手順をお勧めします。
システム A の Caché をアップグレードします。アップグレードが正常に終了すると、アップグレード・プロセスによってシステム A の Caché が起動されますが、すべて (クラスタ全体) のアップグレード・プロセスが完了するまでユーザ (直接接続、バックグラウンド・プロセス、ECP アプリケーション・サーバなど) がシステムに再接続できないようにすることをお勧めします。
Caché クラスタ・リソースをオフラインにして、システム A の Caché をシャットダウンします。
セカンダリ・システム (システム B とします) にクラスタをフェイルオーバーします。
システム B の Caché をアップグレードします。アップグレードが正常に終了すると、アップグレード・プロセスによってシステム B の Caché が起動されますが、すべて (クラスタ全体) のアップグレード・プロセスが完了するまでユーザ (直接接続、バックグラウンド・プロセス、ECP アプリケーション・サーバなど) がシステムに再接続できないようにすることをお勧めします。
システム A にクラスタをフェイルオーバーします。
Caché クラスタ・リソースをオンラインにして、システム A の Caché を起動します。
クラスタのリソース・タイプ (例えば、Caché ISCCres2003) がオンラインになっていて、自動フェイルオーバーが実行可能になっていることを確認します。この時点で、ユーザ (直接接続、バックグラウンド・プロセス、ECP アプリケーション・サーバなど) が Caché (システム A) に再接続可能になります。

UNIX®、Linux、および macOS フェイルオーバー・クラスタにおける Caché のアップグレード

UNIX/Linux システムのクラスタでは、以下の手順で Caché をアップグレードします。

2 つのフェイルオーバー・ノード上にある Caché インスタンスのリストを収集します。この操作は、ccontrol list コマンドを使用して実行できます。セカンド (スタンバイ) フェイルオーバー・ノードに固有のシステム (およびパスなど) がリストに示されていた場合は、それらに注目してください。
クラスタ・フェイルオーバーが自動的に実行されないようにした後で、現在実行中 (プライマリ) のシステム (システム A とします) の Caché をシャットダウンします。
システム A の Caché をアップグレードします。アップグレードが完了すると、アップグレード・プロセスによって Caché が起動されます。この時点で、ユーザ (直接接続、バックグラウンド・プロセス、ECP アプリケーション・サーバなど) が Caché (システム A) に再接続可能となります。
/usr/local/etc/cachesys/ ディレクトリをシステム A からシステム B にコピーします。注意： cachesys ディレクトリおよびそのディレクトリ内のファイルに対する権限および所有権は変更されることのないようにしてください。
システム B に固有の Caché インスタンスがある場合には、ccontrol create コマンドを使用してその情報を手動で再作成し、インスタンスの情報をレジストリに追加する必要があります。このコマンドの適切な使用法は、OS プロンプトで ccontrol create help と入力すると確認できます。
Caché に関連する適切なクラスタ・リソースがオンラインになっていて、自動フェイルオーバーが可能になっていることを確認します。

最小ダウンタイムでのミラーリングのアップグレード

このセクションでは、Caché または Ensemble のインスタンス、アプリケーション、または両方を Caché のミラーのメンバ上でアップグレードする手順を説明します。

"Caché 高可用性ガイド" の “ミラーリング” の章に記述しているように、ミラーのすべてのフェイルオーバー・メンバおよび DR 非同期メンバは同じ Caché バージョンでなければならず、異なるバージョンが許されるのはアップグレード中のみです。アップグレードされるメンバがプライマリになったら、このアップグレードが完了するまで、他方のフェイルオーバー・メンバおよびすべての DR 非同期メンバを使用できません (特に、これらはプライマリにはなれません)。

ミラーリングでは、非同期メンバがフェイルオーバー・メンバと同じ Caché バージョンであることを報告する必要はありませんが、アプリケーションの機能によってこれが要求される場合があります (非同期バージョン要件の報告の詳細は、このリリース用のオンライン・ドキュメント "インターシステムズでサポートされるプラットフォームOpens in a new tab" の “サポート対象バージョン間の相互運用性” を参照)。

ミラーのアップグレード手順は以下の 4 つです。最初の 3 つの手順は、アプリケーションのダウンタイムを可能な限り最短にして必要なアップグレードを実行できるように設計されています。さまざまなアップグレードの状況に合うように 3 つの手順が用意されています。最後の手順はやや単純で、ダウンタイムの最小化が優先事項でない場合にあらゆる種類のアップグレードに使用できます。

ミラーのアップグレード手順の選択に、使用する手順を決定する要素の概要を示します。状況によっては、指定の手順において追加の手順および詳細が必要になる場合があります。どの手順が適切か、または特定の手順が適切かどうかが不明な場合は、インターシステムズのサポート窓口Opens in a new tab (WRC) までお問い合わせください。

繰り返しを避けるために、最小ダウンタイムのアップグレードの用語に、複数の手順で使用される用語を定義しています。

Important:

systemd をサポートする Linux システムでは、systemctl コマンドまたは /etc/init.d/ISCAgent スクリプトのいずれかを使用して ISCAgent を管理できますが、1 つの方法を選択して、その方法のみを使用する必要があります。ISCAgent は、必ず起動方法と同じ方法で停止する必要があります ("Caché 高可用性ガイド" の “ミラーリング” の章にある "Linux システムでの ISCAgent の開始" を参照)。

前述のような Linux システムで Caché をアップグレードすると、実行中の ISCAgent は systemd を使用して自動的に再起動します。/etc/init.d/ISCAgent スクリプトを使用して ISCAgent を管理している場合、このエージェントが自動的に再起動しないように、アップグレードを実行する前にエージェントを停止し、アップグレード後にスクリプトを使用してエージェントを再起動します。

ミラーのアップグレード手順の選択

ご使用のミラーのアップグレードに適切な手順を選択する際に考慮する必要がある主要な要素は以下の 2 つです。

インストール済みバージョンの Caché のメンテナンス・リリースへのアップグレードですか (例えば 2015.1.0 から 2015.1.1)、それとも新しいメジャー・バージョンの Caché へのアップグレードですか (例えば 2014.1.0 から 2015.1.0)。
ミラーリングされるデータベースの変更がアップグレードに含まれますか。

メンテナンス・リリースへのアップグレードで、アプリケーションのアップグレードを行わない場合には、2 番目の質問を考慮する必要はありません。常に単純なメンテナンス・リリースのアップグレードの手順を使用できます。この手順では、ミラーを使用できなくなるのは計画されたフェイルオーバーの実行時間のみです。

ただし、あるメジャー Caché バージョンから別のバージョンへのアップグレード、アプリケーションのアップグレード、または両方を実行する場合、ミラーリングされるデータベースの変更がアップグレードで必要になる可能性があります。このような変更は、アップグレード手順の一部として動作中のプライマリ・フェイルオーバー・メンバで行う必要があり、その間アプリケーションへのアクセスは無効になります。その結果、アップグレードは、ミラーリングされるデータベースの変更を行わない場合に比べて、長いダウンタイムが必要になります。(この変更は、その後バックアップ・メンバおよび非同期メンバのミラーによって複製されます。)

メジャー・アップグレードの後、インスタンスのすべてのアプリケーション・ネームスペース (Ensemble ネームスペースを含む) のすべてのクラスをリコンパイルすることをお勧めします。また、一部のルーチンもリコンパイルする必要があります ("Caché リリース・ノートおよびアップグレード・チェックリスト" の一般的なアップグレード情報の章にある "アップグレードの詳細" を参照)。実行するアプリケーション・アップグレードはアプリケーション・データの変更を必要とする可能性があります。これらの状況のいずれでも、ミラーリングされるデータベースがアップグレードによって変更される場合があります。したがって、メジャー・リリースへのアップグレード、アプリケーションのアップグレード、または両方を実行する場合、以下の条件のいずれかが当てはまるかどうかを確認する必要があります。

クラスとルーチンが、アプリケーション・データも格納されているミラーリングされるデータベースに格納される。これらは、プライマリでリコンパイルする必要があります (アプリケーションがアップグレードされなかった場合でも同様)。
アプリケーションのアップグレードのためにミラーリングされるデータベースのデータをアップグレードする必要がある。これらの変更は、プライマリで実行する必要があります。
ミラーリングされるデータベースが Ensemble または DeepSee で使用される。これらのデータベースにマップされるすべてのネームスペースのすべてのクラスをプライマリでリコンパイルする必要があります。

メジャー・アップグレードおよびアプリケーションのアップグレード (またはいずれか) がこれらの条件のいずれかに当てはまる場合、メジャー・アップグレード (ミラーリングされるデータベースの変更) の手順を使用します。この手順では、ミラーを使用できなくなるのは計画されたフェイルオーバーの実行およびミラーリングされるデータベースの必要な変更の時間のみです。

アップグレードに、ミラーリングされるデータベース変更のリストのいずれも含まれない場合、メジャー・アップグレード (ミラーリングされるデータベースの変更なし) の手順の使用を検討してください。この手順では、ミラーを使用できなくなるのは計画されたフェイルオーバーの実行時間のみです。

計画されたメンテナンス・ウィンドウが大きく、ミラーのダウンタイムの最小化が主要な問題でない場合、代わりにより単純な計画されたダウンタイムによるメジャー・アップグレードの手順の使用を選択できます。

メジャー・アップグレードの場合、各手順の一般的な順序をミラーの Caché インスタンスまたはアプリケーション・コード、あるいはその両方のアップグレードに適用します。アップグレードの対象に応じて、個々のステップを調整してください。

アップグレード中のミラー・メンバの追加

メンバをミラーに追加する計画がある場合、後でアップグレードする必要がなくなるように、このセクションで説明しているアップグレードのいずれかを実行するまでこれを延期してから、アップグレード中に新規バージョンのメンバを追加できます。説明したようにすぐにアップグレードを続行して完了した場合、新規バージョンのメンバはアップグレード中にいつでもミラーに追加できます。ただし、1 つの制限として、新規バージョンのメンバがプライマリになったら、他のすべてのメンバがアップグレードされるまで、プライマリのままにする必要があります。

アップグレード中に新規メンバを追加することは、ミラーを新規ハードウェアに移行する際に非常に役立つ可能性があります。フェイルオーバー・メンバの 1 つをアップグレードしてから、そのメンバにフェイルオーバーするのではなく、まず新規バージョンの新規インスタンスをターゲット・システムにインストールし、それを DR 非同期メンバとしてミラーに追加します。続いて、バックアップに昇格させて、それにフェイルオーバーします。このようにして、ミラー・プライマリを新規システムに移行します。この手法を繰り返すことにより、残りのフェイルオーバー・メンバを移行できます。この方法を示すために、このセクションの手順には、既存のバックアップをアップグレードする代わりに、新規バージョンの新規バックアップを追加する手順が含まれています。

最小ダウンタイムのアップグレードの用語

このセクションの手順では、以下の用語を使用します。

クラスとルーチンのアップグレードは、Caché のメジャー・バージョン・アップグレードおよびアプリケーションのアップグレード (またはいずれか) の後にインスタンスのすべてのアプリケーション・ネームスペースのすべてのクラスをリコンパイルすることを意味します ("インストール後のアップグレード・タスク" を参照)。これらのアップグレードは、状況に応じて以下の操作の 1 つまたは複数を含みます。
- 前述のとおり、クラスとルーチンは、アプリケーション・データも含むミラーリングされるデータベースに存在する場合、(アプリケーションのアップグレードによって変更されたかどうかに関係なく) 動作しているプライマリ・フェイルオーバー・メンバでローカルにリコンパイルする必要があります。
- アプリケーション・データから独立しているミラーリングされないルーチン・データベースに格納されているクラスとルーチンは、現在プライマリであるかどうかに関係なくミラー・メンバでリコンパイルできます。
- 独立したミラーリングされないルーチン・データベースに格納されているクラスとルーチンは、既にターゲットの Caché リリースにアップグレード済みのシステムでデータベースのコピーをリコンパイルすることによって “プリコンパイル” し、アップグレードに続いて各ミラー・メンバに配布することも可能です。
クラスとルーチンをアップグレードするために使用する方法は、状況、使用している手順、およびリコンパイルしているメンバによって決まります。
システム A という名称は、当初はプライマリ・フェイルオーバー・メンバであるミラー・メンバを意味します。システム B は、当初はバックアップ・フェイルオーバー・メンバであるミラー・メンバを意味します。システム C は、フェイルオーバー・メンバに昇格された新規の Caché バージョンの、新しく追加された DR 非同期メンバを意味します。
フェイルオーバーなし設定は、^MIRROR ルーチンを使用して [フェイルオーバーなし] 状態を設定することで、フェイルオーバーが起動しないようにすることを意味します。手順については、"Caché 高可用性ガイド" の “ミラーリング” の章にある "フェイルオーバー・メンバのメンテナンス時の不要なフェイルオーバーの回避" を参照してください。
適切なシャットダウンの実行は ccontrol stop コマンドの使用を意味します ("Caché システム管理ガイド" の “Caché 複数インスタンスの使用法” の章にある "Caché インスタンスの制御" を参照してください)。
フェイルオーバー・メンバに昇格とは、"Caché 高可用性ガイド" の　"“ミラーリング”"　の章にある "DR 非同期メンバのフェイルオーバー・メンバへの昇格" で説明されているように、DR 非同期ミラー・メンバをフェイルオーバー・メンバに昇格させるための手順を意味します。
ミラー・モニタの表示は、インスタンスの管理ポータルの [ミラー・モニタ] ページを使用して、ミラーおよびそのメンバの状態を確認することを意味します。詳細は、"Caché 高可用性ガイド" の “ミラーリング” の章にある "ミラー・モニタの使用法" を参照してください。

Caché メンテナンス・リリースへのアップグレード

新規のメジャー Caché バージョンではなく Caché メンテナンス・リリースにアップグレードする場合で、アプリケーションを変更しない場合、以下の手順を使用します。この手順では、ミラーを使用できなくなるのは計画されたフェイルオーバーの実行に必要な時間のみです。

バックアップが完全にアップグレードされるまでフェイルオーバーが実行されないようにするには、[フェイルオーバーなし] を設定します。
以下の 2 つの操作のいずれかを実行します。
- 既存のバックアップをアップグレードする
  1. バックアップ (B) の適切なシャットダウンを実行します。
  2. バックアップ (B) を Caché の新しいバージョンにアップグレードします。システム B がバックアップとなります。
- 新規バージョンの新規バックアップを追加する
  1. Caché の新規バージョンをシステム C にインストールします。
  2. システム C を DR 非同期メンバとしてミラーに追加します。
  3. システム C をフェイルオーバー・メンバに昇格させます。システム C がバックアップになり、システム B が DR 非同期になります。
ミラー・モニタを表示して、バックアップ (B または C) がアクティブになったことを確認します。
[フェイルオーバーなし] をクリアします。
プライマリ (A) の適切なシャットダウンを実行します。ミラーがフェイルオーバーして、バックアップ (B または C) がプライマリになります。
システム A を Caché の新しいバージョンにアップグレードします。システム A がバックアップとなります。
システム C がプライマリになり、システム B が DR 非同期に降格された場合、システム B をアップグレードします。

ミラーリングされるデータベースの変更を伴うメジャー Caché バージョンへのアップグレード

新規のメジャー Caché バージョンにアップグレードしていて、アプリケーションのアップグレードを実行している場合 (またはいずれか) で、ミラーリングされるデータベースの変更が必要であると判断した場合 ("ミラーのアップグレード手順の選択" の説明を参照)、以下の手順を使用します。この手順では、ミラーを使用できなくなるのは計画されたフェイルオーバーの実行およびミラーリングされるデータベースの必要な変更の時間のみです。

バックアップが完全にアップグレードされるまでフェイルオーバーが実行されないようにするには、[フェイルオーバーなし] を設定します。
以下の 2 つの操作のいずれかを実行します。
- 既存のバックアップをアップグレードする
  1. バックアップ (B) の適切なシャットダウンを実行します。
  2. バックアップ (B) を Caché の新しいバージョンにアップグレードします。システム B がバックアップとなります。
  3. システム B のミラーリングされないクラスとルーチンをアップグレードします (存在する場合)。
- 新規バージョンの新規バックアップを追加する
  1. Caché の新規バージョンをシステム C にインストールします。
  2. システム C を DR 非同期メンバとしてミラーに追加します。
  3. システム C をフェイルオーバー・メンバに昇格させます。システム C がバックアップになり、システム B が DR 非同期になります。
ミラー・モニタを表示して、バックアップ (B または C) がアクティブになったことを確認します。
サイトにおける通常の手順を使用して、ミラーへの新規ユーザ・アクセスを禁止します。また、プライマリになったときにシステム B で通常始動するアプリケーション・ジョブをすべて無効化する必要があります。Ensemble を使用している場合、プロダクションの自動起動を無効にします。
[フェイルオーバーなし] をクリアします。
プライマリ (A) の適切なシャットダウンを実行します。ミラーがフェイルオーバーして、バックアップ (B または C) がプライマリになります。
新規のプライマリ (B または C) のミラーリングされるクラスとルーチンをアップグレードします。アプリケーションのアップグレードでミラーリングされるデータベースの追加の変更が必要な場合、その変更を行います。
ミラーへのユーザ・アクセスを復旧します。Ensemble を使用している場合、プロダクションの自動起動を有効にし、プロダクションを起動します。
完全にアップグレードされるまでシステム A がプライマリになることを防ぐために、[フェイルオーバーなし] を設定します。
システム A を Caché の新しいバージョンにアップグレードします。システム A がバックアップとなります。
システム A のミラーリングされないクラスとルーチンをアップグレードします (存在する場合)。
[フェイルオーバーなし] をクリアします。
システム C がプライマリになり、システム B が DR 非同期に降格された場合、システム B をアップグレードし、システム B のミラーリングされないクラスとルーチンがあればアップグレードします。

ミラーリングされるデータベースの変更を伴わないメジャー Caché バージョンへのアップグレード

新規のメジャー Caché バージョンにアップグレードしていて、アプリケーションのアップグレードを実行している場合 (またはいずれか) で、ミラーリングされるデータベースの変更が必要ないと判断した場合、("ミラーのアップグレード手順の選択" の説明を参照)、以下の手順を使用できます。

これは、独立したミラーリングされないルーチン・データベースが常に維持される静的アプリケーションに対して最も単純な手順です。ただし、アップグレード中にミラーからこの独立したルーチン・データベースを削除することによって、これらのデータベースが普通にミラーリングされる場合でも、この手順を使用できます。

Important:

このルーチン・データベースが普通にミラーリングされる場合、ミラーから削除する前にアプリケーション・データを一切含まないことを確認してください。

この手順は、ECPアプリケーション・サーバがミラーと接続している場合、普通にミラーリングされるルーチン・データベースでは使用できません。

サイトにおける通常の手順を使用して、コードのフリーズおよびアプリケーション構成のフリーズを規定してアップグレード中にアプリケーションの変更を禁止し、アップグレード中にルーチン・データベースが変更されないようにします。
バックアップが完全にアップグレードされるまでフェイルオーバーが実行されないようにするには、[フェイルオーバーなし] を設定します。
以下の 2 つの操作のいずれかを実行します。
- 既存のバックアップをアップグレードする
  1. ルーチン・データベースがミラーリングされたら、システム B のミラーからこのルーチン・データベースを削除します。
  2. ミラー・モニタを表示して、バックアップ (B) がアクティブになったことを確認します
  3. バックアップ (B) の適切なシャットダウンを実行します。
  4. バックアップ (B) を Caché の新しいバージョンにアップグレードします。システム B がバックアップとなります。
  5. システム B のクラスとルーチンをアップグレードします。
- 新規バージョンの新規バックアップを追加する
  1. Caché の新規バージョンをシステム C にインストールします。
  2. システム C を DR 非同期メンバとしてミラーに追加します。
  3. システム C をフェイルオーバー・メンバに昇格させます。システム C がバックアップになり、システム B が DR 非同期になります。
  4. ルーチン・データベースがミラーリングされたら、システム C と B のミラーからこのルーチン・データベースを削除します。
  5. ミラー・モニタを表示して、バックアップ (C) がアクティブになったことを確認します。
[フェイルオーバーなし] をクリアします。
プライマリ (A) の適切なシャットダウンを実行します。ミラーがフェイルオーバーして、バックアップ (B または C) がプライマリになります。
完全にアップグレードされるまでシステム A がプライマリになることを防ぐために、[フェイルオーバーなし] を設定します。
システム A を Caché の新しいバージョンにアップグレードします。システム A がバックアップとなります。
システム A のミラーリングされないクラスとルーチンをアップグレードします。
システム C がプライマリになり、システム B が DR 非同期に降格された場合、システム B をアップグレードし、システム B のミラーリングされないクラスとルーチンがあればアップグレードします。
バックアップ (B または C) のミラーから削除したミラーリングされるルーチン・データベースに対して、それが新しいプライマリになる前に、以下の手順を実行します。
1. システム A のミラーからこのルーチン・データベースを削除します。
2. 新しいプライマリ (B または C) のミラーにこれらのデータベースを追加し、バックアップを作成してバックアップ (A) および DR 非同期 (C がプライマリの場合は B) にリストアします。そのためには、既存データベースをミラーに追加する手順を使用します。これは、"Caché 高可用性ガイド" の “ミラーリング” の章にある "ミラーへのデータベースの追加" で説明しています。これらのバックアップは、新しく追加したミラーリングされたデータベースの最初のバックアップであるため、これらを保持します。アップグレードの前に作成された古いバックアップは災害時にこれらのデータベースのリストアには使用できません。
[フェイルオーバーなし] をクリアします。

計画されたダウンタイムを伴うメジャー Caché バージョンへのアップグレード

新規のメジャー Caché バージョンにアップグレードしていて、アプリケーションのアップグレードを実行している場合 (またはいずれか) で、計画されたメンテナンス・ウィンドウが大きくミラーのダウンタイムを最小化する必要がない場合、プライマリでミラーリングされるデータベースの変更が必要かどうかに関係なく、以下のより単純な手順を使用できます。

ユーザのサイトにおける通常の手順を使用して、ミラーへのユーザ・アクセスをすべて禁止します。また、インスタンスの起動時に通常始動するアプリケーション・ジョブをすべて無効化する必要があります。Ensemble を使用している場合、プロダクションの自動起動を無効にします。
バックアップ (B) の適切なシャットダウンを実行します。
プライマリ (A) の適切なシャットダウンを実行します。
システム A を Caché の新しいバージョンにアップグレードします。システム A がプライマリとなります。
システム A のミラーリングされるクラスとルーチンをアップグレードします。アプリケーションのアップグレードでミラーリングされるデータベースの追加の変更が必要な場合、その変更を行います。
システム A のミラーリングされないクラスとルーチンをアップグレードします (存在する場合)。
以下の 2 つの操作のいずれかを実行します。
- 既存のバックアップをアップグレードする
  1. システム B を Caché の新しいバージョンにアップグレードします。システム B がバックアップとなります。
  2. システム B のミラーリングされないクラスとルーチンをアップグレードします (存在する場合)。
- 新規バージョンの新規バックアップを追加する
  1. Caché の新規バージョンをシステム C にインストールします。
  2. システム C を DR 非同期メンバとしてミラーに追加します。
  3. システム C をフェイルオーバー・メンバに昇格させます。システム C がバックアップとなります。
  4. システム B を Caché の新しいバージョンにアップグレードします。システム B が DR 非同期になります。
  5. システム B のミラーリングされないクラスとルーチンをアップグレードします (存在する場合)。
システム C がプライマリになり、システム B が DR 非同期に降格された場合、システム B をアップグレードし、システム B のミラーリングされないクラスとルーチンがあればアップグレードします。
ミラーへのユーザ・アクセスを復旧します。

ECP 構成のアップグレード

通常は、ECP アプリケーション・サーバが接続するデータ・サーバより前に、ECP アプリケーション・サーバをアップグレードする必要があります。アプリケーション・サーバには、以降のアップグレードをリコンパイルするためのローカルのルーチン・データベースがあるか、またはデータ・サーバ上の “プリコンパイルされた” ルーチン・データベース (目的の Caché バージョンを実行する別のシステムで事前にコンパイルされた) へのアクセスがある必要があります。

以下のいずれかに該当する場合、アップグレードされたアプリケーション・サーバとアップグレードされないアプリケーション・サーバの両方とデータベース・サーバに接続するユーザによるローリング・アップグレードを使用することで、ダウンタイムを最小化することができます。

アプリケーションの変更がない。
アプリケーションの変更はあるが、新しいコードが新しいデータ構造を生成しない。つまり、古いコードが新しいコードによって生成されるデータを使用して機能できる。

新しいアプリケーション・コードが古いデータに対して機能するが、古いコードでは認識されない新しいデータ構造を生成する可能性がある場合、以下の手順に従います。

ローリングベースでアプリケーション・サーバをアップグレードしますが、アップグレードした後、ユーザのアプリケーション・サーバへの接続を禁止します。(アプリケーション・サーバの容量が徐々に減っていくことになります。)
アプリケーション・サーバを十分にアップグレードしたら、アップグレードしたアプリケーション・サーバへのユーザ・アクセスを復旧して、残り (未アップグレード) のアプリケーション・サーバおよびデータ・サーバ (必要な場合) へのユーザの接続をすべて終了させて、有効化するまでそれらのシステムにユーザがアクセスできないようにします。
残りのアプリケーション・サーバをアップグレードして、アップグレード後に各アプリケーション・サーバへのユーザ・アクセスを復旧します。
データ・サーバをアップグレードして、必要に応じてユーザ・アクセスを復旧します。(データ・サーバのアップグレードによって、アプリケーション動作が一時的に停止しますが、その長さはアップグレードに伴うダウンタイムの期間により異なります。)

ご使用の ECP 構成のアップグレードについてのご質問や不明点がある場合は、インターシステムズのサポート窓口Opens in a new tabまでお問い合わせください。

インストール後のアップグレード・タスク

必要なインストール後のタスクは、Caché の新規メジャー・バージョンへのアップグレードか、インストール済みバージョンのメンテナンス・リリースへのアップグレードかによって異なります。

メジャー・バージョンのインストール後のタスク

Caché を新規メジャー・バージョンにアップグレードした後には (例えば 2014.1.0 から 2015.1.0、または 2016.1 から 2016.2 など)、以下のタスクを実行する必要があります (この章の前述の手順の一環として、このタスクを実行していない場合)。

クラスとルーチンのリコンパイル — インターシステムズでは、各ネームスペースに含まれるクラスをすべてリコンパイルすることを推奨しています。一部のルーチンもリコンパイルする必要があります。アップグレードしたインスタンスに特有の依存関係やその他の必要性を考慮して、この目的のための専用ツールや手順を用意してもかまいません。これらの用意がなく、バージョン 2014.1 以降にアップグレードする場合、詳細な情報および手順は、"Caché リリース・ノートおよびアップグレード・チェックリスト" の一般的なアップグレード情報の章にある "アップグレードの詳細" を参照してください (以前のバージョンにアップグレードする場合の情報と手順は、"Caché リリース・ノートおよびアップグレード・チェックリスト・アーカイブ" の付録 “2014.1 以前のアップグレード情報” を参照してください)。
プロキシ・クラスの再生成 — Caché 言語バインディング・セットの適切なガイドの指示に従って、アップグレード済みのインスタンスで生成したすべてのプロキシ・クラスを再生成する必要があります。詳細は、"Caché リリース・ノートおよびアップグレード・チェックリスト" の "一般的なアップグレード情報" の章にある "アップグレードの詳細" を参照してください。
この項目は Web サービスおよび Web クライアントには適用されません。Web サービス定義 (WSDL) ファイルを再インポートする必要はありません。

現在の環境と使用中のコンポーネントによっては、さらに以下のタスクの実行が必要になります。

ブラウザ・キャッシュのクリア — Zen Mojo を使用している場合、インストール済みバージョンの Caché と互換性がなくエラーの原因になると考えられる JavaScript ファイルがブラウザ・キャッシュに含まれている可能性があります。アップグレードが完了したら、即座にブラウザ・キャッシュをクリアしてください。(詳細は、"Zen Mojo の使用法" の “開発中のキャッシュ管理のヒント” の章の "ブラウザ・キャッシュ" を参照してください。)
Web サーバ・ファイルの更新 — Zen を使用している場合、リコンパイルによって外部ファイルが生成されます。また、ユーザ独自の Zen および CSP ファイルが存在することもあります。アップグレード後に、ユーザのサイトにおける通常の手順を使用して、それらのファイルを配置する必要があります。
CSP ゲートウェイのアップグレード — アップグレードする Caché サーバとは別のマシンに CSP ゲートウェイが配置されている場合は、その別のマシン上の CSP ゲートウェイもアップグレードする必要があります。そのためには、Web サーバ・マシンで Caché のカスタム・インストール (このドキュメントの “Microsoft Windows への Caché のインストール” の章にある "CSP ゲートウェイのインストール" のセクションを参照) を実行して、CSP ゲートウェイのみをインストールします。詳細は、"Caché システム管理ガイド" の “リモート・サーバへの接続” の章を参照してください。
スタジオ・クライアントのアップグレード — クライアント上のスタジオのバージョンは、それが接続する Caché サーバのバージョンと同じか、それ以降にする必要があります。これはメンテナンス・リリースにも適用されます。詳細は、"スタジオの使用法" の “スタジオの概要” の章を参照してください。

メンテナンス・リリースのインストール後のタスク

インストール済みバージョンの Caché のメンテナンス・リリースにアップグレードした後 (例えば 2015.1.0 から 2015.1.1)、クラスやルーチンをリコンパイルする必要はありません。ただし、リコンパイルを選択した場合は、"Caché リリース・ノートおよびアップグレード・チェックリスト" の "一般的なアップグレード情報" の章にある "アップグレードの詳細" で説明されているガイダンスに従うことが重要です。

通常、メンテナンス・リリースにアップグレードした後、外部ファイルまたは外部クライアントを変更する必要はありません。