| |
Today addressed a alwaysOn problem - a secondary copy because of insufficient disk space has not synchronized display [-] suspicious, you can see in the log database in a suspended state, out of sync with the master copy. Simply thought to be a secondary copy of the disk cleanup to free up a little space, and then restart the SQL Server service just fine (restart to make the database from the suspend state into an online state, then let alwaysOn restart sync).
However, failure to restart! ! !
See the operating system log Cause SQL Server failed to start is to start :( account) user name and password is wrong! ! !
AlwaysOn had to do when convenience, the direct use of a domain administrator user name and password, then for the sake of security policy, the account password is re-turn, and then no one remembers to modify the startup account password synchronization for SQL Server. On normal, as long as SQL Server does not restart, the password does not change it, all right, but after the restart, you must use the correct password. Otherwise this error.
So to solve this problem simply modify the correct password.
Even so, alwaysOn still will not immediately restore synchronization, you can see from the database log, and the other unfortunate things happened:
Database Mirroring login attempt failed with error: 'Connection handshake failed An OS call failed (8009030c)) x8009030c (login without success). . State.67 '[client: 10.1.2.2]
10.1.2.2 is alwaysOn master copy IP, given the information from the point of view, is a master copy of the database mirroring endpoint (AlwaysOn use database mirroring endpoint for communication) can not log on to the secondary replica.
This is a problem account login. We just changed the secondary replica login account password, but does not modify the master copy of the master copy or with an expired password to access the secondary replica mirroring endpoint, secondary replica will naturally reject the connection request, so we need (in a non business hours) to modify the password logon account under the master copy, and then restart SQL Server on it.
Database mirroring endpoint connection is re-established, the error will not be there, but this still does not recover alwaysOn synchronization, but also on the secondary replica database available right click and select "Restore Data Movement", since only alwaysOn began to recover synchronization.
In fact, this problem can be avoided, if at the time SQL Server starts accounts using a separate, dedicated account will not have this problem, in fact, we also recommend such accounts to try to separate business accounts to avoid mutual influence. |
|
|
|