I ran into an interesting situation this morning. I got alerts for each of my mirrored databases that they had entered the “Synchronizing Principal” state. (I wrote about how to set up these alerts here.) These alerts were sent from the principal server. There were no alerts from the mirror server, which should have happened if a mirroring failover occurred. Sure enough, nothing really changed as far as I could tell. The principal server was still the same principal server as before the alerts, the mirrored databases were all still synchronized, and the mirroring monitor did not show anything out of the ordinary. I couldn’t tell why the alerts fired.
Digging a little deeper, I saw this message in the Windows Application log on the principal:
The computer name given was the name of our mirror server.
In our setup, the current principal is a single machine and the mirror is a two node cluster What had happened was the mirror server had failed over from one node of the cluster to another. This takes longer than 10 seconds (the default timeout for mirroring alerts), so that triggered an alert on the principal. But the cluster failover completed shortly thereafter and the mirroring process caught up and by the time I looked at it, everything looked normal.
This was something I even wrote about before – check out the second bullet point under Things To Watch For here. When I wrote that, I was thinking in terms of the principal being a cluster and a node of that cluster failing over. It appears though, that even a failover of a mirror cluster node will also set off the alert. However, since the principal did not go offline, no mirroring failover occurred – it was just a cluster failover on the mirror. Therefore, looking at the mirroring logs likely won’t show you anything.
The moral: If you get a mirroring alert and you aren’t sure why because things look normal, check to see if a clustering failover was somehow involved.