はじめに
ご存じの方も多いかもしれませんが、長年親しまれてきた「MySQL5.6」は2021年2月に Extended Support が終了し、今後コミュニティ版の新しいバージョンがリリースされなくなりました(最終バージョンは5.6.51)。
その影響か、これまでMySQL5.6を利用していたユーザがMySQL5.7ないしMySQL8.0に移行(バージョンアップ)するケースが増えており、弊社にもそういった依頼を多くいただいております。
こうした場合、どのような方法でバージョンアップをするのか悩む方も多いのではないでしょうか。
アップグレード手順に関しては、公式マニュアルにも記載がありますが、大きく分けて3つの方法がございます。
方法 | 説明 | メリット |
---|---|---|
インプレース | 現行のMySQL5.6サーバをそのままアップグレードする | 今動いているサーバをそのまま使える |
物理バックアップ | 新しく構築したMySQLサーバに現行環境から取得した物理バックアップ(ex. MEB) | バックアップのリストア時間が短い |
論理バックアップ | 上記の論理バックアップ版(ex. mysqldump) | 文字コード、DDLの変更などがしやすい |
この中で、今回は論理バックアップを使ったバージョンアップ方法のやり方の一つとして、「MySQL ShellのdumpInstance()
を使ったやり方」について取り上げたいと思います。
MySQL Shellを使ったバージョンアップ
論理バックアップを使ったバックアップを行う場合、従来はmysqldump
コマンドを使うやり方が一般的でした。例えば、以下のようなコマンドです。
1 2 3 4 5 |
$ mysqldump -u root -p -h 127.0.0.1 --single-transaction --all-databases --routines --triggers > ./56_all_dump.sql ### MySQL5.7 or 8.0 にインポート $ mysql -u root -p -h 127.0.0.1 < ./56_all_dump.sql |
この方法の場合、データロード時に断片化したデータの再構成が行われたり、バージョン間でファイルフォーマットや文字コードを変更したい要望に応えやすいというメリットがあります。
しかし、全テーブルを全件INSERTする上、処理がシングルスレッドになってしまうため、dumpのロード時間が最大のネックとなってしまいます(データが大きいほど時間が長くなります)。
特に、定期メンテナンスのタイミングなどでバージョンアップを一気に終わらせたいケースなどでは悩みの種になってしまうのではないでしょうか?
この問題の解決策となりうるのが、MySQL Shellの dumpInstance() コマンド(Dump Utility)です。このコマンドは、mysqldump と同じように論理バックアップを取得するのですが以下のような違いがあります。
- テーブルデータ(レコード)をINSERTではなく、tsv形式のファイルで出力する
- データのエクスポート・インポート共に、並列スレッドで実行可能
- 整合性や取得するデータのフィルタリングをコマンドオプションで柔軟に選べる
上記のようなメリットから、dumpInstance()コマンドを使うことで論理バックアップを使ったバージョンアップがより高速かつ効率的に実施できることが期待できます。以下の項目でそのやり方について解説していきます。
※ Dump Utilityの処理速度の優位性については、昨年のブログ記事をご参照ください
なお、以前は mysqlpump が上記のような mysqldump の後継を担っていましたが、最近の開発の動きとしては dump utility の方を後継として注力しているようです。
検証環境構築
OCIを使って、検証環境を構築します。
なお、MySQL5.6のバージョンは実際に今もMySQL5.6を使っているお客様のケースを想定し、少し古いバージョンにします。今回は、2年前時点(2019/06/14)の最新版である「5.6.44」にします。
また、移行先として想定するMySQL5.7/8.0に関しては、2021/06/14時点の最新バージョンである [5.7.34]と「8.0.25」にします。
MySQL Shellに関しても、最新バージョンである「8.0.25」にします。
【検証環境スペック(OCI)】
以下の検証で使用するサーバのスペックは全て同一にします。
インスタンスタイプ | OS | CPU | MEMORY | Disk | NW |
---|---|---|---|---|---|
VM.Standard.E4.Flex | Oracle Linux 7.9 | 8 OCPU(16 コア) | 32 MB | NVMe SSD 300 GB | 8 Gbps (1 × OCPU) |
※ セキュリティグループの設定で、プライベートネットワーク(10.0.0.XX)間の 3306 ポートの通信は許可してあります
※ SELinux、iptables(firewalld) は無効にしてあります
※ ディスクは以下のコマンドでブートボリュームの拡張を実施しました
1 2 3 4 5 6 |
$ sudo growpart /dev/sda 3 $ sudo xfs_growfs -d /dev/sda3 $ df -lh Filesystem Size Used Avail Use% Mounted on ... /dev/sda3 292G 6.5G 286G 3% / |
移行元(MySQL5.6)構築
1. プリインストールされているMySQLを削除します
1 2 3 4 5 6 7 8 9 10 |
[opc@blog-mysql56 ~]$ rpm -qa | grep -i mysql mysql-release-el7-1.0-5.el7.x86_64 mysql-community-libs-compat-8.0.25-1.el7.x86_64 mysql-community-client-plugins-8.0.25-1.el7.x86_64 mysql-community-libs-8.0.25-1.el7.x86_64 mysql80-community-release-el7-3.noarch mysql-community-common-8.0.25-1.el7.x86_64 [opc@blog-mysql56 ~]$ sudo yum remove mysql-community* [opc@blog-mysql56 ~]$ sudo yum remove mysql-release-el7-1.0-5.el7.x86_64 |
2. MySQLのyumリポジトリと yum-utils をインストールします
1 2 |
[opc@blog-mysql56 ~]$ sudo yum install https://dev.mysql.com/get/mysql80-community-release-el7-3.noarch.rpm [opc@blog-mysql56 ~]$ sudo yum install yum-utils |
3. リポジトリを5.6向けに切り替え、MySQL5.6.44をインストールします
1 2 3 4 |
[opc@blog-mysql56 ~]$ sudo yum-config-manager --disable mysql80-community [opc@blog-mysql56 ~]$ sudo yum-config-manager --enable mysql56-community [opc@blog-mysql56 ~]$ sudo yum install mysql-community-{libs,common,server,client}-5.6.44 |
4. 簡単なmy.cnfを設定してから、MySQLを起動します
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
[opc@blog-mysql56 ~]$ sudo vi /etc/my.cnf ### 以下の設定を追記 innodb_buffer_pool_size=24G innodb_log_file_size=1G character_set_server=utf8 innodb_file_format=Barracuda [opc@blog-mysql56 ~]$ sudo systemctl start mysqld [opc@blog-mysql56 ~]$ mysql -u root mysql> SET PASSWORD = PASSWORD("MySQL5.6"); mysql> CREATE DATABASE sbtest1; mysql> CREATE DATABASE sbtest2; mysql> CREATE DATABASE sbtest3; mysql> CREATE DATABASE sbtest4; |
5. sysbenchをインストールします
Oracle Linux上でsysbench の yum リポジトリからインストールをすると、 ver.1.0.17(2019/05/15)がインストールされてしまいました。
今回は最新のバージョン(1.0.20)の sysbench を使いたいため、ソースコードからビルドします。
1 2 3 4 5 6 7 8 9 10 11 12 13 |
[opc@blog-mysql56 ~]$ sudo yum install make automake libtool pkgconfig libaio-devel mariadb-devel openssl-devel [opc@blog-mysql56 ~]$ wget https://github.com/akopytov/sysbench/archive/refs/tags/1.0.20.tar.gz [opc@blog-mysql56 ~]$ tar zxvf 1.0.20.tar.gz [opc@blog-mysql56 ~]$ cd sysbench-1.0.20/ [opc@blog-mysql56 ~]$ ./autogen.sh [opc@blog-mysql56 ~]$ ./configure [opc@blog-mysql56 ~]$ make -j [opc@blog-mysql56 ~]$ sudo make install [opc@blog-mysql56 ~]$ /usr/local/bin/sysbench --version sysbench 1.0.20 |
6. sysbenchでテストデータをロードします
同じレコード数、テーブル数のテストデータを作成します。
この時、ランダムデータの分布形式(random numbers distribution)が異なるデータベースを4つ用意します。
ちなみにデフォルトの形式は “special” です。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
[opc@blog-mysql56 ~]$ /usr/local/bin/sysbench --db-driver=mysql --tables=40 --table-size=2000000 --threads=8 \ --mysql-user="root" --mysql-password="MySQL5.6" --mysql-db="sbtest1" \ --rand-type=uniform oltp_read_write prepare & [opc@blog-mysql56 ~]$ /usr/local/bin/sysbench --db-driver=mysql --tables=40 --table-size=2000000 --threads=8 \ --mysql-user="root" --mysql-password="MySQL5.6" --mysql-db="sbtest2" \ --rand-type=gaussian oltp_read_write prepare & [opc@blog-mysql56 ~]$ /usr/local/bin/sysbench --db-driver=mysql --tables=40 --table-size=2000000 --threads=8 \ --mysql-user="root" --mysql-password="MySQL5.6" --mysql-db="sbtest3" \ --rand-type=special oltp_read_write prepare & [opc@blog-mysql56 ~]$ /usr/local/bin/sysbench --db-driver=mysql --tables=40 --table-size=2000000 --threads=8 \ --mysql-user="root" --mysql-password="MySQL5.6" --mysql-db="sbtest4" \ --rand-type=pareto oltp_read_write prepare & |
※ マニュアル上は –rand-type=zipfian も指定できるようですが、実際に試してみると存在しないオプションでした
1 2 3 4 5 |
[opc@blog-mysql56 ~]$ /usr/local/bin/sysbench --help | grep rand-type --rand-type=STRING random numbers distribution {uniform,gaussian,special,pareto} [special] [opc@blog-mysql56 ~]$ /usr/local/bin/sysbench --rand-type=zipfian FATAL: Invalid random numbers distribution: zipfian. |
ロードしたデータの合計サイズは 18GB × 4 = 72GB でした。
1 2 3 4 5 6 7 8 |
[opc@blog-mysql56 ~]$ sudo ls -lh /var/lib/mysql/sbtest1 | head -n 1 total 18G [opc@blog-mysql56 ~]$ sudo ls -lh /var/lib/mysql/sbtest2 | head -n 1 total 18G [opc@blog-mysql56 ~]$ sudo ls -lh /var/lib/mysql/sbtest3 | head -n 1 total 18G [opc@blog-mysql56 ~]$ sudo ls -lh /var/lib/mysql/sbtest4 | head -n 1 total 18G |
移行先(MySQL5.7 + MySQL8.0)構築
次に移行先である MySQL5.7 / MySQL8.0 を構築します。これらは最新バージョンを使用します。
1. MySQL5.7をインストール
1 2 3 4 5 6 7 8 9 |
[opc@blog-mysql57 ~]$ sudo yum remove mysql-community* [opc@blog-mysql57 ~]$ sudo yum remove mysql-release-el7-1.0-5.el7.x86_64 [opc@blog-mysql57 ~]$ sudo yum install https://dev.mysql.com/get/mysql80-community-release-el7-3.noarch.rpm [opc@blog-mysql57 ~]$ sudo yum install yum-utils [opc@blog-mysql57 ~]$ sudo yum-config-manager --disable mysql80-community [opc@blog-mysql57 ~]$ sudo yum-config-manager --enable mysql57-community [opc@blog-mysql57 ~]$ sudo yum install mysql-community-{libs,common,server,client} |
2. MySQL5.7の初期設定
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
[opc@blog-mysql57 ~]$ sudo vi /etc/my.cnf ### 以下の設定を追記 innodb_buffer_pool_size=24G innodb_log_file_size=1G character_set_server=utf8 innodb_file_format=Barracuda [opc@blog-mysql57 ~]$ sudo systemctl start mysqld [opc@blog-mysql57 ~]$ sudo grep "temporary password" /var/log/mysqld.log 2021-06-17T05:37:55.830923Z 1 [Note] A temporary password is generated for root@localhost: u_545+7eQr!- [opc@blog-mysql57 ~]$ mysql -u root -p Enter password: <上記の自動生成パスワードを入力> mysql> SET PASSWORD = "MySQL5.7"; mysql> exit |
3. MySQL8.0をインストール
OCI環境であれば、最初からMySQL8.0の最新バージョンがプリインストールされているはずです。
それ以外の環境であれば、以下のような手順でインストールしてください。
1 2 |
[opc@blog-mysql80 ~]$ sudo yum install https://dev.mysql.com/get/mysql80-community-release-el7-3.noarch.rpm [opc@blog-mysql80 ~]$ sudo yum install mysql-community-{libs,common,server,client} |
4. MySQL8.0の初期設定
データベースの文字コードをMySQL8.0のデフォルトである「utf8mb4」に変更します。
また、innodb_file_format
パラメータ変数はMySQL8.0で廃止されたため削除しました。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
[opc@blog-mysql80 ~]$ sudo vi /etc/my.cnf ### 以下の設定を追記 innodb_buffer_pool_size=24G innodb_log_file_size=1G character_set_server=utf8mb4 [opc@blog-mysql80 ~]$ sudo systemctl start mysqld [opc@blog-mysql80 ~]$ sudo grep "temporary password" /var/log/mysqld.log 2021-06-17T05:27:38.089355Z 1 [Note] A temporary password is generated for root@localhost: :P!orAUhJ9V> [opc@blog-mysql80 ~]$ mysql -u root -p Enter password: <上記の自動生成パスワードを入力> mysql> SET PASSWORD = "MySQL8.0"; mysql> exit |
dumpInstance()でバージョンアップ
環境の準備ができましたので、MySQL ShellのdumpInstance()
を使ったバージョンアップ(データ移行)を試してみましょう。
1. 移行先サーバ(5.7 & 8.0)にMySQL Shell 8.0をインストール
1 2 3 4 5 6 7 |
### 5.7サーバ [opc@blog-mysql57 ~]$ sudo yum-config-manager --disable mysql57-community [opc@blog-mysql57 ~]$ sudo yum-config-manager --enable mysql80-community [opc@blog-mysql57 ~]$ sudo yum install mysql-shell ### 8.0サーバ [opc@blog-mysql80 ~]$ sudo yum install mysql-shell |
2. 移行元サーバ(5.6)にMySQL Shell用ユーザを作成
今回の環境では各サーバにプライベートIP(10.0.0.XX)が割り当てられていますので、同セグメントから接続できるユーザを用意します。
1 2 3 4 5 6 |
[opc@blog-mysql56 ~]$ mysql -u root -p Enter password: mysql> CREATE USER `mysqlsh_user`@`10.0.0.%` IDENTIFIED BY "P@ssword1"; mysql> GRANT ALL ON *.* TO `mysqlsh_user`@`10.0.0.%`; mysql> exit |
3. 移行先サーバから移行元サーバに対して dumpInstance() を実行
dumpInstance()
コマンドで指定しているオプションは以下の通りです。
- defaultCharacterSet : エクスポートするバックアップファイルの文字コード。原則として移行元の文字コードを指定してください。
- consistent : エクスポートするバックアップファイルの整合性。原則として”on”を推奨。
- chunking : バックアップを一定のチャンク(かたまり)にまとめるか否か。原則として”on”を推奨。
- threads : エクスポートを実行する並列スレッド数。移行元サーバのスペックや負荷に応じて引き上げてください。
- user : MySQLユーザ情報をエクスポート対象に含めるか否か。これを true にしてしまうとインポート時に以下のエラーが発生するため、falseを推奨。
1 |
Util.dumpInstance: Dumping user accounts is currently not supported in MySQL versions before 5.7. Set the 'users' option to false to continue. (ArgumentError) |
【MySQL5.7サーバ】
合計72GBのデータベースのエクスポートに7分26秒かかりました。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 |
[opc@blog-mysql57 ~]$ mkdir ./56_backup/ [opc@blog-mysql57 ~]$ mysqlsh mysqlsh_user@10.0.0.30 Please provide the password for 'mysqlsh_user@10.0.0.30': ********* Save password for 'mysqlsh_user@10.0.0.30'? [Y]es/[N]o/Ne[v]er (default No): Y MySQL 10.0.0.30:3306 JS > util.dumpInstance("/home/opc/56_backup/", { defaultCharacterSet: "utf8", consistent: true, chunking: true, threads: 4, users: false } ) ... 4 thds dumping - 103% (319.65M rows / ~307.65M rows), 474.89K rows/s, 92.76 MB/s uncompressed, 41.88 MB 4 thds dumping - 103% (319.78M rows / ~307.65M rows), 475.93K rows/s, 92.98 MB/s uncompressed, 41.96 MB 4 thds dumping - 103% (319.92M rows / ~307.65M rows), 475.93K rows/s, 92.98 MB/s uncompressed, 41.96 MB 1 thds dumping - 104% (320.00M rows / ~307.65M rows), 475.93K rows/s, 92.98 MB/s uncompressed, 41.96 MB/s compressed Duration: 00:07:26s Schemas dumped: 5 Tables dumped: 160 Uncompressed data size: 62.20 GB Compressed data size: 28.14 GB Compression ratio: 2.2 Rows written: 320000000 Bytes written: 28.14 GB Average uncompressed throughput: 139.32 MB/s Average compressed throughput: 63.04 MB/s MySQL 10.0.0.30:3306 JS > \q |
【MySQL8.0サーバ】
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 |
[opc@blog-mysql80 ~]$ mkdir ./56_backup/ [opc@blog-mysql80 ~]$ mysqlsh mysqlsh_user@10.0.0.30 Please provide the password for 'mysqlsh_user@10.0.0.30': ********* Save password for 'mysqlsh_user@10.0.0.30'? [Y]es/[N]o/Ne[v]er (default No): Y MySQL 10.0.0.30:3306 JS > util.dumpInstance("/home/opc/56_backup/", { defaultCharacterSet: "utf8", consistent: true, chunking: true, threads: 4, users: false } ) ... 4 thds dumping - 103% (319.72M rows / ~307.65M rows), 762.46K rows/s, 148.83 MB/s uncompressed, 67.27 M 3 thds dumping - 103% (319.84M rows / ~307.65M rows), 762.46K rows/s, 148.83 MB/s uncompressed, 67.27 M 1 thds dumping - 104% (319.96M rows / ~307.65M rows), 762.46K rows/s, 148.83 MB/s uncompressed, 67.27 M 1 thds dumping - 104% (320.00M rows / ~307.65M rows), 736.58K rows/s, 143.78 MB/s uncompressed, 64.97 MB/s compressed Duration: 00:07:14s Schemas dumped: 5 Tables dumped: 160 Uncompressed data size: 62.20 GB Compressed data size: 28.14 GB Compression ratio: 2.2 Rows written: 320000000 Bytes written: 28.14 GB Average uncompressed throughput: 143.31 MB/s Average compressed throughput: 64.84 MB/s MySQL 10.0.0.30:3306 JS > \q |
4. MySQLユーザ情報のみをエクスポートする
dumpInstance()でエクスポートしなかったMySQLユーザ情報を移行したい場合、mysqldumpコマンドで同情報のみをエクスポート・インポートします。
※ dumpファイルをインポートしたあとは mysql_upgrade (8.0の場合は mysqld –upgrade=FORCE)を実行してください
※ DB単位の権限(GRANT … ON “DB名”.xxx)を付与しているユーザがいる場合、mysql.dbデータベースも移行する必要があります
1 2 3 4 5 |
$ mysqldump -u mysqlsh_user -p -h 10.0.0.30 --allow-keywords mysql user > /home/opc/user_dump_56.sql $ mysqldump -u mysqlsh_user -p -h 10.0.0.30 --allow-keywords mysql db > /home/opc/db_dump_56.sql $ mysql -u root -p mysql < /home/opc/user_dump_56.sql $ mysql -u root -p mysql < /home/opc/db_dump_56.sql |
5. 移行先サーバに移行元サーバのデータをインポートする
インポートにはloadDump()
コマンドを使用します。指定しているオプションは以下の通りです。
- loadDdl : エクスポートされたDDLを実行します。今回は移行先MySQLが空なので、”true”で問題ありません。
- ignoreVersion : エクスポート元のMySQLとインポート先のMySQLのバージョンが異なるため、このオプションは”true”にします。
- threads : エクスポートを実行する並列スレッド数。移行先サーバのスペックや負荷に応じて引き上げてください。
【MySQL5.7サーバ】
合計72GBのデータベースのインポートに51分34秒かかりました。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 |
[opc@blog-mysql57 ~]$ mysqlsh root@localhost Please provide the password for 'root@localhost': ******** Save password for 'root@localhost'? [Y]es/[N]o/Ne[v]er (default No): Y MySQL localhost JS > \sql set global local_infile = ON; Query OK, 0 rows affected (0.0001 sec) MySQL localhost JS > util.loadDump("/home/opc/56_backup/", { loadDdl: true, ignoreVersion: true, threads: 4 } ) ... [Worker002] sbtest4@sbtest14@@14.tsv.zst: Records: 78149 Deleted: 0 Skipped: 0 Warnings: 0 [Worker000] sbtest4@sbtest22@@14.tsv.zst: Records: 78149 Deleted: 0 Skipped: 0 Warnings: 0 [Worker003] sbtest4@sbtest18@@14.tsv.zst: Records: 78149 Deleted: 0 Skipped: 0 Warnings: 0 [Worker001] sbtest4@sbtest38@@14.tsv.zst: Records: 78149 Deleted: 0 Skipped: 0 Warnings: 0 Executing common postamble SQL 2382 chunks (320.00M rows, 62.20 GB) for 160 tables in 5 schemas were loaded in 51 min 34 sec (avg throughput 20.10 MB/s) 0 warnings were reported during the load. |
※ インポート時に”row size too large”エラーが発生した場合、innodb_strict_mode
変数が原因の可能性があります(5.6ではデフォルトOFF、5.7~はデフォルトON)
【MySQL8.0サーバ】
移行元の文字コードはutf8(utf8mb3)ですが、MySQL8.0では新しくデフォルトになった utf8mb4 を利用したい場合は、エクスポートされたDDL(CREATE TABLE)の “DEFAULT CHARSET=utf8” の箇所を utf8mb4 に変更します。
DDLは以下のように DB名@TABLE名.sql ファイルにまとめられていますので、これらの該当部分をまとめて置換してしまいましょう。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
[opc@blog-mysql80 ~]$ ls /home/opc/56_backup/ | grep sql @.post.sql sbtest1@sbtest10.sql sbtest1@sbtest11.sql sbtest1@sbtest12.sql ... ### オリジナルのDDLファイルをバックアップしておく [opc@blog-mysql80 ~]$ mkdir /home/opc/56_ddl_org/ [opc@blog-mysql80 ~]$ cp /home/opc/56_backup/*.sql /home/opc/56_ddl_org/ ### DDLの文字コードの部分をまとめて置換 $ sed -i "s/utf8mb4/utf8/g" /home/opc/56_backup/*.sql $ sed -i "s/utf8/utf8mb4/g" /home/opc/56_backup/*.sql |
文字コードの変更が完了したら、インポートを実行しましょう。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
[opc@blog-mysql80 ~]$ mysqlsh root@localhost Please provide the password for 'root@localhost': ******** Save password for 'root@localhost'? [Y]es/[N]o/Ne[v]er (default No): Y MySQL localhost JS > \sql set global local_infile = ON; Query OK, 0 rows affected (0.0001 sec) MySQL localhost JS > util.loadDump("/home/opc/56_backup/", { loadDdl: true, ignoreVersion: true, threads: 4 } ) ... 1725 chunks (228.41M rows, 62.20 GB) for 160 tables in 5 schemas were loaded in 49 min 44 sec (avg throughput 14.90 MB/s) 1725 warnings were reported during the load. |
これでアプリケーションの向き先を移行先に切り替えてしまえば、バージョンアップは完了です。
6. 移行先サーバと移行元サーバの間でレプリケーションを設定する
MySQL5.6 と MySQL5.7 の間であればレプリケーションが利用できます。もし設定したい場合は、エクスポートしたフォルダに含まれる「@.json」ファイルに記録されたバイナリログポジション(or GTIDポジション)をもとに、「移行先 → 移行元」のレプリケーションを設定してください。
1 2 3 4 5 6 7 8 9 10 |
[opc@blog-mysql57 ~]$ cat 56_backup/@.json { "dumper": "mysqlsh Ver 8.0.25 for Linux on x86_64 - for MySQL 8.0.25 (MySQL Community Server (GPL))", "version": "1.0.2", "origin": "dumpInstance", ... "serverVersion": "5.6.44-log", "binlogFile": "mysqld-bin.000001", "binlogPosition": 22004, ... |
なお、MySQL5.6とMySQL8.0のレプリケーションはサポート外のためご注意ください。
おわりに
以上、MySQL Shellの dumpInstance による論理バックアップを使ってMySQL5.6をバージョンアップする手順について紹介しました。
この手法は単に論理バックアップによるインポート・エクスポートを高速化するだけでなく、新環境でDDLの変更(文字コード変更、インデックス追加など)を手軽に実施することができることもメリットの一つです。
もし、MySQL5.6のサポート切れに伴いバージョンアップを検討している方がいたら、その手助けとなれば幸いです。
また、環境によっては上記のような手順でスムーズに移行できない、もしくは心配な点があるというケースもあるかと思います。そうした場合は、ぜひ以下の問い合わせフォームより弊社までご相談ください。