11.6 设计高可用性解决方案

11.6  设计高可用性解决方案

11.6.1 规划时的考虑因素

　　在规划高可用性时需要综合考虑以下两个因素：

● RTO（Recovery Time Objective，即目标恢复时间）

　　RTO 表示业务系统每次容忍多少宕机时间。如果业务停顿时间过长，损失自然也会增加。对于特别重要的业务系统，可能需要同时使用多种技术确保在发生故障时能够迅速恢复业务。

● RPO（Recovery Point Objective，即目标恢复点）

　　RPO 表示容忍多少数据丢失。通常只要做好备份，就可以使数据不丢失。但当灾难发生时，从备份进行恢复的操作会导致数据库在现阶段不可用；如果恢复的时间特别长，业务停顿所造成的损失可能比丢失少量数据更严重。特别对于数据量非常大的数据库，更需要预先考虑到恢复时间和数据丢失之间的权重而制定充足的预案。

　　通常 RTO 与 RPO 两者之间存在冲突，需要根据业务需求、投资规模等多方面因素来权衡，从而制订服务水平协议（Service Level Agreement，简称 SLA）。

11.6.2  各项技术的对比

对比项目	AlwaysOn 故障转移群集	AlwaysOn 可用性组	数据库镜像	日志传送
副本数量	无	最多8个	1个	无限制
副本的可用性 （只读访问）	不适用	可以	创建快照，然后访问快照	“备用模式”时可以访问
对外统一IP地址	是	是	各自独立的IP地址	各自独立的IP地址
自动故障转移	可以	可以	可以（需要有见证服务器）	不可以
故障转移单元	实例	一组数据库	单个数据库	不适用

11.6.3  负载分摊

　　SQL Server 虽然不支持负载均衡，但考虑到 SQL Server 具有较低的总拥有成本（Total Cost of Ownership，简称 TCO），因此可以将数据库的访问分摊到多个数据库，而多个数据库可以分别位于不同计算机的 SQL Server 实例。

　　在设计数据库应用程序时，就应当考虑到将来可以实现负载分摊。分摊的方式主要有两种：读写分离、业务数据分离。

◆ 读写分离

　　读写分离并不是数据库自有的功能，因为客户端的连接字符串就已经指定了目标数据库，SQL Server 数据库引擎不会主动在客户端的请求中筛选哪些是只读访问，更不会将只读访问重定向到另一个 SQL Server 实例。

　　在设计数据库应用程序时，考虑到只读副本可以承担一些只读访问，因此可以将其中的一些只读访问（例如，报表查询，备份等）定向到只读副本，实现读写分离。

　　根据不同的数据更新的延迟需求，可以考虑采用同步提交（AlwaysOn可用性组）、异步提交（AlwaysOn可用性组、数据库镜像、日志传送等）模式。

◆ 业务数据分离

　　一般情况下，一台计算机的性能是有限的，而让更多的计算机参与进来就有可能提升性能。可以考虑将业务数据分布在多台计算机的 SQL Server 实例上，这样可以使应用程序的访问请求被分摊到多个独立运行的数据库上。

　　下例是一家 OTA（Online Travel Agent，即在线旅游代理）企业在遇到数据库规模迅速增长时将数据库分离到5台服务器。

　　根据具体的业务需求和逻辑结构，可以单独或组合使用上述负载分摊方案，从而实现满意的性能目标。

提示：

　　通常情况下，AlwaysOn 故障转移群集的数据文件位于群集共享磁盘（或者网络共享文件夹），且没有副本，因此不能实现负载分摊。

本文出自 “SQL Server 管理员指南” 博客，谢绝转载！