web-dev-qa-db-ja.com

切断されたレプリカを報告する可用性グループ

いくつかのテストを実行できるように、VM環境で可用性グループを構成しようとしています。

グループが正しく作成されたと思います。両方のサーバーでAlways onグループを確認できます。しかし、グループのダッシュボードを見ると、次のエラーがあります

可用性レプリカが切断されました
このセカンダリレプリカはプライマリレプリカに接続されていません。接続状態はDISCONNECTEDです。

両方のサーバーのエンドポイントを確認しましたが、正しく見えます。ファイアウォールは実行されておらず、両方のサーバーがお互いを認識できます。この種のエラーをデバッグする最良の方法は何ですか？

以下は、これをすべて設定するために使用したTSQLです。

プライマリサーバー

CREATE ENDPOINT dbm_endpoint
    STATE=STARTED 
    AS TCP (LISTENER_PORT=7022) 
    FOR DATABASE_MIRRORING (ROLE=ALL)
GO

セカンダリサーバー

CREATE ENDPOINT dbm_endpoint
    STATE=STARTED 
    AS TCP (LISTENER_PORT=5022) 
    FOR DATABASE_MIRRORING (ROLE=ALL)
GO

プライマリサーバー

CREATE AVAILABILITY GROUP AG1
    FOR
        DATABASE TestDb
    REPLICA ON
        'SQL1' WITH
            (
                ENDPOINT_URL = 'TCP://sql1.sql.sandbox.net:7022',
                PRIMARY_ROLE ( ALLOW_CONNECTIONS = READ_WRITE),
                SECONDARY_ROLE (ALLOW_CONNECTIONS=READ_ONLY),
                AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,
                FAILOVER_MODE = MANUAL
            ),
        'SQL2' WITH
            (
                ENDPOINT_URL = 'TCP://sql2.sql.sandbox.net:5022',
                PRIMARY_ROLE ( ALLOW_CONNECTIONS = READ_WRITE),
                SECONDARY_ROLE (ALLOW_CONNECTIONS=READ_ONLY),
                AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,
                FAILOVER_MODE = MANUAL
            );

セカンダリサーバー

ALTER AVAILABILITY GROUP AG1 JOIN;

もちろん、プライマリデータベースもセカンダリサーバーに復元しました。

どちらかのサーバーにSQLエージェントをインストールしなかったと思ったのですが、これは常時オンの可用性グループには必要ないと思いますか？

sql-serversql-server-2012availability-groups
6
Gavin

この質問は非常に古く、おそらくトラブルシューティングは不可能ですが、同じ問題を抱えているこの質問に出くわした人にとっては、次のことが役立つかもしれません。これは、発生する可能性のあるすべての問題の完全なリストではありませんが、発生する主な問題に当てはまります。

セカンダリレプリカがプライマリによって切断されているとマークされている場合、これは、プライマリがデータベースミラーリングエンドポイントを介してセカンダリレプリカを認識していない、または接続できないことを意味します。これにはさまざまな理由があります。

エンドポイント構成

最も一般的な原因の1つは、データベースミラーリングの役割のエンドポイントが正しく構成されていないことです。使用できるさまざまなオプションと構成があり、特に手動で作成した場合、それらの構成オプションが一致しない場合があります。 OPの例を見てみましょう。

CREATE ENDPOINT dbm_endpoint
    STATE=STARTED 
    AS TCP (LISTENER_PORT=5022) 
    FOR DATABASE_MIRRORING (ROLE=ALL)

これにより、データベースミラーリング用のtcpポート5022にd​​bm_endpointというエンドポイントが作成されます。ただし、デフォルトのデフォルト設定であるassumeの設定オプションはかなり除外されていますが、実際にはわかりません。これは、WindowsまたはKerberosを使用したNTLM認証などのデフォルトオプションを意味し、使用するIPアドレス（v4、v6、インターフェース）も指定しません。デフォルトが必須であり、SQL Serveのバージョンに応じてRC4またはAESの暗号化オプションを指定しますか。

これは、特に仮定を作成することです。特に、機能していない場合はそうです。エンドポイントの設定が不明な場合は、sys.tcp_endpointsをsys.database_mirroring_endpointsと結合して、結果の単一行を個別の構成オプションに変換します。

たとえば、Windows認証を使用できないため、証明書を使用する高度な構成があります。 OPに適切なドメインがあるかどうか、およびこれらのサーバーが参加しているかどうかはわかりません。繰り返しになりますが、エンドポイントに基づいた仮定はそれらがそうであるということですが、確実にはわかりません。証明書を使用する場合の最大の問題は、同じ証明書が複数のレプリカで使用されているにもかかわらず、証明書をコピーしてレプリカにインポートするときに秘密鍵がエクスポートされないことです。エンドポイントは秘密鍵と公開鍵のペアを使用するため、同じ証明書を使用すると、ある時点でそのエンドポイントが秘密鍵を使用する必要があります。複数のレプリカで証明書を使用している場合は、証明書が両方のキーでエクスポートおよびインポートされていることを確認してください。

IPアドレスを指定する場合、デフォルトはANYで、IPv4またはIPv6アドレスのいずれかになります。ほとんどの場所はIPv6アドレスを登録または使用していませんが、時々問題と見なしています。 DNSのホストに登録されているアドレスを確認することで、問題を絞り込むことができます。ポートに基づいてネットワークキャプチャとフィルタを設定することもできます。たまにIPv6アドレスが使用され、他のサーバーで不適切にセットアップ、無効化、またはファイアウォールが設定されていますが、DNS経由で返されます。

可用性グループレプリカの仕様

可用性グループを作成するときは、各レプリカを指定する必要があるため、通信ポート（データベースミラーリングエンドポイント）を定義するエンドポイントURLが必要になります。

OPの例をとります：

REPLICA ON
        'SQL1' WITH
            (
                ENDPOINT_URL = 'TCP://sql1.sql.sandbox.net:7022',
                PRIMARY_ROLE ( ALLOW_CONNECTIONS = READ_WRITE),
                SECONDARY_ROLE (ALLOW_CONNECTIONS=READ_ONLY),
                AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,
                FAILOVER_MODE = MANUAL
            ),

SQL1と呼ばれるこのレプリカには、TCPエンドポイントがあります。アドレスはFQDNのようであり、適切なDNSルックアップ（使用している場合）を確認する必要があります。 Kerberos SPN、およびファイアウォールルールが存在するか作成されます。アドレスのルックアップで返される複数のインターフェースまたはアドレスがある場合、テストのためにエンドポイントURLの特定のアドレスに絞り込むか、または絞り込むことが理にかなっています。ミラーリングエンドポイントの仕様でそれを下にしてください。

SQL Serverの権限

切断された問題が表示される最後の表面領域の1つは、各レプリカのエンドポイント権限です。各エンドポイントでは、エンドポイントを使用するためにアカウントにCONNECT権限（証明書を使用する場合も同様）が必要です。これはかなり一般的な問題であるため、エラーログにマークされ、エンドポイントへの接続権限を付与するというエラーメッセージの修正が提供されることが一般的です。

Windowsクラスタリング

レプリカマネージャーは、起動するために（Linux、Docker、またはRead-Scaleを数えずに）動作するようにWindows Serverフェールオーバークラスタリングに応答するので、クラスターサービスが各レプリカで実行されており、各ノードがクラスター（Powershell、フェールオーバークラスターマネージャーなど）。クラスターサービスが実行されていない場合、マネージャーは復旧するまで停止します。これはエラーログに記録され、非常に明確になります。

トラブルシューティングの方法論

他に何も機能しない、または表示されない場合、何をしますか？

可用性グループは分散システムです。これは、共通のプロトコルセット（可用性グループ）を介して機能する多くの領域（データベース）に分散された多くの個別の部分（レプリカ）があることを意味します。このため、トラブルシューティングの方法は、一般的な単一インスタンスまたはクラスター化されたインスタンスのトラブルシューティングとは異なります。

各部分は、それ自体に対して、および使用可能な全体的なメタデータに対してチェックする必要があります。さらに、各部分では、中間アイテム（ファイアウォール、ネットワークカード、ロードバランサーなど）を相互にチェックする必要があります。

eachレプリカのエラーログを確認することから始めます。（エラーが発生した場所に起因する）一部のエラーのみが、レプリカがプライマリまたはセカンダリの場合にのみ適用されます。 each errorlogの概要の後、これは方向性を示す必要があります-そうでない場合は、SQL Serverに問題がある可能性が高く、ネットワーク、ファイアウォール、OSなどを意味します。システムおよびアプリケーションログここで次のステップとして役立ちます。

システムにインストールされているNDISドライバーに注意してください。それらは、トラフィックをブロックしたり、正しく機能せず、トラフィックをドロップしたりする可能性があります。また、切断された状態が断続的である場合、パケットのドロップや破棄などの問題が発生する可能性があるため、ネットワークカードのインターフェイス診断を確認してください。

他のすべてが失敗した場合、すべてのメタデータを他のメタデータと照合して、すべてが一致し、同じであることを確認します。上記で指定されたOPメタデータでは、1つのポートが7022にあり、もう1つのポートが5022にありました。これ自体は不正確ではなく使用できますが、ファイアウォールルールなどの他の場所で問題が発生し、誰かがポートを簡単に誤って読み取ったり、ポートが同じであると想定し、読み取らないでください。

スキルレベルと知識に応じて、1次側と2次側からのネットワークトレースが理想的です。これにより、プライマリ/セカンダリを離れ、反対側に到着するうまくいけばのパケットが表示されます。そうでない場合は、仲介者が正しく構成されていません-トラフィックを停止しているファイアウォール、ロードバランサー、ルーターなどを探します。

4
Sean Gallardy