スマートスタイル TECH BLOG|データベース&クラウドの最新技術情報を配信

MySQL Database Serviceへ移行してみよう!

MySQL Database Serviceへ移行してみよう

Oracle Cloud Infrastructure(以下OCI) の ピュアMySQL & フルマネージド なDBaaSである MySQL Database Service(旧 MySQL Cloud Service) へ移行してみよう、ということで今回試してみました。

MySQL Database Service(以下MDS) へ移行することで様々なメリットを享受できます。

  • MySQLベンダであるOracle MySQLチームによるサポート、開発、メンテナンス
  • バックアップ・リカバリの自動化
  • 暗黙的なストレージ暗号化
  • OSも含めた自動的なアップデート・セキュリティパッチの適用
  • 監視・監査機能の提供
  • Heatwaveの利用(超高速分析エンジン) -> DataWareHouseとしての利用も可能!

中でもHeatwaveは昨年末にリリースされたインメモリ&列志向なデータベースエンジンで、Oracle社でもイチオシの機能です。
近いうちに本機能についてもご紹介する予定です。

HeatWave

HeatWaveは、MySQLデータベースサービスへのアドオンです。
OracleCloudInfrastructure用に最適化された高性能でスケーラブルなインメモリ分析処理エンジンを提供します。
お客様は、ETLを必要とせず、アプリケーションを変更せずに、MySQLデータベースに保存されているデータに対してHeatWaveを実行できます。
アプリケーションは、標準のMySQLプロトコルを介してHeatWaveにアクセスするだけで、一般的な管理アクションは自動化され、統合され、
OCI Webコンソール、REST API、CLI、またはDevOpsツールを介してアクセスできます。
HeatWaveクエリは、MySQLデータベースよりも桁違いに高速化されます。

日本語のドキュメントではまだHeatwaveについての記載がありませんでしたので、原文の翻訳になりますが、桁違いに高速化されますという一文に自信を感じます。

さて、以前より、バックアップデータを使用したMDSインスタンスを作成することは可能でしたが、インバウンドレプリケーション機能 がリリースされた ことで、より実践的なマイグレーションが可能となったように思います。

オフィシャルのドキュメントで紹介されているmysqlshを使用したデータエクスポート・インポート と、インバウンドレプリケーションを組み合わせて、オンプレのMySQLからMDSへのマイグレーションを実施してみます。

Terraformを使用した検証環境の構築

検証に利用する環境の構成図は以下となります。

概略としては以下のとおりです。

  • MDSなどを配置するためのネットワーク関連リソース(VCN/Subnet/RouteTable/SecurityList/InternetGateway)
  • オンプレミスのMySQLバックアップを配置するためのオブジェクトストレージ
  • MySQL Database Service
  • オンプレミス, OCI間でレプリケーションを接続するためのOpenVPNサーバが稼働するComputeインスタンス
  • OCI サブネット内部からMDSへ操作を行うためのComputeインスタンス

今回OpenVPNサーバを除くリソースについてはTerraformを使用して作成しました。

terraformの設定ファイルは以下となります。

oci-mds-terraform

GUIコンソールを使用した作成方法については、弊社過去ブログ記事で紹介しておりますので、合わせてご確認ください。

MySQL Database Service のインスタンスを作成してみる

オンプレミス-MDS 接続ユーザの作成

クライアント用として作成したComputeインスタンスにMySQL Clientをインストールし、MDSにテスト接続用ユーザを作成します。

オンプレミスのMySQLへデータロード

検証用のMySQLサーバはDockerを使用して用意しました。
テスト用ユーザ、レプリケーション用ユーザを作成し、world databaseのデータをロードしています。

また、オンプレミス側にもクライアントをインストールしておきます。

MySQL Shellを使用したデータエクスポート

ドキュメントに紹介されている通り、MySQL ShellのdumpInstance()/loadDump()を使用し、ベースとなるデータをMDSにインポートしていきます。

なお、OCI Object Storageへダンプファイルを送信する場合、OCI CLI構成ファイルを適切に設定しておく必要があります。

dumpInstanceの実行結果は以下の通りです。

Acquiring global read lock~から始まる箇所を見てわかるように、 dumpInstance() ではデフォルトで consistent: true が設定されているため、実行開始時点で Global Read Lock を取得します。
全てのバックアップスレッドのトランザクションが開始した時点で開放され、バックアップロックに切り替えられます。
トランザクションが開始するまでですので、通常ごく短期間ですが、DMLが停止するという点にご注意ください。
またバックアップロック中はDDLのみブロックされます。

https://dev.mysql.com/doc/mysql-shell/8.0/en/mysql-shell-utilities-dump-instance-schema.html

consistent: [ true | false ] Enable (true) or disable (false) consistent data dumps by locking the instance for backup during the dump.
The default is true.
When true is set, the utility sets a global read lock using the FLUSH TABLES WITH READ LOCK statement.
The transaction for each thread is started using the statements SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ and START TRANSACTION WITH CONSISTENT SNAPSHOT.
When all threads have started their transactions, the instance is locked for backup and the global read lock is released.

CLIで確認すると、正常にバックアップが存在していました。

MySQL Shellを使用したデータインポート

すでにOCI上にエクスポートされたバックアップを使用し、loadDump()を使用してMDSにデータをインポートします。
この作業はClient用のComputeインスタンスから行います。
エクスポート時と同様に、この場合もOCI CLIの設定ファイルを作成する必要がありますのでご注意ください。

なお、MySQL Shellのドキュメントに記載されている通り、loadDump()ではダンプしたバックアップに含まれるGTIDをインポート先に自動的に適用しません。

https://dev.mysql.com/doc/mysql-shell/8.0/en/mysql-shell-utilities-load-dump.html

The dump loading utility does not automatically apply the gtid_executed GTID set from the source MySQL instance on the target MySQL instance.
The GTID set is included in the dump metadata from MySQL Shell’s instance dump utility, schema dump utility, or table dump utility, as the gtidExecuted field in the @.json dump file.
To apply these GTIDs on the target MySQL instance for use with replication, from MySQL Shell 8.0.22, use the updateGtidSet option to either append them to or replace the gtid_purged GTID set,
depending on the release of the target MySQL instance.
This is not currently supported on MySQL DB System due to a permissions restriction.
In MySQL Shell 8.0.21, the GTID set can be imported manually, though this is not supported on MySQL DB System.

ダンプ実行時のGTID_EXECUTEDはダンプデータセット内の @.json ファイルに含まれますので確認できます。

MDSの管理ユーザは、現状のところ SUPERSYSTEM_VARIABLES_ADMIN 権限が付与されておらず、SET GLOBAL GTID_PURGED .. を実行することができませんが、sys.set_gtid_purged() コマンドで同等の操作を実施することが可能です。

VPN接続について

オンプレミスの環境からOCIのSubnetへ接続するためには、VPN接続が必要となります
MDSからソースデータベースとなるオンプレミスのMySQLへ接続するためにも同様にこれは必須です。

今回はOCI Marketplace上のOpenVPNサーバを使用しました。
この OpenVPN Access Server は 2接続まで 無償で利用が可能です。

https://openvpn.net/access-server/pricing/

ここでは詳しい構築方法については触れませんが、ドキュメントに構築の詳しい手順が記載されておりますので、もし検証される場合は適宜ご確認ください。

移行の作業ではVPN接続が完了しており、MDSからオンプレミスMySQLの3306ポートへアクセス可能な事を前提とします。

インバウンドレプリケーションとは

MDSでは、外部のMySQLをソース、MDSをレプリカとした非同期レプリケーションを構成することが可能です。

インバウンドレプリケーションでは、レプリケーションを開始する際にMDSにチャネル(いわゆるCHANGE MASTER TOで設定する内容相当)を定義する必要があります。

もちろんGUIコンソールからも追加が可能ですが、今回はterraformの設定ファイルで定義しています。

var.channel_enabledvariables.tf で “false” に設定しておりますので、レプリケーション自体はこの時点で開始していません。

レプリケーションの開始

レプリケーションを開始します。

MDSでステータスを確認すると、非同期レプリケーションが開始されています。

オンプレ側でデータの更新をしてみましょう。

MDSでデータを確認することができます。

以上でオンプレミスのMySQLとMDSのデータは継続的に同期されます。
あとはアプリケーションの接続先の切り替えなどを行えばMDSへの移行は完了です。

まとめ

各環境でのOCI CLIの実行準備さえできていれば、スムーズな移行ができるものと思います。

今回はOpenVPNサーバを使用しましたが、オンプレミス環境が高トラフィックであったり、データ量が非常に多いなどの状況ではよりパフォーマンスのよい OCI VPN Service や、Fast Connect を準備するのがよいでしょう。

まずは、小規模な環境のレプリカとしてMDSのご利用を初めてみてはいかがでしょうか。


Oracle Cloud Infrastructure(OCI)専門 プロフェッショナルパートナー
OCIサポート総合サイトをオープンいたしました。


【5/26(水) 開催】MySQL Database Service セミナー情報



【8/4(水) 開催】Couchbase Webinar



Oracle Cloud
Return Top