Carefully manage Login (startup) accounts and passwords for SQL Server services

Today is a New Year third day, first with everyone to worship for a year, I wish you all happy.
Today, an alwayson problem has been handled--the secondary replica is showing "not synchronized-suspicious" because of insufficient disk space, and in the log you can see that the database is in a suspended state and is out of sync with the primary replica. It would be nice to just clean up the disk of the secondary replica, make a little space, and then restart the SQL Server service (restart to bring the database from the suspended state to the online state, and then let AlwaysOn restart synchronization).
However, the restart failed!!!
The reason for SQL Server startup failure in the operating system log is that the user name and password are incorrect (starting account)!!!

At the time to do AlwaysOn when the diagram convenient, directly with a domain administrator user name and password, and later because of security policy, the account password was re-changed, no one remembers synchronizing the SQL Server startup account password. In the usual, as long as SQL Server does not restart, password does not change is OK, but after restarting, you must use the correct password. Otherwise, this error will occur.
So to solve this problem just change the password to the correct one.

Even so, AlwaysOn does not immediately resume syncing, as you can see from the database log that another unfortunate thing has happened:

Database Mirroring login attempt failed with error: ' Connection handshake failed. An OS call failed (8009030c)) x8009030c (login not successful). state.67 '. [client:10.1.2.2]

10.1.2.2 is the IP of the AlwaysOn primary replica, which, from the error message, is the database mirroring endpoint of the primary replica (AlwaysOn communicating with the endpoint of database mirroring) cannot log on to the secondary replica.
This is an account login issue. We have just modified the login account password of the secondary replica, but have not modified the primary replica, the primary replica or the invalid password to access the mirror endpoint of the secondary replica, the secondary copy will naturally reject this connection request, so we also need (during non-business hours) to modify the primary replica login account password, and then restart the SQL The server is ready.

After the database mirroring endpoint has re-established the connection, this error will no longer be available, but at this point, AlwaysOn still does not resume synchronization, and you need to right-click on the available database on the secondary replica to select "Recover Data Movement", from which the synchronization begins to resume.

This problem can be avoided in fact, if the SQL Server startup account with a separate, dedicated account will not have this problem, in fact, we also recommend that such accounts should be as far as possible to separate from the business account, to avoid mutual influence.

Carefully manage Login (startup) accounts and passwords for SQL Server services