MySQL半同步复制(Semisynchronous Replication)

MySQL 5.5引入了半同步复制(Semi-synchronous Replication),以下是对于半同步复制的认知和理解:

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

MHA自动Failover过程解析(updated)

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

DRBD使MooseFS跑得更安全

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

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

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

MySQL Tuning之浅析I/O优化

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

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

今天的故事简单有趣,你绝对没有遇到过。当我们把网卡的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”的误导

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

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

Heartbeat+DRBD+MySQL Replication故障处理

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

Innodb Crash Recovery恢复时间的飞跃

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