MySQL内核月报 2014.10-MySQL· 捉虫动态·崩溃恢复失败

现象

  5.6版本,在创建InnoDB表过程中,若发生crash,会导致服务无法启动。

背景

  每个InnoDB表A创建成功后有两个文件A.frm和A.ibd。建表流程如下:

  1、创建A.frm

  2、创建A.ibd

  3、初始化A.ibd

  4、将表A加入InnoDB字典

若crash发生在步骤2之后,则只保留一个完整的A.frm和一个空文件A.idb。

崩溃恢复

  在上述的crash发生后,下一次启动则需要做崩溃恢复。崩溃恢复的一个逻辑是需要遍历数据目录下的所有.ibd文件,验证文件与字典的一致性。

  对于长度为0的.ibd 文件,报错并跳过,继续检测下一个表。

  以上是5.5和5.6共有的逻辑。但5.6的一个新特性破坏了这个规则。

远程目录

  5.6支持create table的时候指定其他目录。语法是create table 里新增参数DATA DIRECTORY.这样一个表就可能存在多个表空间。每个表空间对应一个数据结构(fsp_open_info).

  这意味着在崩溃恢复过程中,需要验证哪一个表空间是可用的(fil_validate_single_table_tablespace),

  验证的方法是尝试读取该表空间的第一个page,若可用则将对应的fsp_open_info::success设置为TRUE。

  而在读取本地默认表空间的第一个页时,若碰到读取失败,直接exit(1),导致程序直接退出。“若文件小于4个page就报错”的逻辑,是在这个exit之后。

分析改进

  其实在这个场景下,多出来的A.frm和A.ibd并不会导致系统严重问题。由于表A还没有记录入系统字典,实际上只需要将这两个文件直接删掉即可。

  因此5.6的这个新增要求过于苛刻。改进方法是将文件大小的判断提前,若发现小于4个page,则直接报错跳过这个表。

时间: 2024-11-10 05:21:44

MySQL内核月报 2014.10-MySQL· 捉虫动态·崩溃恢复失败的相关文章

MySQL内核月报 2014.10-MySQL· 捉虫动态·binlog重放失败

背景 在 MySQL 日常维护中,要回滚或者恢复数据,我们经常会用 binlog 来在数据库上重放,执行类似下面的语句: mysqlbinlog mysql-bin.000001 | mysql -hxxxx -Pxx -u 最近遇到了这样一个问题,在重放 binlog 时,mysqld 报这样的错 ERROR 1064 (42000) at line 25: You have an error in your SQL syntax; check the manual that correspo

MySQL内核月报 2014.11-MySQL· 捉虫动态·SIGHUP 导致 binlog 写错

bug描述 这是5.6中和gtid相关的一个bug,当 mysqld 收到 sighup 信号 (比如 kill -1) 的时候,会 flush binlog,但是新生成binlog开头没写 Previous_gtids_log_event,这会导致下面 2 个问题: 这个时候 mysqld 重启的话,会发现再也起不来了,error log 里有这样的错 The binary log file 'mysql/mysql-bin.000020' is logically corrupted: Th

MySQL内核月报 2014.09-MySQL· 捉虫动态·GTID 和 DELAYED

描述 这是一个MySQL 5.6才有的bug,影响包含最新版本.涉及到的概念有GTID.DELAYED. 现象 在5.6主备都开启GTID-MODE的时候,备库同步线程停止,且Last_SQL_Error显示"When @@SESSION.GTID_NEXT is set to a GTID, you must explicitly set it to a different value after a COMMIT or ROLLBACK. Please check GTID_NEXT var

MySQL内核月报 2014.09-MySQL· 捉虫动态·auto_increment

背景: Innodb引擎使用B_tree结构保存表数据,这样就需要一个唯一键表示每一行记录(比如二级索引记录引用). Innodb表定义中处理主键的逻辑是: 1.如果表定义了主键,就使用主键唯一定位一条记录 2.如果没有定义主键,Innodb就生成一个全局唯一的rowid来定位一条记录 auto_increment的由来: 1.Innodb强烈推荐在设计表中自定义一个主键,因为rowid是全局唯一的,所以如果有很多表没有定义主键,就会在生成rowid上产生争用. row_id由mutex保护,并

MySQL内核月报 2014.08-MySQL· 捉虫动态·Count(Distinct) ERROR

背景 MySQL现行版本中存在一个count(distinct)语句返回结果错误的bug,表现为,实际结果存在值,但是用count(distinct)统计后返回的是0. 原因分析 Count(distinct f)的语义就是计算字段f的去重总数,计算流程大致如下: 流程一: 1. 构造一个unique集合A1(用tree实现) 2. 对每个值都试图插入集合A1中 3. 若和A1中现有item重复则直接跳过,不重复则插入并+1 4. 完成后计算集合中元素个数. 细心的同学会看到上面的语句中有一个s

MySQL内核月报 2014.10-MySQL· 捉虫动态·从库OOM

bug背景 官方最近发布的版本(5.7.5)修复了这样一个bug,主备复制场景下,如果主库和备库对应的表结构中有数据类型不一致,并且主库的 binlog 是 row 格式的,这时候如果主库对不一致的表做了一个大事务更新,备库在应用 relay-log 的时候报OOM(Out of Memory).bug地址在这里,主备数据类型不一致主要发生在这2种情况下: 主备库版本不一致,不同版本之间的数据类型可能存在不一致.用户在报这个bug时,就是在5.5到5.6的复制场景下,用到了时间类型,时间类型在5

MySQL内核月报 2014.12-MySQL· 捉虫动态·Opened tables block read only

背景 MySQL通过read_only参数来设置DB只读,这样MySQL实例就可以作为slave角色,只应用binlog,不接受用户修改数据.这样就可以保护master-slave结构中的数据一致性,防止双写风险. global read_only的实现方式 MySQL5.5版本通过三个步骤来设置read_only: 步骤1:获取global read lock,阻塞所有的写入请求 步骤2:flush opened table cache,阻塞所有的显示读写锁 步骤3:获取commit lock

MySQL内核月报 2014.09-MySQL· 捉虫动态·GTID 和 binlog_checksum

现象描述 在5.6主备环境下,主备都开启GTID-MODE,备库开启crc校验,主库不开.重启备库sql线程后,备库sql线程停止Last_Error显示:Relay log read failure: Could not parse relay log event entry. The possible reasons are: the master's binary log is corrupted(you can check this by running 'mysqlbinlog' on

MySQL内核月报 2014.11-MySQL· 捉虫动态·OPTIMIZE 不存在的表

bug 描述 这是一个和 GTID 相关的Bug,也就是说5.6才会有,并且出现这个 bug 需要满足条件: 做修改性质的表管理操作,如 OPTIMIZE/ANALYZE/REPAIR 可以,CHECK 就不可以 操作对应的表不存在 gtid_next 被设置为一个固定的值,并且 binlog 开启 在同时满足这3种条件下,会发现记录binlog时,对应的 Gtid_log_event 中的UUID会记为 00000000-0000-0000-0000-000000000000,并且这个对应的