Sdílet prostřednictvím

Konfigurace škálování pro čtení pro skupinu dostupnosti AlwaysOn

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 poskytuje jen pro čtení. Neposkytuje vysokou dostupnost.

Poznámka:

Skupina dostupnosti může CLUSTER_TYPE = NONE zahrnovat repliky hostované na různých platformách operačního systému. 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á rutiny z modulu sqlserver, který je publikovaný v galerii 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

Povolení relace 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 škálování pro čtení, ověřovat přes koncový bod. 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 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 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 a c:\Program Files\Microsoft SQL Server\MSSQL14.MSSQLSERVER\MSSQL\DATA\dbm_certificate.cer privátní 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ření koncových bodů 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 v bráně firewall musí být otevřený pro port naslouchacího procesu.

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řesměrovávat požadavky na čtení na každou ze sekundárních replik ze seznamu směrování způsobem kruhového dotazování.

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řipojení k sekundárním repliká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 můžou také používat směrování jen pro čtení, které vyžaduje naslouchací proces. Pokud nasazujete scénář škálování pro čtení bez správce clusteru, můžete stále vytvořit naslouchací proces, který odkazuje na IP adresu aktuální primární repliky a stejný port jako SQL Server naslouchá. 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 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řevzetí služeb 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í.

Ruční 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 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 se každá aktivní transakce potvrdí do primární repliky a alespoň jedné synchronní sekundární repliky.

    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í offline převzetí služeb při selhání, aby se připravily 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ého primárního a jiného sekundárního serveru tak, aby SECONDARYna instanci SYSTÉMU SQL Server, která je hostitelem staré primární repliky, 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 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 původní primární server, přetáhněte ho a vytvořte ho tak, aby odkazovat na nový primární server.

Vynucené ruční převzetí služeb při selhání 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í, převezme primární roli. Pokud se chcete vyhnout tomu, aby každá replika byla v jiném stavu, odeberte původní primární server 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í (N1):

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

  3. Ověřte, že veškerý provoz aplikace odkazuje na naslouchací proces 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 k připojení používáte naslouchací proces, budete muset po provedení převzetí služeb při selhání znovu vytvořit naslouchací proces.

Další kroky

  • Last updated on