PolarDB クラスターのバージョンを表示およびアップグレードする方法 - PolarDB

PolarDB クラスターは、データベースプロキシ (PolarProxy)、データベースカーネルエンジン (DB)、分散ストレージ (Store) の 3 層アーキテクチャを採用しています。PolarProxy またはカーネルエンジンを個別にアップグレードすることも、両方を同時にアップグレードすることもできます。

アップグレード方法

PolarDB for MySQL は、マイナーエンジンバージョンの手動更新と自動更新をサポートしています。

アップグレード方法	説明
手動更新	ビジネス要件に基づいてターゲットバージョンとアップグレード時間を選択し、アップグレードを開始できます。このトピックでは、主に手動アップグレードについて説明します。
自動更新	アップグレード条件が満たされると、システムはマイナーエンジンバージョンの更新タスクをスケジュールします。ルールと設定手順については、「マイナーエンジンバージョンの自動アップグレード」をご参照ください。

注意事項

バージョンのアップグレードは通常 30 分以内に完了します。アップグレード中に PolarProxy またはデータベースカーネルエンジンが再起動され、瞬断が発生する可能性があります。アップグレードはオフピーク時間に実行し、ご利用のアプリケーションに自動再接続メカニズムが実装されていることを確認してください。
説明
Cloud Monitor を設定して PolarDB クラスターを監視している場合、アップグレード中にクラスターのアクセス例外に関する通知を受け取ることがあります。
アップグレード中は、仕様のアップグレードまたはダウングレード、ノードの追加または削除、パラメーターの変更、ノードの再起動など、PolarDB コンソールの一部の変更関連機能は利用できなくなります。ただし、パフォーマンスモニタリングなどのクエリ関連機能は影響を受けません。アップグレード後にバージョンをダウングレードすることはできません。
アップグレードのスイッチオーバー中に長時間のサービス中断を防ぐため、システムはスイッチオーバーの前にプライマリノードの状態をチェックします。プライマリノードに大規模トランザクションや大幅な Redo ログのチェックポイントのバックログがあり、チェックウィンドウ内で繰り返しチェックに失敗した場合、アップグレードは自動的にキャンセルされます。クラスターのバージョンとランタイム状態は変更されず、対応する通知が届きます。解決策については、「アップグレード前チェックの失敗への対応」をご参照ください。

バージョン情報の表示

[PolarDB コンソール] にログインし、左側のナビゲーションウィンドウで クラスター をクリックします。クラスターがデプロイされている [リージョン] を選択し、クラスター ID をクリックしてクラスターの詳細ページに移動します。
左側のナビゲーションウィンドウで、設定と管理 > バージョン管理 を選択します。
マイナーバージョンのアップグレード ページの バージョン情報 セクションで、PolarProxy とデータベースカーネルエンジンのバージョン情報を確認します。

手動アップグレード

クラスターの現在の PolarProxy またはデータベースカーネルエンジンのバージョンが最新でない場合、必要に応じてアップグレードできます。

ターゲットクラスターの 設定と管理 > バージョン管理 メニューに移動し、マイナーバージョンのアップグレード ページの バージョンアップ セクションで、必要に応じて PolarDB データベース Proxy と Kernel のアップグレード、カーネルのみをアップグレード、または PolarDB データベース Proxy のみのアップグレード を選択します。
説明
- クラスターの現在の PolarProxy またはデータベースカーネルのバージョンが最新の場合、PolarDB データベース Proxy と Kernel のアップグレード、カーネルのみをアップグレード、および PolarDB データベース Proxy のみのアップグレード オプションはグレー表示され、利用できなくなります。
- PolarDB データベース Proxy のみのアップグレード を選択した場合、整合性レベル (グローバル整合性)、トランザクション分割、プライマリデータベースが読み取りリクエストを受け入れるかどうかなど、読み書き分離に関連する機能のみがアップグレードされます。
今すぐアップグレード または メンテナンスウィンドウでアップグレード をクリックします。メンテナンスウィンドウでアップグレード を選択した場合、スケジュール済みタスク ページでタスク詳細を表示したり、タスクをキャンセルしたりできます。詳細については、「予約タスク」をご参照ください。
重要
- PolarDB データベース Proxy と Kernel のアップグレード により、プライマリエンドポイントとクラスターエンドポイントの両方で 30～90 秒の瞬断が発生します。アプリケーションに再接続メカニズムがあることを確認してください。
  説明
  上記のインパクトを除き、マイナーバージョンのアップグレードは、残りのプロセスにおいて通常のクラスター使用に影響を与えません。
- PolarDB データベース Proxy のみのアップグレード により、クラスターエンドポイントとカスタムエンドポイントで 30 秒間の瞬断が発生します。プライマリエンドポイントへの接続は影響を受けません。お使いのアプリケーションに再接続メカニズムが備わっていることを確認してください。
- カーネルのみをアップグレード：アップグレード中、PolarDB クラスターでは、バージョン 2.4.7 以降の PolarProxy によって接続維持機能が有効になり、データベース接続の 95% が中断から保護されます。
アップグレードタスクの表示：
- クラスター詳細ページのヘッダーで、右側のタスクアイコンボタンをクリックして、タスク進捗パネルとアップグレードの進捗を表示します。
- クラスター に戻ります。左側のナビゲーションウィンドウで タスク管理 > タスクセンター を選択すると、すべてのクラスターのタスクリストを表示できます。

アップグレード前チェックの失敗への対応

アップグレードのスイッチオーバーの前に、システムはクラスターのプライマリノードに対して以下の 2 つのチェックを実行します。チェックウィンドウ内で繰り返しチェックに失敗した場合、アップグレードは自動的にキャンセルされます。クラスターのバージョンは変更されず、そのランタイム状態はアップグレード前と同じままです。問題を解決した後、再度アップグレードを開始できます。

チェック 1：プライマリノードの大規模トランザクション

システムは、プライマリノード上のすべてのアクティブな未コミットのトランザクションによって変更された行の総数を計算します。

大規模トランザクションの特定：

特権アカウントを使用してプライマリノードに接続し、次のステートメントを実行して確認できます。このビューのクエリには PROCESS 権限が必要です。DMS または DAS のセッション管理でトランザクションを表示することもできます。
```
SELECT SUM(trx_rows_modified) AS sum_trx_rows_modified
FROM information_schema.innodb_trx;
```
NULL の結果は、アクティブなトランザクションが存在しないことを示します。結果が多数の行を変更したトランザクションを示している場合は、次のステートメントを実行して特定のトランザクションを特定します。
```
SELECT trx_id, trx_state, trx_started, trx_mysql_thread_id,
 trx_rows_modified, LEFT(trx_query, 200) AS trx_query
FROM information_schema.innodb_trx
ORDER BY trx_rows_modified DESC
LIMIT 10;
```

解決策：

(推奨。ワークロードへの影響なし) トランザクションが正常にコミットされるのを待ってから、アップグレードを再試行します。
トランザクションを破棄できることを確認した場合は、KILL コマンドを使用して trx_mysql_thread_id に対応するセッションを終了させます。
- KILL QUERY は使用しないでください。これは現在のステートメントのみを終了させます。トランザクションは開いたままでロールバックされないため、チェックは依然として通過できません。
- KILL を実行すると、トランザクションはロールバック (trx_state は ROLLING BACK) に入ります。この期間中、トランザクションは information_schema.innodb_trx に表示され続け、変更された行数は徐々に減少します。クエリ結果から消えるのを待ってから、再度アップグレードを開始してください。

長期的なメンテナンスの推奨事項：

大規模な INSERT ... SELECT、UPDATE、DELETE 操作、およびデータインポートやアーカイブジョブは、小さなバッチに分割してコミットし、アップグレードウィンドウ外でスケジュールしてください。

チェック 2：Redo ログのチェックポイントのバックログ

システムは、プライマリノードに書き込まれた Redo LSN とチェックポイント LSN の差をチェックします。この差は、チェックポイントの進行が書き込みにどれだけ遅れているかを示します。差が大きすぎると、スイッチオーバーが追いつくのに時間がかかり、サービスが利用できない時間が長くなります。

LSN のクエリ：

特権アカウントを使用して、次のステートメントを実行できます。

SHOW STATUS LIKE '%lsn%';

Innodb_lsn と Innodb_log_checkpoint_lsn の差が、現在のバックログ (バイト単位) です。