AWS Aurora 终于推出了Multi-Master，直面硬刚Oracle RAC。在多一份数据库产品选择的小兴奋之余，我们也看看新推出的Multi-Master的特点（包括优缺点）。
1. 首先，Aurora Multi-Master目前只有以下几个Region可用
US East (N. Virginia), US East (Ohio), US West (Oregon), and EU (Ireland)
2. 先来张图，基本可以看到，和Oracle RAC实现的机制是完全不同的，Oracle RAC是内存层面的block cache fusion，Aurora MM是存储复制，基本还是停留在Oracle 9i的理论层面。这里就不深入对比这些了。
本文主要是比较Aurora Multi-Master和Single-Master.
更多安装/测试，请参考：
3. 有个统一的Endpoint可以访问，aurora能内部自动load balance
4. 也可以创建定制化的Endpoint，只访问其中一个instance
5. Multi-Master无法创建replica，整个集群，最多只有两个Master节点。
如果想尝试增加节点，会遇到下面提示。
6. Single-Master可以增加15个replica，Cross Region replica和replica auto scaing等
7. Multi-Master当前只有Mysql-5.6.10a版本可选
8. 其实Single-Master科学的版本也不是很多
9. Multi-Master可选的机器类型只有下面三种，既没有很小的机型，也没有特别大的机型。
10. Single-Master可选的机型，就会丰富很多
总结，Mysql的开源的基因，也决定了，在很多高级功能上，和Oracle还是有不小的差距的。毕竟都是Oracle公司的产品，一个很贵很贵，一个免费free。
但是随个很多大公司的二次开发，在很多方面基于Mysql的数据库产品，也变现出很多值得关注的地方。
Aurora Multi-Master，作为一个新生产品，估计考虑到双主的数据一致性问题，目前还不支持slave的情况。一个Multi-Master集群，目前最多有两个节点。
Aurora single-Master，可以有15个slave，在大数据量，高并发的查询场景中，优势一览无余。由于Aurora的存储是共享的，所以，在Master发生failover的时候，slave接管的过程是很快的。主要延迟在存储同步的gap。理论上，是秒级的failover。
所以，在使用过程中，据需要根据业务情况，数据库可用性的容忍度。来决定，使用Multi-Master还是Single-Master.
金融类强一致性要求的，并且这类传统业务，数据量不会很大，两个节点的Multi-Master，既保证了强一致性，也能满足性能要求。
如果有一定宕机容忍度的系统，Single-Master还是更好的选择，毕竟Master没事也不是经常挂掉。
而且，越美丽，越炫技的功能，就越需要时间去沉淀，去稳定。
所以Aurora Multi-Master，在未来的路上，两个Master是否能和平共处，还是很值得关注的点。
小注：本文已经谢了2个月了，一直没有发blog，为啥没发呢？我也不记得了！估计忙忘记了。所以关于内容部分，不知道在机型支持等细节，是否已经有更新。今天没有验证，直接发blog了。如有细微差别，见谅。