Was verursacht diesen Fehler: Keines der angegebenen Replikate für die Verfügbarkeitsgruppe ag1 ist der Instanz von SQL Server zugeordnet, mit der Sie verbunden sind

Ich konfiguriere Always-on für SQL Server 2017 RC1 (14.0.80.90, vom 2017-7-18) für Linux gemäß https://docs.microsoft.com/en-us/sql/linux/sql-server-linux -Verfügbarkeitsgruppe-konfigurieren-ha . Bei dieser Installation werden Docker-Images verwendet, die sich alle auf demselben physischen Host befinden. Alle Schritte funktionieren, bis ich zum Schritt komme:

CREATE AVAILABILITY GROUP [ag1]
    WITH (DB_FAILOVER = ON, CLUSTER_TYPE = EXTERNAL)
    FOR REPLICA ON
        N'always-onA' 
         WITH (
            ENDPOINT_URL = N'tcp://always-onA:5022',
            AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
            FAILOVER_MODE = EXTERNAL,
            SEEDING_MODE = AUTOMATIC
            ),
        N'always-onB' 
         WITH ( 
            ENDPOINT_URL = N'tcp://always-onB:5022', 
            AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
            FAILOVER_MODE = EXTERNAL,
            SEEDING_MODE = AUTOMATIC
            ),
        N'always-onC'
        WITH( 
           ENDPOINT_URL = N'tcp://always-onC:5022', 
           AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
           FAILOVER_MODE = EXTERNAL,
           SEEDING_MODE = AUTOMATIC
           );

Und ich bekomme die Fehlermeldung:

Msg 35237, Level 16, State 1, Line 2
None of the specified replicas for availability group ag1 maps to the instance of SQL Server to which you are connected. Reenter the command, specifying this server instance to host one of the replicas. This replica will be the initial primary replica. 

Ich habe die Versionshinweise unter https://docs.microsoft.com/en-us/sql/linux/sql-server-linux-release-notes überprüft, um sicherzustellen, dass keine Probleme bekannt sind und diese Funktion unterstützt werden sollte in diesem Moment.

In jedem Docker-Container werden die Namen "always-onX" aufgelöst:

>     root@5194403487fe:/# ping always-onA
>     PING always-onA (172.17.0.10): 56 data bytes
>     64 bytes from 172.17.0.10: icmp_seq=0 ttl=64 time=0.125 ms
>     ^C--- always-onA ping statistics ---
>     1 packets transmitted, 1 packets received, 0% packet loss
>     round-trip min/avg/max/stddev = 0.125/0.125/0.125/0.000 ms
>     root@5194403487fe:/# ping always-onB
>     PING always-onB (172.17.0.11): 56 data bytes
>     64 bytes from 172.17.0.11: icmp_seq=0 ttl=64 time=0.156 ms
>     ^C--- always-onB ping statistics ---
>     1 packets transmitted, 1 packets received, 0% packet loss
>     round-trip min/avg/max/stddev = 0.156/0.156/0.156/0.000 ms
>     root@5194403487fe:/# ping always-onC
>     PING always-onC (172.17.0.12): 56 data bytes
>     64 bytes from 172.17.0.12: icmp_seq=0 ttl=64 time=0.308 ms
>     ^C--- always-onC ping statistics ---
>     1 packets transmitted, 1 packets received, 0% packet loss
>     round-trip min/avg/max/stddev = 0.308/0.308/0.308/0.000 ms

SQL Server überwacht auch Port 5022 auf jeder Instanz (dies zeigt für alle Instanzen dasselbe):

# netstat -alnp | grep 5022
tcp        0      0 0.0.0.0:5022            0.0.0.0:*               LISTEN      9/sqlservr

Darüber hinaus sind auf dem System keine zusätzlichen IP-Adressen vorhanden, die Verwirrung stiften könnten:

# ifconfig
eth0      Link encap:Ethernet  HWaddr 02:42:ac:11:00:0a
          inet addr:172.17.0.10  Bcast:0.0.0.0  Mask:255.255.0.0
          inet6 addr: fe80::42:acff:fe11:a/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:4058 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2016 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:2771303 (2.7 MB)  TX bytes:241070 (241.0 KB)

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:470 errors:0 dropped:0 overruns:0 frame:0
          TX packets:470 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:1870657 (1.8 MB)  TX bytes:1870657 (1.8 MB)

Die Namen Always-onA / B / C werden sowohl in der Hostdatei für die Docker-Images als auch über DNS aufgelöst, sodass auch dort kein Problem auftreten sollte:

# nslookup always-onA
Server:         192.168.1.1
Address:        192.168.1.1#53

Name:   always-onA
Address: 172.17.0.10

Und schließlich zeigen die SQL Server-Protokolle, dass der Spiegelungsendpunkt auf Verbindungen wartet:

# docker logs always-onA | tail -2
2017-07-23 16:53:27.76 spid56      Server is listening on [ 0.0.0.0 <ipv4> 5022].
2017-07-23 16:53:27.76 spid56      The Database Mirroring endpoint is now listening for connections.

Es scheint, dass SQL Server nicht in der Lage ist, sauber zu identifizieren, dass einer der Konfigurationsknoten in der Verfügbarkeitsgruppe tatsächlich selbst ist, und daher den Fehler erhält, aber ich sehe keine Möglichkeit, dies zu debuggen. Ich habe versucht, anstelle des Namens "always-onA" Folgendes zu verwenden:

always-ona 127.0.0.1 localhost 0.0.0.0

Der Fehler ist immer der gleiche. Suchen Sie nach Gedanken zur Lösung dieses Problems.

Behoben: Das Problem besteht darin, dass der Knotenspezifizierer beim Erstellen der Verfügbarkeitsgruppe N'name'den EXACT-Namen verwenden muss, der gemäß dem "hostname"Befehl zurückgegeben wird. Die Verwendung eines anderen Bezeichners scheint nicht zu funktionieren, selbst wenn er in die richtige IP aufgelöst wird.

In meinem Fall war der Name der Verfügbarkeitsgruppe, es wurde gekürzt, weil es sehr lang war.