Funkciók együttműködése az AG-vel és a DNN-figyelővel

  • Cikk

A következőre vonatkozik:SQL Server azure-beli virtuális gépen

Tipp.

Egy rendelkezésre állási csoport üzembe helyezésének számos módja van. Egyszerűsítse az üzembe helyezést, és szükségtelenné teszi az Azure Load Balancer vagy az elosztott hálózatnév (DNN) használatát az Always On rendelkezésre állási csoport számára azáltal, hogy sql serveres virtuális gépeket (VM-eket) hoz létre több alhálózatban ugyanazon az Azure-beli virtuális hálózaton belül. Ha már létrehozta a rendelkezésre állási csoportot egyetlen alhálózatban, migrálhatja azt egy több alhálózatos környezetbe.

Vannak bizonyos SQL Server-funkciók, amelyek egy rögzített virtuális hálózatnévre (VNN) támaszkodnak. Ha az elosztott hálózati név (DNN) figyelőt az Always On rendelkezésre állási csoporttal és az Azure-beli virtuális gépeken futó SQL Servert használja egyetlen alhálózaton, további szempontokat is figyelembe vehet.

Ez a cikk az SQL Server funkcióit és a rendelkezésre állási csoport DNN-figyelőjével való együttműködését ismerteti.

Viselkedésbeli különbségek

A VNN-figyelő és a DNN-figyelő funkciói között van néhány viselkedésbeli különbség, amelyeket fontos megjegyezni:

  • Feladatátvételi idő: A feladatátvételi idő gyorsabb, ha DNN-figyelőt használ, mivel nem kell megvárni, amíg a hálózati terheléselosztó észleli a hibaeseményt, és módosítja annak útválasztását.
  • Meglévő kapcsolatok: egy feladatátvételi csoporton belül egy adott adatbázisba irányuló Csatlakozás, de az elsődleges replikával létesített egyéb kapcsolatok nyitva maradnak, mivel a DNN a feladatátvételi folyamat során online állapotban marad. Ez eltér a hagyományos VNN-környezetétől, ahol az elsődleges replikához tartozó összes kapcsolat általában bezárul, amikor a rendelkezésre állási csoport meghibásodik, a figyelő offline állapotba kerül, és az elsődleges replika átáll a másodlagos szerepkörre. DNN-figyelő használata esetén előfordulhat, hogy módosítania kell az alkalmazás kapcsolati sztring, hogy a kapcsolatok a feladatátvételkor az új elsődleges replikára legyenek átirányítva.
  • Tranzakciók megnyitása: Tranzakciók megnyitása egy feladatátvételi rendelkezésre állási csoportban lévő adatbázison belül, bezárva és visszagördülve, és manuálisan kell újracsatlakoznia. Az SQL Server Management Studióban például zárja be a lekérdezési ablakot, és nyisson meg egy újat.

Ügyfélillesztők

ODBC, OLEDB, ADO.NET, JDBC, PHP és Node.js illesztőprogramok esetén a felhasználóknak explicit módon meg kell adniuk a DNN-figyelő nevét és portot a kiszolgáló neveként a kapcsolati sztring. Ha a feladatátvételkor gyors kapcsolatot szeretne biztosítani, adja hozzá MultiSubnetFailover=True a kapcsolati sztring, ha az SQL-ügyfél támogatja.

Tools

Az SQL Server Management Studio, az sqlcmd, az Azure Data Studio és az SQL Server Data Tools felhasználóinak explicit módon meg kell adniuk a DNN-figyelő nevét és portját a kiszolgáló neveként a kapcsolati sztring a figyelőhöz való csatlakozáshoz.

A DNN-figyelő az SQL Server Management Studio (SSMS) GUI-n keresztül történő létrehozása jelenleg nem támogatott.

Rendelkezésre állási csoportok és FCI

Az Always On rendelkezésre állási csoportot úgy konfigurálhatja, hogy egy feladatátvevő fürtpéldányt (FCI) használ a replikák egyikeként. Ahhoz, hogy ez a konfiguráció működjön a DNN-figyelővel, a feladatátvevő fürtpéldánynak a DNN-t is használnia kell, mivel az FCI virtuális IP-címét nem lehet az AG DNN IP-listájába helyezni.

Ebben a konfigurációban az FCI-replikához tartozó tükrözési végpont URL-címének az FCI DNN-t kell használnia. Hasonlóképpen, ha az FCI-t írásvédett replikaként használják, az FCI-replikához való írásvédett útválasztásnak az FCI DNN-t kell használnia.

A tükrözési végpont formátuma: ENDPOINT_URL = 'TCP://<FCI DNN DNS name>:<mirroring endpoint port>'.

Ha például az FCI DNN DNS-neve dnnlsnr, és 5022 az FCI tükrözési végpontjának portja, a Transact-SQL (T-SQL) kódrészlet a végpont URL-címének létrehozásához a következőképpen néz ki:

ENDPOINT_URL = 'TCP://dnnlsnr:5022'

Hasonlóképpen az írásvédett útválasztási URL formátuma a következő: TCP://<FCI DNN DNS name>:<SQL Server instance port>.

Ha például a DNN DNS-neve dnnlsnr, és 1444 az írásvédett cél SQL Server FCI által használt port, a csak olvasható útválasztási URL-cím létrehozásához használt T-SQL-kódrészlet a következőképpen néz ki:

READ_ONLY_ROUTING_URL = 'TCP://dnnlsnr:1444'

Ha ez az alapértelmezett 1433-at adja meg, kihagyhatja a portot az URL-címből. Névvel ellátott példány esetén konfiguráljon egy statikus portot az elnevezett példányhoz, és adja meg az írásvédett útválasztási URL-címben.

Elosztott rendelkezésre állási csoport

Ha a rendelkezésreállási csoport figyelője elosztott hálózati névvel (DNN) van konfigurálva, akkor a rendelkezésre állási csoport tetején lévő elosztott rendelkezésre állási csoport konfigurálása nem támogatott.

Replikáció

A tranzakciós, az egyesítési és a pillanatkép-replikáció mind támogatja a VNN-figyelő és a figyelőhöz csatlakozó replikációs objektumok DNN-figyelőre és portra való lecserélését.

A replikáció rendelkezésre állási csoportokkal való használatáról további információt a Publisher és az AG, az Előfizető és az AG, valamint a Forgalmazó és AG című témakörben talál.

MSDTC

A helyi és a fürtözött MSDTC is támogatott, de az MSDTC dinamikus portot használ, amelyhez egy standard Azure Load Balancer szükséges a HA-port konfigurálásához. Ezért vagy a virtuális gépnek szabványos IP-foglalást kell használnia, vagy nem lehet az interneten keresztül elérhetővé tenni.

Definiáljon két szabályt, egyet az RPC Endpoint Mapper 135-ös portjához, egyet pedig a valódi MSDTC-porthoz. A feladatátvétel után módosítsa a terheléselosztási szabályt az új MSDTC-portra, miután az az új csomóponton módosult.

Ha az MSDTC helyi, mindenképpen engedélyezze a kimenő kommunikációt.

Elosztott lekérdezés

Az elosztott lekérdezés egy csatolt kiszolgálóra támaszkodik, amely konfigurálható az AG DNN-figyelő és -port használatával. Ha a port nem 1433, a csatolt kiszolgáló konfigurálásakor válassza az SQL Server Management Studio (SSMS) Más adatforrás használata lehetőségét.

FÁJLSTREAM

A FILESTREAM támogatott, de nem olyan esetekben, amikor a felhasználók a Windows File API használatával férnek hozzá a hatókörön belüli fájlmegosztáshoz.

FileTable

A FileTable támogatott, de nem olyan esetekben, amikor a felhasználók a Windows File API használatával férnek hozzá a hatókörön belüli fájlmegosztáshoz.

Társított kiszolgálók

Konfigurálja a csatolt kiszolgálót az AG DNN figyelő nevének és portjának használatával. Ha a port nem 1433, a csatolt kiszolgáló konfigurálásakor válassza az SQL Server Management Studio (SSMS) Más adatforrás használata lehetőségét.

Gyakori kérdések

Melyik SQL Server-verzió támogatja az AG DNN-figyelőt?

SQL Server 2019 CU 8 és újabb.

Mi a DNN-figyelő használata esetén várható feladatátvételi idő?

A DNN-figyelő esetében a feladatátvételi idő megegyezik az AG feladatátvételi idejével, további idő nélkül (például mintavételi idő az Azure Load Balancer használatakor).

Van verziókövetelmény az SQL-ügyfelek számára a DNN OLEDB-vel és ODBC-vel való támogatásához?

Javasoljuk MultiSubnetFailover=True kapcsolati sztring DNN-figyelő támogatását. Az SQL Server 2012 -től (11.x) érhető el.

Szükség van az SQL Server konfigurációs módosításaira a DNN-figyelő használatához?

Az SQL Server nem igényel konfigurációmódosítást a DNN használatához, de egyes SQL Server-funkciók további megfontolást igényelhetnek.

Támogatja a DNN a több alhálózati fürtöket?

Igen. A fürt a DNS-ben lévő DNN-t az alhálózattól függetlenül a rendelkezésre állási csoport összes replikája fizikai IP-címével köti össze. Az SQL-ügyfél az alhálózattól függetlenül megpróbálja a DNS-név összes IP-címét.

Támogatja a rendelkezésre állási csoport DNN-figyelője az írásvédett útválasztást?

Igen. A DNN-figyelő támogatja az írásvédett útválasztást.

Kapcsolódó tartalom