none
AOAG hadr_endpoints bleibt immer "DISCONNECTED" RRS feed

  • Frage

  • Hi,

    auf einer AOAG bei uns, zwei Nodes mit jeweils MS SQL Server 2016 bekomme ich den sog. Endpoint hadr_endpoints nicht mehr in den Status "CONNECTED".

    Egal was ich anstelle, er bleibt immer im Status "DISCONNECTED".

    Anbei kurz eine Übersicht, was ich bisher versucht habe:

    1. löschen des bisherigen Endpoints

    2. neuen Endpoint anlegen

    3. Owner des Endpoints ändern

    4. User auf Endpoint berechtigen:

    -- drop and create endpoint hadr_endpoint
    USE [master]
    DROP ENDPOINT [Hadr_endpoint]
    
    CREATE ENDPOINT [Hadr_endpoint] 
    	STATE=STARTED
    	AS TCP (LISTENER_PORT = 5022, LISTENER_IP = ALL)
    	FOR DATA_MIRRORING (ROLE = ALL, AUTHENTICATION = WINDOWS NEGOTIATE
    , ENCRYPTION = REQUIRED ALGORITHM AES)
    GO
    
    
    -- owner des neuen endpoints ändern:
    USE master;
    ALTER AUTHORIZATION ON ENDPOINT::Hadr_endpoint TO sa
    
    
    
    -- berechtigen des Users mit connect auf den endpoint
    use [master]
    GO
    GRANT CONNECT ON ENDPOINT::[Hadr_endpoint] TO [Domain1\Dienste_Start_User]
    GO

    Aber, der Status will sich partout nicht ändern, auf allen anderen AOAG, wir betreiben ca. 15 davon, ist das alles kein Problem.

    So langsam gehen mir die Ideen aus, ich mag aber auch nicht die AOAG auflösen. 

    Hat jemand noch eine Idee, woran das liegen könnte? Der Endpoint selbst ist gestartet, lässt sich auch ohne Fehler stoppen, und dann wieder anstarten. Aber irgendwo ist bei der Berechtigung ein Wurm drin.

    Danke euch

    Grüße

    Andreas

    Mittwoch, 24. April 2019 08:02

Alle Antworten

  • So,

    also wir können die AOAG wieder zum Leben erwecken, indem wir auf dem inaktiven Node den User ändern, welcher den SQL Server startet.

    Wenn wir den User LocalSystem eintragen, und auf der gegenüberliegenden Node den Server als Login einrichten, und diesem dann noch das CONNECT Recht für den Endpoint geben, dann läuft die AOAG wieder.

    Das würden wir aber gerne verstehen. Interessant ist, dass diese Tabelle hier komplett leer ist, wenn wir das mit den Domain-Usern versuchen:

    SELECT * FROM sys.dm_db_mirroring_connections

    Normalerweise, wenn man den Seiten im Internet trauen kann, sollte gerade die Einrichtung einer AOAG im gleichen Subnetz, mit Domainaccounts kein Problem sein.

    Wenn jemand eine Idee hat, auch wenn diese noch so wirr klingen sollte, immer her damit. 

    Danke

    Grüße

    Andreas

    Donnerstag, 25. April 2019 09:59