Azure Database for MySQL でのメジャー バージョンのアップグレード

この記事では、Azure Database for MySQL フレキシブル サーバーで MySQL メジャー バージョンをアップグレードする方法について説明します。 この機能を使用すると、データを移動したり、アプリケーション接続文字列を変更したりすることなく、メジャー バージョンのアップグレード (たとえば、MySQL 5.7 から 8.0 または 8.0 から 8.4) を実行できます。

前提条件

• 古い MySQL バージョンの読み取りレプリカは、レプリケーションが異なる MySQL バージョン間で互換性を持つプライマリ サーバーの前にアップグレードする必要があります。 詳細については、 MySQL バージョン間のレプリケーションの互換性に関する記事を参照してください。
• 運用サーバーをアップグレードする前に、Azure portal の組み込みの検証機能を使うと、いっそう簡単で効率的になります。 このツールは、データベース スキーマとターゲット MySQL バージョンとの互換性を事前にチェックし、潜在的な問題を強調します。 この便利なオプションを提供しますが、公式の Oracle MySQL アップグレード チェッカー ツールを使用してデータベース スキーマの互換性をテストし、必要な回帰テストを実行して、新しい MySQL バージョンで削除/定義されている機能とのアプリケーションの互換性を確認することを強くお勧めします。
• 運用サーバーでメジャー バージョンのアップグレードを実行する前に、 オンデマンド バックアップ をトリガーします。 アップグレード前に作成されたバックアップは、完全なオンデマンド バックアップから 以前のバージョンにロールバック するために使用できます。
• 進行中の XA トランザクションによってアップグレード プロセスが失敗する可能性があるため、メジャー バージョンのアップグレードに進む前に、データベースにアクティブまたは保留中の XA トランザクションがないことを確かめてください。 まず、この問題を回避するには、 XA RECOVER;を実行して、"準備済み" 状態の XA トランザクションを確認します。 特定されたトランザクションの場合は、 XA ROLLBACK '{xid}'; を使用して各トランザクションをロールバックし、{xid} をトランザクション ID に置き換えます。 トランザクションの整合性を維持し、アップグレード エラーのリスクを軽減するために、アップグレードを開始する前に、すべての XA トランザクションがコミットまたはロールバックされていることを確かめてください。

バースト可能 SKU サーバー用の Azure portal を使用して、計画されたメジャー バージョンのアップグレードを実行する

Azure Database for MySQL バースト可能 SKU コンピューティング レベルのメジャー バージョン アップグレードを実行するには、特化したワークフローが必要です。 メジャー バージョンのアップグレードはリソースを大量に消費し、CPU とメモリが大幅に要求されます。 バースト可能な SKU インスタンスは、クレジットベースで、これらの要件の下で苦労し、アップグレード プロセスが失敗する可能性があります。 そのため、バースト可能な SKU をアップグレードする場合、システムは最初にコンピューティング レベルを General-Purpose SKU にアップグレードして、アップグレードに十分なリソースを確保します。

Azure Database for MySQL バースト可能 SKU コンピューティング レベルのメジャー バージョン アップグレードを実行するには、次の手順に従います。

1. Azure portal で、既存の Azure Database for MySQL フレキシブル サーバー インスタンスを選びます。

   重要

   運用環境を直接アップグレードするのではなく、復元されたサーバー コピーで最初にアップグレードを実行することをお勧めします。 ポイントインタイム リストアを実行する方法を参照してください。

2. [概要] ページのツール バーで、[アップグレード] を選択します。

   重要

   アップグレードする前に、ターゲット MySQL バージョンで 削除された機能 の一覧のリンクを参照してください。 デプロイエラーを回避するために、Azure portal の [サーバー パラメーター] ブレードを使用して、非推奨の sql_mode 値を確認し、現在の Azure Database for MySQL フレキシブル サーバーから削除または選択解除します。 mySQL 8.0 以降では、NO_AUTO_CREATE_USER、NO_FIELD_OPTIONS、NO_KEY_OPTIONS、NO_TABLE_OPTIONSの値を使用したsql_modeはサポートされなくなりました。

   

3. スキーマ互換性の検証

   アップグレードを続行する前に、Oracle の公式 MySQL アップグレード チェッカー ツール を実行して、現在のデータベース スキーマがターゲット MySQL バージョンと互換性があることを検証します。 この手順は、スムーズなアップグレード プロセスを確保するために重要です。

4. アップグレード前の決定

   アップグレードする前に、アップグレードするコンピューティング レベルを選択してメジャー バージョンのアップグレードを実行する必要があります。 既定では、システムは Burstable SKU から最も基本的な General Purpose SKU にアップグレードしますが、必要に応じてより高いコンピューティング レベルにアップグレードできます。 アップグレード中にサーバーが "General Purpose" レベルで動作している間は、この期間中に使用された実際の "General Purpose" リソースに対してのみ課金されることに注意してください。

5. アップグレード後の決定

   アップグレード後に、General Purpose SKU を保持するか、バースト可能 SKU に戻すかを決定します。 この選択は、最初のアップグレード手順中に求められます。

   システムは、メジャー バージョンのアップグレードをサポートするために、コンピューティング レベルを Burstable SKU から選択した General Purpose SKU に自動的にアップグレードします。

6. メジャー バージョンのアップグレード

   コンピューティング レベルがアップグレードされると、システムはメジャー バージョンのアップグレード プロセスを開始します。 Azure portal を使用してアップグレードの進行状況を監視します。 データベースのサイズとアクティビティによっては、アップグレード プロセスに時間がかかる場合があります。 メジャー バージョンのアップグレードに失敗した場合、コンピューティング レベルは以前の Burstable SKU に自動的に戻りません。 これにより、お客様は、コンピューティング レベルのアップグレードを再度実行せずにメジャー バージョンのアップグレードを続行できます。

7. 自動復帰

   アップグレード前の決定に基づいて、システムは General Purpose SKU を保持するか、アップグレード後に自動的に Burstable SKU に戻ります。 バースト可能 SKU に自動的に戻す場合、システムは既定で B2S SKU に戻ります。

汎用およびビジネスクリティカルな SKU サーバー用の Azure portal を使用して、計画的なメジャー バージョンのアップグレードを実行する

Azure portal を使用して Azure Database for MySQL フレキシブル サーバーのメジャー バージョンアップグレードを実行するには、次の手順に従います。

1. Azure portal で、既存の Azure Database for MySQL フレキシブル サーバー インスタンスを選びます。

   重要

   運用環境を直接アップグレードするのではなく、復元されたサーバー コピーで最初にアップグレードを実行することをお勧めします。 ポイントインタイム リストアを実行する方法を参照してください。

2. [概要] ページのツール バーで、[アップグレード] を選択します。

   重要

   アップグレードする前に、ターゲット MySQL バージョンで 削除された機能 の一覧のリンクを参照してください。 デプロイエラーを回避するために、Azure portal の [サーバー パラメーター] ブレードを使用して、非推奨の sql_mode 値を確認し、現在の Azure Database for MySQL フレキシブル サーバーから削除または選択解除します。 mySQL 8.0 以降では、NO_AUTO_CREATE_USER、NO_FIELD_OPTIONS、NO_KEY_OPTIONS、NO_TABLE_OPTIONSの値を使用したsql_modeはサポートされなくなりました。

   

3. アップグレード前の検証を実行する

   アップグレードを続行する前に、[ 検証 ] ボタンを選択して、対象の MySQL バージョンとのサーバーの互換性を確認します。

   

   注

   'Validate' 機能を使用して、対象の MySQL バージョンとの互換性のためにデータベース スキーマを評価する場合は、次の考慮事項に注意してください。

   • 検証中のテーブル ロック: 検証プロセスでは、テーブルをロックしてスキーマ全体を正確に検査します。 これにより、データベースの負荷が高い場合にクエリのタイムアウトが発生する可能性があります。   推奨事項: ピーク営業時間中、またはデータベースが高トラフィックを処理する場合は、検証を実行しないでください。 代わりに、アクティビティの少ない期間中に検証をスケジュールして、操作への影響を減らします。
   • 大きな結果セットが原因でハングする可能性: 特に多くのオブジェクトを含む複雑なデータベースでは、検証結果が大きくなりすぎてオンライン ワークフロー内で処理または表示できない場合があります。 これにより、'Validate' 操作がハングしているように見えたり、無期限に進行中のままになる可能性があります。   推奨事項: この問題が発生した場合は、Oracle の公式のクライアント側アップグレード チェッカー ツール (MySQL シェルに含まれているツールなど) を使用してローカルで検証を実行することをお勧めします。 この方法では、プラットフォーム側の結果サイズの制限を回避し、より詳細で信頼性の高い検証出力を提供します。
   • オンライン検証の推奨されるユース ケース: オンラインの "検証" 機能は、単純または中程度に複雑なスキーマ用に設計されています。 多数のテーブル、ビュー、ルーチン、その他のスキーマ オブジェクトを含む大規模な運用環境では、Oracle のクライアント側アップグレード チェッカー ツールを使用して互換性チェックを実行することを強くお勧めします。 これにより、スキーマ全体が包括的に分析され、結果のサイズや検証のタイムアウトに関連する潜在的な問題を回避できます。

4. [アップグレード] サイドバーの [アップグレードする MySQL バージョン] テキスト ボックスで、アップグレード先のメジャー MySQL バージョン (8.0 や 8.4 など) を確認します。

   

   プライマリ サーバーをアップグレードする前に、関連付けられているすべての読み取りレプリカ サーバーをアップグレードする必要があります。 これが完了するまで、 アップグレード は無効になります。

5. プライマリ サーバーで、確認メッセージを選択して、すべてのレプリカ サーバーがアップグレードされていることを確認し、[アップグレード] を選択します。

   

   読 み取りレプリカとスタンドアロン サーバーでは、アップグレードが既定で有効になっています。

Azure CLI を使用して計画メジャー バージョンのアップグレードを実行する

Azure CLI を使用して Azure Database for MySQL フレキシブル サーバーのメジャー バージョンアップグレードを実行するには、次の手順を実行します。

1. Azure CLI for Windows をインストールするか、Azure Cloud Shell で Azure CLI を使用してアップグレード コマンドを実行します。

   このアップグレードには、Azure CLI バージョン 2.40.0 以降が必要です。 Azure Cloud Shell を使用している場合は、最新バージョンが既にインストールされています。 az version を実行し、インストールされているバージョンおよび依存ライブラリを検索します。 最新バージョンにアップグレードするには、az upgrade を実行します。

2. サインインした後、 az MySQL server upgrade コマンドを実行します。

   az mysql flexible-server upgrade --name {your mysql server name} --resource-group {your resource group} --subscription {your subscription id} --version {target major version}
   

   {target major version}をアップグレードするバージョン (8 や 8.4 など) に置き換えます。

3. 確認プロンプトで、「y」と入力して確認するか、「n」と入力してアップグレード プロセスを停止し、Enter キーを押します。

Azure portal を使用して読み取りレプリカ サーバーでメジャー バージョンのアップグレードを実行する

Azure portal を使用して Azure Database for MySQL フレキシブル サーバーの読み取りレプリカ サーバーのメジャー バージョンアップグレードを実行するには、次の手順を実行します。

1. 既存の Azure Database for MySQL フレキシブル サーバーを選択し、Azure portal でレプリカ サーバーを読み取ります。

2. [概要] ページのツール バーで、[アップグレード] を選択します。

   重要

   アップグレードする前に、ターゲット MySQL バージョンで 削除された機能 の一覧のリンクを参照してください。 デプロイエラーを回避するために、Azure portal の [サーバー パラメーター] ブレードを使用して、非推奨の sql_mode 値を確認し、現在の Azure Database for MySQL フレキシブル サーバーから削除または選択解除します。

3. [ アップグレード ] セクションで、[ アップグレード ] を選択して、Azure Database for MySQL フレキシブル サーバーの読み取りレプリカ サーバーをターゲット メジャー バージョンにアップグレードします。アップグレードが成功したことを確認する通知が表示されます。

4. [ 概要 ] ページで、Azure Database for MySQL フレキシブル サーバーの読み取りレプリカ サーバーがターゲット バージョンを実行していることを確認します。

5. プライマリ サーバーに移動し、メジャー バージョンのアップグレードを実行します。

読み取りレプリカを使用してメジャー バージョンのアップグレードを最小限のダウンタイムで実行する

読み取りレプリカ サーバーを使用してダウンタイムを最小限に抑えて Azure Database for MySQL フレキシブル サーバーのメジャー バージョンアップグレードを実行するには、次の手順を実行します。

1. Azure portal で既存の Azure Database for MySQL フレキシブル サーバー インスタンスを選択します。

2. プライマリ サーバーから読み取りレプリカを作成します。

3. 読み取りレプリカをターゲット メジャー バージョンにアップグレードします。

4. レプリカ サーバーがターゲット バージョンを実行していることを確認したら、アプリケーションがプライマリ サーバーに接続するのを停止します。

5. レプリケーションの状態を確認して、レプリカがプライマリに追い付いたので、すべてのデータが同期され、プライマリに対して新しい操作が実行されていないことを確認します。

6. レプリカ サーバーで show replica status コマンドを使ってレプリケーションの状態を表示して確認します。

   SHOW SLAVE STATUS\G
   

   Slave_IO_RunningとSlave_SQL_Runningの状態が yes で、Seconds_Behind_Masterの値が 0 の場合、レプリケーションは適切に機能します。 Seconds_Behind_Master は、レプリカの遅延を示します。 値が 0 ではない場合、レプリカで引き続き更新が処理されています。 Seconds_Behind_Masterの値が 0 であることを確認したら、レプリケーションを停止しても安全です。

7. レプリケーションを停止して、読み取りレプリカをプライマリに昇格します。

8. 昇格されたプライマリに対する書き込みを開始するには、サーバー パラメーター read_onlyを 0 (OFF) に設定します。

9. ターゲット バージョンを実行している新しいプライマリ (以前のレプリカ) にアプリケーションをポイントします。 各サーバーには一意の接続文字列があります。 ソースではなく、(以前の) レプリカを指すようにアプリケーションを更新します。

   注

   このシナリオでは、ステップ 4 から 7 の間にのみダウンタイムが発生します。

関連するコンテンツ

• よく寄せられる質問をアップグレードする方法
• スケジュールされたメンテナンスを構成する方法
• MySQL バージョン 8.0