MySQL实践积累 » MySQL http://dbahacker.com Thu, 17 May 2012 03:59:57 +0000 en hourly 1 http://wordpress.org/?v=3.3.1 Find out the difference between Com_Select and InnoDB_rows_read http://dbahacker.com/mysql/find-out-the-difference-between-com_select-and-innodb_rows_read http://dbahacker.com/mysql/find-out-the-difference-between-com_select-and-innodb_rows_read#comments Thu, 17 May 2012 03:57:26 +0000 admin http://dbahacker.com/?p=236 This morning  one MySQL cluster ( 4 Master ,4 Slave) , one mysql server ‘s response time raises up.

The raid config of the server

Adapter 0 -- Virtual Drive Information:
Virtual Drive: 0 (Target Id: 0)
Name                :
RAID Level          : Primary-1, Secondary-0, RAID Level Qualifier-0
Size                : 99.999 GB
State               : Optimal
Strip Size          : 64 KB
Number Of Drives per span:2
Span Depth          : 6
Default Cache Policy: WriteBack, ReadAheadNone, Direct, Write Cache OK if Bad BBU
Current Cache Policy: WriteBack, ReadAheadNone, Direct, Write Cache OK if Bad BBU
Access Policy       : Read/Write
Disk Cache Policy   : Disabled
Encryption Type     : None

Virtual Drive: 1 (Target Id: 1)
Name                :
RAID Level          : Primary-1, Secondary-0, RAID Level Qualifier-0
Size                : 1.533 TB
State               : Optimal
Strip Size          : 64 KB
Number Of Drives per span:2
Span Depth          : 6
Default Cache Policy: WriteBack, ReadAheadNone, Direct, Write Cache OK if Bad BBU
Current Cache Policy: WriteBack, ReadAheadNone, Direct, Write Cache OK if Bad BBU
Access Policy       : Read/Write
Disk Cache Policy   : Disabled
Encryption Type     : None

The pressure tends of this server

image

The first trend is MySQL Com_select , the second trend picture is MySQL InnoDB_rows_read. You can find out that the InnoDB_rows_read is larger than the counter of Com_Select.

At the beginng , it makes me confused  that  why the result of innodb_rows_read is bigger than com_select.

And what’s more , iostat tells me that disk is very busy and the avg response time is over 5ms. Yes, Response time is not ideal.

image

Finally , i observe the running sql in MySQL.

I found that a large number of this  sql is running

SELECT id, user_id, subscribe_id, twoway, group_ids, gmt_create, gmt_modified
FROM table_0485
WHERE user_id =376297445
ORDER BY gmt_create DESC
LIMIT 0 , 2000

What’s the problem of this sql?

1. It is query 2000 rows from InnoDB, if we have 100 sql like this is running, the innodb_rows_read = 100*2000;

2. the column user_id is not necessary to select once again, because we have post the user_id . We can redure the traffic after remove user_id,just like this “SELECT id, subscribe_id, twoway, group_ids, gmt_create, gmt_modified ”

 

So , return to our topic “Find out the difference between Com_Select and InnoDB_rows_read”

Right, if we have some query that need over thounds row, although the com_select is little, but the InnoDB_rows_read may is large.

]]> http://dbahacker.com/mysql/find-out-the-difference-between-com_select-and-innodb_rows_read/feed 0 [InnoDB]Truncate table difference between InnoDB build-in and InnoDB Plugin-in http://dbahacker.com/mysql/innodbtruncate-table-difference-between-innodb-build-in-and-innodb-plugin-in http://dbahacker.com/mysql/innodbtruncate-table-difference-between-innodb-build-in-and-innodb-plugin-in#comments Wed, 16 May 2012 09:26:43 +0000 admin http://dbahacker.com/?p=227 MySQL(5.1.37) InnoDB Build-in 

root@(none) 04:55:17> SHOW PLUGINS;
+------------+--------+----------------+---------+---------+
| Name       | Status | Type           | Library | License |
+------------+--------+----------------+---------+---------+
| binlog     | ACTIVE | STORAGE ENGINE | NULL    | GPL     |
| partition  | ACTIVE | STORAGE ENGINE | NULL    | GPL     |
| CSV        | ACTIVE | STORAGE ENGINE | NULL    | GPL     |
| MEMORY     | ACTIVE | STORAGE ENGINE | NULL    | GPL     |
| InnoDB     | ACTIVE | STORAGE ENGINE | NULL    | GPL     |
| MyISAM     | ACTIVE | STORAGE ENGINE | NULL    | GPL     |
| MRG_MYISAM | ACTIVE | STORAGE ENGINE | NULL    | GPL     |
+------------+--------+----------------+---------+---------+
7 rows in set (0.00 sec)

How Can we certify we using InnoDB Plugin, you just need run “show plugins” ,if you see the result like above, it is.

When we truncate one table . 

[MM-Writable@mysqldb /u01/mysql/data/db_02]
$du -sh db.ibd
773M    db.ibd

root@db_02 05:08:55>select count(*) from db;
+----------+
| count(*) |
+----------+
|  1410879 |
+----------+
1 row in set (0.38 sec) 

root@db_02 05:08:59>truncate table db;
Query OK, 0 rows affected (0.08 sec) 

root@db_02 05:09:05>select count(*) from db;
+----------+
| count(*) |
+----------+
|        0 |
+----------+
1 row in set (0.00 sec)

 

After we truncate the table “db”, we found that the total number of the table is zero. But the file is still use the space

$du -sh * | grep db

12K     db.frm
773M    db.ibd

Finally , how can we withdraw the space??? It is easily we just run “ alter table db engine=innodb;”;

root@snsfa_02 05:13:10>alter table sns_universal_relations_0064 engine=innodb;
Query OK, 0 rows affected (0.92 sec)
Records: 0  Duplicates: 0  Warnings: 0 

root@snsfa_02 05:13:17>exit
Bye 

[MM-Writable@my130.cm4 /u01/mysql/data/snsfa_02]
$du -sh * | grep sns_universal_relations_0064
12K     sns_universal_relations_0064.frm
132K    sns_universal_relations_0064.ibd

 

 

InnoDB Plugin-in

root@(none) 04:55:17> SHOW PLUGINS; 

| InnoDB                         | ACTIVE | STORAGE ENGINE     | NULL             | GPL     |
| INNODB_RSEG                    | ACTIVE | INFORMATION SCHEMA | NULL             | GPL     |
| INNODB_TRX                     | ACTIVE | INFORMATION SCHEMA | NULL             | GPL     |
| INNODB_LOCKS                   | ACTIVE | INFORMATION SCHEMA | NULL             | GPL     |
| INNODB_LOCK_WAITS              | ACTIVE | INFORMATION SCHEMA | NULL             | GPL     |
| INNODB_CMP                     | ACTIVE | INFORMATION SCHEMA | NULL             | GPL     |
| INNODB_CMP_RESET               | ACTIVE | INFORMATION SCHEMA | NULL             | GPL     |
| INNODB_CMPMEM                  | ACTIVE | INFORMATION SCHEMA | NULL             | GPL     |
| INNODB_CMPMEM_RESET            | ACTIVE | INFORMATION SCHEMA | NULL             | GPL     |
| INNODB_SYS_TABLES              | ACTIVE | INFORMATION SCHEMA | NULL             | GPL     |
| INNODB_SYS_TABLESTATS          | ACTIVE | INFORMATION SCHEMA | NULL             | GPL     |
| INNODB_SYS_INDEXES             | ACTIVE | INFORMATION SCHEMA | NULL             | GPL     |
| INNODB_SYS_COLUMNS             | ACTIVE | INFORMATION SCHEMA | NULL             | GPL     |
| INNODB_SYS_FIELDS              | ACTIVE | INFORMATION SCHEMA | NULL             | GPL     |
| INNODB_SYS_FOREIGN             | ACTIVE | INFORMATION SCHEMA | NULL             | GPL     |
| INNODB_SYS_FOREIGN_COLS        | ACTIVE | INFORMATION SCHEMA | NULL             | GPL     |
| INNODB_SYS_STATS               | ACTIVE | INFORMATION SCHEMA | NULL             | GPL     |
| INNODB_TABLE_STATS             | ACTIVE | INFORMATION SCHEMA | NULL             | GPL     |
| INNODB_INDEX_STATS             | ACTIVE | INFORMATION SCHEMA | NULL             | GPL     |
| INNODB_BUFFER_POOL_PAGES       | ACTIVE | INFORMATION SCHEMA | NULL             | GPL     |
| INNODB_BUFFER_POOL_PAGES_INDEX | ACTIVE | INFORMATION SCHEMA | NULL             | GPL     |
| INNODB_BUFFER_POOL_PAGES_BLOB  | ACTIVE | INFORMATION SCHEMA | NULL             | GPL     |
| XTRADB_ADMIN_COMMAND           | ACTIVE | INFORMATION SCHEMA | NULL             | GPL

When you are using InnoDB Plugin, it is actually Effective for your work.

When you  truncate table,  InnoDB Plugin would help you immediately empty the space.!

 

Reference http://dev.mysql.com/doc/refman/5.1/en/replacing-builtin-innodb.html

]]> http://dbahacker.com/mysql/innodbtruncate-table-difference-between-innodb-build-in-and-innodb-plugin-in/feed 0 shell脚本批量操作多个表 http://dbahacker.com/mysql/shell%e8%84%9a%e6%9c%ac%e6%89%b9%e9%87%8f%e6%93%8d%e4%bd%9c%e5%a4%9a%e4%b8%aa%e8%a1%a8 http://dbahacker.com/mysql/shell%e8%84%9a%e6%9c%ac%e6%89%b9%e9%87%8f%e6%93%8d%e4%bd%9c%e5%a4%9a%e4%b8%aa%e8%a1%a8#comments Mon, 14 May 2012 14:02:46 +0000 admin http://dbahacker.com/?p=224 分布式情况下很多分表，比如user_0000到 user_0511 。需要一个简便的批量操作方法。

例如 truncate table . alter table engine=innodb; drop tale等

 

脚本非常简单

 

list=`echo "show tables like ‘%user%’ " | mysql -uroot test -N `
for i in  $list;do
echo "alter table test.$i engine=innodb;" | mysql -uroot test
done

]]> http://dbahacker.com/mysql/shell%e8%84%9a%e6%9c%ac%e6%89%b9%e9%87%8f%e6%93%8d%e4%bd%9c%e5%a4%9a%e4%b8%aa%e8%a1%a8/feed 0 遭遇MySQL server has gone away http://dbahacker.com/mysql/%e9%81%ad%e9%81%87mysql-server-has-gone-away http://dbahacker.com/mysql/%e9%81%ad%e9%81%87mysql-server-has-gone-away#comments Wed, 08 Feb 2012 01:40:28 +0000 admin http://dbahacker.com/?p=221 一个开发MM的项目(PHP+MySQL)的PHP项目今天出现了MySQL server has gone away的错误，MySQL服务器端表示毫无压力。

而通过mysql客户端的连接方式mysql -hxx -uxx -pxx databasename -e xxx则毫无问题

而App服务器的netstat -a | grep 3306  | grep TIME_WAIT个数非常小，只有2个。

MySQL在连接超时这块的参数如下

root@(none) 09:24:51>show variables like '%out%';



+------------------------------+----------+



| Variable_name                | Value    |



+------------------------------+----------+



| connect_timeout              | 10       |



| delayed_insert_timeout       | 300      |



| handlersocket_timeout        | 300      |



| handlersocket_wrlock_timeout | 12       |



| innodb_lock_wait_timeout     | 100      |



| innodb_rollback_on_timeout   | OFF      |



| interactive_timeout          | 28800    |



| lock_wait_timeout            | 31536000 |



| log_output                   | FILE     |



| net_read_timeout             | 30       |



| net_write_timeout            | 60       |



| slave_net_timeout            | 3600     |



| wait_timeout                 | 28800    |



+------------------------------+----------+

最终MM把PHP连接MySQL的连接方式从长连接改成了短连接，就再没出现了。

后来查了下资料，总结如下

1.MySQL服务器的wait_timeout参数为默认的28800秒，即8小时。该参数的意思是MySQL等待睡眠的连接的持续时间，如果超过8小时不活动，MySQL就会关闭这个连接。这个参数可以动态修改，但这个参数是session级别的，需要应用重新建立连接获取这个变量值才会生效。

2.PHP的默认php.ini里面，default_socket_timeout参数是默认60s.default_socket_timeout参数的意思是socket超时为60s。 官方解释

3.在MySQL的官方文档里面，有专门的章节介绍MySQL Server has gone away。但并没有提及到客户端本身也会有超时机制，以前曾经试过把wait_timeout设置为1年，但App还是继续出现MySQL server has gone away的错误。

4.在PHP程序里面，如果php.ini修改起来不方便，可以以下代码来尝试解决。

ini_set('mysql.connect_timeout', 300);



ini_set('default_socket_timeout', 300);

在ini_set后，可以用ini_get来验证参数设置适合符合预期。

 

参考资料

1. MySQL server has gone away – in exactly 60 seconds

2.MySQL server has gone away

]]> http://dbahacker.com/mysql/%e9%81%ad%e9%81%87mysql-server-has-gone-away/feed 1 MySQL group by with rollup的用法 http://dbahacker.com/mysql/mysql-group-by-with-rollup%e7%9a%84%e7%94%a8%e6%b3%95 http://dbahacker.com/mysql/mysql-group-by-with-rollup%e7%9a%84%e7%94%a8%e6%b3%95#comments Wed, 01 Feb 2012 07:48:47 +0000 admin http://dbahacker.com/?p=219 有一位同学通过askdba来询问with rollup的用法

(2012-02-01 15:08:22):



 mysql中有这种用法select ... from table_name  group by a with rollup



"with rollup"是什么意思呢？









GROUP BY Modifiers  官方手册里面对这个rollup有一个专门的页面介绍 地址在这里，说得非常详细，我这里做一个简单的例子重现


建一个简单的表并插入几条简单的数据


CREATE TABLE `t` (



  `id` int(11) DEFAULT NULL,



  `id2` int(11) DEFAULT NULL



) ENGINE=InnoDB DEFAULT CHARSET=gbk



insert into t valeu(11,11),(12,12),(13,13);







先来做一个查询


root@test 03:44:32>select id,sum(id2),avg(id2) from t group by id with rollup;



+------+----------+----------+



| id   | sum(id2) | avg(id2) |



+------+----------+----------+



|   11 |       11 |  11.0000 |



|   12 |       12 |  12.0000 |



|   13 |       13 |  13.0000 |



| NULL |       36 |  12.0000 |



+------+----------+----------+



4 rows in set (0.00 sec)




我们可以看到，对于group by的列，with rollup将不会做任何的操作，而是返回一个NULL，而没有group by的列，则根据前面的avg函数和sum函数做了处理。 


再来看另外一个语句，只对一个列做avg


root@test 03:44:36>select id,avg(id2) from t group by id with rollup;



+------+----------+



| id   | avg(id2) |



+------+----------+



|   11 |  11.0000 |



|   12 |  12.0000 |



|   13 |  13.0000 |



| NULL |  12.0000 |



+------+----------+



4 rows in set (0.00 sec)




以前从没留意到有这种用法，这次长见识了。 

]]>
			http://dbahacker.com/mysql/mysql-group-by-with-rollup%e7%9a%84%e7%94%a8%e6%b3%95/feed
		1
		
		
		MySQL 5.0 5.1 下InnoDB的预热方法
		http://dbahacker.com/mysql/mysql-5-0-5-1-%e4%b8%8binnodb%e7%9a%84%e9%a2%84%e7%83%ad%e6%96%b9%e6%b3%95
		http://dbahacker.com/mysql/mysql-5-0-5-1-%e4%b8%8binnodb%e7%9a%84%e9%a2%84%e7%83%ad%e6%96%b9%e6%b3%95#comments
		Tue, 05 Oct 2010 07:13:10 +0000
		admin
				
		
		
		

		http://dbahacker.com/?p=150
		
			asdfsdfsadf0.00 creates/s, 0.00 writes/s

Buffer pool hit rate 757 / 1000


————–


ROW OPERATIONS


————–


0 queries inside InnoDB, 0 queries in queue


1 read views open inside InnoDB


Main thread process no. 12487, id 1157658976, state: waiting for server activity


Number of rows inserted 0, updated 0, deleted 0, read 21


0.00 inserts/s, 0.00 updates/s, 0.00 deletes/s, 0.07 reads/s


—————————-


END OF INNODB MONITOR OUTPUT


==========================MyS


之前在做一个项目的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是要我们自己生成的哦

]]>
			http://dbahacker.com/mysql/mysql-5-0-5-1-%e4%b8%8binnodb%e7%9a%84%e9%a2%84%e7%83%ad%e6%96%b9%e6%b3%95/feed
		2
		
		
		MySQL InnoDB 崩溃恢复过程  前言
		http://dbahacker.com/mysql/mysql-innodb-%e5%b4%a9%e6%ba%83%e6%81%a2%e5%a4%8d%e8%bf%87%e7%a8%8b-%e5%89%8d%e8%a8%80
		http://dbahacker.com/mysql/mysql-innodb-%e5%b4%a9%e6%ba%83%e6%81%a2%e5%a4%8d%e8%bf%87%e7%a8%8b-%e5%89%8d%e8%a8%80#comments
		Thu, 09 Sep 2010 01:02:06 +0000
		admin
				

		http://dbahacker.com/?p=134
		
			最近一个正在进行的项目，性能测试场景中包含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的崩溃恢复过程做详细的介绍

]]>
			http://dbahacker.com/mysql/mysql-innodb-%e5%b4%a9%e6%ba%83%e6%81%a2%e5%a4%8d%e8%bf%87%e7%a8%8b-%e5%89%8d%e8%a8%80/feed
		0
		
		
		测试快速关闭innodb的方法
		http://dbahacker.com/mysql/innodb-fast-shutdown
		http://dbahacker.com/mysql/innodb-fast-shutdown#comments
		Mon, 21 Jun 2010 07:31:07 +0000
		admin
				

		http://dbahacker.com/?p=122
		
			







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




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



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







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




]]>
			http://dbahacker.com/mysql/innodb-fast-shutdown/feed
		2
		
		
		MySQL5.1 InnoDB Plugin 启动信息详解 以及与MySQL5.0的InnoDB启动信息对比
		http://dbahacker.com/mysql/innodb-plugin-log-analyze
		http://dbahacker.com/mysql/innodb-plugin-log-analyze#comments
		Wed, 09 Jun 2010 12:48:57 +0000
		admin
				

		http://dbahacker.com/?p=115
		
			经过一段时间的测试,准备把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

]]>
			http://dbahacker.com/mysql/innodb-plugin-log-analyze/feed
		0
		
		
		MySQL Master-Slave的一个read log event 错误处理
		http://dbahacker.com/mysql/master-slave-read-log-event
		http://dbahacker.com/mysql/master-slave-read-log-event#comments
		Tue, 08 Jun 2010 06:10:11 +0000
		admin
				

		http://dbahacker.com/?p=111
		
			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

]]>
			http://dbahacker.com/mysql/master-slave-read-log-event/feed
		0