对比
![img_129ba205ede99fa8eff1426f5abeb0f7.jpe]()
昨天聊了一篇关于高可用方案中Oracle的RAC和MySQL的MHA的对比。
今天来说下Oracle的DG和MySQL的方案对比，相比来说，可能这方面MySQL会单薄一些，所以文末会说下InnoDB Cluster。
在灾备的概念中，Oracle DBA喜欢叫做主备，即为Primary,Standby,而MySQL喜欢叫做主从，即为Master,Slave
首先在Oracle中，数据是基于物理复制（此处说的都是physical standby），所以对于数据库的状态和角色就很好定位，从库正常状况下是无法读写的。所以在Oracle中的角色转换的概念就很清晰，failover和switchover,failover就是故障转义，switchover就是主备切换。在MySQL中failover的概念很好理解，但是switchover相比来说，就会淡化很多。
Oracle因为是基于物理复制，所以一直以来备库要么就是恢复状态，要么就是只读不应用状态，直到11g这个问题才解决，就是大名鼎鼎的ADG,而在MySQL里面这都不是事儿，备库可以灵活的开关read_only的参数，当然一般是不希望备库写入的。
对于Oracle的备库的理解，我认为除了ADG之外，最有亮点的就是闪回数据库了，可能很多Oracle DBA都对于闪回数据库敬而远之，技术的更新很多，好端端的特性放着不用太可惜了，比如搭建DG,分分钟DG Broker搞定，使用手工方式不见得有多高效。
闪回的概念在MySQL里面也有，目前来说，可以根据binlog抽取的数据做到DML的闪回，和Oracle里面的闪回差距还很大。Oracle里面的闪回五花八门，零零总总算下俩，差不多就有这些。
![img_c1f5caa10277bc8495a605d27f68ae87.png]()
当然常用，实用的不见得这么多，MySQL的DML还算是原生态，但是DDL就是难上加难了，目前MariaDB的DDL闪回就是一个突破，从我的理解来说，应该能够实现一部分的闪回功能，具体的效果我后面测试一下。
所以说闪回是个大宝藏，到底有多好呢，Oracle的备库方案有了快照数据库，就是物理备库可以临时写入，带来的优点就是主库的碎片，在备库是完全一样的。所以在SQL审核方面有着得天独厚的优势，我在线上的很多DDL审核中都做过测试和实际应用，效果很赞。
对于灾备来说，数据库的切换是未雨绸缪的事情，那么到底备库切换的检查是否OK呢，Oracle里面有了DG Broker这么一个神器，还在新版本中做了很多不错的选项，比如新版本中有了validate的选项，可以检测主备切换的条件是否满足。
![img_71ed515a82038eaf4d1ba72a7de13c4f.jpe]()
除此之外，从高可用的角度来说，如果在备库存在连接，做switchover的时候，会话会持续保持，当然会有短暂的卡顿。这也就是特色的会话保持特性。
Preserving Active Data Guard Application Connections
当然在MySQL里面就不可理解了，切换别说会话保持，卡顿的影响都微乎其微。
基于物理复制的方式，Oracle的复制扩展性就很难实现，当然也不是说完全不能实现，比如cascade standby，可以级联复制，到了12c改进一版，就是Far Sync，号称是零数据丢失，对于跨区域的数据中心来说，会把延迟降到最低。
![img_4951ed19e88547e3ebd02ea2aadcbb2e.jpe]()
如果从技术架构的角度来看，部署的分布图类似下面的形式，中间有远距离的数据传输，可以通过中间的节点来转换，中间这个节点很特别，是不存数据的，只是保持一个内存结构，同步数据。
![img_462ad7ed76bda81711451d3d780920cd.jpe]()
还有就是延迟，我测试过DG的延迟，和MySQL在基本相似的压力情况下，Oracle基本上控制在0.1秒左右，MySQL的复制就会有一些延迟的放大。
所以总体看下来，Oracle的方案是一种很专业的解决方案，工具全，架构相对复杂，数据同步是强一致性。所以在涉及交易的业务中对它的偏爱。
我们再来看看MySQL方向的改进。我们不比单机性能和延迟了，因为这个确实是有差距，我们比其他的方面，刚好又是Oracle难以实现的地方。
首先说下主从复制，MySQL是典型的逻辑复制，主库端可以承载大批量的并发，但是性能瓶颈很明显，主库的并发最后落到文件上还是串行的，抛开日志传输进程的开销，最大的瓶颈就在于SQL_Thread的应用延迟。就好比中午大家出去吃饭，前台可以并发点很多的菜品，但是后台的厨师就好比是SQL_Thread,他得一道菜一道菜做啊。怎么能做得更快呢，比如你叫了5分盖饭，他可以一次性炒出来，这样就能够大大提高效率，所以前台的小姑娘也会建议你和其他人点一样的菜，原因就一个字 快。这用在并行复制上就是类似的道理。MySQL 5.6没法做到细粒度的并行复制，只能在库级别，而在MySQL 5.7中可以做到表级别的和更细粒度的，这个改进久很明显了。
![img_3325a54e4e4948fb169d01700e942d28.jpe]()
所以延迟的问题能够解决，后续的扩展就容易多了，MySQL的扩展甚至可以做到指数级的扩展方式，如果允许一些第延时，那么大量的读请求就可以逐步分解。所以一主多从的架构方式也是见怪不怪。而且在MHA中，如果多个从库存在延迟，在切换的时候MHA会补上差异的日志，这是MHA的一大亮点。
而MySQL的级联复制就很纯粹了，和Oracle相比的最大优势就是一个数据库可以既是主库也可以同时是从库，起到承上启下的作用。这种扩展方式兼职是酸爽，在一些跨数据中心的场景，允许一定延迟的情况下还是有用武之地。比如你从北美读数据，可以经过北京的几点达到香港或者新加坡，连接到北美。
![img_32f372e07c4863853903ba98d20fe9f1.jpe]()
有了这种方式就很容易扩展。当然在实时交易中还是存在一些瓶颈和缺陷。MySQL的扩展性方案很多，很多时候都会需要考虑中间件的方案，需要考虑sharding来分片，读写分离来做分担读写压力，前端访问可以通过大量的水平扩展来做，从这个角度来说，MySQL是以规模取胜，因为不是一个人在战斗。
比如在MySQL 5.7.17中一直诟病没有的官方高可用方案MGR正式推出了。这对社区是一个很好的信号，然后紧锣密鼓有了InnoDB Cluster,虽然还没有实现sharding，但是容灾切换，读写分离是有了。由此也能看到MySQL其实不只是想做一个方案，而是希望做到更多的集成。
![img_761c5f72134ac924acee366ff6aeb2b6.jpe]()
