慎重管理SQL Server服务的登录（启动）账户和密码

今天是大年初三，先跟大家拜个年，祝大家新年快乐。
今天处理了一个alwaysOn问题——辅助副本因为磁盘空间不足一直显示【未同步——可疑】，在日志中可以看到数据库处于挂起状态，与主副本失去同步。原以为只需把辅助副本的磁盘做个清理，腾出一点空间，然后重启SQL Server服务就好了（重启让数据库从挂起状态进入到联机状态，然后让alwaysOn重新开始同步）。
但，重启失败！！！
在操作系统日志中看到SQL Server启动失败的原因是：（启动账户的）用户名和密码错误！！！

 

当初做alwaysOn的时候图方便，直接用了一个域管理员的用户名和密码，后来因为安全策略的缘故，这个账户的密码被重新改过了，当时没人记得同步修改SQL Server的启动账户密码。放在平常，只要SQL Server不重启，密码没有改也没事，但重启后，就必须使用正确的密码了。否则会出现这个错误。
所以要解决这个问题只需修改为正确的密码。

即使如此，alwaysOn还是不会立即恢复同步，从数据库日志中可以看到，另一个不幸的事情发生了：

Database Mirroring login attempt failed with error: ‘Connection handshake failed. An OS call failed(8009030c))x8009030c(登录没有成功)。state.67’. [client:10.1.2.2]

 

10.1.2.2是alwaysOn主副本的IP，从报错信息来看，是主副本的数据库镜像端点（AlwaysOn使用数据库镜像的端点进行通讯）无法登录到辅助副本上。
这是一个账户登录的问题。刚刚我们修改了辅助副本的登录账户密码，但没有修改主副本的，主副本还是用的失效的密码来访问辅助副本的镜像端点，辅助副本自然会拒绝这个连接请求，所以我们还需（在非业务时段）修改下主副本登录账户的密码，然后重启SQL Server就可以了。

数据库镜像端点重新建立连接后，这个错误就不会再有了，但此时alwaysOn还是不会恢复同步，还需要在辅助副本上的可用数据库上右击选择“恢复数据移动”，自此alwaysOn才开始恢复同步。

这个问题其实是可以避免的，如果当时SQL Server启动账户用的是一个单独的、专用的账户就不会有这个问题，其实我们也建议这样的账户要尽量与业务账户分开，避免相互影响。

转载于:https://www.cnblogs.com/i6first/p/5186207.html