In a SQL Server Failover Cluster Instance (FCI) environment, a “node blip” refers to the event when the active SQL Server instance moves from one cluster node to another. This movement, typically triggered by a Failover or planned maintenance, causes a brief outage—usually 30 to 60 seconds.
While planned blips are expected during maintenance, unexpected ones should be investigated promptly to identify root causes and prevent recurrence. These events are especially critical in environments hosting high-impact SQL Server workloads.
Tracking SQL Node Blips Using PowerShell
I’m sharing a command that retrieves all recent failover events logged in the Failover Clustering Operational Log.
Replace ListenerName
below with your Always On Availability Group Listener Name or the relevant cluster resource name:
# Get last failover time Get-WinEvent -ComputerName ListenerName -FilterHashtable @{logname='Microsoft-Windows-FailoverClustering/Operational'; id=1641} | Format-Table -AutoSize -Wrap
This command filters the log for Event ID 1641, which tracks clustered role movements. The output lists all failover events, including timestamps and details about why the failover occurred. By reviewing these events, you can determine whether a failover was planned or unexpected.
Why Node Blips Matter in SQL Server FCI
Every node blip results in a temporary outage as the SQL Server instance transitions between nodes. While a 1 minute disruption might seem minor, it can have significant implications for critical databases or applications.
Monitoring and checking these failover events helps identify the point in time of last SQL Server restart, diagnose issues and prevent re-occurrence.
Alternative Methods to Retrieve Node Blip Data
In addition to PowerShell, you can use SQL Server’s error logs to identify failovers. The xp_readerrorlog
stored procedure can be used to find messages related to failover events:
-- check sql error log for failover events EXEC xp_readerrorlog 0, 1, 'failover';
This command filters the SQL Server error log for failover-related entries, providing another layer of insight into node blips.
The last thing I want to share on this is a small PowerShell script that is more useful for automation. It returns only the most recent node blip and includes a param for the AG Listener Name. If you ran this on a frequent schedule it would be easy to add alerting and/or log to a table.
# Define the cluster listener name $listenerName = "ListenerName" # Replace with your actual Listener Name # Get the latest failover events (Event ID 1641) $lastNodeBlip = Get-WinEvent -ComputerName $listenerName -FilterHashtable @{ logname = 'Microsoft-Windows-FailoverClustering/Operational'; id = 1641 } | Sort-Object TimeCreated -Descending | Select-Object -First 1 # Output the most recent node blip $lastNodeBlip | Format-Table -AutoSize -Wrap
Leave a Reply