标签：blog http java 使用 strong os
图片和资料来源于MYSQL大牛姜承尧老师（MYSQL技术内幕作者）
姜承尧： 网易杭州研究院 技术经理 主导INNOSQL的开发
数据库的可靠指的是数据可靠
数据库可用指的是数据库服务可用
可靠的是数据：例如工商银行，数据不能丢失
可用的是服务：服务器不能宕机
灵活运用MYSQL的各种高可用技术来达到下面各种级别的高可用要求
要达到99.9%：使用MYSQL复制技术
要达到99.99%：使用MYSQL NDB 集群和虚拟化技术
要达到99.999%：使用shared-nothing架构的GEO-REPLICATION和NDB集群技术
Gluster Geo-replication是什麼？
Gluster Geo-replication(简称geo-replication)是一种异地灾备技术，
它主要应用于把集群中的一个存储，近乎即时地(near real-time)透过公网（wan）备份到远端的机房
各种高可用级别允许的宕机时间
DRBD：网络磁盘的RAID1
方案一：MYSQL主从复制（单活）
投票选举机制，较复杂
MySQL本身没有提供replication failover的解决方案，自动切换需要依赖MHA脚本
可以有多台从库，从库可以做报表和备份
方案二：双主（单活），failover比单主简单
同样，自动切换需要MMM脚本
缺点是某个主挂掉了，他下面的slave同样挂掉
方案三：双主配SAN存储（单活）
这个架构跟方案二是一样的，只不过两个master之间不需要同步数据，因为他们用的是共享磁盘
这个方案是有钱人方案，无论哪个主挂掉都不会引起其他的slave挂掉，但是SAN存储死贵。。
像通信行业中国联通这些公司有用到
某个主挂掉了，下面的slave不会挂掉
注意：failover之后不会预热，数据没有预先加载到内存中，切换之后一段时间内存储会有一定的性能影响
方案四：DRBD 双主配DRBD （单活）
结构跟方案三一样，唯一不同的是没有使用SAN网络存储 ，而是使用local disk
由于是实时复制磁盘数据，性能会有影响
人们把DRBD称为“屌丝的SAN”
POOR MAN‘S SAN：穷人的SAN
方案五：NDB CLUSTER
国内用NDB集群的公司非常少，貌似有些银行有用
NDB集群不需要依赖第三方组件，全部都使用官方组件，能保证数据的一致性
某个数据节点挂掉，其他数据节点依然可以提供服务
管理节点需要做冗余以防挂掉
缺点是：管理和配置都很复杂，而且某些SQL语句例如join语句需要避免
方案六：第三方的Tungsten软件
使用java编写，不是MYSQL内置的
同样是MYSQL数据库复制，不过他不是用MYSQL内置的组件来做的
不但支持MYSQL数据库复制也支持异构数据库的复制，而且对异构数据库复制支持较好，例如MYSQL复制到ORACLE
方案七：网易的INNOSQL
类似于SQLSERVER的镜像高安全模式
High Safety 模式 （也就是同步模式）没有 witness服务器
数据库在Principle的事务，需要马上得到mirror的确认，才能完成。这种情况下，Mirror和Principle的数据是同步的。
但是因为所有的事务需要mirror的确认，所以性能可能会有所影响。
区别：innosql的slave可以读，镜像的slave（从库）不可读
保证数据不会丢失，数据的高可靠性
mysql5.7开始支持这种模式
总结
每种方案都有不同的特点，配置和应用场景也各有不同
有些偏向于成本低的，有些偏向于成本高的，有些偏向于数据的可靠性，有些则偏向于数据库的可用性
反正各个方案都各有优缺点，DBA要结合自己公司的业务情况进行选择合适自己业务情况的高可用方案
更多参考资料：
读写分离：Amoeba
Ubuntu10下MySQL搭建Amoeba系列（文章索引）
集群技术：数据库集群技术漫谈
如有不对的地方，欢迎大家拍砖o(∩_∩)o
分享MYSQL中的各种高可用技术（源自姜承尧大牛）,布布扣,bubuko.com
标签：blog http java 使用 strong os
原文地址：http://www.cnblogs.com/123ing/p/3840126.html
