MSSQL高可用性和扩展性

概述在众多主流关系型数据库中Oracle的集中型(Rac), Mysql 的分布型(Repl)前者往往依赖于主流厂商的硬件,纵向扩展负载CPU,面对IO的压力只能水平垂直拆分业务.后者未被Oracle收购前版本在面对存储单点故障时M_M_S的结构又不那么灵活.而Mssql属于2者中间.在面对不同业务需求时候 Mssq…

　　在众多主流关系型数据库中Oracle的集中型(Rac),MysqL 的分布型(Repl)

　　前者往往依赖于主流厂商的硬件,纵向扩展负载cpu,面对IO的压力只能水平垂直拆分业务.

　　后者未被Oracle收购前版本在面对存储单点故障时M_M_S的结构又不那么灵活.而Mssql属于2者中间.在面对不同业务需求时候 Mssql同时提供nothing Share和 Everything Share 模式.

　　所谓的nothing Share 即: 横向扩张,读写分离.用多台便宜的Server + Sas盘来替代高端服务器和存储.而面对服务器级别的故障时Mssql同时提供了故障转移群集.群集的个数跟windows 版本有关.生产环境中往往考虑到成本采用AA群集或者 2+1群集.

　　windows Server 2003 最多支持 8 个故障转移群集节点

　　windows Server 2008 最多支持 16 个故障转移群集节点

　　(图:2) Everything Share (AA Cluster)

　　MSsql 扩展性

　　olTP 讲究的是快进快出.因此在面对千万乃至亿级的的数据量.水平拆表成了上上之选

　　同时通过Replication 分发到多台便宜的Server + Sas盘来做读.

　　相对于MysqL的主机Repl,Mssql可以采用远程分发机来减少Repl本身带来的性能压力.

　　同时Mssql从2005 开始支持 乐观事务隔离,配合远程分发机,同时对分发机做AAcluster.

　　从主机性能压力和高安全都有完善的保障. 前端访问通过F5分配到多台SUB上,一旦出现SUB故障或者延迟较高时.可以从F5的虚拟ip池中把故障服务器从中Offline.等恢复故障后在Online.

　　分布式的扩展不仅能负载cpu同时也能对IO负载起到个很好的效果. (图:3)是Mssql Repl 配合水平拆分的扩展.

　　(图:3) MSSQ基于Repl和水平拆分的扩展性

　　MSsql的高可用性

　　Mssql用Cluster 来解决服务器级别高可用.通过存储做RaID10 和Mssql Mirror来保障

　　单点存储的故障.

　　Mssql Cluster 把 OS的 IP和 MS的 IP 分开.一旦出现服务器故障.群集管理器自动把出现故障的节点的MSsql服务转移到另一正常节点上.同时Mssql的IP 不变,因此不会对前端web服务器的写入有任何影响.相对于MysqL的Master_Master 模式不用担心前端数据写入的丢失和故障转移后的Repl的延迟.同时针对于存储级单点故障 Mssql还有Mirror来解决.

　　一般正常情况下存储做 RaID10后损坏的概率相对较小.但也不排除异常情况.比如存储上的控制器异常导致宕机. 一般中端存储的RaID控制器都是2个.当然也不排除某些厂商高端3par 多控制器.最近影响面大的一次宕机非属于艺龙了.

　　(图4:Mssql AAcluster故障转移)

　　(图5:单点Storage故障转移)

　　出处：http://xwj1985.cnblogs.com/

总结

以上是内存溢出为你收集整理的MSSQL高可用性和扩展性全部内容，希望文章能够帮你解决MSSQL高可用性和扩展性所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。