MySQL半同步复制(Semisynchronous Replication)

发表于 由
1

MySQL 5.5引入了半同步复制（Semi-synchronous Replication），以下是对于半同步复制的认知和理解：

1. 半同步启动需要主从两端都需要加载安装各自对应的semi模块，从库端支持半同步功能的数量至少一台；主库端当一个事务成功提交后，并不及时反馈给前端用户，该线程会被临时block，等待由从库端返回确认该条事务也同时成功写入到relay log中的receipt（回执确认），这时主库线程才返回给当前session告知操作完成，半同步复制并不关心在从库一端该事务是否都被执行并被提交完成。 继续阅读 →

MHA自动Failover过程解析(updated)

发表于 由
12

MHA是一位日本MySQL大牛用Perl写的一套MySQL故障切换方案，来保证数据库系统的高可用。近期，在田老师的推动下，开始一步步深入了解这个HA方案，并也计划在公司线上尝试部署。下面的东西是这段时间的学习笔记和个人理解，没有具体的实战经验，只是人为测试模拟故障的发生，通过日志来分析MHA背后的自动切换过程。 继续阅读 →

DRBD使MooseFS跑得更安全

发表于 由
2

之前写过两篇关于MooseFS的相关概念以及操作管理的BLOG，我们可以看到MFS一些好的地方，比如：通过copy数来保证数据的可靠存，当MFS系统中有个别chunkserver宕机发生，也不会影响应用的正常使用；同时，相比ext3它还能节省存储空间。这里说到，“可靠”，并非这个系统就真的如想象一样，和NFS相比的确，多份copy确实可靠了不少，但是它们都有一个共同的问题，那就是主控server的单点问题。MFS系统中，即便有metalogger server的这个作为master的角色，但问题依然存在。下面就说说使用中的体会。 继续阅读 →

MySQL为什么要引入Thread Pool的线程处理模式

发表于 由
1

从5.5.16开始，在MySQL的商业化版本中将Thread Pool作为plugin提供官方功能支持。在之前的版本中，线程处理模式包括两种：no-threads(单线程处理，多用于debug)、one-thread-per-connection（每个请求对应一个线程，目前被作为默认值）；在支持thread pool功能的版本中，thread_handling则需设置为dynamically-loaded。 继续阅读 →

MySQL Tuning之浅析I/O优化

发表于 由
1

目前web的应用大多都以I/O密集型为主，而存储技术的发展远没有计算机中其他系统发展迅速，尽管也有不少高端存储设备，但是价格的昂贵，不是一般大众能享受的起的。而基于现状更多是我们使用一般SAS盘结合应用使用不同的RAID组合，来实现我们平民化存储，为了得到更好的性能，那么和I/O相关的调整优化是必不可少的。 继续阅读 →

MTU值的调整导致MySQL复制异常

发表于 由
2

今天的故事简单有趣，你绝对没有遇到过。当我们把网卡的MTU值从默认的1500，调整为3000/6000/9000后，复制十分诡异，搞得我云里来雾里去的，先记录下：

以下命令可以动态修改MTU值及时生效，和查看状态的一些命令：

shell> ifconfig eth1 mtu 3000 up (永久生效可以增加MTU=XXXX到配置文件ifcfg-ethN中)

shell> ip link list eth1 继续阅读 →

“ERROR 1235 (42000): skip-innodb is defined”的误导

发表于 由
2

ERROR 1235 (42000): Cannot call SHOW INNODB STATUS because skip-innodb is defined

以上这个醒目错误提示，如果你是一个细心专业的DBA的话，可能这辈子你也遇到这样的问题，而我不是，毛躁马虎加上不专业，已经成了我的标签，所以，“幸运的”本人才遭遇到这个Error。究竟怎么一个动作导致出现这样的错误呢，下面简单描述下。 继续阅读 →

Heartbeat+DRBD+MySQL Replication故障处理

发表于 由
1

不久前的一次机房网络故障，再一次对我们在Heartbeat+DRBD+MySQL数据库架构运维水平的一个考验，之前不止一次的测试与线上部署，还有之后大言不惭的关于该架构组件的所谓深入理解，在这一次不经意的意外面前又是“很囧”的收场，慌张呀！这次断网导致H-D-M全线异常，真是千载难逢，都让我们赶上啦lol: 下面就把这次的小幸运小幸福和大家分享下，以下是按照问题处理的先后顺序依次讲述。 继续阅读 →

Innodb Crash Recovery恢复时间的飞跃

发表于 由
2

之前没经历过漫长的crash recovery恢复过程，一是本身库中的数据量就不大，平时的业务量就不是很高，二是innodb_buffer_pool_size和innodb_log_file_size的大小平时设置的也不大。所以，对于意外导致innodb自动恢复时，经历的等待时间的长短没有什么深刻的体会。在浏览peter很早以前的文章时，看到当时大家是多么的无奈和痛苦，同时，在InnoDB没有对其作出改进之前，大家都在开动脑筋，配合各种参数尽可能的缩短故障恢复的时间。先来了解下，什么是Crash Recovery，它究竟都帮我们做了什么。 继续阅读 →