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

注意事項

バージョンのアップグレードは通常 30 分以内に完了します。アップグレード中に PolarProxy またはデータベースカーネルエンジンが再起動され、一時的な接続中断が発生する可能性があります。オフピーク時間にアップグレードを実行し、アプリケーションに自動再接続メカニズムが備わっていることを確認してください。

説明
PolarDB クラスターを監視するように Cloud Monitor を設定している場合、アップグレード中にクラスターアクセス例外に関する通知を受信する可能性があります。
アップグレード中は、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 秒の一時的な切断が発生します。プライマリエンドポイントは影響を受けません。アプリケーションに再接続メカニズムが備わっていることを確認してください。
- カーネルのみをアップグレード の際、PolarProxy 2.4.7 以降を搭載した PolarDB クラスターは、接続維持機能を使用して、データベース接続の 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 の差をチェックします。この差は、チェックポイントが REDO の書き込みにどれだけ遅れているかを示します。差が大きすぎると、切り替えが追いつくのに時間がかかり、サービスの利用不可時間が長引きます。

LSN のクエリ：

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

SHOW STATUS LIKE '%lsn%';

Innodb_lsn と Innodb_log_checkpoint_lsn の差が、現在の遅延 (バイト単位) です。