日志分类:MySQL

MySQL/InnoDB和Group Commit(2)

2011-12-20 23:51  |  分类:MySQL

今天发现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就是这其中的牺牲之一。

[......]

Read more

这里介绍一个最近用得很多的一个小工具:tbdba-restore-mysqldump.pl

主要有两个功能:

(1) 尽可能快的从一个非常大的mysqldump文件的分离出某个单表的备份文件

(2) 可以帮你把一个大的mysqldump文件,切割成非常小的单表备份文件(可继续做并行恢复)

1. 什么时候需要这么做

(1) 如果把MySQL中某一个表数据弄丢了,需要从很大的mysqldump备份文件中恢复这个表

(2) 如果你想并行恢复整个mysqldump备份文件时,这个脚本可以帮你把大文件切割成多个小的单表备份文件,然后就可以方便并行恢复多个文件了

2. 如何使用这个脚本

这里以实例的方式介绍如何使用该脚本:

(1) 从backup.sql文件中获取表process的备份:

tbdba-restore-mysqldump.pl -t process -f backup.sql

(2) 从backup.sql文件中获取数据库monitor中的表process的备份:

tbdba-restore-mysqldump.pl -t process -s monitor -f backup.sql

[......]

Read more

MySQL如何传输二进制日志

2011-11-20 23:53  |  分类:MySQL

MySQL Replication可以很方便的用来做应用的读扩展,也可以帮MySQL实现一定程度的HA方案。MySQL通过向备库传送二进制日志来实现Replication,本文将通过二进制日志相关源代码的主要接口来解释:“MySQL如何传输二进制日志,是主库推,还是备库拉?MySQL日志传输的实时性如何?”。

在MySQL Replication结构中,备库端初次通过CHANGE MASTER TO完成Replication配置,再使用start slave命令开始复制。更细致的,备库通过IO Thread向主库发起读取binlog的请求(COM_BINLOG_DUMP命令),主库收到COM_BINLOG_DUMP请求后,使用单独线程(dump thread)不断向备库IO Thread发送Binlog。示意图(大图):

[......]

Read more

这又是一篇介绍Semi-sync的文章。

Semi-sync主库在一定时间内(可配置的超时时间),如果没有收到备库的响应,则会超时从而降级为普通的replication复制。如果超时发生,有时需要查清什么原因导致备库没有及时响应,一方面可以从备库的日志着手,另一方面,如果需要更细致的信息则需要从备库端的网络包查找原因。这里介绍如何分析一个Semi-sync备库响应主库的数据包。

概述:先使用tcpdump抓取正确(主要是src和dst都正确)的数据包;然后借助wireshark玻璃TCP/IP等层的头信息,仅保留发送的MySQL数据包;再分析MySQL Semi-sync Slave响应的协议。

1. tcpdump原始数据包

通过如下tcpdump抓取主机的网络包:

nohup tcpdump -n -nn -tttt -i bond0 -s 65535 'port 3306 and ((dst host master.host and src host slave.host and len < 100) or (dst host slave.host and src host master.host))' -w tcpdump.ret -C 50 &

参数简单说明:

-n 表示ip不要转换为主机名 -nn表示端口号,不要转为为服务名(例如3306会被转换为mysql) -tttt 打印出完成的格式化的时间戳 -C 50 表示抓取的结果放到文件中,文件大小不超过50MB
2. 使用wireshark找到对应的包

[......]

Read more

Percona-Server/MySQL响应时间统计

2011-09-19 21:02  |  分类:MySQL

在Percona的5.1.53和5.5.8版本,开始将RT的统计内置到MySQL Server端。Thanks, Percona.

Percona在提供了tcprstat工具统计RT时间之后,很快就在Percona Server中集成了响应时间统计的功能。这里介绍一下该功能,各位看官如果在犹豫选择Percona Server还是MySQL Community Server,这里给Percona Server加一个筹码。

"响应时间"(Response time,后面简称RT)在数据库应用中,特别是OLTP的场景,可以说非常重要,不过,MySQL官方版本中一直没有加上这个统计功能。最早,社区开始尝试tcmdump+perl脚本的方式查看RT,后来告警一点用tcpdump+mk-query-digest,再后来Ignacio Nin和Baron Schwartz完成了tcprstat。

在Percona的5.1.53和5.5.8版本,开始将RT的统计内置到MySQL Server端。

1. 配置该功能

这个是功能默认是关闭的,可以通过设置参数query_response_time_stats=1打开这个功能,这是一个动态参数,所以在服务器上可以很方便的打开或者关闭这个功能。可以通过命令SHOW QUERY_RESPONSE_TIME查看响应时间统计。[......]

Read more

MySQL半同步Semi-sync原理介绍【图说】

2011-07-21 23:18  |  分类:MySQL

上图先。

Semi-sync-why

如果还不了解Semi-sync可以阅读(Manual | 概述

1. 优点

当事务返回客户端成功后,则日志一定在至少两台主机上存在。

MySQL在加载并开启Semi-sync插件后,每一个事务需等待备库接收日志后才返回给客户端。如果做的是小事务,两台主机的延迟又较小,则Semi-sync可以实现在性能很小损失的情况下的零数据丢失。

2. 缺点

完成单条事务增加了额外的等待延迟,延迟的大小取决于网络的好坏。

Semi-sync不是分布式事务,主库会在自己完成事务后,等待备库接收事务日志

3. 主机Crash时的处理

[......]

Read more

Pages: Prev 1 2 3 4 5 6 7 8 ... 14 15 16 Next