数据库内核月报 - 2015 / 08-MySQL · TokuDB · 疯狂的 filenum++

本文涉及的产品
RDS MySQL DuckDB 分析主实例,集群系列 4核8GB
RDS AI 助手,专业版
RDS MySQL DuckDB 分析主实例,基础系列 4核8GB
简介:

问题描述

收到一枚RDS TokuDB实例crash导致HA切换的报警,上去一看错误如下:

tokudb/ft-index/ft/cachetable/cachetable.cc toku_cachetable_openfd_with_filenum: Assertion `filenum.fileid != FILENUM_NONE.fileid' failed
/bin/mysqld(_Z19db_env_do_backtraceP8_IO_FILE+0x1b)[0xc57ddb]
/bin/mysqld(_Z35toku_cachetable_openfd_with_filenumPP9cachefileP10cachetableiPKc7FILENUMPb+0x223)[0xbb49b3]
/bin/mysqld(_Z19toku_ft_handle_openP9ft_handlePKciiP10cachetableP7tokutxn+0x135)[0xbf3c05]
/bin/mysqld(_Z20toku_ft_handle_clonePP9ft_handleS0_P7tokutxn+0xb5)[0xbf42f5]
/bin/mysqld(_Z29toku_db_lt_on_create_callbackPN4toku8locktreeEPv+0x2a)[0xb801ba]
/bin/mysqld(_Z18toku_db_open_inameP9__toku_dbP13__toku_db_txnPKcji+0x276)[0xb805b6]
/bin/mysqld(_ZN9ha_tokudb20open_main_dictionaryEPKcbP13__toku_db_txn+0x1ab)[0xb50a0b]
/bin/mysqld(_ZN9ha_tokudb16initialize_shareEPKci+0x2c8)[0xb70848]
/bin/mysqld(_ZN9ha_tokudb4openEPKcij+0x5e9)[0xb71349]
/bin/mysqld(_ZN7handler7ha_openEP5TABLEPKcii+0x33)[0x5e74b3]

这个错误信息在RDS上第一次碰到,隐隐感到这是一个“可遇不可求”的bug导致,开始捉虫。

问题分析

每个表(索引)文件被打开后,TokuDB都会为这个文件赋予一个唯一id,即filenum。

filenum有什么作用?
TokuDB在写redo log的时候,每个事务里会带一个filenum属性,用来标示该事务属于哪个表文件,在崩溃恢复的时候,会根据这个filenum回放到相应的表里。

filenum在什么时候被分配?
表(索引)文件被打开的时候会被分配。

filenum如何分配?
为了保证唯一性,TokuDB维护了一个filenum数据结构(类似binary tree) : m_active_filenum,分配算法:

uint32_t m_next_filenum_to_use;  //全局变量,用来标识已分配的最大filenum
lock();
retry:
int ret = m_active_filenum.find(m_next_filenum_to_use);
if (ret == 0) {
  //m_next_filenum_to_use被占用
  m_next_filenum_to_use++;
  goto retry;
}
filenum = m_next_filenum_to_use; //得到我们想要的filenum
m_next_filenum_to_use++;
unlock();

这样问题就来了,如果用户有非常多的表(索引)文件,不停的被打开和关闭,m_next_filenum_to_use会一直递增下去,由于是uint32_t类型,小宇宙终于爆发了,filenum 递增到4294967295(UINT_MAX),从而导致assert失败。

问题修复

当一些表(索引)文件被close后,这些filenum可以被回收再利用,所以当filenum递增到UINT_MAX后,重置到0即可:

uint32_t m_next_filenum_to_use;  //全局变量,用来标识已分配的最大filenum
lock();
retry:
int ret = m_active_filenum.find(m_next_filenum_to_use);
if (ret == 0) {
  //m_next_filenum_to_use被占用
  m_next_filenum_to_use++;
  goto retry;
}
// 从0开始重新获取未被使用的filenum
if (m_next_filenum_to_use == UINT_MAX) {
  m_next_filenum_to_use = 0;
  goto retry;
}
filenum = m_next_filenum_to_use; //得到我们想要的filenum
m_next_filenum_to_use++;
unlock();

RDS版本已修复此问题,官方patch戳这里

相关实践学习
每个IT人都想学的“Web应用上云经典架构”实战
本实验从Web应用上云这个最基本的、最普遍的需求出发,帮助IT从业者们通过“阿里云Web应用上云解决方案”,了解一个企业级Web应用上云的常见架构,了解如何构建一个高可用、可扩展的企业级应用架构。
MySQL数据库入门学习
本课程通过最流行的开源数据库MySQL带你了解数据库的世界。   相关的阿里云产品:云数据库RDS MySQL 版 阿里云关系型数据库RDS(Relational Database Service)是一种稳定可靠、可弹性伸缩的在线数据库服务,提供容灾、备份、恢复、迁移等方面的全套解决方案,彻底解决数据库运维的烦恼。 了解产品详情: https://www.aliyun.com/product/rds/mysql 
目录
相关文章
|
5月前
|
缓存 关系型数据库 BI
使用MYSQL Report分析数据库性能(下)
使用MYSQL Report分析数据库性能
440 158
|
5月前
|
关系型数据库 MySQL 数据库
阿里云数据库RDS费用价格:MySQL、SQL Server、PostgreSQL和MariaDB引擎收费标准
阿里云RDS数据库支持MySQL、SQL Server、PostgreSQL、MariaDB,多种引擎优惠上线!MySQL倚天版88元/年,SQL Server 2核4G仅299元/年,PostgreSQL 227元/年起。高可用、可弹性伸缩,安全稳定。详情见官网活动页。
1029 152
|
5月前
|
关系型数据库 MySQL 数据库
阿里云数据库RDS支持MySQL、SQL Server、PostgreSQL和MariaDB引擎
阿里云数据库RDS支持MySQL、SQL Server、PostgreSQL和MariaDB引擎,提供高性价比、稳定安全的云数据库服务,适用于多种行业与业务场景。
812 156
|
5月前
|
缓存 监控 关系型数据库
使用MYSQL Report分析数据库性能(中)
使用MYSQL Report分析数据库性能
418 156
|
5月前
|
关系型数据库 MySQL 分布式数据库
阿里云PolarDB云原生数据库收费价格:MySQL和PostgreSQL详细介绍
阿里云PolarDB兼容MySQL、PostgreSQL及Oracle语法,支持集中式与分布式架构。标准版2核4G年费1116元起,企业版最高性能达4核16G,支持HTAP与多级高可用,广泛应用于金融、政务、互联网等领域,TCO成本降低50%。
|
5月前
|
关系型数据库 分布式数据库 数据库
阿里云数据库收费价格:MySQL、PostgreSQL、SQL Server和MariaDB引擎费用整理
阿里云数据库提供多种类型,包括关系型与NoSQL,主流如PolarDB、RDS MySQL/PostgreSQL、Redis等。价格低至21元/月起,支持按需付费与优惠套餐,适用于各类应用场景。
|
5月前
|
SQL 关系型数据库 MySQL
Mysql数据恢复—Mysql数据库delete删除后数据恢复案例
本地服务器,操作系统为windows server。服务器上部署mysql单实例,innodb引擎,独立表空间。未进行数据库备份,未开启binlog。 人为误操作使用Delete命令删除数据时未添加where子句,导致全表数据被删除。删除后未对该表进行任何操作。需要恢复误删除的数据。 在本案例中的mysql数据库未进行备份,也未开启binlog日志,无法直接还原数据库。
|
5月前
|
关系型数据库 MySQL 数据库
自建数据库如何迁移至RDS MySQL实例
数据库迁移是一项复杂且耗时的工程,需考虑数据安全、完整性及业务中断影响。使用阿里云数据传输服务DTS,可快速、平滑完成迁移任务,将应用停机时间降至分钟级。您还可通过全量备份自建数据库并恢复至RDS MySQL实例,实现间接迁移上云。
|
5月前
|
缓存 监控 关系型数据库
使用MYSQL Report分析数据库性能(上)
最终建议:当前系统是完美的读密集型负载模型,优化重点应放在减少行读取量和提高数据定位效率。通过索引优化、分区策略和内存缓存,预期可降低30%的CPU负载,同时保持100%的缓冲池命中率。建议每百万次查询后刷新统计信息以持续优化
522 161
|
6月前
|
存储 运维 关系型数据库
从MySQL到云数据库,数据库迁移真的有必要吗?
本文探讨了企业在业务增长背景下,是否应从 MySQL 迁移至云数据库的决策问题。分析了 MySQL 的优势与瓶颈,对比了云数据库在存储计算分离、自动化运维、多负载支持等方面的优势,并提出判断迁移必要性的五个关键问题及实施路径,帮助企业理性决策并落地迁移方案。

相关产品

  • 云数据库 RDS MySQL 版
  • 推荐镜像

    更多