问题描述

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

  1. tokudb/ft-index/ft/cachetable/cachetable.cc toku_cachetable_openfd_with_filenum: Assertion `filenum.fileid != FILENUM_NONE.fileid' failed
  2. /bin/mysqld(_Z19db_env_do_backtraceP8_IO_FILE+0x1b)[0xc57ddb]
  3. /bin/mysqld(_Z35toku_cachetable_openfd_with_filenumPP9cachefileP10cachetableiPKc7FILENUMPb+0x223)[0xbb49b3]
  4. /bin/mysqld(_Z19toku_ft_handle_openP9ft_handlePKciiP10cachetableP7tokutxn+0x135)[0xbf3c05]
  5. /bin/mysqld(_Z20toku_ft_handle_clonePP9ft_handleS0_P7tokutxn+0xb5)[0xbf42f5]
  6. /bin/mysqld(_Z29toku_db_lt_on_create_callbackPN4toku8locktreeEPv+0x2a)[0xb801ba]
  7. /bin/mysqld(_Z18toku_db_open_inameP9__toku_dbP13__toku_db_txnPKcji+0x276)[0xb805b6]
  8. /bin/mysqld(_ZN9ha_tokudb20open_main_dictionaryEPKcbP13__toku_db_txn+0x1ab)[0xb50a0b]
  9. /bin/mysqld(_ZN9ha_tokudb16initialize_shareEPKci+0x2c8)[0xb70848]
  10. /bin/mysqld(_ZN9ha_tokudb4openEPKcij+0x5e9)[0xb71349]
  11. /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，分配算法：

  1. uint32_t m_next_filenum_to_use;  //全局变量，用来标识已分配的最大filenum
  2. lock();
  3. retry:
  4. int ret = m_active_filenum.find(m_next_filenum_to_use);
  5. if (ret == 0) {
  6.   //m_next_filenum_to_use被占用
  7.   m_next_filenum_to_use++;
  8.   goto retry;
  9. }
  10. filenum = m_next_filenum_to_use; //得到我们想要的filenum
  11. m_next_filenum_to_use++;
  12. unlock();

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

问题修复

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

  1. uint32_t m_next_filenum_to_use;  //全局变量，用来标识已分配的最大filenum
  2. lock();
  3. retry:
  4. int ret = m_active_filenum.find(m_next_filenum_to_use);
  5. if (ret == 0) {
  6.   //m_next_filenum_to_use被占用
  7.   m_next_filenum_to_use++;
  8.   goto retry;
  9. }
  10. // 从0开始重新获取未被使用的filenum
  11. if (m_next_filenum_to_use == UINT_MAX) {
  12.   m_next_filenum_to_use = 0;
  13.   goto retry;
  14. }
  15. filenum = m_next_filenum_to_use; //得到我们想要的filenum
  16. m_next_filenum_to_use++;
  17. unlock();

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