Megosztás:

Sql Server Always On rendelkezésre állási csoport konfigurálása Windowson és Linuxon (platformfüggetlen)

A következőkre vonatkozik: SQL Server 2017 (14.x) és újabb verziók

Ez a cikk bemutatja az Always On rendelkezésre állási csoport (AG) létrehozásának lépéseit egy Windows-kiszolgálón található egyik replikával, a másik replikával linuxos kiszolgálón.

Fontos

Az SQL Server platformfüggetlen rendelkezésre állási csoportjai, amelyek heterogén replikákat tartalmaznak teljes körű magas rendelkezésre állással és vészhelyreállítási támogatással, a DH2i DxEnterprise szolgáltatással érhetők el. További információ: SQL Server rendelkezésre állási csoportok vegyes operációs rendszerekkel.

A dh2i platformfüggetlen rendelkezésre állási csoportokról az alábbi videóban tájékozódhat.

Ez a konfiguráció platformfüggetlen, mert a replikák különböző operációs rendszereken találhatók. Ezt a konfigurációt használhatja az egyik platformról a másikra vagy vészhelyreállításra (DR). Ez a konfiguráció nem támogatja a magas rendelkezésre állást.

A fürt típus nélküli rendelkezésre állási csoport diagramja.

A folytatás előtt ismernie kell az SQL Server-példányok windowsos és linuxos telepítését és konfigurációját.

Forgatókönyv

Ebben a forgatókönyvben két kiszolgáló különböző operációs rendszereken található. Az elsődleges replikát egy WinSQLInstance nevű Windows Server 2022 üzemelteti. A másodlagos replikát egy LinuxSQLInstance nevű Linux-kiszolgáló üzemelteti.

Az AG konfigurálása

Az AG létrehozásának lépései megegyeznek a olvasási skálázásra optimalizált számítási feladatokhoz készítettAG létrehozásának lépéseivel. Az AG-fürt típusa NINCS ÉRTÉKELVE, mert nincs fürtkezelő.

A cikkben szereplő szkriptek esetében a szögletes zárójelek < és > azonosítják a környezet számára lecserélendő értékeket. Maguk a szögletes zárójelek nem szükségesek a szkriptekhez.

  1. Telepítse az SQL Server 2022 -t (16.x) Windows Server 2022-en, engedélyezze Always On rendelkezésre állási csoportok az SQL Server Configuration Managerből, és állítsa be a vegyes módú hitelesítést.

    Borravaló

    Ha ezt a megoldást az Azure-ban érvényesíti, helyezze mindkét kiszolgálót ugyanabban a rendelkezésre állási csoportban, hogy biztosan külön legyenek az adatközpontban.

    Rendelkezésre állási csoportok engedélyezése

    Útmutatásért lásd: Always On rendelkezésreállási csoport funkció engedélyezése vagy letiltása.

    Rendelkezésre állási csoportok engedélyezését bemutató képernyőkép.

    Az SQL Server Configuration Manager megjegyzi, hogy a számítógép nem egy feladatátvevő fürt csomópontja.

    A rendelkezésre állási csoportok engedélyezése után indítsa újra az SQL Servert.

    Vegyes módú hitelesítés beállítása

    Útmutatásért lásd: Kiszolgálóhitelesítési mód módosítása.

  2. Telepítse az SQL Server 2022-t (16.x) Linux rendszeren. Útmutatásért tekintse meg Linuxsql server telepítési útmutatóját. Engedélyezze a hadr-t a mssql-conf segítségével.

    A(z) hadr engedélyezéséhez a rendszerhéj parancssorban a(z) mssql-conf használatával adja ki a következő parancsot:

    sudo /opt/mssql/bin/mssql-conf set hadr.hadrenabled 1

    A hadrengedélyezése után indítsa újra az SQL Server-példányt:

    sudo systemctl restart mssql-server.service

  3. Konfigurálja a hosts fájlt mindkét kiszolgálón, vagy regisztrálja a kiszolgálóneveket a DNS-ben.

  4. Nyisson meg tűzfalportokat a TCP 1433-hoz és az 5022-hez Windows és Linux rendszeren is.

  5. Az elsődleges replikán hozzon létre egy adatbázis-bejelentkezést és jelszót.

    CREATE LOGIN dbm_login
    WITH PASSWORD = '<password>';

CREATE USER dbm_user FOR LOGIN dbm_login;
GO

    Figyelem

    A jelszónak az SQL Server alapértelmezett jelszóházirendetkell követnie. Alapértelmezés szerint a jelszónak legalább nyolc karakter hosszúnak kell lennie, és a következő négy készletből három karakterből kell állnia: nagybetűk, kisbetűk, 10 számjegyből és szimbólumokból. A jelszavak legfeljebb 128 karakter hosszúak lehetnek. Használjon olyan jelszavakat, amelyek a lehető legkomplexebbek és hosszúak.

  6. Az elsődleges replikán hozzon létre egy főkulcsot és egy tanúsítványt, majd készítsen biztonsági másolatot a tanúsítványról egy titkos kulccsal.

    CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<master-key-password>';

CREATE CERTIFICATE dbm_certificate
    WITH SUBJECT = 'dbm';

BACKUP CERTIFICATE dbm_certificate TO FILE = 'C:\Program Files\Microsoft SQL Server\MSSQL16.MSSQLSERVER\MSSQL\DATA\dbm_certificate.cer'
    WITH PRIVATE KEY (
         FILE = 'C:\Program Files\Microsoft SQL Server\MSSQL16.MSSQLSERVER\MSSQL\DATA\dbm_certificate.pvk',
         ENCRYPTION BY PASSWORD = '<private-key-password>'
);
GO

    Figyelem

    A jelszónak az SQL Server alapértelmezett jelszóházirendetkell követnie. Alapértelmezés szerint a jelszónak legalább nyolc karakter hosszúnak kell lennie, és a következő négy készletből három karakterből kell állnia: nagybetűk, kisbetűk, 10 számjegyből és szimbólumokból. A jelszavak legfeljebb 128 karakter hosszúak lehetnek. Használjon olyan jelszavakat, amelyek a lehető legkomplexebbek és hosszúak.

  7. Másolja a tanúsítványt és a privát kulcsot a Linux kiszolgálóra (másodlagos replika) a megadott helyen, /var/opt/mssql/data. A pscp használatával másolhatja a fájlokat a Linux-kiszolgálóra.

  8. Állítsa be a titkos kulcs és a tanúsítvány csoportját és tulajdonjogát mssql:mssql.

    Az alábbi szkript beállítja a fájlok csoportját és tulajdonjogát.

    sudo chown mssql:mssql /var/opt/mssql/data/dbm_certificate.pvk
sudo chown mssql:mssql /var/opt/mssql/data/dbm_certificate.cer

    Az alábbi ábrán a tulajdonos és a csoport helyesen van beállítva a tanúsítványhoz és a kulcshoz.

    Képernyőkép egy Git Bash-ablakról, amelyen a .cer és a .pvk látható a /var/opt/mssql/data mappában.

  9. A másodlagos replikán hozzon létre egy adatbázis-bejelentkezést és jelszót, és hozzon létre egy főkulcsot.

    CREATE LOGIN dbm_login
    WITH PASSWORD = '<password>';

CREATE USER dbm_user FOR LOGIN dbm_login;
GO

CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<master-key-password>';
GO

    Figyelem

    A jelszónak az SQL Server alapértelmezett jelszóházirendetkell követnie. Alapértelmezés szerint a jelszónak legalább nyolc karakter hosszúnak kell lennie, és a következő négy készletből három karakterből kell állnia: nagybetűk, kisbetűk, 10 számjegyből és szimbólumokból. A jelszavak legfeljebb 128 karakter hosszúak lehetnek. Használjon olyan jelszavakat, amelyek a lehető legkomplexebbek és hosszúak.

  10. A másodlagos replikán állítsa vissza azt a tanúsítványt, amelyet korábban a /var/opt/mssql/data-ra másolt.

    CREATE CERTIFICATE dbm_certificate
    AUTHORIZATION dbm_user
    FROM FILE = '/var/opt/mssql/data/dbm_certificate.cer'
    WITH PRIVATE KEY (
        FILE = '/var/opt/mssql/data/dbm_certificate.pvk',
        DECRYPTION BY PASSWORD = '<private-key-password>'
);
GO

    Az előző példában cserélje le <private-key-password> ugyanazzal a jelszóval, amelyet a tanúsítvány elsődleges replikán való létrehozásakor használt.

  11. Az elsődleges replikán hozzon létre egy végpontot.

    CREATE ENDPOINT [Hadr_endpoint]
    AS TCP
(
            LISTENER_IP = (0.0.0.0),
            LISTENER_PORT = 5022
)
    FOR DATABASE_MIRRORING
(
            ROLE = ALL,
            AUTHENTICATION = CERTIFICATE dbm_certificate,
            ENCRYPTION = REQUIRED ALGORITHM AES
);

ALTER ENDPOINT [Hadr_endpoint]
    STATE = STARTED;

GRANT CONNECT
    ON ENDPOINT::[Hadr_endpoint] TO [dbm_login];
GO

    Fontos

    A tűzfalnak nyitva kell lennie a figyelő TCP-portjához. Az előző szkriptben a port 5022. Használjon bármilyen elérhető TCP-portot.

  12. A másodlagos replikán hozza létre a végpontot. Ismételje meg az előző szkriptet a másodlagos replikán a végpont létrehozásához.

  13. Az elsődleges replikán hozza létre az AG-t CLUSTER_TYPE = NONE. A példaszkript SEEDING_MODE = AUTOMATIC-t használ AG létrehozásához.

    Jegyzet

    Ha az SQL Server Windows-példánya különböző elérési utakat használ az adatokhoz és a naplófájlokhoz, az automatikus magvetés nem sikerül az SQL Server Linux-példányán, mivel ezek az elérési utak nem léteznek a másodlagos replikán. A következő szkript platformfüggetlen AG-hez való használatához az adatbázisnak ugyanazt az elérési utat kell használnia a Windows-kiszolgálón található adatokhoz és naplófájlokhoz. Másik lehetőségként beállíthatja a SEEDING_MODE = MANUAL-t a szkriptben, majd biztonsági másolatot készíthet az adatbázisról, és visszaállíthatja azt NORECOVERY segítségével az adatbázis inicializálásához.

    Ez a viselkedés az Azure Marketplace-rendszerképekre vonatkozik.

    Az automatikus vetésről további információt az Automatikus vetés – Lemezelrendezéscímű témakörben talál.

    A szkript futtatása előtt frissítse az AG-k értékeit.

    • Cserélje le <WinSQLInstance> az elsődleges replika SQL Server-példányának kiszolgálónevére.

    • Cserélje le <LinuxSQLInstance> a másodlagos replika SQL Server-példányának kiszolgálónevére.

    Az AG létrehozásához frissítse az értékeket, és futtassa a szkriptet az elsődleges replikán.

    CREATE AVAILABILITY
GROUP [ag1]
WITH (CLUSTER_TYPE = NONE)
FOR REPLICA
    ON N'<WinSQLInstance>'
WITH (
    ENDPOINT_URL = N'tcp://<WinSQLInstance>:5022',
    AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,
    SEEDING_MODE = AUTOMATIC,
    FAILOVER_MODE = MANUAL,
    SECONDARY_ROLE(ALLOW_CONNECTIONS = ALL)
    ),
    N'<LinuxSQLInstance>'
WITH (
    ENDPOINT_URL = N'tcp://<LinuxSQLInstance>:5022',
    AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,
    SEEDING_MODE = AUTOMATIC,
    FAILOVER_MODE = MANUAL,
    SECONDARY_ROLE(ALLOW_CONNECTIONS = ALL);
    )
GO

    További információ: CREATE AVAILABILITY GROUP.

  14. A másodlagos replikán csatlakozzon az AG-hez.

    ALTER AVAILABILITY GROUP [ag1] JOIN WITH (CLUSTER_TYPE = NONE);
ALTER AVAILABILITY GROUP [ag1] GRANT CREATE ANY DATABASE;
GO

  15. Hozzon létre egy adatbázist az AG számára. A példalépések egy TestDBnevű adatbázist használnak. Ha automatikus vetést használ, állítsa be ugyanazt az elérési utat az adatokhoz és a naplófájlokhoz is.

    A szkript futtatása előtt frissítse az adatbázis értékeit.

    • Cserélje le TestDB az adatbázis nevére.

    • Cserélje le a <F:\Path> az adatbázis és a naplófájlok elérési útjára. Használja ugyanazt az elérési utat az adatbázishoz és a naplófájlokhoz.

    Az alapértelmezett elérési utakat is használhatja.

    Az adatbázis létrehozásához futtassa a szkriptet.

    CREATE DATABASE [TestDB] CONTAINMENT = NONE
    ON
    PRIMARY(NAME = N'TestDB', FILENAME = N'<F:\Path>\TestDB.mdf')
    LOG ON (NAME = N'TestDB_log', FILENAME = N'<F:\Path>\TestDB_log.ldf');
GO

  16. Készítsen teljes biztonsági másolatot az adatbázisról.

  17. Ha nem használ automatikus vetést, állítsa vissza az adatbázist a másodlagos replikakiszolgálón (Linux). SQL Server-adatbázis áttelepítése Windowsról Linuxra biztonsági mentéssel és visszaállítással. Állítsa vissza az WITH NORECOVERY adatbázist a másodlagos replikára.

  18. Adja hozzá az adatbázist az AG-hez. Frissítse a példaszkriptet. Cserélje le TestDB az adatbázis nevére. Az elsődleges replikán futtassa a T-SQL-lekérdezést az adatbázis AG-hez való hozzáadásához.

    ALTER AG [ag1] ADD DATABASE TestDB;
GO

  19. Ellenőrizze, hogy az adatbázis ki van-e töltve a másodlagos replikán.

Az elsődleges replika átváltása biztonsági másolatra

Minden rendelkezésre állási csoport csak egy elsődleges replikával rendelkezik. Az elsődleges replika olvasást és írást tesz lehetővé. Az elsődleges replika módosításához átállást végezhet. Egy tipikus rendelkezésre állási csoportban a fürtkezelő automatizálja a feladatátvételi folyamatot. Egy 'NONE' típusú fürt nélküli rendelkezésre állási csoportban a feladatátvételi folyamat manuálisan történik.

Az elsődleges replika átterelése két módon történhet egy rendelkezésre állási csoportban, fürttípus nélkül:

  • Manuális átkapcsolás adatvesztés nélkül
  • Kényszerített manuális feladatátvétel adatvesztéssel

Manuális átkapcsolás adatvesztés nélkül

Ezt a módszert akkor használja, ha az elsődleges replika elérhető, de ideiglenesen vagy véglegesen módosítania kell, hogy melyik példány tárolja az elsődleges replikát. A lehetséges adatvesztés elkerülése érdekében a manuális feladatátvétel megkezdése előtt győződjön meg arról, hogy a másodlagos célreplika naprakész.

Manuális feladatátvétel adatvesztés nélkül:

  1. Az aktuális elsődleges replikát tegyük elsődleges szerepkörűvé, a célmásodlagos replikát pedig másodlagos célúvá SYNCHRONOUS_COMMIT.

    ALTER AVAILABILITY GROUP [AGRScale] 
     MODIFY REPLICA ON N'<node2>' 
     WITH (AVAILABILITY_MODE = SYNCHRONOUS_COMMIT);

  2. Annak megállapítására, hogy az aktív tranzakciók véglegesítve vannak-e az elsődleges replikán és legalább egy szinkron másodlagos replikán, futtassa a következő lekérdezést:

    SELECT ag.name, 
   drs.database_id, 
   drs.group_id, 
   drs.replica_id, 
   drs.synchronization_state_desc, 
   ag.sequence_number
FROM sys.dm_hadr_database_replica_states drs, sys.availability_groups ag
WHERE drs.group_id = ag.group_id;

    A másodlagos replika akkor lesz szinkronizálva, ha synchronization_state_descSYNCHRONIZED.

  3. Frissítse a REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT 1-re.

    Az alábbi szkript REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT értékét 1-re állítja egy ag1nevű rendelkezésre állási csoportban. A következő szkript futtatása előtt cserélje le ag1 a rendelkezésre állási csoport nevére:

    ALTER AVAILABILITY GROUP [AGRScale] 
     SET (REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT = 1);

    Ez a beállítás biztosítja, hogy minden aktív tranzakció az elsődleges replikához és legalább egy szinkron másodlagos replikához legyen lekötve.

    Jegyzet

    Ez a beállítás nem a feladatátvételre vonatkozik, és a környezet követelményeinek megfelelően kell beállítani.

  4. Állítsa be az elsődleges replikát és a másodlagos replikát, amely nem vesz részt a feladatátvételben offline állapotban, hogy felkészüljön a szerepkör módosítására:

    ALTER AVAILABILITY GROUP [AGRScale] OFFLINE

  5. A másodlagos replikát léptesse elő elsődlegessé.

    ALTER AVAILABILITY GROUP AGRScale FORCE_FAILOVER_ALLOW_DATA_LOSS;

  6. Frissítse a régi elsődleges és más másodpéldányok szerepkörét SECONDARY, futtassa a következő parancsot a régi elsődleges replikát futtató SQL Server-példányon:

    ALTER AVAILABILITY GROUP [AGRScale] 
     SET (ROLE = SECONDARY);

    Jegyzet

    Elérhetőségi csoport törléséhez használja a DROP AVAILABILITY GROUPparancsot. A NINCS vagy KÜLSŐ típusú fürttípussal létrehozott rendelkezésre állási csoport esetén hajtsa végre a parancsot a rendelkezésre állási csoport részét képező összes replikán.

  7. Folytassa az adatáthelyezést, futtassa a következő parancsot az elsődleges replikát üzemeltető SQL Server-példány rendelkezésre állási csoportjának összes adatbázisához:

    ALTER DATABASE [db1]
     SET HADR RESUME

  8. Hozzon létre újra minden olyan figyelőt, amelyet olvasási skálázás céljából hozott létre, és amelyet nem a fürtkezelő felügyel. Ha az eredeti figyelő a régi elsődlegesre mutat, törölje, majd hozza létre újra úgy, hogy az új elsődlegesre mutasson.

Kényszerített manuális feladatátvétel adatvesztéssel

Ha az elsődleges replika nem érhető el, és nem állítható helyre azonnal, akkor kényszeríteni kell az átállást a másodlagos replikára, ami adatvesztéssel jár. Ha azonban az eredeti elsődleges replika helyreáll a feladatátvétel után, akkor átveszi az elsődleges szerepkört. Annak elkerülése érdekében, hogy minden replika más állapotban legyen, távolítsa el az eredeti elsődleges replikát a rendelkezésre állási csoportból egy adatvesztéssel járó kényszer-feladatátvétel után. Miután az eredeti elsődleges ismét online állapotba kerül, távolítsa el az elérhetőségi csoportot teljesen.

Ha adatvesztéssel járó manuális átvitelt szeretne kényszeríteni az N1 elsődleges replikáról az N2 másodlagos replikára, kövesse az alábbi lépéseket:

  1. A másodlagos replikán (N2) indítsa el a kényszerített feladatátvételt:

    ALTER AVAILABILITY GROUP [AGRScale] FORCE_FAILOVER_ALLOW_DATA_LOSS;

  2. Az új elsődleges replikán (N2) távolítsa el az eredeti elsődlegest (N1):

    ALTER AVAILABILITY GROUP [AGRScale]
REMOVE REPLICA ON N'N1';

  3. Ellenőrizze, hogy az összes alkalmazásforgalom a figyelőre és/vagy az új elsődleges replikára van-e irányítva.

  4. Ha az eredeti elsődleges (N1) online állapotba kerül, azonnal kapcsolja offline állapotba az AGRScale rendelkezésre állási csoportot az eredeti elsődlegesen (N1):

    ALTER AVAILABILITY GROUP [AGRScale] OFFLINE

  5. Ha vannak adatok vagy nem aszinkron módosítások, őrizze meg ezeket az adatokat biztonsági másolatokkal vagy más, az üzleti igényeinek megfelelő adatreplikálási lehetőségekkel.

  6. Ezután távolítsa el a rendelkezésre állási csoportot az eredeti elsődlegesből (N1):

    DROP AVAILABILITY GROUP [AGRScale];

  7. A rendelkezésre állási csoport adatbázisának elvetése az eredeti elsődleges replikán (N1):

    USE [master]
GO
DROP DATABASE [AGDBRScale]
GO

  8. (Nem kötelező) Ha szükséges, most már hozzáadhatja az N1-et új másodlagos replikaként az AGRScale rendelkezésre állási csoporthoz.

Ez a cikk áttekintette a migrálást vagy olvasási skálázást támogató platformfüggetlen AG létrehozásának lépéseit. Manuális vészhelyreállításhoz használható. Azt is elmagyarázta, hogyan lehet feladatátvételt végrehajtani az AG-en. A platformfüggetlen AG fürttípusú NONE használ, és nem támogatja a magas rendelkezésre állást.

Kapcsolódó tartalom

  • Last updated on