数据库高可用架构 转载

数据库高可用架构对于咱们这些应用端开发的人来讲是一个比较陌生的领域，是在具体的数据库产品之上搭建的环境，须要像DBA这样对数据库产品有足够的了解才能有所涉及，虽然不能深刻其中，但能够经过一些经典的高可用架构学习其中的思想。就我所了解到的有如下几种：

• MySQL Replication
• MySQL Cluster
• Oracle RAC
• IBM HACMP
• Oracle ASM

MySQL Replication

MySQL Replication就是经过异步复制多个copy以达到提升可用性的目的，常规的复制架构有如下几种：

• Master-Slaves
• Master-Master
• Master-Master-Salves

1）Master-Slaves

Master-Slaves是最经常使用的提升可用的方法，特别是在互联网应用中，读远远大于写，所以提升读的可用性是首当其中的，Master-Slaves就是让写的操做集中在一台数据库Master上，而后这个Master会把更新的操做复制到其余数据库Slaves上，读的操做都发生在Slaves上，架构图以下所示：

如上图在SlaveC不可用时，读和写都不会中断，等SlaveC恢复后会自动同步丢失的数据，又能从新投入运转，可维护性很是好。但若是Master有问题就麻烦了，所以它只解决了读的高可用性，但不保证写的高可用性。关于Master-Slaves的实战可参考之前的一篇博文构建高性能web之路------mysql读写分离实战

2）Master-Master

为解决上面谈的写的高可用性，MySQL提供了Master-Master的复制架构，以下所示：

通常说来都向MasterA写，MasterA同步数据到MasterB，当MasterA有问题时，会自动切换到MasterB，等MasterA恢复时，MasterB同步数据到MasterA

3）Master-Master-Salves

Master-Master-Salves是结合上面两种方案，是一种同时提供读和写高可用的复制架构，以下图所示：

MySQL Cluster

MySQL Cluster主要由三个部分组成：

• SQL服务器节点
• NDB数据存储节点
• 监控和管理节点

三个部门的组成结构以下图所示：

这样的分层也是由MySQL自己把SQL处理和存储分开的架构相关系的，关于MySQL的架构可见之前的博文设计与开发应用服务器（一）------常见模式

这样一来MySQL Cluster就能够分别在SQL处理和存储两个层次上作高可用的复制策略。在SQL处理层次上，比较容易作集群，由于这些SQL处理是无状态性的，彻底能够经过增长机器的方式加强可用性。在存储层次上，经过对每一个节点进行备份的形式增长存储的可用性，这相似与MySQL Replication，结构图以下所示：

Oracle RAC

Oracle RAC和MySQL Cluster有些类似，但主要集中在SQL处理层的高可用性，而在存储上体现很少，结构图以下所示：

它的主要优势就是对应用透明，而且经过Heartbeat检测可用性很是高，主要缺点就是存储是共享的，存储上可扩展能力不足。

IBM HACMP

IBM HACMP与Oracle RAC也是相似，主要用于双机互备，运行流程以下所示：

1）做为双机系统的两台服务器（主机A和B）同时运行在Hacmp环境中；
2）服务器除正常运行自机的应用外，同时又做为对方的备份主机；
3）两台主机系统（A和B）在整个运行过程当中，经过 “心跳线”相互监测对方的运行状况（包括系统的软硬件运行、网络通信和应用运行状况等）；
4）一旦发现对方主机的运行不正常（出故障）时，故障机上的应用就会当即中止运行，本机（故障机的备份机）就会当即在本身的机器上启动故障机上的应用，把故障机的应用及其资源（包括用到的IP地址和磁盘空间等）接管过来，使故障机上的应用在本机继续运行；
5）应用和资源的接管过程由Ha软件自动完成，无需人工干预；
6）当两台主机正常工做时，也能够根据须要将其中一台机上的应用人为切换到另外一台机(备份机)上运行。
Oracle ASM

Oracle ASM主要提供存储的可扩展性，经过自动化的存储管理加上后端可扩展性的存储阵列达到高可用性，结构图以下所示：

所以，能够尝试把Oracle RAC和ASM组合起来使用，同时提供SQL处理和存储的高可用性，这也是MySQL Cluster想达到的效果