orczhou.com

MySQL

  • MySQL/InnoDB和Group Commit(2)

    ·

    orczhou

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

    (more…)

  • 使用tbdba-restore-mysqldump.pl切割mysqldump文件

    ·

    orczhou

    这里介绍一个最近用得很多的一个小工具：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

    (more…)

  • MySQL如何传输二进制日志

    ·

    admin

    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。示意图(大图)：

    (more…)

  • MySQL MHA

    ·

    admin

    7月份YOSHINORI MATSUNOBU在Blog上Release了第一个版本的MySQL Master High Availability manager and tools(简称MHA)。

    1. Overview

    用于自动主备切换（Master的Failover），切换时间大约是10-30秒，MHA主要的优势是解决了主备的一致性问题，是第三方脚本的方式，对原来的MySQL没有任何影响，也不需要改变任何原来的架构部署。当然也支持在线的计划切换，切换时间大约也就0.5-2秒【可读，不可写】

    是一种简单、优雅的高可用解决方案，有一些功能：

    1.1 主库监控和Failover

    在一个配好的主从环境中，MHA能够实时的监控MySQL主库，如果探测到主库失败，则会启动自动的切换程序(master failover)。这时，MHA能够保证所有的备库上的数据都一致。MHA会检查所有备库上的relay log，并使用最靠前的relay log，来同步所有其他的备库，保证各个备库的数据一致。MHA一般能够很快完成切换工作：9-12秒来探测主库失败，7-10秒来关闭master来避免脑裂(可选的)，然后在各个落后的备库上应用最新的日志(某一个备库上受到的最新的日志)。整个downtime大概是10-30秒。可以设置某一个备库，总是优先成为主库（可以通过在配置文件中设置优先级来实现），因为各个备库会全部同步，所以任何一个备库都可以成为主库。由于不一致导致的备库失败，这里都可以避免。

    1.2 命令行交互式切换（手动切换）

    不监控，直接进行切换操作。

    1.3 直接切换（非交互式）

    1.4 在线切换主库

    有时候，需要更换主库，例如原主库有已知的硬件故障（RAM、RAID control等）或者换上更好的硬件等等。这是一种计划切换，MHA能够非常快速、并且“一致的”的完成切换。所谓“一致的”，即避免在切换时，原主库上还存在存活的Session，在做一些事务，导致数据的不一致。MHA完成这个“一致的”切换，大概会有0.5-2秒的写阻塞，一般这都是可以接受的维护时间。

    2. Master Failover的挑战

    主库Failover并没有想象的那么繁琐。我们看看最典型的MySQL部署情况：单个主库拖多个备库。当主库挂了，则需要先找到“最新”的Slave，将其升级为新的主库，并且让其他的备库都指向这个新主库。这并不复杂。当找到“最新”的slave，很容易确定其他备库哪些event还没有收到，如果这些非“最新”的备库不问青红皂白就直接连到新主库上的话，则会导致一些数据不一致。为了避免这种不一致，则需要确定哪些是丢失的events，然后apply到这些备库上，再连新主库。如果手动来做这些事儿的话，那就十分繁琐而且复杂。在这个Slide里面详细描述了这个细节：Automated master failover

    Fig: Master Failover: What makes it difficult?

    “最新”的slave表示：获得最多binlog的备库。

    Currently most MySQL Replication users have no choice but to perform failover manually on master crashes.
    在主库crash的时候，目前还没有什么好办法保证各个备库的一致。所以，很多时候需要手动去做这些操作，虽然主库crash的时候不多，但是一旦出现，那将是“相当”（用宋丹丹的口气说）的痛苦。

    MHA目标就是实现这样的自动恢复。这个恢复包括选定新主库、确定各个备库relay log的差异、在新主库上应用差异的relay log，然后将其他备库指向新主库。一般MHA10-30秒可以完成全部的操作（可能更久如果你的备库延迟了很久的话）。

    MHA有自动和命令行切换工具，自动切换命令”masterha_manager (MHA Manager)”由主库监控和主库Failover两部分组成。masterha_manager一直监控主库是否可用，如果发现无法连接主库，则可以立即执行一个非交互是的切换过程。

    手动切换命令：masterha_master_switch先检查主库是否确实挂了，如果真挂了，masterha_master_switch选一个备库作为新主库（也可以指定一个），然后做恢复和切换。命令行把前面的复杂操作全部都封装起来了。

    当已经有了自己的监控系统时（例如，你可以使用Pacemake之类的监控），无需使用MHA的监控功能时，这个功能可以帮你实现MySQL的切换操作。

    3. MHA使用注意事项

    注意事项：

    1. 检测Master是否挂了，可以通过两个路由来确认。详细参考：secondary_network_script
    2. MHA完成切换后，应用还需要完成切换，可以通过脚本：master_ip_failover_script parameter来帮助你做后续的工作。
    3. 为了避免脑裂，MHA提供了一个关闭原Master的脚本shutdown_script parameter
    4. 另外MHA，还提供了一个发送Email切换报告的功能：report_script parameter
    5. 需要考虑级联的情况
    6. Relay log不能再做自动清除了，否则需要的时候可能就没了。需要手动清理relay log，清理relay log时需要注意，没有应用的relay log千万不要清，否则备库就需要重新指向了。MHA有个脚本可以做这个工作：purge_relay_logs script
    7. 在SBR时不要使用LOAD DATA INFILE

    参考资料

    1. MHA Google code主页
    2. MHA 文档资源
    3. MHA download
    4. MHA 介绍: Announcing MySQL-MHA: “MySQL Master High Availability manager and tools” |
    5. MHA for MySQL 0.52 released

  • MySQL5.5 Semi-sync备库响应协议分析

    ·

    orczhou

    这又是一篇介绍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找到对应的包

    (more…)

  • Percona-Server/MySQL响应时间统计

    ·

    orczhou

    在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查看响应时间统计。 (more…)