内容简介:TokuDB 引擎提供很好的压缩比(笔者环境中的数据在默认的 zlib 设置下压缩比大致为 InnoDB:TokuDB ~= 5:1), 以及快速增加, 删除, 重命名列, 热更索引等特性, 这些特性很适合日志记录类的表来使用, 该类表可以仅做主从复制, 不做定期的备份. 如果需要备份可以参考更多基础的特性说明可以参考以前的文章:TokuDB 使用简单说明. 下述的问题列表则主要介绍在使用 TokuDB 的过程中碰到的一些问题, 后期碰到的问题也会在该列表中持续更新.详见
简单介绍
TokuDB 引擎提供很好的压缩比(笔者环境中的数据在默认的 zlib 设置下压缩比大致为 InnoDB:TokuDB ~= 5:1), 以及快速增加, 删除, 重命名列, 热更索引等特性, 这些特性很适合日志记录类的表来使用, 该类表可以仅做主从复制, 不做定期的备份. 如果需要备份可以参考 AliSQLBackup
, 其基于 xtrabackup-2.3.5
版本, 可以同时备份 InnoDB 和 TokuDB 引擎的表. 另外 innodb_buffer_pool_size
和 tokudb_cache_size
两个参数的值需要按需分配, 如果没有多少 InnoDB 表, 最好调小 innodb_buffer_pool_size
的值.
更多基础的特性说明可以参考以前的文章:TokuDB 使用简单说明. 下述的问题列表则主要介绍在使用 TokuDB 的过程中碰到的一些问题, 后期碰到的问题也会在该列表中持续更新.
问题列表
- 修改分区表耗时长问题处理
- 转换 InnoDB 大表到 TokuDB 崩溃问题
- 修改 tokudb_data_dir 参数出现不能找到文件错误
- temp 锁占用不能启动问题
修改分区表耗时长问题处理
转换 InnoDB 大表到 TokuDB 崩溃问题
在将一个 80G 的 InnoDB 表转为 TokuDB 的时候出现以下错误, 数据库进程也崩溃退出:
Feb 18 12:25:56 db1 mysqld-3328: /mnt/workspace/percona-server-5.6-binaries-release/label_exp/centos6-64/percona-server-5.6.38-83.0/storage/tokudb/PerconaFT/src/load er.cc:471 toku_loader_abort: Assertion `r == 0' failed (errno=28) (r=28) Feb 18 12:25:56 db1 mysqld-3328: : No space left on device Feb 18 12:25:56 db1 mysqld-3328: Backtrace: (Note: toku_do_assert=0x0x7fb7404daa10) Feb 18 12:25:56 db1 mysqld-3328: /opt/Percona-Server-5.6.38-rel83.0-Linux.x86_64.ssl101/lib/mysql/plugin/ha_tokudb.so(_Z19db_env_do_backtraceP8_IO_FILE+0x1b)[0x7fb7404d3adb] ...
从上面的错误来看是因为磁盘空间不足而引起的, 修改表的时候需要保存一些临时文件到 MySQL 的 tmpdir 指定的目录中, 上面的实例中 tokudb_tmp_dir 的值为 /dev/shm, 使用了 tmpfs 来存储临时的文件. 该系统下 /dev/shm
的可用空间仅有 32G, 如下所示:
# df -hl /dev/shm Filesystem Size Used Avail Use% Mounted on tmpfs 32G 16G 83G 50% /dev/shm
这也就说明了临时文件的大小超过了 /dev/shm
设置的容量. 如下所示为修改表的过程中 /dev/shm
中产生的临时文件:
# ls -hl /dev/shm/ | less total 18G -rw------- 1 mysql mysql 0 Feb 18 10:15 __tokudb_lock_dont_delete_me_temp -rw------- 1 mysql mysql 1.1M Feb 18 13:10 tokuld00TjtL -rw------- 1 mysql mysql 1.3M Feb 18 13:24 tokuld022Xnh -rw------- 1 mysql mysql 1.2M Feb 18 13:13 tokuld028HPP ......
解决该问题可以使用下面两种方式中的一种:
临时增大 /dev/shm 设备的大小
可以临时增大设备大小, 更改完成后再改为 32G 即可. 该设备的最大有效大小受 kernel.shmmax
参数控制. 默认为系统内存的大小.
mount -o remount,size=64G,noatime /dev/shm
修改 tokudb_tmp_dir
参数路径信息, 重启实例
也可以修改 tmpdir 的路径, 确保有足够的大小, 更改完成后再修改回来.
修改 tokudb_data_dir 参数出现不能找到文件错误
在设置完 tokudb 参数后, 所有创建的表都通过 tokudb.directory 保存对应的映射关系, 如下所示:
mysql root@[localhost:s3340 information_schema] > select dictionary_name, internal_file_name, table_name from TokuDB_file_map; +---------------------------+------------------------------------------------------------------------------------+------------+ | dictionary_name | internal_file_name | table_name | +---------------------------+------------------------------------------------------------------------------------+------------+ | ./percona/user-key-idx_id | /export/mysql/node3340/data/tokudb_data/_percona_user_key_idx_id_6_3_1d_B_0.tokudb | user | | ./percona/user-main | /export/mysql/node3340/data/tokudb_data/_percona_user_main_4_2_1d.tokudb | user | | ./percona/user-status | /export/mysql/node3340/data/tokudb_data/_percona_user_status_4_1_1d.tokudb | user | +---------------------------+------------------------------------------------------------------------------------+------------+ .....
这种绝对路径的映射关系是固定的不可修改的. 这种方式意味着我们在做备份恢复的时候不能修改 tokudb_data_dir 参数值, 对应的绝对路径也不能修改. 如下所示, 在更改 tokudb_data_dir 为不同的路径后, 查询表出现以下错误, 因为映射关系对应不上:
ERROR 1017 (HY000): Can't find file 'xxxxx'
这点限制没有 InnoDB 方便, 也带来了很多不便, 比如我们想更换实例端口, 变更目录等都不可行, 除非 tokudb_data_dir 指定为相对路径的目录, 变更起来就很方便, 如下所示:
tokudb_data_dir = tokudb_data
这种参数即为相对目录, 具体的路径则为 $mysql_datadir/tokudb_data, 查看映射关系如下:
mysql root@[localhost:s3342 information_schema] > select * from TokuDB_file_map; +----------------------------+-----------------------------------------------------+--------------+------------+-----------------------+ | dictionary_name | internal_file_name | table_schema | table_name | table_dictionary_name | +----------------------------+-----------------------------------------------------+--------------+------------+-----------------------+ | ./percona/user_find-main | tokudb_data/_percona_user_find_main_4_2_1d.tokudb | percona | user_find | main | | ./percona/user_find-status | tokudb_data/_percona_user_find_status_4_1_1d.tokudb | percona | user_find | status | +----------------------------+-----------------------------------------------------+--------------+------------+-----------------------+
temp 锁占用不能启动问题
在一台主机上运行多个 TokuDB 实例的时候, 出现了以下错误:
Feb 18 14:22:27 dbinfo8 mysqld-3342: 2019-02-19 14:22:27 7f2b6dff9700 InnoDB: Loading buffer pool(s) from .//ib_buffer_pool Feb 18 14:22:27 dbinfo8 mysqld-3342: Couldn't start tokuft because some other tokuft process is using the same directory [/dev/shm] for [temp] Feb 18 14:22:27 dbinfo8 mysqld-3342: 2019-02-19 14:22:27 37280 [ERROR] TokuDB unknown error 11 Feb 18 14:22:27 dbinfo8 mysqld-3342: 2019-02-19 14:22:27 37280 [ERROR] Plugin 'TokuDB' init function returned error. Feb 18 14:22:27 dbinfo8 mysqld-3342: 2019-02-19 14:22:27 37280 [ERROR] Plugin 'TokuDB' registration as a STORAGE ENGINE failed.
/dev/shm
目录中仅包含一个文件 /dev/shm/__tokudb_lock_dont_delete_me_temp
, 使用 lsof 查看使用的进程如下:
# lsof /dev/shm/__tokudb_lock_dont_delete_me_temp COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME mysqld 35338 mysql 15uW REG 0,19 0 11786530 /dev/shm/__tokudb_lock_dont_delete_me_temp
可以看到已经有进程占用了 __tokudb_lock_dont_delete_me_temp
, 该文件用来保护 TokuDB 的临时文件, 避免多个进程并发访问的时候操作同一临时目录的文件. 由此来看出现错误的原因是另一个 TokuDB 实例的 tmp 目录设置的也是 /dev/shm
, 将 tokudb_tmp_dir
修改掉即可解决该问题. 该参数留空的话则 __tokudb_lock_dont_delete_me_temp
会存放到 tokudb_data_dir
的目录中.
以上就是本文的全部内容,希望本文的内容对大家的学习或者工作能带来一定的帮助,也希望大家多多支持 码农网
猜你喜欢:- 【iOS 开发】ReactiveObjC(RAC)的使用汇总
- 使用Spring Data Jpa遇到问题汇总
- Nacos使用中的常见问题汇总
- HTML5中Audio使用踩坑汇总
- 近期使用新冠疫情(COVID-19)为诱饵的APT攻击活动汇总
- Redis 应用场景汇总
本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。
数据库索引设计与优化
【美】Tapio Lahdenmaki、【美】Michael Leach / 曹怡倩、赵建伟 / 电子工业出版社 / 2015-6 / 79.00元
《数据库索引设计与优化》提供了一种简单、高效、通用的关系型数据库索引设计方法。作者通过系统的讲解及大量的案例清晰地阐释了关系型数据库的访问路径选择原理,以及表和索引的扫描方式,详尽地讲解了如何快速地估算SQL 运行的CPU 时间及执行时间,帮助读者从原理上理解SQL、表及索引结构、访问方式等对关系型数据库造成的影响,并能够运用量化的方法进行判断和优化,指导关系型数据库的索引设计。 《数据库索......一起来看看 《数据库索引设计与优化》 这本书的介绍吧!