Azure Database for MySQL でのメジャー バージョンのアップグレード - フレキシブル サーバー

適用対象: Azure Database for MySQL - フレキシブル サーバー

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

前提条件

• レプリケーションが異なる MySQL バージョン間で互換性を持つよう、プライマリ サーバーの前に、MySQL バージョン 5.7 の読み取りレプリカをアップグレードする必要があります。詳しくは、「MySQL のバージョン間でのレプリケーションの互換性」をご覧ください。
• 運用サーバーをアップグレードする前に、Azure portal の組み込みの検証機能を使うと、いっそう簡単で効率的になります。 このツールでは、データベース スキーマの MySQL 8.0 との互換性が事前にチェックされて、潜在的な問題が明示されます。 この便利なオプションが用意されてはいますが、Oracle 公式の MySQL アップグレード チェッカー ツールを使って、データベース スキーマの互換性をテストし、必要な回帰テストを実行して、MySQL の新しいバージョンで削除または非推奨化された機能とのアプリケーションの互換性を確認することも強くお勧めします。

  Note

  Oracle の公式ツールを使用してスキーマの互換性を確認すると、ストアド プロシージャで予期しないトークンを示す次のような警告が表示されることがあります。mysql.az_replication_change_master - at line 3,4255: unexpected token 'REPLICATION'mysql.az_add_action_history - PROCEDURE uses obsolete NO_AUTO_CREATE_USER sql_mode これらの警告は、無視してもかまいません。 これらは、Azure MySQL 機能のサポートに使用される、mysql. で始まる組み込みのストアド プロシージャを参照しています。 これらの警告は、データベースの機能には影響しません。

• 運用サーバーでメジャー バージョンのアップグレードを行う前に、オンデマンド バックアップをトリガーします。これは、オンデマンドで作成された完全バックアップからバージョン 5.7 にロールバックするために使用できます。
• 進行中の XA トランザクションによってアップグレード プロセスが失敗する可能性があるため、メジャー バージョンのアップグレードに進む前に、データベースにアクティブまたは保留中の XA トランザクションがないことを確かめてください。 この問題を回避するには、まず、XA RECOVER; を実行して、"準備済み" 状態の XA トランザクションを確認します。 特定されたトランザクションの場合は、XA ROLLBACK '{xid}' を使用して、各トランザクションをロールバックします。{xid} はトランザクション ID に置き換えます。 トランザクションの整合性を維持し、アップグレード エラーのリスクを軽減するために、アップグレードを開始する前に、すべての XA トランザクションがコミットまたはロールバックされていることを確かめてください。

Azure portal を使用して、バースト可能 SKU サーバーに対する MySQL 5.7 から MySQL 8.0 へのメジャー バージョンの計画的アップグレードを実行する

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

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

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

   重要

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

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

   重要

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

   

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

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

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

   アップグレードに進む前に、アップグレード先のコンピューティング レベルを選択してからメジャー バージョンのアップグレードを実行する必要があります。 既定では、システムはバースト可能 SKU から最も基本的な General Purpose SKU にアップグレードされますが、必要に応じて、より高いコンピューティング レベルにアップグレードすることもできます。

   Note

   アップグレード中にサーバーが "General Purpose" レベルで動作している間は、この期間中に使用された実際の "General Purpose" リソースに対してのみ課金されます。

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

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

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

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

   コンピューティング レベルがアップグレードされると、システムはメジャー バージョンのアップグレード プロセスを開始します。 Azure portal を使用してアップグレードの進行状況を監視します。 データベースのサイズとアクティビティによっては、アップグレード プロセスに時間がかかる場合があります。

   Note

   メジャー バージョンのアップグレードが失敗した場合、コンピューティング レベルは前のバースト可能 SKU に自動的には戻りません。 これは、お客様がコンピューティング レベルのアップグレードを再度実行しなくてもメジャー バージョンのアップグレードを続行できるようにするためです。

7. 自動復帰

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

   Note

   バースト可能 SKU に自動的に戻すことを選択した場合、システムは既定で B2S SKU に戻ります。

Azure portal を使用して、General Purpose と Business Critical SKU サーバーに対する MySQL 5.7 から MySQL 8.0 へのメジャー バージョンの計画的アップグレードを実行する

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

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

   重要

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

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

   重要

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

   

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

   アップグレードを続ける前に、[検証] ボタンをクリックして、お使いのサーバーと MySQL 8.0 の互換性を確認します。

   

   重要

   "検証" 機能を使ってデータベース スキーマの MySQL 8.0 との互換性を調べるときは、スキーマ全体を正確に評価するため、テーブルがロックされれることに注意してください。 このプロセスにより、クエリがタイムアウトする可能性があります。 そのため、ピーク営業時間中、またはデータベースでトラフィックが多いときは、検証を実行しないことをお勧めします。 アクティビティが少ない時間帯を選んで検証を行うと、操作への影響を最小限に抑えることができます。

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

   

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

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

   

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

Azure CLI を使用して MySQL 5.7 から MySQL 8.0 へのメジャー バージョンの計画的アップグレードを実行する

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

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 8
   

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

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

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

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

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

3. [アップグレード] セクションで [アップグレード] を選んで、Azure Database for MySQL フレキシブル サーバー 5.7 の読み取りレプリカ サーバーを 8.0 にアップグレードします。

   アップグレードが成功したことを確認する通知が表示されます。

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

5. ここで、プライマリ サーバーにアクセスし、そこでメジャー バージョンのアップグレードを実行します。

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

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

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

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

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

4. レプリカ サーバーがバージョン 8.0 で実行されていることを確認した後で、アプリケーションからプライマリ サーバーへの接続を停止します。

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 の値が **** であることを確認した後は、レプリケーションを安全に停止することができます。

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

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

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

よく寄せられる質問

• これによってサーバーのダウンタイムは発生しますか? その場合、長さはどのくらいですか?

  アップグレードの間のダウンタイムを最小限にするには、「読み取りレプリカを使用して、MySQL 5.7 から MySQL 8.0 へのメジャー バージョンのアップグレードを最小限のダウンタイムで実行する」で説明されている手順のようにします。 アップグレード プロセス中はサーバーを使用できなくなるので、この操作は計画メンテナンス期間中に実行することをお勧めします。 推定ダウンタイムは、データベースのサイズ、プロビジョニングされたストレージのサイズ (プロビジョニングされた IOPS)、およびデータベース上のテーブルの数によって異なります。 アップグレード時間は、サーバー上のテーブルの数に直接比例します。 サーバー環境のダウンタイムを推定するために、最初にサーバーの復元済みコピーにアップグレードを実行することをお勧めします。

• アップグレード後にバックアップはどうなりますか?

  メジャー バージョンのアップグレード前に作成されたすべてのバックアップ (自動とオンデマンド) を復元に使うと、常に古いバージョン (5.7) のサーバーに復元されます。 メジャー バージョンのアップグレード後に作成されたすべてのバックアップ (自動とオンデマンド) では、アップグレードされたバージョン (8.0) のサーバーに復元されます。 簡単にロールバックできるよう、メジャー バージョンのアップグレードを実行する前に、オンデマンド バックアップを実行することを強くお勧めします。

• 現在、バースト可能 SKU を使用しています。Microsoft は今後、この SKU でメジャー バージョンのアップグレードをサポートする予定ですか?

  バースト可能 SKU は、この SKU のパフォーマンス制限のため、メジャー バージョンのアップグレードをサポートできません。

  Azure Database for MySQL フレキシブル サーバー インスタンスでメジャー バージョンのアップグレードを実行する必要があり、現在、バースト可能 SKU を使っている場合、一時的な解決策の 1 つは、General Purpose または Business Critical SKU にアップグレードし、アップグレードを実行してから、バースト可能 SKU に戻す方法です。

  より高い SKU にアップグレードすると、価格が変更され、デプロイのコストが増加する可能性があることに注意してください。 ただし、アップグレード プロセスに長い時間はかからないと思われるため、コストが大幅に増えることはないはずです。

次のステップ

• Azure Database for MySQL フレキシブル サーバー インスタンスの予定メンテナンスを構成する方法について詳しく理解します。
• MySQL バージョン 8.0 の新機能について学習する。