第 1 世代のインスタンスを第 2 世代にアップグレードする

このページでは、第 1 世代の MySQL インスタンスを第 2 世代にアップグレードする方法について説明します。

概要

Cloud SQL の第 2 世代には第 1 世代よりも大きなメリットがあります。インスタンスが対応していれば、Cloud SQL の第 1 世代インスタンスから第 2 世代のインスタンスにインプレースでアップグレードできます。第 1 世代のインスタンスが対応している場合、Console のインスタンスの一覧ページ、または [インスタンスの詳細] ページで、名前の横に [アップグレード] ボタンが表示されます。

アップグレード プロセスは、インスタンスとアプリケーションへの影響を最小限に抑えるように設計されています。たとえば、アップグレードでカットオーバーのタイミングを制御し、インスタンスの IPv4 アドレスを維持できるので、アプリケーションをすぐに変更する必要はありません。ただし、Cloud SQL 第 2 世代のインスタンスでサポートされる機能は第 1 世代とは異なるため、インスタンスやアプリケーションになんらかの変更が必要になることがあります。

始める前に

インスタンスのアップグレードに進む前に、プロセス全体を理解し、アップグレードによってインスタンスとアプリケーションがどのような影響を受けるかを理解しておく必要があります。

事前構成の要件

第 2 世代にアップグレードする前に必要な手順は、現在のインスタンス構成とクライアントの接続方法によって異なります。

第 1 世代インスタンスの状態 必要な手順 詳細
MySQL 5.5 を使用している MySQL 5.5 と 5.6 の相違点の一覧を確認し、必要な手順を実行してください。アップグレード後、インスタンスは MySQL 5.6 を使用するようになります。 MySQL 5.6 へのアップグレードに影響を与える変更点をご覧ください。
MEMORY ストレージ エンジンを使用するテーブルがある アップグレード プロセスを開始する前に、MEMORY ストレージ エンジンを使用するテーブルをすべて削除します。これらのテーブルのデータがアプリケーションで必要な場合は、InnoDB ストレージ エンジンを使用する新しいテーブルに移動する必要があります。

これらのテーブルは、次の SQL コマンドを使用して見つけることができます。


SELECT table_schema, table_name, table_type
   FROM information_schema.tables
   WHERE engine = 'MEMORY' AND
   table_schema NOT IN
   ('mysql','information_schema','performance_schema');

Cloud SQL のアップグレード前の構成チェックで、これらのテーブルはハイライト表示されます。

performance_schema データベースに、PERFORMANCE_SCHEMA ストレージ エンジンを使用しないテーブルがある アップグレード プロセスを開始する前に、PERFORMANCE_SCHEMA ストレージ エンジンを使用しないテーブルを performance_schema データベースから削除します。

これらのテーブルは、次の SQL コマンドを使用して見つけることができます。


SELECT table_name
   FROM information_schema.tables
   WHERE table_schema='performance_schema'
   AND engine != 'performance_schema';

Cloud SQL のアップグレード前の構成チェックで、これらのテーブルはハイライト表示されます。

slow_query_log または general_log テーブルにデータがある これらのテーブルを切り詰めます。

これらのテーブルのデータは、第 2 世代のインスタンスに移行されません。これらのテーブルに大量のデータがある場合、切り替え中に長いダウンタイム(場合によっては数時間程度)が発生する可能性があります。

Cloud SQL で log_output フラグを FILE に設定することをおすすめします。これにより、ロゴの出力が Google Cloud Platform Console ログビューアに送信されます。詳細については、こちらをご覧ください。

アプリケーションの状態 注意点 詳細
IPv6 を使用して接続しているが、インスタンスに IPv4 アドレスが割り当てられていない アプリケーションのダウンタイムを長くするか、アプリケーションの更新で追加の作業を行うかどうかを決めます。

切り替え中に数分のダウンタイムが許容される場合は、アップグレード後に新しいパブリック(プライマリ)IPv4 アドレスが使用可能になってからアプリケーションの更新を行います。

アプリケーションのダウンタイムを最小限に抑える必要がある場合(カットオーバーでは必ずある程度のダウンタイムが発生する)は、アップグレードを開始する前に第 1 世代のインスタンスに IPv4 アドレスを追加し、このアドレスを使用するようにアプリケーションを更新します。この IPv4 アドレスは、アップグレード後の第 2 世代のインスタンスで維持され、移行された第 1 世代の IP アドレスとして表示されます。ただし、移行された IP アドレスは今後非推奨となる予定のため、新しい(パブリック)IPv4 アドレスを使用するようにアプリケーションの更新が再度必要になります。

GTID 対応でないコードが含まれている アプリケーションを更新して、サポートされていないステートメントを削除する必要があります。 これらの変更は、必要に応じてアップグレード後に行うことができます。ただし、その場合はアップグレード後にバイナリ ロギングを無効にする必要があります。最良の結果を得るには、アップグレード前に変更を行ってください。
Apps Script を使用し、オリジナルの jdbc パス(jdbc:google:rdbms//)を使用して接続している サポートされている接続パスを使用するようにアプリケーションを更新する必要があります。 JDBC をご覧ください。

事前構成の推奨事項

以下の手順は必須ではありませんが、アップグレード プロセスの簡素化や短縮に役立ちます。

第 1 世代インスタンスの状態 検討事項 詳細
本番環境アプリケーションをサポートしている インスタンスのクローンを作成し、クローン上でアップグレード プロセスを実行します。このプロセスには、アップグレードされたクローン上でのアプリケーションのテストなども含まれます。

クローン上でアップグレード プロセスをテストすることによって、本番環境でアップグレードを実行する前に、インスタンスやアプリケーションに対してどのような変更が必要かを判断できます。

インスタンスのクローン作成の詳細については、インスタンスのクローンを作成するをご覧ください。

自動バックアップまたはバイナリ ロギングが有効になっていない これらの両方の設定を有効にします。 アップグレード プロセス中にこの手順を実行することもできます。この設定変更を行う場合、インスタンスの再起動が必要になります。

第 2 世代の構成と管理

第 2 世代のインスタンスの管理要件は、第 1 世代のインスタンスとは異なります。第 1 世代と第 2 世代の違いのリストを確認し、それらの違いが Cloud SQL の管理にどのような影響を与えるかを理解しておく必要があります。

第 2 世代のインスタンスでは、ストレージの自動増加メンテナンスの時間枠の構成オンデマンド バックアップなどの追加の構成オプションも使用できます。詳細については、第 2 世代インスタンスの設定をご覧ください。

ストレージの要件と料金

第 2 世代のインスタンスでは、システムで使用するためにより多くのストレージが確保されます。インスタンスを第 2 世代にアップグレードすると、使用されるストレージ量は約 0.75 GB 増加します。

第 2 世代のストレージ料金は、ストレージの使用量ではなく、ストレージの容量に基づいて計算されます。詳細については、ストレージとネットワークの料金をご覧ください。

マシンタイプ

第 2 世代のマシンタイプは第 1 世代のインスタンス階層とは異なり、料金体系も異なります。第 1 世代のインスタンスは、次の対応表のように第 2 世代のインスタンスにアップグレードされます。アップグレード後の第 2 世代のインスタンスには、少なくとも第 1 世代のインスタンスと同程度のリソースが割り当てられます。必要であれば、アップグレード後に第 2 世代インスタンスのマシンタイプを変更できます。

表にある第 1 世代の料金は「常にオン」パッケージの料金です。

第 1 世代の階層 第 2 世代のマシンタイプ
D0(0.125 CPU、128 MB RAM)
最大接続数: 250
$10.80/月
db-f1-micro(1 個の共有 CPU、0.60 GB RAM)
最大接続数: 250
$10.35/月
D1(0.25 CPU、512 MB RAM)
最大接続数: 250
$43.80/月
db-g1-small(1 個の共有 CPU、1.70 GB RAM)
最大接続数: 1,000
$28.25/月
D2(0.5 CPU、1 GB RAM)
最大接続数: 250
$87.90/月
db-n1-standard-1(1 CPU、3.75 GB RAM)
最大接続数: 4,000
$104.00/月(フェイルオーバー レプリカを含む)
D4(1 CPU、2 GB RAM)
最大接続数: 500
$132.00/月
db-n1-standard-1(1 CPU、3.75 GB RAM)
最大接続数: 4,000
$104.00/月(フェイルオーバー レプリカを含む)
D8(2 CPU、4 GB RAM)
最大接続数: 1,000
$263.40/月
db-n1-standard-2(2 CPU、7.50 GB RAM)
最大接続数: 4,000
$210.00/月(フェイルオーバー レプリカを含む)
D16(4 CPU、8 GB RAM)
最大接続数: 2,000
$527.10/月
db-n1-standard-4(4 CPU、15 GB RAM)
最大接続数: 4,000
$448.00/月(フェイルオーバー レプリカを含む)
D32(8 CPU、16 GB RAM)
最大接続数: 4,000
$1,053.90/月
db-n1-standard-8(8 CPU、30 GB RAM)
最大接続数: 4,000
$996.00/月(フェイルオーバー レプリカを含む)

サンプル構成の料金を含む第 2 世代の料金については、料金ページをご覧ください。

ON_DEMAND アクティベーション ポリシー

第 2 世代インスタンスは、ON_DEMAND アクティベーション ポリシーをサポートしていません。手動でインスタンスを停止できますが、インスタンスを再び開始するまで受信接続リクエストに応答しません。 詳細については、こちらをご覧ください。

MySQL のシステム変数とオプション

MySQL の一部のシステム変数とオプションでは、第 2 世代のインスタンスのデフォルト値が異なります。第 2 世代でサポートされていない値が設定された MySQL 変数がインスタンスにある場合、その値はアップグレード プロセス時に変更されます。これらの変数は構成できません。

次の表に、影響を受ける変数とアップグレード後の値を示します。

システム変数 第 2 世代の値
default_time_zone 形式が UTC からのオフセットに変更されました。
expire_logs_days 0
innodb_log_file_size 512 MB
max_connections マシンタイプの表を参照してください。
sync_binlog 有効

ダウンタイム

以下のように、アップグレード中にアプリケーションのダウンタイムが発生します。

  1. 第 1 世代のインスタンスでバイナリ ロギングが有効になっていない場合は、バイナリ ロギングを有効にするために再起動されます。これはアップグレードを行うために必要です。
  2. 第 1 世代のインスタンスが再起動され、SSL / TLS 証明書がインストールされます。これは、アップグレード時にインスタンスと第 2 世代のレプリカ間の安全なレプリケーションをサポートするためのものです。
  3. 切り替えプロセスを開始し、第 2 世代のインスタンスがプライマリ インスタンスとして動作を開始すると、第 1 世代のインスタンスがリクエストへのレスポンスを停止していながら第 2 世代のインスタンスがまだオンラインになっていない時間が発生します。

    切り替えに必要な時間は、インスタンスとそのレプリカ間のレプリケーション ラグの影響を強く受けます。このため、切り替え前に書き込みオペレーションを減らすか停止することをおすすめします。

App Engine スタンダード環境から接続するアプリケーションに関する考慮事項

サービス アカウント

第 1 世代のインスタンスでは、アプリのプロジェクトを承認することで、App Engine アプリケーションからインスタンスへのアクセスを制御します。この承認はインスタンス単位で行います。

第 2 世代のインスタンスでは、サービス アカウントを使用して App Engine アプリケーションからのアクセスを制御します。このため、アクセスを承認すると、特定のプロジェクトに含まれるすべての Cloud SQL インスタンスに対するアクセスが許可されます。

承認された App Engine プロジェクトを含むインスタンスを第 1 世代から第 2 世代にアップグレードすると、Cloud SQL は特別なサービス アカウントを作成し、この App Engine プロジェクトがアップグレード前に許可されていたものと同じアクセス権を付与します。このサービス アカウントは、プロジェクト全体ではなく特定のインスタンスに対するアクセスのみを許可するため、IAM サービス アカウントのページには表示されません。このアカウントは更新したり、削除したりできません。

接続レイテンシ

通常、第 1 世代のインスタンスと比べると、第 2 世代のインスタンスの接続レイテンシは短くなります。ただし、App Engine スタンダード環境から接続するアプリケーションの場合は、レイテンシが 0.3 ms ほど増加します。

定義済みの MySQL ユーザー アカウントに対する変更

App Engine からの接続に使用される事前定義の MySQL ユーザー アカウントのホスト名は、root@localhost から root@cloudsqlproxy~% に変更されます。

localhost をホストとして使用する他の MySQL ユーザーがある場合も、同様に変更されます。移行処理中に MySQL の grant テーブルと user テーブル内にあるホスト名は自動的に更新されます。通常、この変更を考慮して App Engine アプリを更新する必要はありません。

ただし、使用しているアプリや他のツールが、ユーザー テーブルや権限設定を MySQL 内で直接変更している場合は、アップグレードが完了した後に cloudsqlproxy~% をホストとして使用するように更新する必要があります。アップグレード中にユーザー テーブルや権限設定を変更しないでください。

この変更は、このアカウントを使用した接続のパフォーマンスには影響しません。

rdbms 接続ライブラリ

非推奨の rdbms 接続ライブラリをアプリケーションで使用している場合は、アプリケーションを更新して、サポートされている接続方法を使用する必要があります。rdbms ライブラリは、アップグレード後の第 2 世代インスタンスで機能しません。

アップグレードの実行

準備手順を完了したら、アップグレードを続行できます。

  1. Google Cloud Platform Console で Cloud SQL インスタンス ページに移動します。
    Cloud SQL インスタンス ページに移動
  2. アップグレードするインスタンスを探して、名前の横にある [アップグレード] ボタンをクリックします。
  3. [第 2 世代へのアップグレード] パネルで [構成を確認] をクリックします。
  4. アップグレードを開始する前にインスタンスの更新が必要な場合は、[変更を実行] をクリックし、手順に沿って操作します。
  5. [続行] をクリックしてアップグレード プロセスを開始します。

    元のインスタンスはアクティブのままですが、データはレプリカに複製されます。注: 元のインスタンスとレプリカの両方が存在する間は、両方のインスタンスに対して料金が発生します。追加料金を最小限に抑えるには、このステップが完了したらすぐに新しいインスタンスに切り替えます。

  6. 推奨されるオプション: 第 1 世代のインスタンスのクローンを作成します。

    クローンを使用すると、アップグレードに問題がある場合に現在の状態にロールバックできます。

  7. 推奨されるオプション: レプリカの作成が完了したら、アプリケーションをシャットダウンします。

    これらのアプリケーションは切り替え中にインスタンスにアクセスできなくなります。アプリケーションでトランザクションをオープン状態にしておく必要がある場合は、特に注意が必要です。

  8. レプリカの作成が完了したら、[切り替え] をクリックします。

    これにより、レプリカの昇格が行われ、データ処理が引き継がれます。インスタンスが新しい接続の受け入れを停止し、5〜10 分のダウンタイムが発生します。切り替え処理は、[オペレーション] パネルにフェイルオーバーのオペレーションとして表示されます。

  9. 切り替えが完了したら、[完了] をクリックしてアップグレード プロセスを終了し、アップグレード後の手順に進みます。

アップグレードの確認と完了

次のチェックリストは、アップグレード プロセスが完了した後、すべてが正常に動作しており、第 2 世代のインスタンスが正しく構成されていることを確認するのに役立ちます。

アップグレードをロールバックする必要がある場合は、アップグレードのロールバックをご覧ください。

  • クライアントとアプリケーションが接続され正しく動作していることを確認します。

    第 2 世代のインスタンスでは GTID が有効になります。この変更を正しく処理するためにアプリケーションを更新する必要がある場合は、バイナリ ロギングを一時的に無効にするという方法があります。これにより GTID チェックも無効になります。ただし、バイナリ ロギングを無効にすると、レプリケーションやポイントインタイム リカバリも無効になるため、GTID 対応になるようにアプリケーションを更新し、できるだけ早くバイナリ ロギングを再び有効にする必要があります。

  • 必要に応じて、高可用性向けにインスタンスを構成します

    インスタンスが本番環境用データを処理している場合は、データの耐久性と可用性のためにこの手順を実施することを強くおすすめします。

  • 必要なリードレプリカを再作成します。

    レプリカを再作成するときには、同じレプリカの名前を再利用することはできません。別の名前を選択する必要があります。

  • アップグレード前に作成された IPv6 アドレスまたは IPv4 アドレスがアプリケーションの接続に使用されている場合は、アップグレード中に割り当てられた新しいパブリック(プライマリ)アドレスを使用するようにアプリケーションを更新します。

    アップグレード前に作成された IPv4 アドレスは、移行された第 1 世代の IP アドレスとして表示されます。移行された IP アドレスは今後非推奨となる予定です。

  • 他の接続パスの更新も検討してください。

    アップグレード前に使用したのと同じ接続パスを引き続き使用できますが、いくつかの新しいオプションを利用できます。

  • アプリケーションが次のような第 1 世代インスタンスの接続名を使用して接続している場合:

    <project_id>:<instance_id>

    アプリケーションを更新して、次のような第 2 世代インスタンスの接続名を使用するようにします。

    <project_id>:<region>:<instance_id>

  • データベースに MyISAM テーブル(システム テーブル以外)がある場合は、InnoDB ストレージ エンジンを使用するように変換することを検討してください。

    引き続き既存の MyISAM テーブルを使用できますが、データの耐久性を高めるためにこの変換をおすすめします。詳細については、MyISAM から InnoDB へのテーブルの変換をご覧ください。

アップグレードのロールバック

アップグレードされた第 2 世代のインスタンスで問題が発生した場合は、アップグレード プロセスを開始する前の第 1 世代のインスタンスと同じ状態の新しいインスタンスを作成できます。

  1. アップグレード プロセス中にクローンを作成した場合は、そのクローンを指すようにアプリケーションを更新します。
  2. それ以外の場合は、次の操作を行います。

    1. 元のインスタンスと同じ階層を使用して、新しい第 1 世代のインスタンスを作成します。
    2. アップグレードされたインスタンスの [バックアップ] ページを開き、アップグレード プロセス開始時に取得したバックアップを見つけます。
    3. 作成した新しい第 1 世代のインスタンスに上記のバックアップを復元します。

      詳細については、別のインスタンスへの復元をご覧ください。

次のステップ

このページは役立ちましたか?評価をお願いいたします。

フィードバックを送信...