微信号:weixin_dba_zhg

介绍:运维er的自媒体公共账号.在云计算,大数据,自动化时代下的运维丰富生活~

MySQL新纪元(一)

2015-03-03 12:41 David

写这篇文章,主要是感叹很多从业人员依然把MySQL视为一个玩具数据库。很多时候我有这样的感觉,就是他们的思维方式还是停留在10年之前。如果10年太久,那至少也是5年的时间。5年前,Oracle“间接”收购了MySQL,5年后,MySQL非但没有被Oracle给“干”掉,反而依然维持着旺盛的生命力。今年即将发布的5.7将是Oracle对MySQL数据库最大的一次改进,MySQL将完成一次美丽的蜕变,破茧化蝶(这也是为什么去年我新书《MySQL内核:InnoDB存储引擎 卷1》用蝴蝶作为封面的原因)。然而可惜的是,即使是MySQL的相关从业人员本身,如开发人员、DBA等,或许他们自己都没有体会到这样一个新纪元的来临。

MySQL数据库被人诟病的第一要点就是replication(复制),replication技术成就了早期的MySQL数据库。在那个Oracle称雄的年代里,standby服务就真的仅仅是一台备机,除非进行failover,否则其就”一无是处“。MySQL逻辑复制的灵活性是那个时代闪光点,standby服务器可以进行读取操作,资源的灵活性大幅度地提升,而读写分离是那时最为流行的方案。

正可谓成也萧何,拜也萧何。随着应用的深入,用户不得不面对replication的各种问题,逻辑复制的缺点也慢慢凸显出来,首要问题是复制的正确性。MySQL数据库主从的一致性一直是个考验,这或许是其早期不能大规模应用在核心环境的首要问题。虽然5.1版本推出了ROW格式的日志,但是replication依然不是crash safe,即主从任何一台服务器宕机都可能导致主从数据的不一致。虽然Google最早就在3.23的版本中解决过crash safe的问题,但官方直到5.6版本才真正修复了该问题。

逻辑复制的另一个缺点就是回放速度较慢。在十年前这真的不是一个大问题,单台服务器本身承受的QPS就比较低,DML操作可能就更少了,这样的环境下,复制基本没延迟,或者说发生的频率比较小,这也是读写分离方案得以能够真正实施的重要原因。然而,借助于硬件技术的发展,SSD设备的广泛应用,现在仅DML的操作,4K+的QPS就不少见。而且随着移动app的兴起,数据库的写入操作所占的比重已经有了很大幅度的提高,曾经那个读写10:1的年代,可能会从此一去不复返。而曾经那个主从读写分离的架构方案正离应用越走越远前端memcached、redis的缓存技术已逐步替代了replication的负载请求。虽然MySQL 5.6版本提供了并行复制技术,但是由于仅是面向schema的并行,实际效果还是较为有限的。展望即将到来的MySQL 5.7版本,推出了”真正意义”的并行复制,从机的落后情况将得到极大程度的改善。

或许即使MySQL 5.7的并行复制也没有办法将读写分离的解决方案“发扬光大”了,因为用户已经拥有了更好性能、更好成本控制的的缓存架构方案。但是并行复制还可以解决用户的另一个痛点,failover的等待时间。这很好理解,但也是在5.7版本得到了真正的解决。

未完待续……


 
我的运维之路 更多文章 面试MySQL DBA的心得 一起走进MySQL备份身后的故事(篇一 备份的秘密) 一起走进MySQL备份身后的故事(篇二 无锁的备份) 一起走进MySQL备份身后的故事(隐蔽的陷阱) How to Monitor Redis
猜您喜欢 【原译】webpack 2和babel 6的tree-shaking 空间秀的发现之旅:Qzone6.0动画诞生记 API 调用次数限制实现 14年技术经验的创业Boss用人秘籍:我的程序员谁也挖不走! C语言基础入门视频