一次失败的生产系统中AlwaysOn AG切换经历

14：25分左右，某数据库主副本服务器崩溃报错，
在数据库无法接收SQL语句进行调整的情况下重启了主副本服务器。

由于服务器重启时间会比较长，为了保证主副本服务器重启期间数据库能正常进行写入，强制将主库切换到辅助服务器。并通知连接字符串中不能自动切换的部分应用的数据库直接配置到新的主副本服务器。

而由于咱们AlwaysOn的同步模式是异步模式，原本应该承担只读路由的新只读辅助副本无法同步新主副本的数据，意味着AlwaysOn配置失效，进而导致使用只读数据库连接的大部分应用不可用。

整个AlwasyOn必须重新搭建（主库备份->拷贝->从库还原->日志还原->加入AlwaysOn）。在这期间由于急着恢复AlwaysOn，没能想到应用无法连接只读从库的快速解决方案。（先临时让修改连接字符串配置）
重新搭建过程中遇到一个坑,AlwaysOnGroup中稍大的库在加入AlwaysOn之前还原日志备份时总是报错,在脑子不太好使的情况下重试了好几次后才想起来是新的主库上配置有日志定期备份的作业(在主要节点模式时自动生效)导致日志链断裂。

15：45分左右，终于脑子灵光点，重新配置AlwasyOn只读路由，使得只读连接和读写连接全部指向主副本服务器，至此，外部影响终于消灭。

17：20分左右，新的AlwaysOn搭建完成，并使用同步模式重新切换回原来的主副本服务器，数据库恢复原状。

 

相关脚本：

如果新的辅助副本无法承担只读连接，修改新主副本的只读路由：

?

1 2	ALTER AVAILABILITY GROUP [AG-01] MODIFY REPLICA ON N'SQL2' WITH (PRIMARY_ROLE(READ_ONLY_ROUTING_LIST = (N'SQL2',N'SQL1')))   --新主副本SQL2的只读路由为先SQL2，即不路由到辅助副本。（修改前顺序应该是(N'SQL1',N'SQL2')）

?

1 2 3

ALTER AVAILABILITY GROUP [AG-01] MODIFY REPLICA ON N'SQL1' WITH (SECONDARY_ROLE(ALLOW_CONNECTIONS = NO))  --关闭原主库的只读连接 GO

重搭AlwaysOn时，还原完整备份，日志备份后将DB1加入AG-01

ALTER DATABASE Db1 SET HADR AVAILABILITY GROUP = [AG-01];

经验教训:

1.如果AlwaysOn AG是异步模式，在设置只读路由时，第一辅助副本的路由应该优先指向自己，而非别的副本。因为异步模式下切换后，整个AG就只剩下新的主副本那一个孤家寡人了，路由指向其它副本只是一厢情愿。

2.如果是同步模式，当然第一辅助副本的只读路由优先指向别的可用副本。（切换后也能读写分离）

本文链接:http://www.cnblogs.com/ajiangg/p/6398858.html