针对AlwaysOn Group的几点建议

1）关于Login帐号的同步

    针对SQL Server Login帐号，建议在所有辅助副本上创建一遍，以免发生故障转移以后，新的主副本没有相关登入权限而造成业务无法访问。

2）关于计划任务的执行

    通常，发生故障转移以后，代理作业不会自动转移到新的主副本上！

    所以，建议在所有辅助副本上也进行部署，可在计划任务里，判断当前实例是否是主副本。

3）关于向当前可用性组添加数据库的建议

    若数据库较大，建议先在辅助副本上恢复最新的完整备份+日志备份，恢复过程请用with norecovery！然后利用“添加数据库”向导，在初始数据同步的时候选择“仅联接”，以加快初始化速度。

4）在辅助副本上进行备份，请注意以下几点：

    A. BACKUP DATABASE仅支持数据库的仅复制完整备份(即WITH COPY_ONLY)。

比如：BACKUP DATABASE firstdb TODISK = 'd:\fristdb.bak' WITHCOPY_ONLY

注意：仅复制备份不影响日志链；

    B. BACKUP LOG 仅支持常规日志备份（辅助副本上的日志备份不支持 COPY_ONLY 选项）。

比如：BACKUP LOG firstdb TODISK = 'd:\fristdb.trn'

    C. 若要备份辅助数据库，辅助副本必须能够与主副本进行通信，并且状态必须为"已同步"或"正在同步"；

5）关于执行故障转移的说明

A. 可在任意副本上通过Management Studio来手动执行故障转移；

B. 但只能在辅助副本上通过语句来执行故障转移(将可用性组转移到本实例)；

USE master

ALTER AVAILABILITYGROUP [ag01] FAILOVER

C. 在任意副本上执行故障转移，都将改变主副本与辅助副本的角色关系；

6）故障转移集群，请合理选择仲裁配置

通常，启用AlwaysOn的故障转移集群的时候，只用如下2种仲裁配置：

奇数节点：选择“多数节点”

偶数节点：选择“多数节点和文件共享”

注意，关于文件共享，只需要各个节点都能读写即可，并且该共享文件夹所在机器不需要加入域。

7）关于补丁更新的安装

由于各个群集节点都需要安装相同的更新程序，建议关闭自动更新，由系统管理员定期做手动更新。

8）生产系统(有读写分离设计)的几点建议

A.建议主副本(写节点)的配置比读节点的配置高一些，可使用SSD来大幅提升磁盘IO性能；

<注：若有读写分离，建议辅助副本(读节点)也使用SSD以降低与主节点的延迟>

B.前端业务通过负载均衡来访问数据，主副本(写节点)可以加入读取队列，但降低比重；

C.需要注意Windows故障转移群集的仲裁，防止脑裂现象；

D.最后一个辅助副本设置异步提交，可作为离线查询、数据抽取，以及异地灾备；

9）辅助副本的统计信息更新问题

问题：由于读写库负载会相差很大，主副本上的数据变更，统计信息如何在读库上反映出来？

建议：在辅助副本上创建一个作业，每天更新所有表的统计信息、以及索引重建。

10）建议利用可用性组侦听器(AG Listener)

    设定一个虚拟的SharedIP，用于Failover后的数据访问。

11）根据业务需求选择合适的可用性模式

    A. AlwaysOn支持2种可用性模式：同步提交模式（强调高可用性）、异步提交模式（强调性能）。

可用性搭配故障转移以后，有如下3种模式：

B. 两个可用性副本之间的同步和故障转移行为取决于这两个副本的可用性模式。

例如，为进行同步提交，当前主副本和有关的辅助副本必须都配置为同步提交。

同样，为进行自动故障转移，这两个副本需要都配置为自动故障转移

    C. 讲述一个典型的AG架构图(5个副本)：

    节点01和02：使用同步提交模式以及自动故障转移，作为生产系统的高可用；

    节点03：使用手动故障转移的同步提交模式；

    节点04和05：使用异步提交模式，仅支持强制手动故障转移，作为异地容灾；

    当故障转移到节点04后，节点01、02、03保持异步提交，这将有助于避免因两个站点之间网络延迟较长而导致可用性组中的性能下降。