クラスターを高可用性および手動フェイルオーバーに設定しました。フェイルオーバーが発生するたびに、DBAに電子メールで通知するアラートがあります。私たちがメールでも見たいのはWHYやWHOです。常に再起動、テスト、削除を行っている他のチームがいますが、これが誰かが何かに取り組んでいるのか、何かが間違っているのかを知りたいのです。現在、メールは「可用性グループデータベース "TESTIN2"はロールを "PRIMARY"から "RESOLVING"に変更しています。これは、ミラーリングセッションまたは可用性グループが役割の同期のためにフェールオーバーしたためです。これは情報メッセージです。ユーザーの操作は必要ありません。 」ありがとう
私たちがメールでも見たいのはWHYやWHOです。
その後、あなたはあなたの前にかなりの開発作業をしています。真剣に。
誰もが同じ質問をしますが、「現時点では失敗しました」以上の解決策で答えるのは簡単なことではありません。ツールやハイパーバイザー自体がサンドボックスの範囲外の処理を実行する可能性があるため、仮想化などの処理はさらに困難になります。
ただし、開始するには、データをスクラブする場所を以下に示します。
幸運を祈ります。
常に再起動、テスト、削除を行っている他のチームがいますが、これが誰かが何かに取り組んでいるのか、何かが間違っているのかを知りたいのです。
これは組織の情報共有/管理の問題であり、単純なSQL Serverアラートで対処する上で大きな助けとなる問題ではありません。実際、これを適切に行うには、SQL Serverを完全に排除する必要があります。
ほとんどの場合、イベントログ、トレース、エラーログなどを常に消費し、問題が発生したときにアクションを実行するサービスを作成する必要があります。
私は、batch_starting、sql_statement_starting、alwayson_ddl_executed、availability_replica_state_changeイベントのsql_textを追跡する拡張イベントの設定を検討します。上の画像はXEのライブデータのビューで、下の画像は記録されたものです。情報をぼかしましたが、フェイルオーバーコマンドを発行したユーザーを示すためにユーザー名が表示されています。
私が使用したXEを作成するためのコード(おそらく、私が含めたイベントではやり過ぎですが、それは私にとってはうまくいきました):
CREATE EVENT SESSION [Audit_Availability_Group_Failovers] ON SERVER
ADD EVENT sqlserver.alwayson_ddl_executed(
ACTION(sqlserver.client_app_name,sqlserver.client_hostname,sqlserver.database_id,sqlserver.database_name,sqlserver.nt_username,sqlserver.session_nt_username,sqlserver.sql_text,sqlserver.username)
WHERE ([sqlserver].[like_i_sql_unicode_string]([sqlserver].[sql_text],N'%ALTER AVAILABILITY GROUP%FAILOVER%'))),
ADD EVENT sqlserver.availability_group_lease_expired(
ACTION(sqlserver.client_app_name,sqlserver.client_hostname,sqlserver.database_id,sqlserver.database_name,sqlserver.nt_username,sqlserver.session_nt_username,sqlserver.sql_text,sqlserver.username)
WHERE ([sqlserver].[like_i_sql_unicode_string]([sqlserver].[sql_text],N'%ALTER AVAILABILITY GROUP%FAILOVER%'))),
ADD EVENT sqlserver.availability_replica_automatic_failover_validation(
ACTION(sqlserver.client_app_name,sqlserver.client_hostname,sqlserver.database_id,sqlserver.database_name,sqlserver.nt_username,sqlserver.session_nt_username,sqlserver.sql_text,sqlserver.username)
WHERE ([sqlserver].[like_i_sql_unicode_string]([sqlserver].[sql_text],N'%ALTER AVAILABILITY GROUP%FAILOVER%'))),
ADD EVENT sqlserver.availability_replica_manager_state_change(
ACTION(sqlserver.client_app_name,sqlserver.client_hostname,sqlserver.database_id,sqlserver.database_name,sqlserver.nt_username,sqlserver.session_nt_username,sqlserver.sql_text,sqlserver.username)
WHERE ([sqlserver].[like_i_sql_unicode_string]([sqlserver].[sql_text],N'%ALTER AVAILABILITY GROUP%FAILOVER%'))),
ADD EVENT sqlserver.availability_replica_state(
ACTION(sqlserver.client_app_name,sqlserver.client_hostname,sqlserver.database_id,sqlserver.database_name,sqlserver.nt_username,sqlserver.session_nt_username,sqlserver.sql_text,sqlserver.username)
WHERE ([sqlserver].[like_i_sql_unicode_string]([sqlserver].[sql_text],N'%ALTER AVAILABILITY GROUP%FAILOVER%'))),
ADD EVENT sqlserver.availability_replica_state_change(
ACTION(sqlserver.client_app_name,sqlserver.client_hostname,sqlserver.database_id,sqlserver.database_name,sqlserver.nt_username,sqlserver.session_nt_username,sqlserver.sql_text,sqlserver.username)
WHERE ([sqlserver].[like_i_sql_unicode_string]([sqlserver].[sql_text],N'%ALTER AVAILABILITY GROUP%FAILOVER%'))),
ADD EVENT sqlserver.hadr_undo_of_redo_log_scan(
ACTION(sqlserver.client_app_name,sqlserver.client_hostname,sqlserver.database_id,sqlserver.database_name,sqlserver.nt_username,sqlserver.session_nt_username,sqlserver.sql_text,sqlserver.username)
WHERE ([sqlserver].[like_i_sql_unicode_string]([sqlserver].[sql_text],N'%ALTER AVAILABILITY GROUP%FAILOVER%'))),
ADD EVENT sqlserver.sql_batch_completed(
ACTION(sqlserver.client_app_name,sqlserver.client_hostname,sqlserver.database_id,sqlserver.database_name,sqlserver.nt_username,sqlserver.session_nt_username,sqlserver.sql_text,sqlserver.username)
WHERE ([sqlserver].[like_i_sql_unicode_string]([sqlserver].[sql_text],N'%ALTER AVAILABILITY GROUP%FAILOVER%'))),
ADD EVENT sqlserver.sql_batch_starting(
ACTION(sqlserver.client_app_name,sqlserver.client_hostname,sqlserver.database_id,sqlserver.database_name,sqlserver.nt_username,sqlserver.session_nt_username,sqlserver.sql_text,sqlserver.username)
WHERE ([sqlserver].[like_i_sql_unicode_string]([sqlserver].[sql_text],N'%ALTER AVAILABILITY GROUP%FAILOVER%'))),
ADD EVENT sqlserver.sql_statement_completed(
ACTION(sqlserver.client_app_name,sqlserver.client_hostname,sqlserver.database_id,sqlserver.database_name,sqlserver.nt_username,sqlserver.session_nt_username,sqlserver.sql_text,sqlserver.username)
WHERE ([sqlserver].[like_i_sql_unicode_string]([sqlserver].[sql_text],N'%ALTER AVAILABILITY GROUP%FAILOVER%'))),
ADD EVENT sqlserver.sql_statement_starting(
ACTION(sqlserver.client_app_name,sqlserver.client_hostname,sqlserver.database_id,sqlserver.database_name,sqlserver.nt_username,sqlserver.session_nt_username,sqlserver.sql_text,sqlserver.username)
WHERE ([sqlserver].[like_i_sql_unicode_string]([sqlserver].[sql_text],N'%ALTER AVAILABILITY GROUP%FAILOVER%')))
ADD TARGET package0.event_file(SET filename=N'D:\Audit_Availability_Group_Failovers.xel'),
ADD TARGET package0.ring_buffer
WITH (MAX_MEMORY=4096 KB,EVENT_RETENTION_MODE=ALLOW_SINGLE_EVENT_LOSS,MAX_DISPATCH_LATENCY=30 SECONDS,MAX_EVENT_SIZE=0 KB,MEMORY_PARTITION_MODE=NONE,TRACK_CAUSALITY=ON,STARTUP_STATE=ON)
GO
私の経験では、ユーザーがフェイルオーバーを開始すると、ログに記録されません。ログの検索に何時間も費やすことはできますが、だれがそれを実行したかはわかりません。特定のユーザーだけがAlwaysOnダッシュボードにアクセスできるようにする場合は、インスタンス内でセキュリティ設定を構成する必要があります。プライマリレプリカを格納しているサーバーを誰かが再起動した場合、フェイルオーバーがいつ発生したかを確認し、システムログでUSER32イベントを確認して、サーバーを再起動したユーザーを確認できます。それ以外に、ログイン監査を使用してインスタンスに誰が接続しているかを確認できますが、それは推測ゲームである可能性があります。
エラーログがないため、それがユーザーであることがわかります(手動フェイルオーバーまたは再起動)。一方、エラーが原因である場合は、Seanが言及した場所に明示的なエラーが必ず表示されます。
同時に、Windowsアプリケーションイベントログをチェックする必要があります(ID-19406)。同じログに、フェイルオーバーを開始したユーザーなどの追加情報が表示されます。
Log Name: Application
Source: MSSQLSERVER
Date: 4/7/2018 8:59:15 AM
Event ID: 19406
Task Category: Server
Level: Information
Keywords: Classic
User: ABC\TestUser
Computer: abc.local.com
Description: The state of the local availability replica in availability group
'XXXXX' has changed from 'SECONDARY_NORMAL' to 'RESOLVING_PENDING_FAILOVER'. The
replica state changed because of either a startup, a failover, a communication issue,
or a cluster error. For more information, see the availability group dashboard,
SQL Server error log, Windows Server Failover Cluster management console or Windows
Server Failover Cluster log.