Azure Database for MySQL をいじってみたよ

Azure

こんにちは。

今回は、このサイトで使っている DB をいじったときの忘備録です。

って、書いておいても自分ではわすれちゃうんだろうな~w

 

今回 DB をいじろうと思ったきっかけ

今回、DB をいじってみようと思ったきっかけは、以下の 3 つです。

  • Azure Database for MySQL の Basic を使っていたが、パフォーマンス劣化のアラートが出ていたが、リソースの増強ができない状態であったため。
  • Azure Database for MySQL Flexible Server が素敵そうなので、ちょっと使ってみたかったため。
  • MySQL のバージョンが、5.7 だけど、最新バージョンは 8.0 なのでそろそろマイグレーションを考えてもいいのかなって思ったから。

 

1.パフォーマンス劣化問題

細かいことわすれちゃったし、このブログ書く予定でもなかったので細かな事象は、わすれちゃいました。

WordPress のダッシュボードで、パフォーマンス劣化のアラートがでていて、調べてみると検索時の一次テーブルが狭くなってるから拡大せよってことだったんですよね。

ただ、Azure Daabase for MySQL の Basic だと、この Server Parameter がいじることができなく、SKU を変更が必要だったんです。

 

ただ、もうちょっと考えると、閲覧者は Azure FrontDoor Service 越しにサイトを見ていて、Azure FrontDoor Service でキャッシュを有効にしているので、DB から直接データを表示することは、そこまで多くないはずなので、閲覧側には大きな影響は与えていなかったと思います。

なので、若干放置していましたw

 

ちなみに、Basic からの SKU の変更は、サポートされてませんので、新しいリソースを作って、データマイグレーションすることになります。

 

2.Azure Database for MySQL Flexible Server

Azure Database for MySQL には、以下の 2 つのデプロイメントモデルがあります。

  • シングルサーバ
  • Flexible Server(プレビュー)

 

ドキュメントから感じた違いは、以下の 2 つかな

  • 単一可用性ゾーンの中で高可用性を実現しているシングルサーバと、複数の可用性ゾーンにまたがる構成ができる Flexible Server
  • パフォーマンス性能はリソース(Storageのサイズ)に比例するシングルサーバと、IOPS で変更できる Flexible Server

まぁーなんとなく、Flexible Server の方が柔軟な感じですよね~。

 

詳しくはドキュメントを読んでくださいね~。

概要 - Azure Database for MySQL - Flexible Server
MySQL Community Edition に基づく Microsoft クラウドのリレーショナル データベース サービスである Azure Database for MySQL - フレキシブル サーバーについて説明します。

 

シングルサーバから Flexible Server にかえるとすると、そもそもリソースが違うので、先に Flexible Server をデプロイしてからデータマイグレーションという順番になります。

 

3.MySQL のバージョンアップ問題

MySQL のバージョンアップについては、5.6 から 5.7 はあるんですよね。

まぁーポータルからもできる。

Major version upgrade in Azure Database for MySQL - Single Server
This article describes how you can upgrade major version for Azure Database for MySQL - Single Server

 

ただ、5.7 から 8.0 へのアップグレード方法はなさそうなので、新しいリソースを 8.0 で作ってデータマイグレーションするっていう形になるので、放置してましたw

 

試したこと

データマイグレーションの方法

データマイグレーションの方法は、Azure Database Migration Service を使ってみました。

Azure Database Migration Service | Microsoft Azure
評価とデータ移行ソフトウェアには、オンプレミスの SQL Server と Oracle データベースをクラウドに移行するための Azure Database Migration Service をお選びください。

 

ただ結論としては、Azure Database Migration Service を使った場合、インスタンスやテーブルの作成を事前にやる必要があるので、めんどくさくなって、MySQL Workbench を使ってマイグレーションしちゃいましたw

 

Azure Database Migration Service は、移行の検証とか終わっていてデータを移すだけって準備できてる時は、便利そう!
(Public Access しなくていいので、不要な IP の穴あけとかいらないから)

 

5.7 Basic シングルサーバから、5.7 General Purpose シングルサーバへの移行

これは、成功しました。

っていうか、失敗する要素が何もないからw

 

先にネタバレすると、これ以外は全部失敗したので、バージョンは変えずに、デプロイモデルも変えずに SKU だけ変えた形になります。

 

MySQL 5.7 から 8.0 へのマイグレーションの問題点

シングルサーバ間でも、5.7 から 8.0 へのマイグレーションは失敗しました。

原因は、MySQL 8.0 からいくつか仕様変更が入っていて、それが原因でマイグレーションツールで Create Table するところでエラーが起きちゃって、テーブルが作れなかったんですよね。

 

で、それを1個づつ潰すのがめんどくさくなっちゃって。。。

だってこのサイトは、すごく雑に運用するがモットーでやってるからw

 

ということで、5.7から8.0にバージョンアップするのは、次回に先延ばし~。

 

シングルサーバから Flexible Server へのマイグレーション

これも、結果的には、5.7 から 8.0 へのマイグレーションと同じエラーがでてマイグレーションできませんでした。

こっちは、なんも調べてないからわかんないけど、5.7 から 8.0 へのマイグレーションができないと進まないと思ったのでw

 

まとめ

ひとまず、性能改善することはできるようになったのでよしとしましょうw

ただ、せっかく無駄にリソースをふんだんに使っているんだから、もうちょっとこのサイトの PV が増えるといいなぁ~。

って、もっと記事かけってことかw

コメント

タイトルとURLをコピーしました