Database Migration Service を使用して MySQL メジャー バージョンをアップグレード
Google Cloud Japan Team
※この投稿は米国時間 2021 年 8 月 6 日に、Google Cloud blog に投稿されたものの抄訳です。
すでにご存じかもしれませんが、昨年 11 月に Google の Database Migration Service が MySQL 向けに一般提供開始されたため、SQL データベースの移行が簡単になりました。つまり、SQL データベースを Cloud SQL に移行するのが簡単になったということです。また、もうお気づきの方もいらっしゃると思いますが、Database Migration Service を使用すれば、オンプレミス、AWS、Cloud SQL for MySQL など、さまざまなソースから pull できるようにもなります。
話はそれますが、先日発表したように DMS で Cloud SQL for PostgreSQL がソースとしてサポートされるようになったため、DMS を使用して PostgreSQL のメジャー バージョン アップグレードを行えるようにもなりました。ですが、今回の投稿は MySQL に関するものです。
私がこのようなことを言い出したのには訳があります。DMS プロセスの [宛先の作成] ページにこれが表示されることに気づいていただきたかったのです。
この投稿をお読みの皆様に、MySQL データベースのメジャー バージョン アップグレードにも DMS を使えるということをお教えしましょう。もちろん、インプレース アップグレードができるに越したことはありませんが、これが利用可能になるまでの間、DMS が優れた手段になります。
もちろん、注意は必要です。ここで重要なことは、アップグレードに移行ツールを使用するため、対処すべき複雑さには 2 つの側面があるということです。移行に関わるものと、アップグレードに関わるものです。DMS を使用すれば、問題のほとんどに対処できるようになりますが、考慮すべき事項がいくつかあります。この投稿では、Database Migration Service を使用して MySQL のメジャー バージョン アップグレードを行うために検討すべきすべてのことと、実行すべきことをまとめています。
アップグレードの目的
最初に、なぜ MySQL をアップグレードする必要があるかについてお話しします。パフォーマンス アップグレードや機能アップデートが実施されるのには、多くの理由があります。アップグレードの理由を確認したい方は、MySQL 8.0 で強化された機能の一覧をご覧ください。また、5.6 が 2 月に正式に非推奨になったという、表には出ない懸念事項もあります。この 8 年間、5.6 を使用し続けた方もいるでしょうし、その方々にとっては、5.6 の公式サポート終了は少し混乱する出来事でしょう。幸いなことに、Cloud SQL ではもうしばらく 5.6 がサポートされますが、だからと言って今がアップグレードを行うタイミングではないということではありません。
バージョンの互換性
まず、どのバージョンからどのバージョンへのアップグレードかを確認しましょう。5.6 は 5.7 に、5.7 は 8.0 にアップグレードされます。要するに、5.6 から 8.0 です。MySQL のメジャー バージョン間には、互換性を損なう可能性のある大幅な変更があるため、このような互換性のない変更に関して、データベースをよく確認する必要があります。
たとえば、5.6 から 5.7 にアップグレードする場合、5.6 データベースの INFORMATION_SCHEMA テーブルのシステム変数やステータス変数に注意する必要があります。これらはすべて、5.7.6 の Performance Schema テーブルにより置き換えられています。この他にも細かい注意点はいくつかあり、たとえば、YEAR(2) データ型の列がある場合、この列を再度利用するにはこれらの値すべてを 4 桁の YEAR 列にアップデートする必要があります。5.6 から 5.7 へのアップグレードに伴う変更点の一覧は、こちらから確認できます。
もちろん、5.7 から 8.0 へのアップグレードにおいては、さらに多くの注意点があります。私にとって大きな注意点は、この 2 つのバージョン間でデフォルトのフラグが大幅に変更されたことです。ほとんどの場合、セグメンテーション違反で中断の発生はないものの、アプリケーションで予期しない挙動が発生する可能性があります。また、AUTO_INCREMENT 列にも注意する必要があり、これは、FLOAT 型および DOUBLE 型で非推奨となります。この 2 つのバージョン間の変更点の一覧は、こちらをご確認ください。
点と点をつなぐ
Cloud SQL インスタンスから別の Cloud SQL インスタンスへのメジャー バージョン アップグレードを計画している場合は、これから説明する内容はすでに実行されているため、このセクションをスキップできます。しかし、オンプレミス データベースから Cloud SQL に移行する場合や、GCE（仮想マシン）インスタンスから Cloud SQL に移行するというエッジケースの場合、いくつか注意すべきことがあります。
1 つ目はレイテンシについてです。もしもアプリケーションのすぐ近くにあるデータベースからのほぼリアルタイムのレスポンスに慣れているのであれば、少し覚悟してください。アプリケーションもクラウド上に配置しない限り、アプリケーションとデータベースとの間のやり取りに余分に時間がかかることになります。これはまったく問題にならないこともあります。また、デバッグが非常に難しい再入可能性のバグがアプリケーションに導入される可能性もあります。私の同僚が、別のソースから Cloud SQL へのデータベース移行時に注意を要し、変更が必要になる可能性がある事項を網羅した投稿を作成していますので、こちらもぜひご覧ください。
2 つ目は、どのようにデータベースに接続するかに関してです。ネットワークへの接続性は、大きな障害となる可能性があります。ファイアウォール、ルーティング、DNS、これらすべてが作業の支障になる可能性があるのです。これまであらゆる点で問題なく接続されていたデータベースが、（おそらく）インターネット上のまったく異なる場所に、異なる接続要件で突如として配置されることになります。このようなまったく異なる場所への移行については、私がすでに詳細に検討しています。こちらから、Database Migration Service を使用した移行元インスタンスと移行先インスタンスの接続に関して詳しく書いたブログ投稿をご覧いただけます。接続性に関して何か問題が発生した場合には、こちらの投稿でほとんどの状況について解説しているはずです。
さらなる移行
DMS でプロセスのデータ部分の移行を簡単にすることはできますが、データベース エンジンのネイティブ移行メカニズムに依存しているため、その制約を受けることになります。つまり、データベースの移行後、その移行元にかかわらず、行うべきステップがあるということです。たとえば、ご存じのように、移行後には IP アドレスが変更されます。Google はバージョンをアップグレードするのに移行という手段を使っているため、新しいインスタンスを作成することになります。インプレース アップグレードの場合は問題になりませんが、これが利用できるようになるまでの間は、古い IP アドレスを指すアプリケーションやロードバランサなどを更新する必要があります。
また、移行されていないシステム テーブルにユーザーが保存されていることも忘れないでください。DMS による移行作業が完了したら、これらの情報も移行する必要があります。他にも細かいことがいくつかあります。新しいインスタンスを使用可能な状態にするために行う必要がある項目の一覧は、こちらの投稿をご覧ください。
次のステップ
これで、新しくアップグレードされたインスタンスを設定できたので、本番環境で使用する準備を始めることができます。今後必要になるかもしれないものの、Cloud SQL インスタンスが完全にオンラインになるまで設定できないものがいくつかあります。
たとえば、常時 SSL 接続はデフォルトでオフになっていますが、現状として、多くの組織で常時 SSL 接続が使用されています。そのため、常時 SSL 接続をサーバーで有効にする必要があり、また、証明書を設定する必要があります。これは、データの移行後、DMS ターゲット インスタンスがプロモートされる前に行えます。
障害復旧機能も、本番環境インスタンスに必ず実装する必要があります。これも、稼働率を保証する Google の SLA で要求される要件であり、必ず設定しなければなりません。インスタンスを編集すると、メインの概要ページに表示されます。
「マルチゾーン」に設定すると、この機能が有効になります。
また、このカテゴリに分類されるのは、リードレプリカです。データ インフラストラクチャを最適化してアプリケーションをサポートできるようにすることが重要であり、リードレプリカがこれにおいて不可欠な要素になります。読み取りが多いアプリケーションを使用している場合は、作業のこの段階でもリードレプリカを設定することをおすすめします。
高可用性とリードレプリカの設定は、DMS プロセスの最後にインスタンスをプロモートした後でのみ実行できます。
最後に一つだけ。これで、インスタンスを次のバージョンにアップグレードするためのすべての作業が完了しました。必要な設定がすべて完了し、アプリケーションを接続して、データベースとの通信ができるようになりました。ですが、まだ本番環境に移行するボタンを押すタイミングではありません。この投稿をお読みの多くの方にとっては当たり前のことのように思えるでしょうが、それでも言わなければならないことがあります。テストをしてください。ありとあらゆるものをテストしてください。考えうる限りのエッジケースをテストしてください。システムに意図的にレイテンシを追加して、アプリケーションとデータベース間のランダムなインターネット ラグ スパイクを処理できることを確認してください。高可用性機能が利用可能になれば、自動フェイルオーバーをテストすることで、プライマリ インスタンスのダウンからフォールバック インスタンスへの引き継ぎまでの流れをシミュレーションできます。ですから、テストをしてください。あらゆるシナリオをテストして、新しいメジャー バージョンの SQL インスタンスをスムーズに開始できるようにしてください。
Database Migration Service を使用して MySQL インスタンスを新しいバージョンにアップグレードする際に、この投稿が役立つことを願っています。質問やコメントがある場合は、Twitter までご連絡ください。DM はどなたでも送れる設定になっています。最後までお読みいただきありがとうございました。
-デベロッパー アドボケイト Gabe Weiss
