DBA Hacker --提高DBA的工作效率

问题&自我的提升

admin — Thu, 02 Sep 2010 15:20:31 +0000

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

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

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

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

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

思维导图&节省开会时间

admin — Wed, 28 Jul 2010 12:30:03 +0000

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

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

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

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

测试快速关闭innodb的方法

admin — Mon, 21 Jun 2010 07:31:07 +0000

Google docs 查看地址 http://docs.google.com/Doc?docid=0AR0iV03BDag2ZGRyMjI5cjdfODAxZnd6ejZ2Z3c&hl=en

pdf下载地址 _mysqlporformanceblog_innodb_ (1)

测试mysqlporformanceblog提供的减少关闭innodb时间的方法

经常发现一些MySQL镜像库的InnoDB的关闭时间会特别久，mysqlperformanceblog给出了一个不错的解决方案

How to decrease InnoDB shutdown times http://www.mysqlperformanceblog.com/2009/04/15/how-to-decrease-innodb-shutdown-times/

InnoDB关闭的过程解释

MySQL官方手册介绍影响到InnoDB关闭的参数有

innodb_fast_shutdown

如果你把这个参数设置为0，InnoDB在关闭之前做一个完全净化和一个插入缓冲合并。这些操作要花几分钟时间，在极端情况下要几个小时。

如果你设置这个参数为1，InnoDB在关闭之时跳过这些操作。默认值为1。

如果你设置这个值为2 (在Netware无此值)， InnoDB将刷新它的日志然后冷关机，仿佛MySQL崩溃一样。已提交的事务不会被丢失，但在下一次启动之时会做一个崩溃恢复。

innodb_max_dirty_pages_pct

这是一个范围从0到100的整数。默认是90。InnoDB中的主线程试着从缓冲池写页面，使得脏页（没有被写的页面）的百分比不超过这个值。如果你有SUPER权限，这个百分比可以在服务器运行时按下面来改变：

SET GLOBAL innodb_max_dirty_pages_pct = value;

100423 0:10:18 InnoDB: Starting shutdown…

100423 0:10:20 InnoDB: Shutdown completed; log sequence number 0 4000976145

100423 0:10:20 [Note] /usr/sbin/mysqld: Shutdown complete

测试环境

1.在一个镜像库节点进行测试,innodb_buffer_pool_size=1G

2.在一个线上节点进行测试,碰巧这个节点要进行机架更换,所以可以趁机测试一把

innodb_buffer_pool_size=12G,线上环境和镜像环境还是有点不一样,没法让Innodb_buffer_pool_pages_dirty的值少于1000，虽然是大于1000，但关闭起来还是比较快速的

测试过程
正常关闭的normal-shutdown.sh

#!/bin/bash

#正常关闭innodb

log=”normal-shutdown.log”

start_time=`date`

echo “start time:”$start_time > $log

mysqladmin –defaults-file=db-32-1.cnf -uxxx -pxxx ext | grep dirty >> $log

mysqladmin –defaults-file=db-32-1.cnf -uxxx -pxxx shutdown

end_time=`date`

echo “end time:” $end_time >> $log

normal-shutdown.log 输出的日志如下

start time:2010年 06月 18日星期五 17:21:00 CST

| Innodb_buffer_pool_pages_dirty | 43492 |

end time: 2010年 06月 18日星期五 17:23:10 CST

设置set global innodb_max_dirty_pages_pct =0的关闭方式

首先执行 mysql –defaults-file=db-31-2.cnf -uxxx -pxxx -e” set global innodb_max_dirty_pages_pct =0“
经过了大概3分钟后 Innodb_buffer_pool_pages_dirty的值少于1000

然后执行faster-shutdown.sh，生成faster-shutdown.log

#!/bin/bash

log=”faster-shutdown.log”

start_time=`date`

echo “faster shutdown start time:”$start_time >$log

mysqladmin –defaults-file=db-32-1.cnf -uxxx -pxxx ext | grep dirty >> $log

mysqladmin –defaults-file=db-32-1.cnf -uxxx -pxxx shutdown

end_time=`date`

echo “faster shutdown end time:” $end_time >>$log

faster-shutdown.log的内容

faster shutdown start time:2010年 06月 18日星期五 17:47:08 CST

| Innodb_buffer_pool_pages_dirty | 569 |

faster shutdown end time: 2010年 06月 18日星期五 17:47:12 CST

关闭时间比较

	正常关闭	快速关闭
Innodb_buffer_pool_pages_dirty	43492	569
关闭时间	2分10秒	4秒

结论

日常维护中,可以使用set global innodb_max_dirty_pages_pct =0,让Innodb_buffer_pool_pages_dirty 的数值为一个较小的值,这样就可以减少在关闭mysql服务器中耗费在innodb的时间

最终达到减少影响用户的时间

参考资料

InnoDB启动 http://dev.mysql.com/doc/refman/5.1/zh/storage-engines.html#innodb-start

How to decrease InnoDB shutdown times http://www.mysqlperformanceblog.com/2009/04/15/how-to-decrease-innodb-shutdown-times/

Dirty pages, fast shutdown, and write combining http://www.xaprb.com/blog/2010/05/25/dirty-pages-fast-shutdown-and-write-combining/

MySQL5.1 InnoDB Plugin 启动信息详解以及与MySQL5.0的InnoDB启动信息对比

admin — Wed, 09 Jun 2010 12:48:57 +0000

经过一段时间的测试,准备把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

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

admin — Tue, 08 Jun 2010 06:10:11 +0000

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

[存储引擎基础知识]InnoDB与MyISAM的六大区别

admin — Mon, 07 Jun 2010 14:03:49 +0000

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

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

InnoDB与Myisam的六大区别
	MyISAM	InnoDB
构成上的区别：	每个MyISAM在磁盘上存储成三个文件。第一个文件的名字以表的名字开始，扩展名指出文件类型。 .frm文件存储表定义。数据文件的扩展名为.MYD (MYData)。索引文件的扩展名是.MYI (MYIndex)。	基于磁盘的资源是InnoDB表空间数据文件和它的日志文件，InnoDB 表的大小只受限于操作系统文件的大小，一般为 2GB
事务处理上方面:	MyISAM类型的表强调的是性能，其执行数度比InnoDB类型更快，但是不提供事务支持	InnoDB提供事务支持事务，外部键等高级数据库功能
SELECT UPDATE,INSERT，Delete操作	如果执行大量的SELECT，MyISAM是更好的选择	1.如果你的数据执行大量的INSERT或UPDATE，出于性能方面的考虑，应该使用InnoDB表 2.DELETE FROM table时，InnoDB不会重新建立表，而是一行一行的删除。 3.LOAD TABLE FROM MASTER操作对InnoDB是不起作用的，解决方法是首先把InnoDB表改成MyISAM表，导入数据后再改成InnoDB表，但是对于使用的额外的InnoDB特性（例如外键）的表不适用
对AUTO_INCREMENT的操作	每表一个AUTO_INCREMEN列的内部处理。 MyISAM为INSERT和UPDATE操作自动更新这一列。这使得AUTO_INCREMENT列更快（至少10%）。在序列顶的值被删除之后就不能再利用。(当AUTO_INCREMENT列被定义为多列索引的最后一列，可以出现重使用从序列顶部删除的值的情况）。 AUTO_INCREMENT值可用ALTER TABLE或myisamch来重置对于AUTO_INCREMENT类型的字段，InnoDB中必须包含只有该字段的索引，但是在MyISAM表中，可以和其他字段一起建立联合索引更好和更快的auto_increment处理	如果你为一个表指定AUTO_INCREMENT列，在数据词典里的InnoDB表句柄包含一个名为自动增长计数器的计数器，它被用在为该列赋新值。自动增长计数器仅被存储在主内存中，而不是存在磁盘上关于该计算器的算法实现，请参考 AUTO_INCREMENT列在InnoDB里如何工作
表的具体行数	select count() from table,MyISAM只要简单的读出保存好的行数，注意的是，当count()语句包含 where条件时，两种表的操作是一样的	InnoDB 中不保存表的具体行数，也就是说，执行select count(*) from table时，InnoDB要扫描一遍整个表来计算有多少行
锁	表锁	提供行锁(locking on row level)，提供与 Oracle 类型一致的不加锁读取(non-locking read in SELECTs)，另外，InnoDB表的行锁也不是绝对的，如果在执行一个SQL语句时MySQL不能确定要扫描的范围，InnoDB表同样会锁全表，例如update table set num=1 where name like “%aaa%”
本文原出处为 http://www.dbahacker.com 转载烦请保留链接

5月第三周关键词慢语句处理

admin — Fri, 21 May 2010 14:09:55 +0000

依稀记得是上周开始部署了mysql的节点监控程序到线上环境，设定的查询周期是90秒一次，超过10秒的查询和超过x个连接的时候就会发报警邮件给DBA。

这个在镜像库部署的时候，会经常发现开发人员查一下没用索引的语句或者没有limit n的语句，这些没语句会对数据库造成很大的影响，例如一个几千万条记录的大表要全部扫描，或者是不停的做filesort，对数据库和服务器造成io影响等。这是镜像库上面的情况。

而到了线上库，除了出现没有索引的语句，没有用limit的语句，还多了一个情况,mysql连接数过多的问题。说到这里，先来看看以前我们的监控做法

1. 部署zabbix等开源分布式监控系统，获取每天的数据库的io，cpu，连接数

2. 部署每周性能统计，包含数据增加量，iostat，vmstat，datasize的情况

3. Mysql slowlog收集，列出top 10

以前以为做了这些监控已经是很完美了，现在部署了mysql节点进程监控之后，才发现很多弊端

第一种做法的弊端: zabbix太庞大，而且不是在mysql内部做的监控，很多数据不是非常准备，现在一般都是用来查阅历史的数据情况

第二种做法的弊端：因为是每周只跑一次，很多情况没法发现和报警

第三种做法的弊端: 当节点的slowlog非常多的时候，top10就变得没意义了，而且很多时候会给出那些是一定要跑的定期任务语句给你。。参考的价值不大

最后总结一下节点监控的好处

1．轻量级的监控，而且是实时的，还可以根据实际的情况来定制和修改

2．设置了过滤程序，可以对那些一定要跑的语句进行过滤

3．及时发现那些没有用索引，或者是不合法的查询，虽然这很耗时去处理那些慢语句，但这样可以避免数据库挂掉，还是值得的

4. 在数据库出现连接数过多的时候，程序会自动保存当前数据库的processlist，DBA进行原因查找的时候这可是利器

5. 使用mysqlbinlog 来分析的时候，可以得到明确的数据库状态异常的时间段

python在windows服务器上面安装python-mysqldb

admin — Sun, 09 May 2010 13:53:29 +0000

python在windows服务器上面安装python-mysqldb

刚才试验了一把在windows服务器上面使用python setup.py install来安装 python-mysqldb

发现很多编译错误的问题，其实最简单的方法是使用windows版本的exe点击安装

目前已经提供了pytho2.5,python2.6的版本哦

http://sourceforge.net/projects/mysql-python/files/mysql-python/

刚才试验了一把在windows服务器上面使用python setup.py install来安装 python-mysqldb

发现很多编译错误的问题，其实最简单的方法是使用windows版本的exe点击安装

目前已经提供了pytho2.5,python2.6的版本哦

http://sourceforge.net/projects/mysql-python/files/mysql-python/

MySQL5.5的亮点和MySQL Cluster 7.1介绍

admin — Sat, 08 May 2010 02:42:14 +0000

MySQL5.5亮点

InnoDB

多个缓冲池实例
多个回滚段
扩展变化和清除缓冲调度
Improved Log Sys and Flush List mutex 改善日志系统
改进锁策略
改进InnoDB互斥，读写锁，线程和I/O操作的策略

改进win32，64平台下的性能/规模

扩展到32个内核

半同步复制

性能架构

SIGNAL/RESIGNAL (finally!)

新的增强分区

Configuring the heartbeat period

More than 10x improvement in recovery times

200% performance gain for MySQL 5.5 over 5.1.40

MySQL Cluster 7.1 (GA)

NDBINFO – improved real time status and usage statistics
MYSQL Cluster Manager (CGE only)
Sub-second failover and self healing recovery
Parallel multi-master architecture
Low latency – real time responsiveness

MySQL5.5.4InnoDB Plugin 新特性＆改进

admin — Tue, 20 Apr 2010 00:55:49 +0000

http://dev.mysql.com/doc/innodb-plugin/1.1/en/innodb-performance.html

mysql5.5.4的innodb增加了很多特性希望在oracle里面，mysql可以继续走下去

DBA Hacker --提高DBA的工作效率

问题&自我的提升

思维导图&节省开会时间

测试快速关闭innodb的方法

测试环境

结论

MySQL5.1 InnoDB Plugin 启动信息详解 以及与MySQL5.0的InnoDB启动信息对比

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

[存储引擎基础知识]InnoDB与MyISAM的六大区别

5月第三周关键词 慢语句处理

python在windows服务器上面安装python-mysqldb

MySQL5.5的亮点 和MySQL Cluster 7.1介绍

MySQL5.5.4InnoDB Plugin 新特性＆改进

MySQL5.1 InnoDB Plugin 启动信息详解以及与MySQL5.0的InnoDB启动信息对比

5月第三周关键词慢语句处理

MySQL5.5的亮点和MySQL Cluster 7.1介绍