InnoDB

  • 在上上周给下厨房做过一次数据恢复(故障回顾:故障发生的技术总结 致歉信),恢复使用了开源工具Percona Data Recovery Tool for InnoDB(后面简称PDRTI),这里分享一下期间的注意事项,和遇到MySQL数据丢失的一些应对。

    本文主要介绍在使用Percona Data Recovery Tool for InnoDB时候的一些注意事项,并不包括具体的step by step的使用步骤,使用文档可以参考:Reference Manual and Documentation(more…)

  • MySQL/InnoDB和Group Commit(2)

    ·

    今天发现Percona Release的Percona-Server-5-5-18-23-0已经完成了Group Commit工作,而且是用最优雅的方式(移植了MariaDB的实现,而不是workaround),心里难掩激动。

    这篇文章接前篇继续介绍一下问题的背景:什么是Group Commit,现在的官方版本Group Commit做到了什么程度?

    1. 什么是Group Commit

    MySQL/InnoDB在做事务的时候使用的日志先行(Write-ahead logging)的方式保证事务的快速和持久,所以每次事务完成都要求日志必须持久化到磁盘,在Linux上对应的操作就是“write and fsync”,write速度是很快的,一般对应的写Page Cache,而fsync则要求文件系统把对应文件的哦Page Cache必须持久化到磁盘上,而对于传统磁盘一次写操作大约需要1~3ms(不说BBU),这意味着对于传统磁盘1秒钟最多最多做333~1000个事务,这是不理想的,对硬件的利用率(吞吐量)也是非常低。

    所以,这里就有了Group操作的概念,即当好几个线程都要fsync同一个日志文件时,我们将这些fsync合并到一次来做。简单举例:我们让系统每2ms做一次fsync,这样如果这2ms内有100个线程都需要做fsync,那就赚到了,原本100个fsync都独立来做那耗时会非常多的。

    你肯定会说,难道这不是很简单的想法吗?是的,这就是原本是很简单、也很自然的想法。

    但对MySQL来说却变成了一种奢求(看看这个Bug讨论)。

    2. 为啥MySQL一直没有实现?

    MySQL是不是太弱了,这么简单的事情都搞不定?不是的。

    MySQL从开源到现在,成功的一个非常重要的原因,就是MySQL的插件式架构。如果MySQL只是MyISAM估计不会有现在的流行程度,插件式的架构让诸如Heikki Tuuri有了发挥空间,在InnoDB和MySQL一起时,MySQL才能算是一个真正的DBMS。再到后来,有Infobright、 FEDERATED、PBXT等等。

    插件式的架构给MySQL带来了活力,做出牺牲便是在上层(MySQL)和下层(存储引擎)交互时带来的额外消耗,有时甚至上层和下层需要做一些重复工作。无法做Group Commit就是这其中的牺牲之一。

    (more…)

  • 也说快速关闭MySQL/InnoDB

    ·

    如果用的引擎是InnoDB,每次敲下mysqladmin -uroot -p shutdown关闭数据库的时候,总是很难预测这个命令会执行多久,实际经验表明,短则五秒,长则三十分钟一小时都有可能。也分享一下我的经验吧。

    1. 为什么InnoDB关闭会慢?

    事实上,并不是每次关闭InnoDB都很慢的。Why?InnoDB较之MyISAM,一个重要特性是InnoDB会在内存中开辟一个Buffer Pool来存储最近访问的数据块/索引块,使得下次再次访问这个块时速度能够很快。当InnoDB对需要修改数据块的时候,会先记录修改日志,然后直接对Buffer_Pool中的数据块的操作。记录日志是顺序写,对数据块的操作是内存操作,这让InnoDB在很多场景下有这很好的速度优势。 (more…)

  • 很多人都讨论了这个问题,参数innodb_thread_concurrency限制了InnoDB内部线程的数量。例如当有query需要InnoDB处理时,InnoDB首先会检查一下当前的内部线程数是不是超过了innodb_thread_concurrency的限制,如果超出则会让当前线程sleep一会儿,再试,如果还是受限,则会进入一个FIFO的队列。如果innodb_thread_concurrency设置成0表示,内部线程数量将不受限制(注:innodb_thread_concurrency值在不同的版本意义略有不同)。

    1. 该参数设置成多少合适?

    我不知道多大合适。我的经验值设置成64就够了,正常情况,应用并发不会超过这个值。

    如果设置成0,会让InnoDB的内部线程不受限制,如果你高并发的IO-bound的应用,很可能在InnoDB内部累计很多的并发等待IO的线程,主机的Load会很高,但是数据库依然会正常运行。

    从5.1.11开始这个值的默认值是8,意味着,InnoDB会限制内部线程数不超过8。如果是高并发的应用,你的MySQL能力可能会受到这个参数的限制。对于很多情况这个值有偏小的,并发量可能会比8大,这时参数innodb_thread_concurrency就会成为InnoDB的瓶颈。对于一个16核的系统,处理的并发很多时候都会大于8,而受cpu核数限制,太多的线程会在CPU切换上消耗过多资源。

    但是如果你系统并发量始终都是小于8的,那么设置成一个大于8的值并没有意义。

    2. 高并发下实验

    通过supersmack模拟了128个线程并发,做了5组对比测试:

    innodb_thread_concurrency

    最后,提一下,没事不要在生产环境动态更改innodb_thread_concurrency,很危险:Bug 40760

    参考:

    1. MySQL Manual

    2. MySQL: innodb_thread_concurrency beast

    3. do we still need innodb_thread_concurrency

    4. Mess with innodb_thread_concurrency

    5. InnoDB线程并发检查机制

    6. MySQL Bugs

  • MySQL/InnoDB和Group Commit(1)

    ·

    估计相关的东西一篇文章是讲不清楚的。

    这个问题由来已久,Kristian Nielsen连续写了四篇文章《Fixing MySQL group commit》(part 1 | part 2 | part 3 | part 4 )深入细致的分析了“故事”的前因后果。本文完全没有任何新意,仅做一个小的总结。这里会先介绍一下什么是“Group Commit”,MySQL/InnoDB里面的Group Commit为什么引起如此大的关注,现在是怎么解决问题的。 (more…)

  • 这是该系列的第三篇文章(12)了。之所以选择并发线程控制着手研究InnoDB的代码有两个原因:第一,这段代码相对独立,不要了解太多的相关代码就可以理解;第二,稍微多看一些代码你会发现,到处都是线程并发控制相关的代码出现,所以这也是一个基础。

    第一篇中,介绍了InnoDB内部排他锁的实现,第二篇则介绍InnoDB内部读写锁的实现原理(这里说的“内部”是为了区别于数据库层面的读写锁)。本篇则将延续第二篇,介绍读写锁相关的代码实现。 (more…)