MySQL为什么要引入Thread Pool的线程处理模式

从5.5.16开始,在MySQL的商业化版本中将Thread Pool作为plugin提供官方功能支持。在之前的版本中,线程处理模式包括两种:no-threads(单线程处理,多用于debug)、one-thread-per-connection(每个请求对应一个线程,目前被作为默认值);在支持thread pool功能的版本中,thread_handling则需设置为dynamically-loaded。
      » 继续阅读 MySQL为什么要引入Thread Pool的线程处理模式

MySQL Tuning之浅析I/O优化

目前web的应用大多都以I/O密集型为主,而存储技术的发展远没有计算机中其他系统发展迅速,尽管也有不少高端存储设备,但是价格的昂贵,不是一般大众能享受的起的。而基于现状更多是我们使用一般SAS盘结合应用使用不同的RAID组合,来实现我们平民化存储,为了得到更好的性能,那么和I/O相关的调整优化是必不可少的。
      » 继续阅读 MySQL Tuning之浅析I/O优化

MTU值的调整导致MySQL复制异常

今天的故事简单有趣,你绝对没有遇到过。当我们把网卡的MTU值从默认的1500,调整为3000/6000/9000后,复制十分诡异,搞得我云里来雾里去的,先记录下:

以下命令可以动态修改MTU值及时生效,和查看状态的一些命令:

shell> ifconfig eth1 mtu 3000 up (永久生效可以增加MTU=XXXX到配置文件ifcfg-ethN中)

shell> ip link list eth1
      » 继续阅读 MTU值的调整导致MySQL复制异常

“ERROR 1235 (42000): skip-innodb is defined”的误导

ERROR 1235 (42000): Cannot call SHOW INNODB STATUS because skip-innodb is defined

以上这个醒目错误提示,如果你是一个细心专业的DBA的话,可能这辈子你也遇到这样的问题,而我不是,毛躁马虎加上不专业,已经成了我的标签,所以,“幸运的”本人才遭遇到这个Error。究竟怎么一个动作导致出现这样的错误呢,下面简单描述下。
      » 继续阅读 “ERROR 1235 (42000): skip-innodb is defined”的误导

Heartbeat+DRBD+MySQL Replication故障处理

不久前的一次机房网络故障,再一次对我们在Heartbeat+DRBD+MySQL数据库架构运维水平的一个考验,之前不止一次的测试与线上部署,还有之后大言不惭的关于该架构组件的所谓深入理解,在这一次不经意的意外面前又是“很囧”的收场,慌张呀!这次断网导致H-D-M全线异常,真是千载难逢,都让我们赶上啦lol: 下面就把这次的小幸运小幸福和大家分享下,以下是按照问题处理的先后顺序依次讲述。
      » 继续阅读 Heartbeat+DRBD+MySQL Replication故障处理

Innodb Crash Recovery恢复时间的飞跃

之前没经历过漫长的crash recovery恢复过程,一是本身库中的数据量就不大,平时的业务量就不是很高,二是innodb_buffer_pool_size和innodb_log_file_size的大小平时设置的也不大。所以,对于意外导致innodb自动恢复时,经历的等待时间的长短没有什么深刻的体会。在浏览peter很早以前的文章时,看到当时大家是多么的无奈和痛苦,同时,在InnoDB没有对其作出改进之前,大家都在开动脑筋,配合各种参数尽可能的缩短故障恢复的时间。先来了解下,什么是Crash Recovery,它究竟都帮我们做了什么。
      » 继续阅读 Innodb Crash Recovery恢复时间的飞跃

快速预热Innodb Buffer Pool的方法

当innodb_buffer_pool_size大到几十GB或是百GB的时候,因为某些日常升级更新或是意外宕机,而必须要重新启动mysqld服务的之后,就面临一个问题,如何将之前频繁访问的数据重新加载回buffer中,也就是说,如何对innodb buffer pool进行预热,以便于快速恢复到之前的性能状态。如果是光靠Innodb本身去预热buffer,将会是一个不短的时间周期,业务高峰时,数据库将面临相当大的考验,I/O的瓶颈会带来糟糕的性能。那么,该怎么办呢?于是大家便想出一些办法,最后Percona把这个需求,在XtraDB中最为一个新特性实现这个功能。
      » 继续阅读 快速预热Innodb Buffer Pool的方法

如何监控主从之间的延时:seconds_behind_master OR mk-heartbeat

日常工作中,对于MySQL主从复制检查,一方面我们要保证复制的整体结构是否正常,另一方面需要检查主从数据是否保持一致。对于前者我们可以通过监控复制线程是否工作正常以及主从延时是否在容忍范围内,对于后者则可以通过分别校验主从表中数据的md5码是否一致,来保证数据一致,可以使用Maatkit工具包中的mk-table-checksum工具去检查。在这里,我只想讨论下关于如何检查主从延时的问题。

判断主从延时,通常有两个方法:1. Seconds_Behind_Master  vs  2. mk-heartbeat,下面具体说下两者在实现功能的差别。
      » 继续阅读 如何监控主从之间的延时:seconds_behind_master OR mk-heartbeat

xtrabackup知多少

最近小弄下Percona Xtrabackup,写脚本做测试,对这个世界唯一的开源免费(the world’s only open-source freeMySQLthe world’s most popular open source databases这句我也很喜欢 lol:)热备工具有了一些懵懂的认识,对于付费的InnoDB Hot Backup我们有了更欢乐的选择。Percona Xtrabackup工具主要有两部分构成,一个就是c写的xtrabackup命令,它又有多个版本,分别对应不同版本(5.0及以上)的MySQL/XtraDB以及InnoDB的差别(build-in or plugin),该命令只能备份InnoDB/XtraDB的数据文件;另一个是perl写的innobackupex的脚本,将xtrabackup命令包裹起来,让备份的过程更透明化更轻松,它会自行判断选择合适的xtrabackup工具,同时,它还能备份InnoDB对应的.frm文件以及MyISAM类型的库表;至于tar4ibd这个命令,未曾研究,看它的解释应该是一个打包InnoDB数据文件的工具。下面就具体说说这美妙的工作是如何高效工作的。
      » 继续阅读 xtrabackup知多少

MySQL临时表:Internal和Used-defined

为什么突然想说说临时表呢,之前都没有太过多的留意这些知识,是昨天以前的一个同事问了我一句关于临时表的疑问,我也顺便加深写认识。其实,我对于MySQL临时表的应用可以说是一无所知,说的最多听得最多的也都是,查询语句时用到临时表的情况,就是说的internal temporary table,是MySQL自己因为执行某个操作需要额外使用的,而另一种就是user-defined,用户自己定义的(create temporary table); 之前在798game的时候,公司的手游数据库的设计用到了大量临时表。下面是一些可能在某种意义上,你会觉得很不靠谱的认识,因为这些只是看了一些文字后的皮毛理解。

Internal Temporary Table
      » 继续阅读 MySQL临时表:Internal和Used-defined