将 MySQL5.6 中的表格转换为 MyRocks 在 MariaDB 中
因为在MySQL领域引起了轰动的MyRocks,所以在2017年5月23日发布的MariaDB 10.2.6中添加了MyRocks(RocksDB)引擎(alpha版本)。因此,我尝试将InnoDB表进行转换并使用MyRocks引擎。
首先
就注意事项和结论而言,如果是用于实际应用,那么MyRocks也需要进行调优才行。然而,这已超出了本文的范围。
关于调谐,官方也有这样的描述。
不幸的是,优化RocksDB并不简单。即使作为RocksDB开发人员,我们也不能完全理解每个配置更改的影响。如果您想为您的工作负载充分优化RocksDB,我们建议进行实验和基准测试,并注意三个放大因素。
简而言之,就是说“因为还未成熟,请自行尝试一下”。
此外,在本文撰写时,RocksDB其实还处于Alpha发布阶段。
准备MariaDB
我会写下安装和简单设置的步骤。
安装
让我们安装最新的MariaDB吧。在撰写本文时,最新版本是10.2.7,但在构建验证环境时,10.2.6是最新版本。
本文所述的环境是以CentOS7作为操作系统,并安装了以下软件包的环境。
-
- MariaDB-client-10.2.6-1.el7.centos.x86_64
-
- MariaDB-shared-10.2.6-1.el7.centos.x86_64
-
- MariaDB-common-10.2.6-1.el7.centos.x86_64
-
- MariaDB-devel-10.2.6-1.el7.centos.x86_64
-
- MariaDB-compat-10.2.6-1.el7.centos.x86_64
-
- MariaDB-server-10.2.6-1.el7.centos.x86_64
- MariaDB-rocksdb-engine-10.2.6-1.el7.centos.x86_64
在 10.2.6 版本中,MyRocks 已经成为另一个名为 MariaDB-rocksdb-engine 的插件包,所以与 MariaDB-server 一起安装。
简单的设置
我认为会自动创建名为rocksdb.cnf的文件。
$ cat /etc/my.cnf.d/rocksdb.cnf
[mariadb]
plugin-load-add=ha_rocksdb.so
如果存在这段描述,那么将启用RocksDB引擎。
当启动MariaDB时,应该可以确认RocksDB引擎已启用如下。
MariaDB> SHOW ENGINES;
+--------------------+---------+----------------------------------------------------------------------------------+--------------+------+------------+
| Engine | Support | Comment | Transactions | XA | Savepoints |
+--------------------+---------+----------------------------------------------------------------------------------+--------------+------+------------+
| ROCKSDB | YES | RocksDB storage engine | YES | YES | YES | ←これ
| MRG_MyISAM | YES | Collection of identical MyISAM tables | NO | NO | NO |
| CSV | YES | CSV storage engine | NO | NO | NO |
| Aria | YES | Crash-safe tables with MyISAM heritage | NO | NO | NO |
| MyISAM | YES | MyISAM storage engine | NO | NO | NO |
| MEMORY | YES | Hash based, stored in memory, useful for temporary tables | NO | NO | NO |
| Mroonga | YES | CJK-ready fulltext search, column store | NO | NO | NO |
| SEQUENCE | YES | Generated tables filled with sequential values | YES | NO | YES |
| PERFORMANCE_SCHEMA | YES | Performance Schema | NO | NO | NO |
| InnoDB | DEFAULT | Supports transactions, row-level locking, foreign keys and encryption for tables | YES | YES | YES |
+--------------------+---------+----------------------------------------------------------------------------------+--------------+------+------------+
10 rows in set (0.00 sec)
你能看到ROCKSDB吧。你也可以看到它具有类似于InnoDB的功能。
设定数值补充
可能在后续版本中会修复该问题,这只是一个补充说明…
在MariaDB 10.2.6中,RocksDB目录被识别为数据库,并出现了名为”#mysql50#.rocksdb”的数据库。(已知的错误)
如果在上述的设定文件中添加以下参数,就可以避免这个问题。
ignore-db-dirs=.rocksdb
数据库的迁移 de
既经准备好了MariaDB,所以我将尝试迁移数据。
Percona的XtraBackup非常快速且方便。
环境信息
在本次验证中,我们成功地将数据从以下环境/版本迁移到另一处。(关于XtraBackup,我们只是因为节省时间而省略了,所以最好使用最新版本。)
-
- 移行元: CentOS6 + MySQL 5.6.12 + XtraBackup 2.2.11
- 移行先: CentOS7 + MariaDB 10.2.6 + XtraBackup 2.3.6
备份与恢复
由于不是这个问题的主题,我将简要地写下。
备份
在移行源MySQL服务器上按以下方式进行备份。
您可以根据需要自行更改各种路径、并行值、lz4压缩率等。
[MySQLサーバー]
$ mkdir /var/tmp/tmp.xtrabackup
### 認証情報が必要な場合はオプションを付ける
$ innobackupex --stream=xbstream --parallel=4 --socket=/var/lib/mysql/mysql.sock /var/tmp/tmp.xtrabackup | lz4 -4 > /var/tmp/dbbackup.xbstream.lz4
将以此方式创建的/var/tmp/dbbackup.xbstream.lz4文件传输到目标位置。
恢复
在目标MariaDB服务器上,使用以下命令进行恢复。
当然,需要注意的是,现有的所有数据将被清空。
[MariaDBサーバー]
### 作業ディレクトリに移動
$ mkdir /var/tmp/tmp.xtrabackup
$ cd /var/tmp/tmp.xtrabackup
### 展開とリストア可能状態への変換
$ lz4 -d /var/tmp/dbbackup.xbstream.lz4 | xbstream -x -v
$ innobackupex --apply-log ./
### リストア
$ mv /var/lib/mysql /var/tmp/.
$ innobackupex --move-back ./
$ chown -R mysql:mysql /var/lib/mysql
只需启动MariaDB即可完成恢复。
如果在日志中输出了字符串”请运行 mysql_upgrade”,那么可以尝试运行 mysql_upgrade。
$ mysql_upgrade
将数据转换为RocksDB
准备之前
Percona的pt-online-schema-change非常优秀,可以在切换到RocksDB时使用。
请按照官方页面的指示进行操作。
本次测试的版本如下。
- percona-toolkit-3.0.3-1.el7.x86_64
原始表的信息
目标是针对名为hoge的表。
mysql> SHOW CREATE TABLE hoge\G
中略
ENGINE=InnoDB AUTO_INCREMENT=19103259 DEFAULT CHARSET=utf8 ROW_FORMAT=COMPRESSED
这是一个已压缩的InnoDB表,几乎包含了有关正式数据的相关信息。
请注意,下面的行数(tbl_rows)只是一个估计值,仅供参考。
mysql> select
-> table_name, engine, table_rows as tbl_rows, avg_row_length as rlen,
-> floor((data_length+index_length)/1024/1024) as allMB,
-> floor((data_length)/1024/1024) as dMB,
-> floor((index_length)/1024/1024) as iMB
-> from information_schema.tables
-> where table_schema=database() and table_name='hoge';
+------------+--------+----------+------+-------+------+------+
| table_name | engine | tbl_rows | rlen | allMB | dMB | iMB |
+------------+--------+----------+------+-------+------+------+
| hoge | InnoDB | 16005625 | 605 | 13065 | 9240 | 3825 |
+------------+--------+----------+------+-------+------+------+
1 row in set (0.03 sec)
引擎转换
以输入此命令的方式来执行pt-osc。
ALTER TABLE hoge ENGINE=ROCKSDB ROW_FORMAT=Dynamic;
由于非常耗时,我们可以使用nohup命令来执行。
### Dryrun
$ nohup pt-online-schema-change --charset=utf8 --nocheck-replication-filters --alter "ENGINE=ROCKSDB ROW_FORMAT=Dynamic" h=localhost,D=DBNAME,t=hoge,u=root --socket=/var/lib/mysql/mysql.sock --dry-run 2>&1 > /tmp/pt-osc.log &
### Execute
$ nohup pt-online-schema-change --charset=utf8 --nocheck-replication-filters --alter "ENGINE=ROCKSDB ROW_FORMAT=Dynamic" h=localhost,D=DBNAME,t=hoge,u=root --socket=/var/lib/mysql/mysql.sock --execute 2>&1 > /tmp/pt-osc.log &
在验证环境(Openstack虚拟机)上花了约6个小时。
请确认转换后的结果。
让我们再次从information_schema中获取信息试试看。
MariaDB> select
-> table_name, engine, table_rows as tbl_rows, avg_row_length as rlen,
-> floor((data_length+index_length)/1024/1024) as allMB,
-> floor((data_length)/1024/1024) as dMB,
-> floor((index_length)/1024/1024) as iMB
-> from information_schema.tables
-> where table_schema=database() and table_name='hoge';
+------------+---------+----------+------+-------+------+------+
| table_name | engine | tbl_rows | rlen | allMB | dMB | iMB |
+------------+---------+----------+------+-------+------+------+
| hoge | ROCKSDB | 17774854 | 585 | 11937 | 9926 | 2010 |
+------------+---------+----------+------+-------+------+------+
1 row in set (0.00 sec)
可以确认已经使用了RocksDB。容量也稍微减少了一点。
试着使用
我尝试发送一个全件COUNT查询的请求来验证一下。
-
- 注意1) Indexが使われるため実際のデータフルスキャンとは違いますが・・・参考に捉えていただければ。
- 注意2) 違う日に比較しているので結果(件数)が異なりますが、おおよそ同じデータ量なので差異は無視してください。
MySQL 5.6加上InnoDB
由于这个hoge表很大,所以在暖气之前会导致DiskRead非常严重。
mysql> SELECT SQL_NO_CACHE COUNT(*) FROM hoge;
+----------+
| COUNT(*) |
+----------+
| 17824275 |
+----------+
1 row in set (48.98 sec)
暖风停止后,为了进入缓冲池,结果会稍微快一些。(尽管还需要4秒呢……)
mysql> SELECT SQL_NO_CACHE COUNT(*) FROM hoge;
+----------+
| COUNT(*) |
+----------+
| 17824275 |
+----------+
1 row in set (4.03 sec)
MariaDB和RocksDB
我将尝试使用与MySQL类似的方法处理。
MariaDB> SELECT SQL_NO_CACHE COUNT(*) FROM hoge;
+----------+
| COUNT(*) |
+----------+
| 17774854 |
+----------+
1 row in set (48.76 sec)
暖机之后怎么样呢?
MariaDB> SELECT SQL_NO_CACHE COUNT(*) FROM hoge;
+----------+
| COUNT(*) |
+----------+
| 17774854 |
+----------+
1 row in set (11.81 sec)
这需要花费11秒钟……是因为所有设置都是默认的,所以是缓冲区不足,还是这是由于RocksDB的结构导致的开销呢。
无论如何,我已经明白在实际使用中需要进行调整。
最后
希望通过本文能够增加对MyRocks的了解和案例。许多企业正在考虑将MySQL 5.6迁移到MariaDB还是MySQL 5.7。希望这对这些企业也有所帮助。