MySQL5.5引入了半同步复制(Semi-synchronous Replication)，以下是对于半同步复制的认知和理解： 1. 半同步启动需要主从两端都需要加载安装各自对应的semi模块，从库端支持半同步功能的数量至少一台；主库端当一个事务成功提交后，并不及时反馈给前端用户，该线程会被临时block，等待由从库端返回确认该条事务也同时成功写入到relay log中的receipt(回执确认)，这时主库线程才返回给当前session告知操作完成，半同步复制并不关心在从库一端该事务是否都被执行并被提交完成。 2. 半同步与异步复制相比，进一步提高了数据完整性(不太理解为什么这么说)，保证了事务成功提交后，有两份记录被记录下来，一份在主库上，另一份至少在一个从库上。 3. 半同步复制在平衡性能与数据可靠性方面，采用了network group commit的方式来复制binlog。
之前写过两篇关于MooseFS的相关概念以及操作管理的BLOG，我们可以看到MFS一些好的地方，比如：通过copy数来保证数据的可靠存，当MFS系统中有个别chunkserver宕机发生，也不会影响应用的正常使用；同时，相比ext3它还能节省存储空间。这里说到，“可靠”，并非这个系统就真的如想象一样，和NFS相比的确，多份copy确实可靠了不少，但是它们都有一个共同的问题，那就是主控server的单点问题。MFS系统中，即便有metalogger server的这个作为master的角色，但问题依然存在。下面就说说使用中的体会。问题：当mfsmaster主机发生问题，按照MFS系统的提供的故障切换方法，mfsmetalogger主机会被提升为mfsmaster，继续提供服务，服务是能够提供，但是，如果你真的实际操作过，就知道后续你要做多少动作。
MHA是一位日本MySQL大牛用Perl写的一套MySQL故障切换方案，来保证数据库系统的高可用。近期，在田老师的推动下，开始一步步深入了解这个HA方案，并也计划在公司线上尝试部署。下面的东西是这段时间的学习笔记和个人理解，没有具体的实战经验，只是人为测试模拟故障的发生，通过日志来分析MHA背后的自动切换过程。首先，介绍下它的一些特点，以及为什么用它，在哪种场合更适合用它。 1. 10-30s实现master failover(9-12s可以检测到主机故障，7-10s可以关闭主机避免SB，在用很短的时间应用差异日志) 2. 部署简单，无需对现有M-S结构做任何改动(至少3台，保证切换后仍保持M-S结构) 3. 支持手动在线切换(主机硬件维护)，downtime几乎很短0.5-2s 4. 保证故障切换后多从库数据的一致性 5. 完全自动化的failover及快速复制架构恢复方案(一主多从)
今天的故事简单有趣，你绝对没有遇到过。当我们把网卡的MTU值从默认的1500，调整为3000/6000/9000后，复制十分诡异，搞得我云里来雾里去的，先记录下：以下命令可以动态修改MTU值及时生效，和查看状态的一些命令： shell> ifconfig eth1 mtu 3000 up (永久生效可以增加MTU=XXXX到配置文件ifcfg-ethN中) shell> ip link list eth1 shell> ethtool shell> ping -s xxxx IP (当增大MTU后，-s值大于1500的ping都会失...
从5.5.16开始，在MySQL的商业化版本中将Thread Pool作为plugin提供官方功能支持。在之前的版本中，线程处理模式包括两种：no-threads(单线程处理，多用于debug)、one-thread-per-connection(每个客户请求对应一个线程，目前被作为默认值)；在支持thread pool功能的版本中，thread_handling则需设置为dynamically-loaded。最初当我看到说MySQL会支持Thread Pool这个功能的时候，我很疑惑，心想不是已经有thread_cache_size来提高线...
目前web的应用大多都以I/O密集型为主，而存储技术的发展远没有计算机中其他系统发展迅速，尽管也不少高端存储设备，但是价格的昂贵，不是一般大众能享受的起的。而基于现状更多是我们使用一般SAS盘结合应用使用不同的RAID组合，来实现我们平民化存储，为了得到更好的性能，那么和I/O相关的调整优化是必不可少的。对于我们数据库调优来说，磁盘io优化是首屈一指的调优重点，我们都知道木桶原理，短板绝对整体的好坏，而数据库系统...
日常工作中，对于MySQL主从复制检查，一方面我们要保证复制的整体结构是否正常，另一方面需要检查主从数据是否保持一致。对于前者我们可以通过监控复制线程是否工作正常以及主从延时是否在容忍范围内，对于后者则可以通过分别校验主从表中数据的md5码是否一致，来保证数据一致，可以使用Maatkit工具包中的mk-table-checksum工具去检查。在这里，我只想讨论下关于如何检查主从延时的问题。判断主从延时，通常有两个方法：1. Second...
当innodb_buffer_pool_size大到几十GB或是百GB的时候，因为某些日常升级更新或是意外宕机，而必须要重新启动mysqld服务的之后，就面临一个问题，如何将之前频繁访问的数据重新加载回buffer中，也就是说，如何对innodb buffer pool进行预热，以便于快速恢复到之前的性能状态。如果是光靠Innodb本身去预热buffer，将会是一个不短的时间周期，业务高峰时，数据库将面临相当大的考验，I/O的瓶颈会带来糟糕的性能。那么，该怎么办呢？
不久前的一次机房网络故障，再一次对我们在Heartbeat+DRBD+MySQL数据库架构运维水平的一个考验，之前不止一次的测试与线上部署，还有之后大言不惭的关于该架构组件的所谓深入理解，在这一次不经意的意外面前又是“很
之前没经历过漫长的crash recovery恢复过程，一是本身库中的数据量就不大，平时的业务量就不是很高，二是innodb_buffer_pool_size和innodb_log_file_size的大小平时设置的也不大。所以，对于意外导致innodb自动恢复时，经历的等待时间的长短没有什么深刻的体会。在浏览peter很早以前的文章时，看到当时大家是多么的无奈和痛苦，同时，在InnoDB没有对其作出改进之前，大家都在开动脑筋，配合各种参数尽可能的缩短故障恢复的时间。先...
最近小弄下Percona Xtrabackup，写脚本做测试，对这个世界唯一的开源免费(the world’s only open-source free)MySQL(the world’s most popular open source databases这句我也很喜欢 lol:)热备工具有了一些懵懂的认识，对于付费的InnoDB Hot Backup我们有了更欢乐的选择。Percona Xtrabackup工具主要有两部分构成，一个就是c写的xtrabackup命令，它又有多个版本，分别对应不同版本(5.0及以上)的MySQL/XtraDB以及InnoDB的差别(bui...
为什么突然想说说临时表呢，之前都没有太过多的留意这些知识，是昨天以前的一个同事问了我一句关于临时表的疑问，我也顺便加深写认识。其实，我对于MySQL临时表的应用可以说是一无所知，说的最多听得最多的也都是，查询语句时用到临时表的情况，就是说的internal temporary table，是MySQL自己因为执行某个操作需要额外使用的，而另一种就是user-defined，用户自己定义的(create temporary table)； 之前在798game的时候，公司的手...
sql_slave_skip_counter这个全局参数，维护过主从架构的DBA一定都不陌生，当从库的sql_thread被意外中断，你又想尽快恢复主从间的正常复制，就会用到这个参数；这个跳过的后果就是，你的业务要能容忍这个跳过所带来的丢失，也就是主库和从库上的数据将会不再一致，尽管之后你的主从同步又正常，其实严格意义上，这个从库已经没有意义了，无论是去备份还是对外提供读的服务，也就是说“她”已经不在纯净。那么，这个参数具体是什么...
年前很长时间都在鼓弄cacti+nagios，完善我们的监控报警系统，并在在田老师的指导下，对监控系统又有了跟多的认识，其实，监控系统不单单仅仅为了发现故障，它还可以为我们的许多项目实施提供资源，运维的很多事情都可以围绕它来展开，可谓ALL IN ONE。目前，还是主要采用cacti+nagios的组合，cacti提供历史记录和趋势走势，nagios主机和服务的故障报警，当随着主机的增多，各应用监控项的不断增加，cacti和nagios都将会面临性能问...
最近了解了一个分布式文件系统――MooseFS，之前对分布式的东西知道的很少，分布式文件系统、分布式数据库都是近而远之，觉得太复杂了离我还很遥远。在各位老师的推动下我用6台机器实践了一下moosefs，moosefs的部署还是很简单的，和配置NFS很像，就是多了两种角色的机器，正是有了它们，才使得moosefs在可扩展性和稳定性上都要远好于NFS，在读写的性能方面，通过dd进行的简单测试来看，moosefs也就是写入的速度稍微好于NFS，读上...
自从nagios报警服务配置完善以后,潜伏在DB上的问题变得愈加凸显，这期间还经历了三番五次的机器故障，于是就更加紧绷了我们对于目前DB状态的关注度，通过cacti看每组机器资源的使用情况，通过nagios的alert提示会知道哪些异常在频繁出现，尽管没有发出报警通知（报警策略：所有服务检测每个5分钟扫描一次，发现故障第一次提示开始，每隔1分钟再去尝试，一共4次，当确认该服务失败或者超过阀值后，将状态从之前的Soft更新为Hard，然...
DRBD和Heartbeat这两个用于实现高可用的组合,折腾了有一周了，从开始的新鲜到配置成功的兴奋再到遇到问题的苦闷最后还是在其中一点点的被纠结着，似懂非懂中迷茫着，似乎从小到大没有一件事能做得明白的，稀里糊涂得就奔着三十去了。下面就把这一周里遇到的疑惑，抖露抖露，大家也给点力，说说你们的理解。DRBD是个什么东西――Distributed Replicated Block Device，这4个英文单词说的很明白，BD说明要实现这个功能首先要是块设备...
曾经写过一篇关于XtraDB的体验篇的文章，里面曾提到我们可以动态将XtraDB加载到运行的MySQL中；MySQL中引擎我们都可以把它看作是一个个功能各异的插件（plugin），可以根据需要来加载卸载禁用启用，相当的方便灵活，只要你想你也可以写自己的ENGINE，然后把它加载进来，而这个plugin也是正是MySQL独特的地方所在。当初也就是那么一提，并没有具体操作怎么就动态把一个plugin加进来。而这次也是工作中碰到了，必须要这么做，其实，...
先简单说下什么是MySQL Proxy。从名字上就清晰可见代理嘛，就是在你能直接进行操作前，都要经过这个代理或是agent（国外片里的特工），client-agent-server就是这么一个过程，既然mysql-proxy加在客户端和服务端之间，那么它就必须要能听懂双方说的是什么，它的角色就像一名接线员（operator）。我们都知道mysql client和mysqld通信时，采用的是MySQL自己的网络协议，而MySQL Proxy也同样使用的是这个网络协议，那么三者之间也就没有什么障碍了。除了可以按照策略分发请求，既然放在两者中间，那么所有过来的请求它自然都可以截获，如果你愿意当然还可以做操作前的审核，也可注入些新的东西。Agent嘛，无所不能,不过你需要先对Lua无所不能LoL。
之前的一段时间，工作趋于稳定，没有过多的波动了，除了日常的琐事，就是配置replicaton以及更新维护脚本，也没有什么提高了。就像上周面试的时候PICA的一个项目技术总监，问我平时都做什么，听完后，便诧异的问：你这个DBA，似乎每天都没有什么事情呀！我自己想想，也是哦，真的想不出都做了点什么有技术的工作，那怎么每天每天还不把自己弄的跟个忙人似的，我很脸红，5个SQL题，没有一个能够写对，就这样还志高气昂的想做DBA，最基本的SQL都写不明白，哎…我沉默了，无言以对。还有一点，感触就是，自己做事情真的不到位，从来没有说我要把一件事一个脚本写到“极致”，做到精益求精，没有，还是没有，失败呀！
