[SqlServer03]-数据库高可用性方案

       随着企业的业务扩展,企业应用所承载的访问需求也更加频繁及多元化,对于大多数企业应用来说,确保企业应用的高可用性(HA)是十分必要的。比如公共安全系统,电子商务支持系统、银联支付系统等等系统。高可用性分为两个主要的部分,一部分是应用程序(SOA服务)的高可用性,另一个方面就是数据库的高可用性。企业应用服务的高可用性主要是通过网络负载均衡(NLB)来实现,这个在另外的章节我们再探讨,这一章节我们主要探讨sqlserver数据库的高可用性集群是如何满足高可用性需求的。

       数据库有两大基础作用,一个是存储系统相关的数据,二是提供对数据的管理机制。管理机制很多时候比存储数据功能更重要。这套机制能够确保数据的一致性,合理性、提高读取性能等等方面,当然这些规则及特性支持可以实际情况进行手动开启或关闭,并且可以自定义一些规则来约束对数据的操作。基于数据安全性的考虑,通常需要在另外一个物理位置对数据进行备份,避免数据因为一些特殊原因丢失而造成无法挽回的损失。这种情况下,确保两个数据库的数据一致性就很重要,如何将针对其中一个数据库的操作准确无误地反映到另外一个备份数据库上是一个重要的课题。其实这也是数据库HA最需要解决的问题。具体来说有以下几种方式:

      1)数据库复制

      数据库复制不是数据库备份和还原。数据库复制是通过发布和订阅来实现的。主数据库和备份数据库之间是发布和订阅的关系,一旦主库数据进行了修改,那么从库也做相应的动作,但主从数据库并不是实时同步的,一般会有延时,因为订阅数据库在一定时间内(通常5sec)会扫面主数据库是否有更改。这种方式是通过日志进行同步操作的,效率也还可以接受。但有一点是不接受DDL语句,即主数据库表结构的变动无法反应到从数据库,必须手动来同时更改库结构再同步。

      2)数据库镜像

      数据库镜像顾名思义是数据库的实时备份镜像。不同于发布订阅,数据库镜像的镜像数据库是不可读也不可写的。也就是说,如果应用程序希望通过访问镜像数据库来获取数据从而分担主数据库的压力这种方案是行不通的。必须对镜像数据库做数据库快照才可以访问。做数据库镜像的时候对数据库有一些要求,如必须在Full Recovery 模式下才能做数据库镜像,对版本也有一定的要求。

      3)数据库快照

      数据库快照是给数据库的拍的照片,这个不是实时的备份,很多的应用需求不能被满足。相比于通过日志进行的同步,性能损耗比较大,尤其是当数据量比较大。通常是通过数据库快照恢复数据。

      这三种方式中数据库复制订阅支持多个数据往一个数据库进行同步。对于单向数据复制的需求能够很好地满足。比如有多个录入系统,数据入库进入本地数据库,本地数据库与服务端的数据库进行发布订阅,本地数据库发布数据库,服务端数据库订阅数据库,每一个录入端都发布数据库,服务端数据库订阅每一个服务端,这样每个录入端的数据就能够及时进入服务端,服务端就能够对所有客户端的数据进行汇总,统计,分析等等。优点是无论是订阅端还是发布端数据都是可读的(客户端当然是可写的),原则上订阅端的数据时不可写的,因为订阅端的更改不会反应到发布端,因为发布订阅是单向的。

      通常数据库镜像是由三个物理数据库组成,一个是Principle,一个是Mirror, 还有一个Witness,Witness数据库是监测Principle 和 Mirror 的状态,实际并不存储数据,通常Witness 会承担其他任务,比如 Reporting Service。Principle 和 Mirror 之间传递着一个 Message. 这个Heart Beat是主从数据库角色转换的依据,一旦从数据库收不到主数据的Heart Beat 信息,从数据库立即响应数据库访问请求,从数据库立即转变成主数据库,主数据库理解转换成从数据库。主从数据库之间的数据同步是通过日志来实现的,并且有High PerformanceHigh Safety 两种模式,前者是理解响应访问请求,然后再将数据更改反应到从数据库,后者是先将数据更改反应到从数据库,再响应访问请求。因为将数据更改反应到从数据库的过程中可能fail掉。

      数据库响应请求分为读请求和写请求,由于数据库有物理读和逻辑读,读请求访问物理磁盘的几率较小,效率最低的是写请求。如果能够将读请求和写请求进行分离,能够大大地提高数据库集群的处理能力。于是SqlServer 2012 开始,提供了 SqlAlwaysOn组件。SqlServer 2012 组件让数据库的镜像能够可读。由数据库镜像来处理数据库的读请求,主数据库处理写请求。

      还有非常重要的一点是SqlAlwaysOn能够对数据库进行分组。

      [SqlServer03]-数据库高可用性方案_第1张图片

       下一个章节继续。


     




你可能感兴趣的:(数据库)