Konfigurace skupiny dostupnosti SQL Serveru pro škálování čtení v Linuxu

platí pro:SQL Server – Linux

Tento článek vysvětluje, jak vytvořit skupinu dostupnosti AlwaysOn (AG) SQL Serveru v Linuxu bez správce clusteru. Tato architektura je určena pouze pro škálování čtení. neposkytuje vysokou dostupnost.

Pro skupiny AG existují dva typy architektur. Architektura pro vysokou dostupnost využívá správce clusteru k zajištění lepší kontinuity podnikových procesů. Pokud chcete vytvořit architekturu s vysokou dostupností, viz Konfigurace skupiny dostupnosti SQL Server Always On pro zajištění vysoké dostupnosti v linuxovém prostředí.

Skupina dostupnosti s CLUSTER_TYPE = NONE může zahrnovat repliky hostované na různých platformách operačního systému. Nemůže podporovat vysokou dostupnost.

Požadavky

Před vytvořením skupiny dostupnosti musíte:

• Nastavte prostředí tak, aby všechny servery, které budou hostovat repliky dostupnosti, mohly komunikovat.
• Nainstalujte SQL Server.

V systému Linux musíte vytvořit skupinu dostupnosti ještě před tím, než ji přidáte jako prostředek spravovaný clusterem. Tento dokument obsahuje příklad, který vytvoří skupinu dostupnosti.

1. Aktualizujte název počítače pro každého hostitele.

   Každý název instance SQL Serveru musí být:

   • 15 znaků nebo méně.
   • Jedinečné v rámci sítě.

   Chcete-li nastavit název počítače, upravte /etc/hostname. Následující skript umožňuje upravovat /etc/hostname pomocí vi:

   sudo vi /etc/hostname
   

2. Nakonfigurujte soubor hostitelů.

   Poznámka

   Pokud jsou názvy hostitelů zaregistrované s jejich IP adresou na serveru DNS, nemusíte provádět následující kroky. Ověřte, že všechny uzly, které mají být součástí konfigurace skupiny dostupnosti, spolu můžou komunikovat. (Příkaz ping na název hostitele by měl vrátit odpovídající IP adresu.) Ujistěte se také, že soubor /etc/hosts neobsahuje záznam, který mapuje IP adresu localhost 127.0.0.1 na název hostitele uzlu.

   Soubor hostitelů na každém serveru obsahuje IP adresy a názvy všech serverů, které se budou účastnit skupiny dostupnosti.

   Následující příkaz vrátí IP adresu aktuálního serveru:

   sudo ip addr show
   

   Aktualizace /etc/hosts. Následující skript umožňuje upravovat /etc/hosts pomocí vi:

   sudo vi /etc/hosts
   

   Následující příklad ukazuje /etc/hosts na node1 s doplňky pro node1, node2a node3. V této ukázce node1 odkazuje na server, který je hostitelem primární repliky, a node2 a node3 odkazovat na servery, které hostují sekundární repliky.

   127.0.0.1    localhost localhost4 localhost4.localdomain4
   ::1          localhost localhost6 localhost6.localdomain6
   10.128.18.12 node1
   10.128.16.77 node2
   10.128.15.33 node3
   

Instalace SQL Serveru

Nainstalujte SQL Server. Následující odkazy odkazují na pokyny k instalaci SQL Serveru pro různé distribuce:

• rychlý start pro : Instalace SQL Serveru a vytvoření databáze v Red Hat
• Rychlý start: Instalace SQL Serveru a vytvoření databáze na SUSE Linux Enterprise Server
• rychlý start pro : Instalace SQL Serveru a vytvoření databáze na Ubuntu

Povolení skupin dostupnosti AlwaysOn

Povolte skupiny dostupnosti AlwaysOn pro každý uzel, který je hostitelem instance SQL Serveru, a restartujte mssql-server. Spusťte následující skript:

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

Povolte relaci událostí AlwaysOn_health

Volitelně můžete povolit rozšířené události (XE), které vám pomůžou s diagnostikou původní příčiny při řešení potíží se skupinou dostupnosti. Na každé instanci SQL Serveru spusťte následující příkaz:

ALTER EVENT SESSION AlwaysOn_health ON SERVER
WITH
(
        STARTUP_STATE = ON
);
GO

Další informace o této relaci XE naleznete v tématu Konfigurace rozšířených událostí pro skupiny dostupnosti.

Vytvoření certifikátu

Služba SQL Serveru v Linuxu používá certifikáty k ověření komunikace mezi koncovými body zrcadlení.

Následující Transact-SQL skript vytvoří hlavní klíč a certifikát. Pak zálohuje certifikát a zabezpečí soubor privátním klíčem. Aktualizujte skript silnými hesly. Připojte se k primární instanci SQL Serveru. Certifikát vytvoříte spuštěním následujícího skriptu Transact-SQL:

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

CREATE CERTIFICATE dbm_certificate
    WITH SUBJECT = 'dbm';

BACKUP CERTIFICATE dbm_certificate
    TO FILE = '/var/opt/mssql/data/dbm_certificate.cer'
    WITH PRIVATE KEY (
        FILE = '/var/opt/mssql/data/dbm_certificate.pvk',
        ENCRYPTION BY PASSWORD = '<private-key-password>'
);

V tomto okamžiku má primární replika SQL Serveru certifikát v /var/opt/mssql/data/dbm_certificate.cer a privátní klíč v var/opt/mssql/data/dbm_certificate.pvk. Zkopírujte tyto dva soubory do stejného umístění na všech serverech, které budou hostovat dostupnostní repliky. Použijte uživatele mssql nebo udělte uživateli mssql oprávnění pro přístup k těmto souborům.

Například na zdrojovém serveru následující příkaz zkopíruje soubory do cílového počítače. Nahraďte hodnoty <node2> názvy instancí SYSTÉMU SQL Server, které budou hostovat repliky.

cd /var/opt/mssql/data
scp dbm_certificate.* root@<node2>:/var/opt/mssql/data/

Na každém cílovém serveru udělte uživateli mssql oprávnění pro přístup k certifikátu.

cd /var/opt/mssql/data
chown mssql:mssql dbm_certificate.*

Vytvoření certifikátu na sekundárních serverech

Následující skript Transact-SQL vytvoří hlavní klíč a certifikát ze zálohy, kterou jste vytvořili na primární replice SQL Serveru. Aktualizujte skript silnými hesly. Dešifrovací heslo je stejné heslo, které jste použili k vytvoření souboru .pvk v předchozím kroku. Certifikát vytvoříte spuštěním následujícího skriptu na všech sekundárních serverech:

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

CREATE CERTIFICATE dbm_certificate
    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>'
);

V předchozím příkladu nahraďte <private-key-password> stejným heslem, které jste použili při vytváření certifikátu na primární replice.

Vytvořte koncové body pro zrcadlení databáze na všech replikách

Koncové body zrcadlení databáze používají protokol TCP (Transmission Control Protocol) k odesílání a přijímání zpráv mezi instancemi serveru, které se účastní relací zrcadlení databáze, nebo replikami dostupnosti hostitele. Koncový bod zrcadlení databáze naslouchá jedinečnému číslu portu TCP.

Následující skript Transact-SQL vytvoří koncový bod naslouchání s názvem Hadr_endpoint pro skupinu dostupnosti. Spustí koncový bod a udělí připojení k certifikátu, který jste vytvořili. Před spuštěním skriptu nahraďte hodnoty mezi < ... >. Volitelně můžete zahrnout IP adresu LISTENER_IP = (0.0.0.0). IP adresa naslouchacího procesu musí být adresa IPv4. Můžete také použít 0.0.0.0.

Aktualizujte následující Transact-SQL skript pro vaše prostředí ve všech instancích SQL Serveru:

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

ALTER ENDPOINT [Hadr_endpoint]
    STATE = STARTED;

Poznámka

Pokud k hostování repliky jen pro konfiguraci používáte edici SQL Serveru Express na jednom uzlu, jedinou platnou hodnotou pro ROLE je WITNESS. V edici SQL Server Express spusťte následující skript:

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

ALTER ENDPOINT [Hadr_endpoint]
    STATE = STARTED;

Port TCP na bráně firewall musí být otevřený pro naslouchací port.

Důležitý

Pro SQL Server 2017 (14.x) je jediná metoda ověřování podporovaná pro koncový bod zrcadlení databáze CERTIFICATE. Možnost WINDOWS není dostupná.

Další informace naleznete v tématu Koncový bod zrcadlení databáze (SQL Server).

Vytvoření skupiny dostupnosti

Vytvořte AG. Nastavte CLUSTER_TYPE = NONE. Kromě toho nastavte každou repliku pomocí FAILOVER_MODE = MANUAL. Klientské aplikace, na kterých běží analytické úlohy nebo úlohy generování sestav, se můžou přímo připojit k sekundárním databázím. Můžete také vytvořit seznam směrování jen pro čtení. Připojení k primární replice přesměrovává požadavky na čtení střídavě na každou ze sekundárních replik podle seznamu směrování.

Následující skript Transact-SQL vytvoří skupinu dostupnosti (AG) s názvem ag1. Skript nakonfiguruje repliky AG pomocí SEEDING_MODE = AUTOMATIC. Toto nastavení způsobí, že SQL Server po přidání do skupiny dostupnosti (AG) automaticky vytvoří databázi na každém sekundárním serveru. Aktualizujte následující skript pro vaše prostředí. Nahraďte hodnoty <node1> a <node2> názvy instancí SYSTÉMU SQL Server, které hostují repliky. Hodnotu <5022> nahraďte portem, který jste nastavili pro koncový bod. Na primární replice SQL Serveru spusťte následující skript Transact-SQL:

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

ALTER AVAILABILITY GROUP [ag1] GRANT CREATE ANY DATABASE;

Připojení sekundárních instancí SQL Serveru ke skupině dostupnosti

Následující skript Transact-SQL připojí server ke skupině dostupnosti s názvem ag1. Aktualizujte skript pro vaše prostředí. Na každé sekundární replice SQL Serveru spusťte následující skript Transact-SQL pro připojení skupiny dostupnosti:

ALTER AVAILABILITY GROUP [ag1] JOIN WITH (CLUSTER_TYPE = NONE);

ALTER AVAILABILITY GROUP [ag1] GRANT CREATE ANY DATABASE;

Přidání databáze do skupiny dostupnosti

Ujistěte se, že databáze, kterou přidáte do skupiny dostupnosti, je v úplném modelu obnovení a má platnou zálohu protokolu. Pokud je vaše databáze testovací nebo nově vytvořená databáze, vytvořte zálohu databáze. Na primárním SQL Serveru spusťte následující skript Transact-SQL (T-SQL), který vytvoří a zálohuje databázi s názvem db1:

CREATE DATABASE [db1];
GO

ALTER DATABASE [db1]
    SET RECOVERY FULL;
GO

BACKUP DATABASE [db1]
    TO DISK = N'/var/opt/mssql/data/db1.bak';

Na primární replice SQL Serveru spusťte následující skript T-SQL, který přidá databázi s názvem db1 do skupiny dostupnosti s názvem ag1:

ALTER AVAILABILITY GROUP [ag1] ADD DATABASE [db1];

Ověřte, že je databáze vytvořená na sekundárních serverech.

Na každé sekundární replice SQL Serveru spusťte následující dotaz, abyste zjistili, jestli byla vytvořena db1 databáze a synchronizována:

SELECT *
FROM sys.databases
WHERE name = 'db1';
GO

SELECT DB_NAME(database_id) AS 'database',
       synchronization_state_desc
FROM sys.dm_hadr_database_replica_states;
GO

Tato dostupnostní skupina není konfigurací vysoké dostupnosti. Pokud potřebujete vysokou dostupnost, postupujte podle pokynů v tématu Konfigurace skupiny dostupnosti Always On ve službě SQL Server pro vysokou dostupnost na Linuxu. Konkrétně vytvořte AG pomocí CLUSTER_TYPE=WSFC (Windows) nebo CLUSTER_TYPE=EXTERNAL (Linux). Pak se můžete integrovat se správcem clusteru pomocí clusteringu Windows Serveru s podporou převzetí služeb při selhání ve Windows nebo Pacemakeru v Linuxu.

Připojení k sekundárním replikám jen pro čtení

Existují dva způsoby připojení k sekundárním replikám jen pro čtení. Aplikace se můžou připojit přímo k instanci SQL Serveru, která je hostitelem sekundární repliky, a dotazovat se na databáze. Mohou také používat směrování pouze pro čtení, které vyžaduje posluchač.

• Přesunutí úlohy, která je pouze ke čtení, na sekundární repliku skupiny dostupnosti Always On
• směrování pouze pro čtení

Převzetí služeb při selhání primární repliky ve skupině pro čtení s rozšířenou dostupností

Každá skupina dostupnosti má pouze jednu primární repliku. Primární replika umožňuje čtení a zápisy. Pokud chcete změnit primární repliku, můžete provést přepnutí. V typické skupině dostupnosti správce clusteru automatizuje proces převzetí služeb při selhání. Ve skupině dostupnosti s typem clusteru NONE je proces převzetí služeb při selhání ruční.

Existují dva způsoby přepnutí při selhání primární repliky ve skupině dostupnosti s typem clusteru „NONE“:

• Ruční převzetí řízení při selhání bez ztráty dat
• Vynucené ruční převzetí služeb při selhání se ztrátou dat

Ruční převzetí služeb v případě selhání bez ztráty dat

Tuto metodu použijte, pokud je primární replika dostupná, ale potřebujete dočasně nebo trvale změnit, která instance je hostitelem primární repliky. Abyste se vyhnuli možné ztrátě dat, ujistěte se, že cílová sekundární replika je před ručním převzetím služeb při selhání aktualizovaná.

Ruční převzetí služeb při selhání bez ztráty dat:

1. Nastavte aktuální repliku jako primární a cílovou jako sekundární repliku SYNCHRONOUS_COMMIT.

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

2. Pokud chcete zjistit, že aktivní transakce jsou potvrzeny do primární repliky a alespoň jedné synchronní sekundární repliky, spusťte následující dotaz:

   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; 
   

   Sekundární replika se synchronizuje, když je synchronization_state_descSYNCHRONIZED.

3. Aktualizujte REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT na 1.

   Následující skript nastaví REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT na 1 ve skupině dostupnosti s názvem ag1. Před spuštěním následujícího skriptu nahraďte ag1 názvem vaší skupiny dostupnosti:

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

   Toto nastavení zajišťuje, že každá aktivní transakce je potvrzena primární replikou a alespoň jednou synchronní sekundární replikou.

   Poznámka

   Toto nastavení není specifické pro převzetí služeb při selhání a mělo by se nastavit na základě požadavků prostředí.

4. Nastavte primární repliku a sekundární repliky, které se neúčastní převzetí služeb při selhání, offline k přípravě na změnu role.

   ALTER AVAILABILITY GROUP [AGRScale] OFFLINE
   

5. Zvýšení úrovně cílové sekundární repliky na primární.

   ALTER AVAILABILITY GROUP AGRScale FORCE_FAILOVER_ALLOW_DATA_LOSS; 
   

6. Aktualizujte roli starých primárních a dalších sekundárních serverů na SECONDARY, spusťte následující příkaz v instanci SYSTÉMU SQL Server, která je hostitelem staré primární repliky:

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

   Poznámka

   Pokud chcete odstranit skupinu dostupnosti, použijte DROP AVAILABILITY GROUP. Pro skupinu dostupnosti vytvořenou s typem clusteru NONE nebo EXTERNAL spusťte příkaz na všech replikách, které jsou součástí skupiny dostupnosti.

7. Pokračujte v přesunu dat, spusťte následující příkaz pro každou databázi ve skupině dostupnosti v instanci SQL Serveru, která je hostitelem primární repliky:

   ALTER DATABASE [db1]
        SET HADR RESUME
   

8. Znovu vytvořte libovolný naslouchací proces, který jste vytvořili pro účely škálování pro čtení a který nespravuje správce clusteru. Pokud původní naslouchací proces odkazuje na starý primární, zrušte ho a vytvořte ho znovu tak, aby odkazoval na nový primární.

Vynucený ruční přechod při selhání se ztrátou dat

Pokud primární replika není dostupná a nelze ji okamžitě obnovit, je nutné vynutit převedení provozu na sekundární repliku, přestože to povede ke ztrátě dat. Pokud se ale původní primární replika po selhání obnoví, opět převezme primární roli. Pokud se chcete vyhnout tomu, aby každá replika byla v jiném stavu, odeberte původní primární repliku ze skupiny dostupnosti po vynuceném převzetí se ztrátou dat. Jakmile se původní primární server vrátí zpátky do online režimu, odeberte skupinu dostupnosti úplně z ní.

Pokud chcete vynutit ruční převod se ztrátou dat z primární repliky N1 na sekundární repliku N2, postupujte takto:

1. Na sekundární replice (N2) zahajte vynucené převzetí úlohy při selhání.

   ALTER AVAILABILITY GROUP [AGRScale] FORCE_FAILOVER_ALLOW_DATA_LOSS;
   

2. Na nové primární replice (N2) odeberte původní primární repliku (N1):

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

3. Ověřte, že veškerý provoz aplikace směřuje na naslouchací stanici nebo na novou primární repliku.

4. Pokud je původní primární server (N1) online, okamžitě přepněte skupinu dostupnosti AGRScale do režimu offline na původní primární (N1):

   ALTER AVAILABILITY GROUP [AGRScale] OFFLINE
   

5. Pokud existují data nebo nesynchronizované změny, zachovejte tato data prostřednictvím záloh nebo jiných možností replikace dat, které vyhovují vašim obchodním potřebám.

6. Potom odeberte skupinu dostupnosti z původní primární skupiny (N1):

   DROP AVAILABILITY GROUP [AGRScale];
   

7. Odstraňte databázi skupiny dostupnosti na původní primární repliku (N1):

   USE [master]
   GO
   DROP DATABASE [AGDBRScale]
   GO
   

8. (Volitelné) V případě potřeby teď můžete přidat N1 zpět jako novou sekundární repliku do skupiny dostupnosti AGRScale.

Související obsah

• distribuované skupiny dostupnosti
• Co je skupina dostupnosti AlwaysOn?
• Provedení vynuceného ručního převzetí služeb při selhání skupiny dostupnosti Always On (SQL Server)