Konfigurovat škálování pro čtení pro skupinu dostupnosti Always On

platí pro:SQL Server

Skupinu dostupnosti AlwaysOn SQL Serveru můžete nakonfigurovat pro úlohy škálování čtení ve Windows. Pro skupiny dostupnosti existují dva typy architektury:

  • Architektura pro vysokou dostupnost, která používá správce clusteru k zajištění lepší kontinuity podnikových procesů a která může zahrnovat čitelné sekundární repliky. Pokud chcete vytvořit tuto architekturu s vysokou dostupností, přečtěte si téma Vytvoření a konfigurace skupin dostupnosti ve Windows.
  • Architektura, která podporuje jen úlohy na úrovni čtení.

Tento článek vysvětluje, jak vytvořit skupinu dostupnosti bez správce clusteru pro úlohy škálování čtení. Tato architektura umožňuje pouze škálování pro čtení. Neposkytuje vysokou dostupnost.

Poznámka:

Skupina dostupnosti s CLUSTER_TYPE = NONE může zahrnovat repliky hostované na různých platformách operačních systémů. Nemůže podporovat vysokou dostupnost. Informace o operačním systému Linux najdete v tématu Konfigurace skupiny dostupnosti SQL Serveru pro škálování čtení v Linuxu.

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. Podrobnosti najdete v průvodci instalací SQL Serveru .

Povolení skupin dostupnosti AlwaysOn a restartování serveru mssql

Poznámka:

Následující příkaz využívá cmdlety z modulu SqlServer, který je publikován v Galerie prostředí PowerShell. Tento modul můžete nainstalovat pomocí Install-Module příkazu.

Povolte skupiny dostupnosti AlwaysOn na každé replice, která je hostitelem instance SQL Serveru. Potom restartujte službu SQL Serveru. Spuštěním následujícího příkazu povolte a restartujte služby SQL Serveru:

Enable-SqlAlwaysOn -ServerInstance <server\instance> -Force

Povolte relaci událostí AlwaysOn_health

Pokud chcete pomoct s diagnostikou původní příčiny při řešení potíží se skupinou dostupnosti, můžete volitelně povolit relaci rozšířených událostí skupin dostupnosti AlwaysOn (XEvents). Uděláte to tak, že na každé instanci SQL Serveru spustíte následující příkaz:

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

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

Ověřování koncového bodu zrcadlení databáze

Aby synchronizace fungovala správně, musí se repliky, které jsou součástí skupiny dostupnosti pro horizontální škálování čtení, ověřovat prostřednictvím koncového bodu. V dalších částech jsou popsané dva hlavní scénáře, které můžete pro takové ověřování použít.

Účet služby

V prostředí služby služba Active Directory, ve kterém jsou všechny sekundární repliky připojené ke stejné doméně, se SQL Server může ověřit pomocí účtu služby. Pro každý účet služby musíte explicitně vytvořit přihlašovací jméno pro každou instanci SQL Serveru:

CREATE LOGIN [<domain>\service account] FROM WINDOWS;

Ověřování přihlášení SQL

V prostředích, kde sekundární repliky nemusí být připojené k doméně služby služba Active Directory, musíte využít ověřování SQL. Následující skript Transact-SQL vytvoří přihlašovací jméno dbm_login a uživatele s názvem dbm_user. Nahraďte <password> platným heslem. Pokud chcete vytvořit uživatele koncového bodu zrcadlení databáze, spusťte na všech instancích SQL Serveru následující příkaz.

CREATE LOGIN dbm_login WITH PASSWORD = '<password>';
CREATE USER dbm_user FOR LOGIN dbm_login;

Ověření certifikátu

Pokud využíváte sekundární repliku, která vyžaduje ověřování pomocí ověřování SQL, použijte certifikát pro ověřování 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. Spusťte skript v primární instanci SQL Serveru a vytvořte certifikát:

CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<dmk-password>';
CREATE CERTIFICATE dbm_certificate WITH SUBJECT = 'dbm';

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

V tomto okamžiku má primární replika SQL Serveru certifikát na adrese c:\Program Files\Microsoft SQL Server\MSSQL14.MSSQLSERVER\MSSQL\DATA\dbm_certificate.cer a soukromý klíč na adrese c:\Program Files\Microsoft SQL Server\MSSQL14.MSSQLSERVER\MSSQL\DATA\dbm_certificate.pvk. Zkopírujte tyto dva soubory do stejného umístění na všech serverech, které budou hostovat repliky dostupnosti.

Na každé sekundární replice se ujistěte, že účet služby pro instanci SQL Serveru má oprávnění pro přístup k certifikátu.

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. Příkaz také autorizuje uživatelům přístup k certifikátu. 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 replikách:

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

CREATE CERTIFICATE dbm_certificate
    AUTHORIZATION dbm_user
    FROM FILE = 'C:\Program Files\Microsoft SQL Server\MSSQL14.MSSQLSERVER\MSSQL\DATA\dbm_certificate.cer'
    WITH PRIVATE KEY (
        FILE = 'c:\Program Files\Microsoft SQL Server\MSSQL14.MSSQLSERVER\MSSQL\DATA\dbm_certificate.pvk',
        DECRYPTION BY PASSWORD = '<private-key-password>'
    );

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 replik 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í pojmenovaný Hadr_endpoint pro skupinu dostupnosti. Spustí koncový bod a udělí oprávnění k připojení k účtu služby nebo přihlášení SQL, které jste vytvořili v předchozím kroku. 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;
GRANT CONNECT ON ENDPOINT::[Hadr_endpoint] TO [<service account or user>];

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

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

Vytvoření skupiny dostupnosti

Vytvořte skupinu dostupnosti. Nastavte CLUSTER_TYPE = NONE. Kromě toho nastavte každou repliku pomocí FAILOVER_MODE = NONE. Klientské aplikace, které spouštějí úlohy analýzy nebo 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řeposílají požadavky na připojení pro čtení na jednotlivé sekundární repliky ze směrovacího seznamu cyklicky.

Následující Transact-SQL skript vytvoří skupinu dostupnosti s názvem ag1. Skript nakonfiguruje repliky skupiny dostupnosti pomocí SEEDING_MODE = AUTOMATIC. Toto nastavení způsobí, že SQL Server po přidání do skupiny dostupnosti automaticky vytvoří databázi na každém sekundárním serveru.

Aktualizujte následující skript pro vaše prostředí. <node1> Nahraďte hodnoty <node2> názvy instancí SYSTÉMU SQL Server, které hostují repliky. <5022> Hodnotu 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í Transact-SQL skript připojí server ke skupině dostupnosti s názvem ag1. Aktualizujte skript pro vaše prostředí. Pokud se chcete připojit ke skupině dostupnosti, spusťte na každé sekundární replice SQL Serveru následující skript Transact-SQL:

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 databáze testovací nebo nově vytvořená databáze, vytvořte zálohu databáze. Pokud chcete vytvořit a zálohovat databázi s názvem db1, spusťte následující Transact-SQL skript v primární instanci SQL Serveru:

CREATE DATABASE [db1];
ALTER DATABASE [db1] SET RECOVERY FULL;
BACKUP DATABASE [db1]
   TO DISK = N'c:\Program Files\Microsoft SQL Server\MSSQL14.MSSQLSERVER\MSSQL\Backup\db1.bak';

Pokud chcete přidat databázi volanou db1 do volané ag1skupiny dostupnosti, spusťte na primární replice SQL Serveru následující skript Transact-SQL:

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

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

Pokud chcete zjistit, jestli db1 byla databáze vytvořená a synchronizovaná, spusťte na každé sekundární replice SQL Serveru následující dotaz:

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;

Tato skupina dostupnosti není konfigurací vysoké dostupnosti. Pokud potřebujete vysokou dostupnost, postupujte podle pokynů v tématu Konfigurace skupiny dostupnosti AlwaysOn pro SQL Server v Linuxu nebo vytvoření a konfigurace skupin dostupnosti ve Windows.

Připojit se k sekundárním replikám určeným jen pro čtení

K sekundárním replikám jen pro čtení se můžete připojit dvěma způsoby:

  • Aplikace se můžou připojit přímo k instanci SQL Serveru, která je hostitelem sekundární repliky, a dotazovat se na databáze. Další informace naleznete v tématu čitelné sekundární repliky.
  • Aplikace mohou také používat směrování pouze pro čtení, což vyžaduje listener. Pokud nasazujete scénář škálování pro čtení bez správce clusteru, můžete stále vytvořit listener, který ukazuje na IP adresu aktuální primární repliky a na stejný port, na kterém naslouchá SQL Server. Po převzetí služeb při selhání budete muset znovu vytvořit naslouchací proces, který bude odkazovat na novou primární IP adresu. Další informace najdete v tématu Směrování jen pro čtení.

Převzetí služeb při selhání primární repliky ve skupině dostupnosti na úrovni čtení

Každá skupina dostupnosti má pouze jednu primární repliku. Primární replika umožňuje čtení a zápisy. Pokud chcete změnit, která replika je primární, můžete převzít služby při selhání. 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, jak provést převzetí služeb při selhání primární repliky ve skupině dostupnosti s typem clusteru NONE:

  • Ruční převzetí služeb 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řepnutí při 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 potenciální ztrátě dat, před vydáním ručního převzetí služeb při selhání se ujistěte, že je cílová sekundární replika aktuální.

Chcete-li ručně provést převzetí služeb při selhání bez ztráty dat:

  1. Nastavit aktuální primární a cílovou 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, pokud synchronization_state_desc je SYNCHRONIZED.

  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 v primární replice a alespoň jedné synchronní sekundární replice.

    Poznámka:

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

  4. Přepněte primární repliku a sekundární repliky, které se neúčastní převzetí služeb při selhání, do režimu offline v rámci přípravy na změnu role:

    ALTER AVAILABILITY GROUP [AGRScale] OFFLINE

  5. Povýšit cílovou sekundární repliku na primární.

    ALTER AVAILABILITY GROUP AGRScale FORCE_FAILOVER_ALLOW_DATA_LOSS;

  6. Aktualizujte roli starého primárního serveru a ostatních sekundárních replik na SECONDARY a na instanci serveru SQL Server, na které je hostována stará primární replika, spusťte následující příkaz:

    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 jakýkoli listener, který jste vytvořili pro škálování čtení a který není spravován správcem clusteru. Pokud původní listener odkazuje na starý primární server, odstraňte jej a znovu jej vytvořte tak, aby odkazoval na nový primární server.

Vynucené ruční převzetí služeb při výpadku se ztrátou dat

Pokud primární replika není dostupná a nejde ji okamžitě obnovit, musíte vynutit převzetí služeb při selhání sekundární repliky se ztrátou dat. Pokud se ale původní primární replika po převzetí služeb při selhání obnoví, ujme se primární role. Pokud se chcete vyhnout tomu, aby každá replika byla v odlišném stavu, odeberte původní primární repliku ze skupiny dostupnosti po vynuceném převzetí služeb při selhání 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řevzetí služeb při selhání 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í služeb 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 naslouchač a/nebo 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.

Upozorňujeme, že pokud se k připojení používá listener, bude nutné jej po provedení failoveru znovu vytvořit.

Další kroky

  • Last updated on