HADR 環境での Db2 サーバーのアップグレード (スタンバイ再初期設定なし)
この手順は、単一パーティション Db2 バージョン 10.5 フィックスパック 7 以降のデータベースを Db2 バージョン 11.5にアップグレードする際に、高可用性災害時リカバリー (HADR) 環境で使用します。 この手順ではデータベースの役割は維持されます。また、この手順には、HADR 機能の共通の特性である通常のログ・シッピングとログ再生が必要です。 この手順では、アップグレードのために HADR を停止する必要も、HADR を再初期化する必要もありません。 そのため、スタンバイ・データベースが存在しない期間が短縮され、再初期化のためにバックアップ・イメージをスタンバイ・サイトに送信するコストも不要になります。
手順は、 Db2 バージョン 10.5 フィックスパック 7 以降の 1 次データベースがすべてのログ・データをフィックスパック 7 以降のスタンバイ・データベースにシップし、スタンバイ・データベースが受信したすべてのログ・データを再生したかどうかによって異なります。
Db2 バージョン 11.5 スタンバイ・データベースは、以前の Db2 バージョンのログ・データを適用できません。 この手順では、db2iupgrade の処理中に実行される db2ckupgrade によって、または、データベースへの排他接続を確立して正確なデータベース整合性検査を実施する db2ckupgrade を呼び出して、この制限を適用します。
この手順は、単一スタンバイ構成または複数スタンバイ構成を使用する単一パーティション環境の HADR データベースに適用できます。
始める前に
- HADR のシステム要件を確認します。 詳しくは、 Db2 高可用性災害時リカバリー (HADR) のシステム要件を参照してください。
- 2 つの HADR データベース (データベース A とデータベース B) を以下のようにセットアップしている場合は、アップグレード時に両方の 1 次データベースを同じシステムに置くために、一方のデータベースで役割の切り替えを実行します。
- データベース A は 1 次をシステム 1 で実行し、スタンバイをシステム 2 で実行する
- データベース B は 1 次をシステム 2 で実行し、スタンバイをシステム 1 で実行する
- Db2 インスタンスと Db2 データベースのアップグレードに関連した手順を十分に理解しておきます。
- 高可用性災害時リカバリー (HADR) モニターを使用して、 db2ckupgradeを実行する前に、1 次側のログ・シッピング機能とスタンバイ側のログ再生機能の両方が正しく機能していることを確認してください。
- スタンバイの読み取り機能を使用している場合は、1 次データベースのデータベース構成パラメーター logindexbuild をオンにして、アップグレード中に実行される索引再作成を再生用にスタンバイ・データベースに送信するようにします。 これにより、アップグレード後にスタンバイ・データベースで読み取り接続を再開できます。
- HADR アップグレード手順中に障害が発生した場合は、 HADR 環境での Db2 サーバーのアップグレード中の障害の処理 (スタンバイ再初期設定なし)について十分に理解しておく必要があります。
- どのような場合でも、Db2 アップグレード、ハードウェア・アップグレード、ソフトウェア・アップグレードを実動システムに適用する前に、まずはテスト環境で実施するようにします。
このタスクについて
このアップグレード・タスクでは、単一パーティションの単一スタンバイ環境の HADR データベースを 10.5 フィックスパック 7 以降から Db2 バージョン 11.5 にアップグレードする手順について説明します。 1 次データベースとスタンバイ・データベースの両方で Db2 の同じレベルのフィックスパックを使用するようにしてください。
重要: db2iupgrade コマンドを実行してサーバーをアップグレードするたびに、必ず db2licm -a < license file> コマンドを実行して Db2 ライセンスを再適用してフォローアップしてください。
の制約事項
プロシージャー
HADR 環境のデータベースを Db2 バージョン 11.5にアップグレードするには、以下のようにします。
- 1 次インスタンスで、 db2pd -hadr または MON_GET_HADR コマンドを使用してデータベースをモニターし、1 次ログ・シッピングおよびスタンバイ・ログ適用が遅れていないこと、および正しく機能していることを確認します。 HADR データベースをモニターすることで、アップグレード・プロセスが失敗する可能性を低くすることができます。 また、遅延時間が長くならないように、スタンバイの再生遅延をオフにしてください。
- データベース構成パラメーター hadr_replay_delay を 0 に設定して、スタンバイ・ログの適用位置が妥当な時間内に 1 次にキャッチアップできるようにすることで、すべてのスタンバイ・データベースで適用遅延がオフになっていることを確認します。
- 1 次インスタンスで、 DEACTIVATE DATABASE コマンドを使用してデータベースを非アクティブ化し、1 次データベースでログ・シッピングが完了し、データがスタンバイ・データベースに転送されるようにします。
- 1 次インスタンスで、 db2stop コマンドを使用して Db2 インスタンスを停止します。 確実にアプリケーションが接続しない状態にすることで、新しいログ・データが生成されず、スタンバイ・データベースのログ再生の位置が最終的に 1 次データベースのログ・シッピングの位置と一致するようにします。
- 1 次インスタンスで、 db2iupgrade コマンドを使用して Db2 インスタンスをアップグレードします。 db2iupgrade コマンドは、db2ckupgrade コマンドを呼び出して、データベースがアップグレード可能かどうかを検査します。 db2ckupgrade コマンドがエラーを報告する場合、db2iupgrade は実行されません。 何らかのエラーが発生した場合、ログ・ファイルを検査してください。 10.5 フィックスパック 7 以降の HADR 1 次データベースの場合、 db2ckupgrade コマンドは、有効なスタンバイ・データベースが 1 次データベースに接続できることを検証します。 接続が確立されると、ログ・シッピング機能が開始され、必要に応じて、ペンディング状態のログ・データが送信されます。 db2ckupgrade コマンドは、1 次データベースのログ・シッピング位置がスタンバイ・データベースのログ適用位置と一致するかどうかも検査します。
- スタンバイ・インスタンスで、 DEACTIVATE DATABASE を使用してデータベースを非アクティブ化し、1 次データベースでログ・シッピングが完了し、データがスタンバイ・データベースに転送されるようにします。
- スタンバイ・インスタンスで、 db2stop コマンドを使用して Db2 インスタンスを停止します。
- スタンバイ・インスタンスで、 db2iupgrade コマンドを使用して Db2 インスタンスをアップグレードします。 db2iupgrade コマンドは db2ckupgrade コマンドを呼び出して、スタンバイ・データベースのアップグレードの準備ができていることを確認します。
- スタンバイ・インスタンスで、 UPGRADE DATABASE コマンドを発行します。 このコマンドにより、データベースのメタデータ・オブジェクトがアップグレードされ、前の手順でログの検証が成功していれば、プリンシパル・スタンバイが始動して 1 次からの接続を待機する状態になります。 再生機能の処理がバックグラウンドで始まり、1 次からアップグレード・ログ・データが送信されるのを待ちます。 この時点で、スタンバイはアップグレード進行中と見なされ、UPGRADE DATABASE コマンドから SQL1103W が返されます。 このアップグレード進行中の状態では、ユーザー接続はできません。 スタンバイ・データベースでの進行状況は、db2pd -hadr と Db2 の診断ログでモニターできます。 接続を試みることもできますが、スタンバイがアップグレード進行中の状態である限り、SQL1776N と理由コード 9 を受け取ることになります。
- 1 次インスタンスで、 UPGRADE DATABASE コマンドを発行して 1 次データベースをアップグレードします。 このコマンドは、すべてのデータベース・メタデータ・ファイル (データベース構成ファイル、表スペース定義ファイル、ログ・ヘッダー制御ファイル、ストレージ・グループ・ファイルなど) をアップグレードします。 それらのメタデータ・ファイルのアップグレードが完了すると、1 次データベースが HADR のタイムアウト時間内にスタンバイ・データベースに接続しようとします。 接続が確立されると、アップグレード処理が開始され、ログ・データがスタンバイ・データベースに送信されて再生されます。
- 1 次インスタンスで、 ACTIVATE DATABASE コマンドを発行して、新しいバージョンの Db2 でデータベースの使用を開始します。