MySQL实践积累

昨天一台(slave)不停的出现包含HA_ERR_KEY_NOT_FOUND的复制错误

1. Include/my_base.sh (376行)  #define HA_ERR_KEY_NOT_FOUND    120     /* Didn’t find key on read or update */

翻译的意思是查询或者更新操作找不到键值，实际进行测试的时候 ，where查询条件为索引和普通列值的时候，当主库binlog_format=row的时候，slave也会报错HA_ERR_KEY_NOT_FOUND

改slave对应的主库binlog_format=ROW

1. 2. 测试重现

v031082.sqa.cm4   搞两个mysql实例   做主备

主库 /u01/mysql 3306    binlog_format=ROW

备库 /u01/mysql2 3309  binlog_format=STATEMENT

主库 create table t1(id int ,name varchar(100);

Insert into table t1 (name) value (‘mysql’);

Insert into table t1 (name) value (‘hbase’);

Insert into table t1 (name) value (‘oracle’);

主备库确认三条记录都在,备库清空t1表 .

备库 show slave status\G无告警

源码剖析

storage/innodb_plugin/handler/ha_innodb.cc 这里包含index_read(),index_first(),index_last()函数，这些函数都会判断记录是否存在

/**********************************************************************//**

Positions an index cursor to the index specified in the handle. Fetches the

row if any.

@return  0, HA_ERR_KEY_NOT_FOUND, or error number */

UNIV_INTERN

Int ha_innobase::index_read(

case DB_RECORD_NOT_FOUND:

error = HA_ERR_KEY_NOT_FOUND;

table->status = STATUS_NOT_FOUND;

break;

}

/********************************************************************//**

Positions a cursor on the first record in an index and reads the

corresponding row to buf.

@return 0, HA_ERR_END_OF_FILE, or error code */

UNIV_INTERN Int ha_innobase::index_first(

if (error == HA_ERR_KEY_NOT_FOUND) {

error = HA_ERR_END_OF_FILE;

}

)

/********************************************************************//**

Positions a cursor on the last record in an index and reads the

corresponding row to buf.

@return 0, HA_ERR_END_OF_FILE, or error code */

UNIV_INTERN  int  ha_innobase::index_last(

if (error == HA_ERR_KEY_NOT_FOUND) {

error = HA_ERR_END_OF_FILE;

}

)

之前在做一个项目的MySQL数据库极限压测, 有部分场景是涉及到MySQL重启的,而这个项目使用的是InnoDB存储引擎。

重启完毕后,一开始十几分钟的性能是非常差的,原因是因为InnoDB有innodb buffer pool(简称ibf)的概念

和innodb buffer pool相关的参数innodb_buffer_pool_size,size越大,可以放到内存的数据越多,而大多数的项目都会有热点数据的存在,当热点数据经过LRU算法进入到buffer pool之后,读磁盘的次数减少,读的都是内存,速度是最快的

问题来了,数据库一重启,热点数据都被清空,bf里面都是空的.等待app的sql请求过来让bf填满数据是一个方法,但30分钟内很难把热点数据都装载进来.

这个时候,我们可以采取人工预热的办法来让bf满足我们的需求

MySQL 5.0的预热是最简单的

方法1 : 在MySQL重启后 执行 SELECT COUNT(*) FROM INFORMATION_SCHEMA.TABLES,经过我在一台5.0MySQL的实验 在重启后查看show innodb status\G 和执行完这条语句后 Free buffers的页数会减少.

这个count语句有何作用呢?InnoDB的存储格式和MyISAM不一样, innodb会在mysql启动后的第一次访问表的时候,统计表的索引基数等相关信息,如果表很多的话,这也是一个巨大的开销.所以在正式提供服务之前,就把表打开,放入到bp里面

MySQL 5.1的数据预热

我在一台5.1.48的MySQL进行了重启,测试了同样的SELECT COUNT(*) FROM INFORMATION_SCHEMA.TABLES 但发现free buffers的页数没有变少，情况和mysqlperformanceblog.com作者所说的一样–这个方法在5.1之后就无法达到我们的需求了

可以采用另外一种方法:获得数据库里面的库和对应的表，来进行预热，核心代码是这一句

SELECT table_schema, table_name FROM information_schema.tables

可以用perl或者python来获取库和表 然后执行 select * from db.table limit 1 来实现我们的方法

最后提一下,我们可以再my.cnf 加入init-file=/mysql/init.sql ，在每次mysql重启的时候就自动执行这个预热的sql  当然了 sql是要我们自己生成的哦

这一周的周二到周四都是参加公司的社招新人培训,今天给我们分享的有淘宝的业务介绍,工程师@淘宝 by(文初) ， 毕玄给我们讲淘宝架构介绍&未来发展，以及伏威给我们分享 用户体验，速度，稳定，成本–四个关键词

淘宝的业务介绍，是一位消费者事业部的产品经理给我们分享，其中一个问题让我印象非常深刻，淘宝有一年的在线交易总额KPI是1000亿，但实际只有达到的是999.4亿，相差了0.6亿，去了哪里？是因为临近过年之前，交易量瞬间上升，系统抗不住，服务不可用的时间非常长，从而导致了当年的KPI没有100%实现，上课的时候听到这个情况，心情挺不好受的，也感觉压力很大.这个培训，我觉得最大的收获是了解了前人的一些痛苦，自己来听一番，也感受这个过程，以后在工作的时候对类似的情况有所考虑

第二位给我们做分享的是放翁,工程师@淘宝的话题。认识文初，我依稀记得是大三的时候在javaeye.com看到他的博客,从他的博客文章，感觉他是沟通能力非常强的技术高手，当年的我，也没想到可以一睹他的风采。今天他全程的分享都是脱稿，而条理也非常清晰。他所分享的内容我做了记录：

1. 工程师如何把事情做到极致–把所负责的事情产品化，记录下来分享，不用怕吃亏

2.责任: 产品责任，关注自己的客户的需求，提前想到他们会有什么样的疑惑

3.心态: 在淘宝，你会发现你很忙，如果没有一个良好的心态，很容易把自己给压垮

4.沟通: 今天你给别人什么态度，明天别人就会给你什么态度。

5.时间管理：首先要和清晰的知道，自己今天要完成什么;不要做万金油,懂得让别人知道怎样解决问题，选择好的方式去帮助别人

放翁的分享很精彩，营养很好.值得好好的记录下来

下午是毕玄给我们做淘宝架构&未来发展,分享了淘宝的v1,v2,v3架构的优势和缺点不足。毕玄是淘宝秒杀活动的技术方案提供者 ，具体可以看这篇文章  http://www.aliresearch.com/viewpoint/6774/ 。

v1阶段 采用了外国的技术方案来进行，一开始业务不是非常庞大，也勉强维持的过去

v2阶段,业务开始激增，整个淘宝的代码都放在一个工程，每次打包都要个20多分钟，大家都可以修改代码，数据都在一个数据库里面，日子过得不轻松

v3阶段，也就是目前我们的所在阶段，一个关键词–拆分 。从上层开始，拆应用，拆项目，产生各种各种的中间件，tfs,taif,notify,hsf,tddl，数据库分库分表，分机房。分布式的一个好处是，挂了一个子节点，其他节点还可以顶住其他的业务，鸡蛋没有放在同一个篮子。但也带来一个难题–应用拆分了，数据库拆分了，一大堆中间件，互相的依赖非常强，随便哪个子系统出了问题，都可能导致一对服务不可用。鸡蛋没有在同一个篮子里面，分散放，某个地方不小心，就打烂一两个鸡蛋了。

最后的是伏威给我们分享2010年淘宝的技术方面的四个关键词: 用户体验，速度，稳定，成本.  其实有3个词，我认为都是和v3阶段的拆分有关系,分别是用户体验，稳定，成本。

用户体验和稳定:  这两个词其实有非常大的关系，系统不稳定，用户访问不了网站，用户体验就非常糟糕了。

成本: 分布式和拆分所带来的，就是设备数量的激增，从而带来各种各样的成本问题，机柜，服务器，内存，cpu，人力成本等等

今天的分享，既有经验的收获，也带给了我思考,比如放翁所提到的责任精神，比如毕玄所提到的未来10w级别的服务器，如何智能化管理，还有伏威所提到的四个关键词，这些点，对于我自己的工作，应该也是需要加以注意并做好的，而这，就是我的工作的意义所在”个人能力得到提升，所做的事情解决了已有的问题，证明自己的价值”

最近一个正在进行的项目，性能测试场景中包含MySQL 为较大压力的应用程序提供服务，Linux服务器CPU占用100% ，OS 不可用，我写了一个吃CPU的shell脚本来不断的跑，结果把服务器跑挂了，手动重启了服务器后，发现MySQL起来的时间需要非常长，为大家所不能接受

MySQL相关信息   5.0.67    InnoDB Buffer Pool Size为36G  ,innodb_flush_log_at_trx_commit = 1，innodb_log_file_size = 900M

，当时候的服务器情况比较糟糕，CPU占用100% ，ssh也登录不进去，维持了一段时间后才进行重启，所以没有收集到最重要的崩溃之前的MySQL内部信息   整个的恢复过程用了6个小时

这个时候，引发了我们的反思:

1. 我们的MySQL压测模型没有针对不同版本的MySQL进行崩溃恢复压测  所以出现这个崩溃恢复的问题，我们只能补回来这个测试，针对不同版本的MySQL(MySQL 5.0.67 和MySQL5.1.xx)，需要进行相同TPS的场景下进行kill -9  pid (mysqld)的测试，掌握一手的崩溃恢复时间，为将来线上出现MySQL崩溃，做最好的准备

2. 我自己对MySQL InnoDB崩溃恢复的过程不是非常了解,导致MySQL崩溃之前没有去采集有参考价值的数值，这点需要加把劲

这一篇是前言，下一篇，我会对MySQL InnoDB的崩溃恢复过程做详细的介绍

下午江枫 召集了我们10号人，在外面的咖啡室订了个包厢，用了一下午的时间来进行头脑风暴–把大家觉得不爽的问题抛出来

形式很简单，江枫让我们一个个的来把大家觉得不爽的问题列出来，不过也是专门腾出时间来搞这个事情，其他日常的工作暂时抛开了一个下午

今天参加完这个“批斗会”，感受很深，大家把觉得有问题的都说了个遍，压抑在心里面的疑惑，困惑，不爽都释放出来了，让我想起了上一次的“批斗会”–在学校的quanta第一年的时候面临一些团队沟通问题，也通过这种方式来解决

当我们碰到困惑的时候，发现这是一个问题，或多或少会有自己的想法去解决，但很可能这个想法只是一下子划过自己的脑袋…之后再碰到，除非我们有特定的时间(自己去挤或者向别人要求这个时间来做)，如果没有做这一步。。很大可能我们对问题的处理仅仅停留在思考方面，而不是去行动

下午在听同事们的觉得是一个问题的时候，自己也在反思，原来自己也曾经对某个东西有疑惑，但没有去做好….这一点如果做好了..可能我们会觉得自己所做的东西是很有价值的

下午听了一个项目技术方案评审会,足足四个小时，项目升级非常多功能，其实PD的很多描述都可以用思维导图来描述

一图胜千言，或许就可以省很多时间了

经过一段时间的测试,准备把MySQL 5.1 InnoDB Plugin部署到线上，今天发现MySQL 5.0 InnoDB 和MySQL5.1 InnoDB Plugin启动是有点区别的，这里做一个整理

5.0MySQL 的版本信息

mysql> show variables like ’%version%’;

+————————-+—————————–+

| Variable_name           | Value                       |

+————————-+—————————–+

| protocol_version        | 10                          |

| version                 | 5.0.38-Debian_3netease5-log |

| version_comment         | Debian etch distribution    |

| version_compile_machine | x86_64                      |

| version_compile_os      | pc-linux-gnu                |

+————————-+—————————–+

5 rows in set (0.01 sec)

启动的日志信息

InnoDB: The first specified data file xxx//ibdata1 did not exist:

InnoDB: a new database to be created!

100609 19:18:50  InnoDB: Setting file xxx//ibdata1 size to 32 MB

InnoDB: Database physically writes the file full: wait…

100609 19:18:51  InnoDB: Log file xxx/ib_logfile0 did not exist: new to be created

InnoDB: Setting log file xxx/ib_logfile0 size to 128 MB

InnoDB: Database physically writes the file full: wait…

InnoDB: Progress in MB: 100

100609 19:18:53  InnoDB: Log file xxx/ib_logfile1 did not exist: new to be created

InnoDB: Setting log file xxxx/ib_logfile1 size to 128 MB

InnoDB: Database physically writes the file full: wait…

InnoDB: Progress in MB: 100

InnoDB: Doublewrite buffer not found: creating new

InnoDB: Doublewrite buffer created

InnoDB: Creating foreign key constraint system tables

InnoDB: Foreign key constraint system tables created

100609 19:18:57  InnoDB: Started; log sequence number 0 0

100609 19:18:57 [Note] /usr/sbin/mysqld: ready for connections.

Version: ’5.0.38-Debian_3netease5-log’  socket: xxx/mysqld.sock’  port: 4591  Debian etch distribution

MySQL 5.1 的版本信息

mysql>  show variables like ’%version%’;

+————————-+———————+

| Variable_name           | Value               |

+————————-+———————+

| innodb_version          | 1.0.6-unknown       | ##这个是InnoDB Plugin的新信息

| protocol_version        | 10                  |

| version                 | 5.1.45-log          |

| version_comment         | Source distribution |

| version_compile_machine | x86_64              |

| version_compile_os      | unknown-linux-gnu   |

+————————-+———————+

MySQL5.1 InnoDB Plugin启动日志信息，多了很多内容，下面逐一介绍

InnoDB: The InnoDB memory heap is disabled

InnoDB: Mutexes and rw_locks use GCC atomic builtins

InnoDB: The first specified data file ./ibdata1 did not exist:

InnoDB: a new database to be created!

100609 17:17:11  InnoDB: Setting file ./ibdata1 size to 512 MB

InnoDB: Database physically writes the file full: wait…

InnoDB: Progress in MB: 100 200 300 400 500

100609 17:17:15  InnoDB: Log file xxx/ib_logfile0 did not exist: new to be created

InnoDB: Setting log file  xxx/ib_logfile0 size to 512 MB

InnoDB: Database physically writes the file full: wait…

InnoDB: Progress in MB: 100 200 300 400 500

100609 17:17:21  InnoDB: Log file xxx/ib_logfile1 did not exist: new to be created

InnoDB: Setting log file xxxx/ib_logfile1 size to 512 MB

InnoDB: Database physically writes the file full: wait…

InnoDB: Progress in MB: 100 200 300 400 500

InnoDB: Doublewrite buffer not found: creating new

InnoDB: Doublewrite buffer created

InnoDB: Creating foreign key constraint system tables

InnoDB: Foreign key constraint system tables created

100609 17:17:26 InnoDB Plugin 1.0.6-unknown started; log sequence number 0

100609 17:17:28 [Note] Event Scheduler: Loaded 0 events

100609 17:17:28 [Note] /usr/xtradb/libexec/mysqld: ready for connections.

Version: ’5.1.45-log’  socket: ’xxx/mysqld.sock’  port: 4331  Source distribution

InnoDB: The InnoDB memory heap is disabled

是因为使用了操作系统的内存分配器,所以就禁用了InnoDB的内置内存分配器

mysql> show variables like ’%malloc%’;

+———————–+——-+

| Variable_name         | Value |

+———————–+——-+

| innodb_use_sys_malloc | ON    |

+———————–+——-+

1 row in set (0.00 sec)

而在5.0里面执行是为空结果的，关于这个innodb_use_sys_malloc，具体可以参阅InooDB的官方介绍

Mutexes and rw_locks use GCC atomic builtins

对比以往的版本,InnoDB Plugin 1.0.3之后的版本 使用了GCC atomic builtins来执行互斥和读写锁,性能会比以往使用的pthread_mutex_t要高效

参见 InnoDB Plugin: Enabling GCC atomic built-in functions for InnoDB rw-locks
InnoDB: The first specified data file ./ibdata1 did not exist:

InnoDB: a new database to be created!

第一次启动mysql，因为默认的是innodb引擎，所以会自动创建一个test

InnoDB: Doublewrite buffer not found: creating new

InnoDB: Doublewrite buffer created

什么是Doublewrite?

InnoDB将BP中的Dirty Page刷（flush）到磁盘上时，首先会将Page刷到InnoDB tablespace的一个区域中，我们称该区域为Double write Buffer。在向Double write Buffer写入成功后，再择机将数据拷贝到正在的数据文件对应的位置。

更多详细的信息可以看看performace blog 的对doublewrite的介绍

或者是苏普的对Doublewrite整理 InnoDB Double write

参考资料

InnoDB Plugin: Enabling GCC atomic built-in functions for InnoDB rw-locks

http://www.innodb.com/wp/support/tips/atomics/

InnoDB Plugin 1.0 for MySQL 5.1 User’s Guide

http://www.innodb.com/doc/innodb_plugin-1.0-doc-single/innodb-plugin.html#innodb-performance-use_sys_malloc

Innodb Double Write

http://www.mysqlperformanceblog.com/2006/08/04/innodb-double-write/#more-72

转载烦请保留原文连接 http://dbahacker.com/mysql/innodb-plugin-log-analyze

Master-Slave的一个read log event 错误处理

现在简单介绍一下几个节点的情况
B服务器上面有一个B1节点，是MySQL5.0版本，普通InnoDB的表
C服务器上面有两个测试节点（C1，C2）,
它们是A服务器上面的A1节点的slave,C1，C2，都是使用XtraDB压缩功能的表

也就是 A为Master,有3个Slave(B1,C1,C2)

因为某些原因,C2的slave 复制出现了问题,而C1是没有问题的，当时候采取了以下措施
1.停止C1,C2的slave,使用mysqladmin shutdown来关闭C1,C2
2.删掉C2的数据目录等，只留下my.cnf
3.把C1的数据目录等都拷贝到C2目录下
4.启动C1,C2

这时候发现C2的mysqd.log 里面有了这样的内容

100608 12:44:14 [Note] Slave: received end packet from server, apparent master shutdown:
100608 12:44:14 [Note] Slave I/O thread: Failed reading log event, reconnecting to retry, log ‘mysql-bin.007817′ at postion 86542498
100608 12:44:15 [Note] Slave I/O thread killed while reading event

同时在C2里面执行show slave status \G的时候,Seconds_behind_master = 会出现落后的秒数，但连续的执行show slave status 的时候就会看到有NULL的信息

mysqlperformanceblog有一篇文章是提到过是server-id的问题 http://www.mysqlperformanceblog.com/2008/06/04/confusing-mysql-replication-error-message/
但是我的3个slave的server-id都是不一样的，和master的server-id也是不一样的

最后的解决方法是尝试了一把把C2的server-id改成新的值，重启mysql,stop slave ;start slave;show slave status \G后发现复制正常了，不知道是否和我直接copy C1的数据库等文件过来是否有关

参考文献/文章

Confusing MySQL Replication Error Message http://www.mysqlperformanceblog.com/2008/06/04/confusing-mysql-replication-error-message/
Many Errors “Slave: received end packet from server” http://bugs.mysql.com/bug.php?id=9325

这其实是09年总结的一篇文章，今天被一位朋友问到InnoDB有什么好处，一下子讲不清楚，现在把在自己另外一个博客的文章在这里重发一遍，主要是讲InnoDB和MyISAM的对比，从中可以看到InnoDB的很多好处，比如并发插入的时候行级锁等

本 文主要整理了Mysql 两大常用的存储引擎MyISAM，InnoDB的六大常见区别，来源于Mysql手册以及互联网的资料