Převzetí služeb při selhání skupiny dostupnosti AlwaysOn v Linuxu

Platí pro:SQL Server v Linuxu

V rámci skupiny dostupnosti (AG) jsou primární a sekundární role replik dostupnosti obvykle vzájemně zaměnitelné v procesu označovaném jako tzv. převzetí služeb při selhání. Existují tři formy převzetí služeb při selhání: automatické převzetí služeb při selhání (bez ztráty dat), plánované ruční převzetí služeb při selhání (bez ztráty dat) a vynucené ruční převzetí služeb při selhání (s možnou ztrátou dat), obvykle označované jako vynucené převzetí služeb při selhání. Automatické a plánované ruční převzetí služeb při selhání zachovává všechna vaše data. AG se přepne v případě selhání na úrovni repliky. To znamená, že skupina dostupnosti převezme služby při selhání na jednu ze svých sekundárních replik (aktuální cíl převzetí služeb při selhání).

Základní informace o převzetí služeb při selhání najdete v tématu Převzetí služeb při selhání a jejich režimy (skupiny dostupnosti Always On).

Ruční převzetí při selhání

K přepnutí při selhání skupiny dostupnosti (AG) spravované externím správcem clusteru použijte nástroje pro správu clusteru. Pokud například řešení používá Pacemaker ke správě clusteru s Linuxem, použijte pcs k ručnímu převzetí služeb při selhání na Red Hat Enterprise Linux (RHEL) nebo Ubuntu. Na SUSE Linux Enterprise Serveru (SLES) použijte crm. (Počínaje SQL Serverem 2025 (17.x) se nepodporuje SUSE Linux Enterprise Server (SLES).)

Důležitý

Při běžném provozu nepoužívejte přepnutí při chybě s Transact-SQL nebo nástroje pro správu, jako je SSMS nebo PowerShell u SQL Serveru. Při CLUSTER_TYPE = EXTERNALje jediná přijatelná hodnota pro FAILOVER_MODEEXTERNAL. S těmito nastaveními provádí správce externího clusteru všechny akce ručního nebo automatického převzetí služeb při selhání. Pokyny k vynucení převzetí služeb při selhání s potenciální ztrátou dat najdete v tématu Vynucení převzetí služeb při selhání.

Kroky ručního převzetí provozu při selhání

Pro přepnutí při selhání musí být sekundární replika, která se stane primární replikou, synchronní. Pokud je sekundární replika asynchronní, změňte režim dostupnosti.

Ruční převzetí při selhání ve dvou krocích

Nejprve ruční převzetí služeb při selhání přesunutím prostředku skupiny dostupnosti z uzlu clusteru, který vlastní prostředky do nového uzlu.

Cluster přepne prostředek skupiny dostupnosti (AG) a přidá omezení umístění. Toto omezení nakonfiguruje prostředek tak, aby běžel na novém uzlu. Aby bylo možné v budoucnu úspěšně provést přechod, odeberte toto omezení.
Za druhé, odebrání omezení umístění.

Krok 1. Ruční převzetí služeb při selhání přesunutím prostředku skupiny dostupnosti

Pokud chcete ručně přepnout prostředek AG s názvem ag_cluster na uzel clusteru s názvem nodeName2 na uzlu, spusťte příslušný příkaz pro vaši distribuci.

příklad RHEL/Ubuntu

sudo pcs resource move ag_cluster-master nodeName2 --master --lifetime=30S

Příklad SLES

crm resource migrate ag_cluster nodeName2 --lifetime=30S

Pokud použijete možnost --lifetime, omezení umístění vytvořené k přesunutí prostředku je dočasné a platí 30 sekund v předchozím příkladu.

Dočasné omezení se nevymaže automaticky a může se zobrazit v seznamu omezení, ale jako omezení s vypršenou platností. Omezení s vypršenou platností neovlivňují chování clusteru pacemakeru při selhání. Pokud při přesouvání prostředku nepoužíváte možnost --lifetime, měli byste odebrat omezení umístění, které se automaticky přidá, které je uvedeno v následující části.

Krok 2. Odstranit místní omezení

Během ručního převzetí služeb při selhání příkaz pcsmove nebo příkaz crmmigrate přidá omezení umístění pro prostředek, který bude umístěn na novém cílovém uzlu. Pokud chcete zobrazit nové omezení, spusťte po ručním přesunutí prostředku následující příkaz:

příklad RHEL/Ubuntu
```
sudo pcs constraint list --full
```
Příklad SLES
```
crm config show
```
Toto je příklad omezení, které se vytvoří kvůli ručnímu přepnutí.

Enabled on: Node1 (score:INFINITY) (role: Master) (id:cli-prefer-ag_cluster-master)

Poznámka

Název prostředku skupiny dostupnosti v clusterech pacemakeru v systémech Red Hat Enterprise Linux 8.x a Ubuntu 18.04 se může podobat ag_cluster-clone, protože se vyvíjí terminologie týkající se prostředků, které používají promotovatelný klon.
příklad RHEL/Ubuntu

V následujícím příkazu cli-prefer-ag_cluster-master je ID omezení, které je potřeba odebrat. sudo pcs constraint list --full vrátí toto ID.
```
sudo pcs resource clear ag_cluster-master
```
Nebo
```
sudo pcs constraint remove cli-prefer-ag_cluster-master
```
Alternativně můžete provést přesunutí i vymazání automaticky generovaných omezení na jednom řádku následujícím způsobem. Následující příklad používá terminologii klon podle Red Hat Enterprise Linuxu 8.x.
```
sudo pcs resource move ag_cluster-clone --master nodeName2 && sleep 30 && sudo pcs resource clear ag_cluster-clone
```
Příklad SLES

V následujícím příkazu cli-prefer-ms-ag_cluster je ID omezení. crm config show vrátí toto ID.
```
crm configure
delete cli-prefer-ms-ag_cluster
commit
```

Poznámka

Automatické převzetí služeb při selhání nepřidá omezení umístění, takže není potřeba žádné vyčištění.

Další informace:

Red Hat – Správa prostředků clusteru
Pacemaker – Ruční přesun prostředků
Průvodce správou SLES – Správa prostředků clusteru

Vynucení převzetí služeb při selhání

Vynucené převzetí služeb při selhání je určeno výhradně pro zotavení po havárii. V takovém případě nemůžete přepnout na záložní systém pomocí nástrojů pro správu clusteru, protože primární datové centrum je mimo provoz. Pokud vynutíte převzetí při selhání na nesynchronizovanou sekundární repliku, může dojít k určité ztrátě dat. Vynutit převzetí služeb při selhání pouze v případě, že službu musíte okamžitě obnovit do skupiny dostupnosti a jste ochotni riskovat ztrátu dat.

Pokud nemůžete použít nástroje správy clusteru pro interakci s clusterem (například pokud cluster nereaguje kvůli pohromě v primárním datacentru), možná budete muset vynutit přepnutí, abyste obešli externího správce clusteru. Tento postup se nedoporučuje pro běžné operace, protože riskuje ztrátu dat. Použijte ho, když se nepodaří spustit akci převzetí služeb při selhání v nástrojích pro správu clusteru. Tento postup je funkčně podobný provedení vynuceného ručního převzetí služeb při selhání ve skupině dostupnosti ve Windows.

Tento proces vynucení převzetí služeb je specifický pro SQL Server na Linuxu.

Ověřte, že cluster už nespravuje prostředek AG.
- Nastavte prostředek na nespravovaný režim na cílovém uzlu clusteru. Tento příkaz signalizuje agenta prostředků, aby zastavil monitorování a správu prostředků. Například:
```
sudo pcs resource unmanage <resourceName>
```
- Pokud pokus o nastavení režimu prostředku na nespravovaný režim selže, odstraňte prostředek. Například:
```
sudo pcs resource delete <resourceName>
```
  Poznámka
  
  Když prostředek odstraníte, odstraní se také všechna přidružená omezení.
Na instanci systému SQL Server, která je hostitelem sekundární repliky, nastavte proměnnou relace kontextu external_cluster.
```
EXECUTE sp_set_session_context
    @key = N'external_cluster',
    @value = N'yes';
```
Přepněte skupinu dostupnosti pomocí Transact-SQL. V následujícím příkladu nahraďte <MyAg> názvem vaší AG. Připojte se k instanci SQL Serveru, která je hostitelem cílové sekundární repliky, a spusťte následující příkaz:
```
ALTER AVAILABILITY GROUP <MyAg> FORCE_FAILOVER_ALLOW_DATA_LOSS;
```
Po vynuceném převzetí služeb při selhání převeďte skupinu dostupnosti do stavu v pořádku před restartováním monitorování a správy prostředků clusteru nebo opětovným vytvořením prostředku skupiny dostupnosti. Zkontrolujte klíčové úkoly po vynuceném převzetí služeb.
Buď restartujte monitorování a správu prostředků clusteru:

Pokud chcete restartovat monitorování a správu prostředků clusteru, spusťte následující příkaz:
```
sudo pcs resource manage <resourceName>
sudo pcs resource cleanup <resourceName>
```
Pokud jste odstranili prostředek clusteru, vytvořte ho znovu. Pokud chcete znovu vytvořit prostředek clusteru, postupujte podle pokynů v části Vytvoření prostředku skupiny dostupnosti.

Důležitý

Pro postupy zotavení po havárii nepoužívejte předchozí kroky, protože riskují ztrátu dat. Místo toho změňte asynchronní repliku na synchronní a pokyny pro normální ruční převzetí služeb při selhání.

Monitorování na úrovni databáze a spuštění převzetí služeb při selhání

Pro CLUSTER_TYPE=EXTERNALse sémantika triggeru převzetí služeb při selhání liší v porovnání s WSFC. Pokud je skupina dostupnosti na instanci SQL Serveru ve WSFC, přechod z ONLINE stavu databáze způsobí, že stav skupiny dostupnosti oznámí chybu. Správce clusteru v reakci na to aktivuje akci převzetí služeb při selhání. V Linuxu nemůže instance SQL Serveru komunikovat s clusterem. Monitorování stavu databáze se provádí mimo. Pokud uživatel zvolil monitorování a převzetí služeb při selhání na úrovni databáze (nastavením možnosti DB_FAILOVER=ON při vytváření skupiny dostupnosti), cluster pokaždé, když spustí monitorovací akci, zkontroluje, zda je stav databáze ONLINE. Cluster se dotazuje na stav v sys.databases. Pro jakýkoli stav, který se liší od ONLINE, aktivuje převzetí služeb při selhání automaticky (pokud jsou splněny podmínky automatického převzetí služeb při selhání). Skutečný čas převzetí služeb při selhání závisí na četnosti akce monitorování a stavu databáze, který se aktualizuje v sys.databases.

Automatické přepnutí při selhání vyžaduje alespoň jednu synchronní repliku.

Přispět do dokumentace SQL

Věděli jste, že obsah SQL můžete upravovat sami? Pokud to uděláte, nejen že vám pomůžete vylepšit naši dokumentaci, ale také jste získali kredit jako přispěvatel na stránku.

Další informace naleznete v Upravit dokumentaci Microsoft Learn.

Váš názor

Byla tato stránka užitečná?

Last updated on 2026-01-02