InnoDB

  • 作为DBA关心的更多的可能是原理、机制,对于源码一般大家也不是特别关心,也不太用得上。而且对于对于源代码级别的细节也很难用文字表达自己的理解,最终理解必须还是需要自己去看看每一行代码到底是怎样的。也读过《Understanding.MySQL.Internals》的大部分章节,作者也是偏重于从代码的实现目的(原理、机制)来介绍的,国内的《MySQL核心内幕》(个人对于“核心内幕”这个词有莫名的反感)算是更多的从源码开始介绍MySQL了,可是这本书也许是授予篇幅的限制,介绍的东西也并不多。

    开始写这篇文章,不能期待自己能写多少,也不能期待自己能研究多少,不过至少走出了自己探索的第一步。文章的宗旨不在于能够多么细致的分析MySQL的源代码,而是希望能给自己,能给他人打开走向源代码的第一道门。

    我是BNU数学系毕业的,对C语言知道甚少,C语言的经历大概就是“计算方法”课程中实现的求解各种方程的撇脚程序了。所以虽然我会极力避免错误,但是相信还是会犯一堆错误,希望各位看官能够宽容点,有错误指出来,慢慢改正。

    0. 开始

    InnoDB的代码通过宏定义考虑很多平台的兼容问题,这里分析的主要是类Unix/Linux平台(POSIX标准)的代码段,所以下面的很多代码段也是删除相关兼容性代码的。本文InnoDB源码是Plugin1.0.6版本。[……]

    Read more

  • InnoDB Corruption

    ·

    以前没有遇到InnoDB文件损坏的情况,特此记录。从日志来看,损坏的应该是一个索引页,导致对应的数据表无法访问,也无法获取对应数据表中的数据,尝试check optimize也无法修复。最后设置innodb_force_recovery=1后启动数据库后,能够导出全部数据。

    1. 故障

    最近,在从一个Xtrabackup的备份中恢复数据后,发现MySQL数据库能正常启动,但是发现use dbname一下MySQL就会崩溃,看日志:[……]

    Read more

  • MySQL Optimize Table

    ·

    很难说Optimize Table到底能不能提高系统运行效率,但是有一点是肯定的:它能够帮我们回收更多的空间、减少“碎片”(defragment)

    1. 回收空间 Defragment

    在InnoDB的维护过程中,我们总会遇到磁盘耗尽、或者InnoDB Tablespaces用完的情况。这时候,在考虑扩容等方案之前,最好先使用Optimize Table试试。如果你的表大字段(Text Blob Varchar),并且更新、删除较频繁的话,Optimize之后可能会腾出大量的空间。[……]

    Read more

  • InnoDB Plugin在快速DDL上做了一些改进,在做的实验中看到,创建secondary indexes时,大约快了20%。

    1. 原理

    在MySQL5.0里面,如果数据表的记录数很多,增加和删除索引是非常慢的。CREATE INDEX and DROP INDEX命令是通过先创建一个空的临时表,这个表就是你新增或删除索引后的结构,然后把原表中的全部记录都拷贝(插入)到新的临时表中,最后把原表删除,临时表重命名成原表。

    MySQL5.1的一些架构上的改变,可以简化上面的过程(不再需要逐行拷贝数据)。InnoDB Plugin利用这个改变,缩短了大多数情况下的索引变更时间。对InnoDB来说有两类索引:the clustered index and secondary indexes。因为InnoDB的主键是the clustered index,数据存放再此,所以,删除或者添加主键(the clustered index)逐行拷贝也是必须[……]

    Read more

  • 这两天是O’Reilly MySQL Conference & Expo,期间有很多关于MySQL的相关话题的介绍,包括MySQL、PBXT、Drizzle、MariaDB、XtraDB等等,不过最抢风头的应该是InnoDB1.0.7GA(with MySQL-5.5)的新特性,回头想想,Oracle/InnoDB也酝酿了很久的吧。

    无论如何,这些新特性中最吸引我的是InnoDB的Faster Recovery。

    一般地,MySQL/InnoDB都是运行在普通的PC Server + Linux(Unix),虽然不期待小型机+AIX的高可用,但想尽一切办法缩短MySQL的不可用时间,仍然是DBA的目标。根据经验,主机OS崩溃、硬件故障,仍然是影响MySQL可用性的最主要因素,当这些故障(OS、硬件)恢复后,另一个非常耗时的恢复就是InnoDB自己的恢复时间。一般主机发生一次重启,正常大约<5分钟,而这时InnoDB恢复可能需要40分钟或者更久(这依赖于Buffer Pool、脏页面比例、TPS等因素)。[……]

    Read more

  • InnoDB Plugin特性介绍-1

    ·

    迫于开源社区、团体(Google Facebook Percona Xaprb等)的巨大压力,InnoDB Plugin相比Built-in版本有了很大的提升,这些提升多数来自开源社区贡献的代码,虽然本身也有一些改进。

    1. 关于Fast locking

    在多个线程并发访问相同资源的时候,需要使用一些InnoDB实现的互斥量(mutex)和读写锁(read/write lock)。在Unix-like平台上,InnoDB是通过Pthread的互斥量(这是POSIX标准的一部分)来实现的。在现代OS和硬件平台中,一般都有了更有效的替代方案,多数情况下这些替代方案使用更少的CPU指令和时钟周期来完成这些互斥处理。
    [……]

    Read more