Automatické upgrady PostgreSQL clusterů v cloudu s téměř nulovým výpadkem (část II)

Začal jsem psát o nástroji (pglupgrade), který jsem vyvinul k provádění automatických upgradů clusterů PostgreSQL s téměř nulovými prostoji. V tomto příspěvku budu mluvit o nástroji a diskutovat o jeho konstrukčních detailech.

První díl série si můžete prohlédnout zde: Automatické upgrady clusterů PostgreSQL v cloudu s téměř nulovým výpadkem (část I).

Nástroj je napsán v Ansible. Mám předchozí zkušenosti s prací s Ansible a v současné době s ní pracuji také ve 2ndQuadrantu, a proto to pro mě byla pohodlná volba. Jak již bylo řečeno, můžete implementovat logiku upgradu s minimálními prostoji, která bude vysvětlena později v tomto příspěvku, pomocí vašeho oblíbeného automatizačního nástroje.

Další čtení:Příspěvky na blogu Ansible Loves PostgreSQL , PostgreSQL Planet v Ansible Galaxy a  prezentace Správa PostgreSQL pomocí Ansible.

Pglupgrade Playbook

V Ansible, příručky jsou hlavní skripty, které jsou vyvinuty k automatizaci procesů, jako je zřizování cloudových instancí a upgradování databázových clusterů. Příručky mohou obsahovat jednu nebo více her . Příručky mohou také obsahovat proměnné , role a obslužné nástroje pokud je definováno.

Nástroj se skládá ze dvou hlavních příruček. První příručka je provision.yml který automatizuje proces vytváření počítačů se systémem Linux v cloudu podle specifikací (Toto je volitelná příručka napsaná pouze pro poskytování cloudových instancí a přímo nesouvisí s upgradem ). Druhá (a hlavní) příručka je pglupgrade.yml který automatizuje proces upgradu databázových clusterů.

Příručka Pglupgrade má osm přehrání pro organizaci upgradu. Pro každou hru použijte jeden konfigurační soubor (config.yml ), provádět některé úlohy na hostitelích nebo skupinách hostitelů, které jsou definovány v hostitelském souboru inventáře (host.ini ).

Soubor inventáře

Soubor inventáře umožňuje Ansible vědět, ke kterým serverům se potřebuje připojit pomocí SSH, jaké informace o připojení vyžaduje a volitelně, které proměnné jsou k těmto serverům přidruženy. Níže můžete vidět ukázkový soubor inventáře, který byl použit k provádění automatických upgradů clusteru pro jednu z případových studií navržených pro tento nástroj. Tyto případové studie probereme v nadcházejících příspěvcích této série.

[staré-primární]54.171.211.188[nové-primární]54.246.183.100[staré-pohotovostní režimy]54.77.249.8154.154.49.180[nové-pohotovostní režimy:děti]staré-pohotovostní stavy]85 
Soubor inventáře (host.ini ) 
 

 Ukázkový soubor inventáře obsahuje pět hostitelů pod pěti hostitelskými skupinami které zahrnují old-primary , new-primary , old-standbys , new-standbys a pgbouncer . Server může patřit do více než jedné skupiny. Například old-standbys je skupina obsahující new-standbys skupina, což znamená hostitele, kteří jsou definováni pod old-standbys skupina (54.77.249.81 a 54.154.49.180) také patří do new-standbys skupina. Jinými slovy, new-standbys skupina je zděděna z (dětí) old-standbys skupina. Toho je dosaženo pomocí speciálního :children přípona.
 

 Jakmile bude soubor inventáře připraven, Ansible playbook lze spustit prostřednictvím ansible-playbook příkazem ukázáním na soubor inventáře (pokud se soubor inventáře nenachází ve výchozím umístění, jinak použije výchozí soubor inventáře), jak je znázorněno níže:
 
$ ansible-playbook -i hosts.ini pglupgrade.yml
 
Spuštění příručky Ansible 
 
Konfigurační soubor
 

 Pglupgrade playbook používá konfigurační soubor (config.yml ), který umožňuje uživatelům specifikovat hodnoty pro logické proměnné upgradu.
 

 Jak je uvedeno níže, config.yml ukládá hlavně proměnné specifické pro PostgreSQL, které jsou nutné k nastavení clusteru PostgreSQL, jako je postgres_old_datadir a postgres_new_datadir uložit cestu k datovému adresáři PostgreSQL pro starou a novou verzi PostgreSQL; postgres_new_confdir k uložení cesty konfiguračního adresáře PostgreSQL pro novou verzi PostgreSQL; postgres_old_dsn a postgres_new_dsn pro uložení připojovacího řetězce pro pglupgrade_user abyste se mohli připojit k pglupgrade_database nového a starého primárního serveru. Samotný připojovací řetězec se skládá z konfigurovatelných proměnných, takže uživatel (pglupgrade_user ) a databáze (pglupgrade_database ) informace lze změnit pro různé případy použití.
 
ansible_user:adminpglupgrade_user:pglupgradepglupgrade_pass:pglupgrade123pglupgrade_database:postgresreplica_user:postgresreplica_pass:""pgbouncer_user:pgbouncerpostgres_old_version:9.5postgres_new_version:9.6subscription_name:upgradereplication_set:upgradeinitial_standbys:1postgres_old_dsn:"dbname={{pglupgrade_database}} host={{groups['old- primární'][0]}} uživatel {{pglupgrade_user}}"postgres_new_dsn:"dbname={{pglupgrade_database}} hostitel={{groups['new-primary'][0]}} uživatel={{pglupgrade_user}}" postgres_old_datadir:"/var/lib/postgresql/{{postgres_old_version}}/main" postgres_new_datadir:"/var/lib/postgresql/{{postgres_new_version}}/main"postgres_new_confdir:"/etc/postgresql/{{postgres_new_version}}/ hlavní"
 
Konfigurační soubor (config.yml ) 
 

 Jako klíčový krok pro jakýkoli upgrade lze zadat informace o verzi PostgreSQL pro aktuální verzi (postgres_old_version ) a verzi, která bude upgradována na (postgres_new_version ). Na rozdíl od fyzické replikace, kde je replikace kopií systému na úrovni bajtů/bloků, logická replikace umožňuje selektivní replikaci kde replikace může zkopírovat logická data, včetně specifikovaných databází a tabulek v těchto databázích. Z tohoto důvodu config.yml umožňuje konfigurovat, která databáze se má replikovat pomocí pglupgrade_database variabilní. Také uživatel logické replikace musí mít oprávnění k replikaci, proto pglupgrade_user proměnná by měla být specifikována v konfiguračním souboru. Existují další proměnné, které souvisejí s pracovními vnitřnostmi pglogical, jako je subscription_name a replication_set které se používají v pglogické roli.
 
Návrh vysoké dostupnosti nástroje Pglupgrade
 

 Nástroj Pglupgrade je navržen tak, aby uživateli poskytoval flexibilitu z hlediska vlastností vysoké dostupnosti (HA) pro různé systémové požadavky. initial_standbys proměnná (viz config.yml ) je klíčem pro určení vlastností HA clusteru během operace upgradu.
 

 Například pokud initial_standbys je nastavena na 1 (lze nastavit na libovolné číslo, které umožňuje kapacita clusteru), to znamená, že v upgradovaném clusteru bude spolu s hlavním serverem vytvořen 1 pohotovostní režim před zahájením replikace. Jinými slovy, pokud máte 4 servery a nastavíte initial_standbys na 1, budete mít v upgradované nové verzi 1 primární a 1 pohotovostní server a ve staré verzi také 1 primární a 1 záložní server.
 

 Tato možnost umožňuje opětovné použití stávajících serverů, zatímco upgrade stále probíhá. V příkladu 4 serverů lze starý primární a záložní server po dokončení replikace přebudovat na 2 nové záložní servery.
 

 Když je initial_standbys je nastavena na 0, v novém clusteru nebudou před zahájením replikace vytvořeny žádné počáteční rezervní servery.
 
Pokud je initial_standbys konfigurace zní zmateně, nebojte se. To bude lépe vysvětleno v příštím příspěvku na blogu, kde probereme dvě různé případové studie. 
 

 Konečně konfigurační soubor umožňuje specifikovat staré a nové skupiny serverů. To lze zajistit dvěma způsoby. Za prvé, pokud existuje klastr, IP adresy serverů (mohou to být kovové nebo virtuální servery ) je třeba zadat do hosts.ini zvážením požadovaných vlastností HA při operaci upgradu.
 

 Druhým způsobem je spuštění provision.yml playbook (takto jsem zřídil cloudové instance, ale můžete použít své vlastní zřizovací skripty nebo ručně zřídit instance ) k poskytování prázdných serverů Linux v cloudu (instance AWS EC2) a získávání IP adres serverů do hosts.ini soubor. V obou případech config.yml získá informace o hostiteli prostřednictvím hosts.ini soubor.
 
Pracovní postup procesu upgradu
 

 Po vysvětlení konfiguračního souboru (config.yml ), který používá pglupgrade playbook, můžeme vysvětlit pracovní postup procesu upgradu.
 

 
 
Pglupgrade Workflow 
 

 Jak je vidět z výše uvedeného diagramu, existuje šest skupin serverů, které jsou na začátku generovány na základě konfigurace (obě hosts.ini a config.yml ). new-primary a old-primary skupiny budou mít vždy jeden server, pgbouncer skupina může mít jeden nebo více serverů a všechny pohotovostní skupiny mohou mít nula nebo více serverů. Z hlediska implementace je celý proces rozdělen do osmi kroků. Každý krok odpovídá hře v playbooku pglupgrade, která provádí požadované úkoly na přiřazených hostitelských skupinách. Proces upgradu je vysvětlen v následujících hrách:
 
 
Sestavte hostitele na základě konfigurace: Přípravná hra, která staví vnitřní skupiny serverů na základě konfigurace. Výsledek této hry (v kombinaci s hosts.ini obsah) je šest skupin serverů (v diagramu pracovního postupu znázorněných různými barvami), které budou použity v následujících sedmi hrách.
 
Nastavit nový cluster s počátečním pohotovostním režimem: Nastaví prázdný cluster PostgreSQL s novým primárním a počátečním pohotovostním režimem (pokud jsou nějaké definovány). Zajišťuje, že nezůstanou žádné zbytky z instalací PostgreSQL z předchozího použití.
 
Upravte starou primární, aby podporovala logickou replikaci: Nainstaluje rozšíření pglogical. Poté nastaví vydavatele přidáním všech tabulek a sekvencí do replikace.
 
Replikovat do nového primárního: Nastaví předplatitele na novém hlavním serveru, který funguje jako spouštěč pro spuštění logické replikace. Tato hra dokončí replikaci existujících dat a začne dohánět, co se od zahájení replikace změnilo.
 
Přepněte pgbouncer (a aplikace) na nový primární: Když zpoždění replikace konverguje k nule, pozastaví pgbouncer, aby se aplikace postupně přepínala. Potom nasměruje konfiguraci pgbouncer na novou primární a počká, dokud se rozdíl replikace nedostane na nulu. Nakonec se pgbouncer obnoví a všechny čekající transakce se přenesou do nového primárního serveru a tam se zahájí zpracování. Počáteční pohotovostní režimy se již používají a odpovídají na požadavky na čtení.
 
Vyčistěte nastavení replikace mezi starou primární a novou primární: Ukončí spojení mezi starým a novým primárním serverem. Protože jsou všechny aplikace přesunuty na nový primární server a upgrade je dokončen, není již potřeba logická replikace. Replikace mezi primárním a záložním serverem pokračuje fyzickou replikací.
 
Zastavení starého clusteru: Služba Postgres je na starých hostitelích zastavena, aby se zajistilo, že se k ní již žádná aplikace nemůže připojit.
 
Překonfigurujte zbytek pohotovostních režimů pro nový primární: Znovu sestaví další pohotovostní režimy, pokud existují nějací zbývající hostitelé kromě počátečních pohotovostních režimů. Ve druhé případové studii již nezbývají žádné rezervní servery, které by bylo možné znovu sestavit. Tento krok dává šanci přestavět starý primární server jako nový pohotovostní režim, pokud je naznačen ve skupině new-standbys na hosts.ini. Opětovné použitelnosti stávajících serverů (dokonce i starého primárního) je dosaženo pomocí dvoukrokového návrhu konfigurace v pohotovostním režimu nástroje pglupgrade. Uživatel může určit, které servery by se měly stát pohotovostními režimy nového clusteru před upgradem a které by se měly stát pohotovostními režimy po aktualizaci.
 
 
Závěr
 

 V tomto příspěvku jsme diskutovali o podrobnostech implementace a návrhu vysoké dostupnosti nástroje pglupgrade. Přitom jsme také zmínili několik klíčových konceptů vývoje Ansible (tj. playbook, inventář a konfigurační soubory) pomocí nástroje jako příkladu. Ilustrovali jsme pracovní postup procesu upgradu a shrnuli, jak každý krok funguje, s odpovídající hrou. Budeme pokračovat ve vysvětlování pglupgrade ukázáním případových studií v nadcházejících příspěvcích této série.
 

 Děkujeme za přečtení!