V posledních několika měsících jsem pracoval na online upgradu velmi rozsáhlých databází v rámci projektu AXLE a rád bych se podělil o své myšlenky na toto téma a jaký pokrok jsme v poslední době udělali.
Před vstupem do 2ndQuadrant jsem pracoval ve Skypu, kde firma neumožňovala období údržby našich databází. To znamenalo, že nebyly povoleny žádné prostoje pro nasazení, upgrady atd. Tento druh pravidla vás nutí změnit způsob, jakým věci děláte. Většina změn je malých, neprovádíte žádné těžké zámky, máte repliky, které umožňují rychlé převzetí služeb při selhání. Ale i když můžete svá vydání udělat malá a neblokující, co se stane, když potřebujete provést upgrade hlavní verze databáze PostgreSQL?
Můžete být v jiné situaci, protože většina společností má okno upgradu, a tak si můžete dovolit nějaké prostoje během upgradu. To však přináší dva problémy. Za prvé, žádná společnost ve skutečnosti nemá ráda prostoje, i když jsou povolené. A co je důležitější, jakmile velikost vaší databáze překročí velikost gigabajtů do rozsahu terabajtů nebo stovek terabajtů, výpadek může trvat dny nebo dokonce týdny a nikdo si nemůže dovolit zastavit své operace na tak dlouho. Výsledkem je, že mnoho společností často vynechává důležité upgrady, takže ten další je ve skutečnosti ještě bolestivější. A vývojářům chybí nové funkce, vylepšení výkonu. Oni (společnosti) někdy dokonce riskují provoz verze PostgreSQL, která již není podporována a má známé poškození dat nebo bezpečnostní problémy. V následujících odstavcích budu mluvit trochu o své práci na tom, aby upgrady byly méně časově náročné a v důsledku toho méně bolestivé a doufejme, že častější.
Nejprve začnu trochou historie. Před PostgreSQL 9.0 bylo jediným způsobem, jak provést upgrade hlavní verze, spustit pg_dump a obnovit výpis do instance s novější verzí PostgreSQL. Tato metoda vyžadovala, aby byla struktura a všechna data načtena z databáze a zapsána do souboru. Poté načíst ze souboru a vložit do nové databáze, indexy je třeba znovu vytvořit atd.
Jak si dokážete představit, tento proces může nějakou dobu trvat. Zlepšení výkonu bylo provedeno v 8.4 pro pg_restore s přidanou volbou -j, kde jste mohli určit, kolik paralelních úloh se má spustit. To umožňuje paralelně obnovovat několik tabulek (indexů atd.), čímž je proces obnovy rychlejší pro výpisy z vlastního formátu. Verze 9.3 přidala podobnou možnost jako pg_dump, čímž se výkon ještě zlepšil. Ale vzhledem k tomu, jak rychle rostou objemy dat, samotná paralelizace není dostatečná k tomu, aby v době potřebné k upgradu dosáhla nějakého výrazného zisku.
Pak v PostgreSQL 9.0 dorazil nástroj s názvem pg_upgrade. Pg_upgrade vypíše pouze struktury a obnoví je do nového clusteru. Zkopíruje však datové soubory tak, jak jsou na disku, což je mnohem rychlejší než jejich uložení do logického formátu a opětovné vložení. To je dost dobré pro malé databáze, protože to znamená prostoj v rozsahu minut nebo hodin, což je doba přijatelná pro mnoho scénářů. Existuje také režim propojení, který pouze vytváří pevné odkazy (spojovací body ve Windows), což tento proces ještě urychluje. Ale z mého osobního pohledu je příliš nebezpečné spouštět takové nastavení na produkčním master serveru. Stručně vysvětlím proč. Pokud se něco pokazí, jakmile spustíte svůj nový server, který byl upgradován pomocí režimu propojení, jste náhle bez produkční databáze a musíte provést selhání, nebo v horším případě musíte obnovit ze zálohy. To znamená, že se vám nejen nepodařilo upgradovat, ale způsobili jste další prostoje! Hodně štěstí se schválením příště.
Nyní mnoho lidí, kteří si nemohou dovolit dlouhé prostoje kvůli upgradům, používá k provedení upgradu řešení replikace založená na spouštěči, jako je Slony nebo Londiste. To je dobré řešení, protože můžete replikovat svá data, zatímco původní server běží, a poté přejít s minimálními prostoji. V praxi však existuje několik problémů. Jedním z nich je, že nastavení založená na spouštěči jsou často neohrabaná, zvláště pokud to děláte pouze jednou za pár let a pouze kvůli upgradu. Je také snadné vynechat tabulku nebo přidat tabulky ve špatném pořadí, a tak nezískat celou kopii. Byl jsem toho svědkem v praxi a lidé provádějící upgrade denně pracovali s replikací založenou na spouštěči . Dalším problémem je, že řešení založená na spouštěči značně zatěžují zdrojovou databázi, což někdy znemožňuje upgrade kvůli přetížení databázového serveru po aktivaci replikace. A v neposlední řadě může trvat velmi dlouho, než replikace založená na spouštěči skutečně přesune data na nový server. Při poslední příležitosti, kdy jsem se podílel na projektu upgradu, trvalo řešení založeném na spouštěči asi měsíc, než zkopírovalo databázi a dohnalo změny. Ano, jeden měsíc.
S PostgreSQL 9.4 přichází funkce logického dekódování, která nabízí nový začátek pro navrhování nového a lepšího řešení problému s online upgradem. V rámci projektu AXLE jsme vytvořili nástroj, který kombinuje logické dekódování s výše popsanými technikami. Řešení řeší většinu problémů předchozích přístupů. Rozšíření Uni-Directional Replication PostgreSQL (zkráceně UDR) provádí logickou replikaci pomocí logického dekódování protokolu před zápisem (WAL). Díky tomu je dopad na master server téměř srovnatelný s fyzickou streamovací replikací, takže dodatečné zatížení způsobené probíhající aktualizací je na běžícím systému minimální. Poskytuje také nástroje pro inicializaci nových uzlů, a to jak pomocí fyzického, tak logického zálohování. Můžete dokonce přepnout stávající fyzický pohotovostní režim na pohotovostní režim UDR. A protože se jedná o logický replikační systém, je možné jej navrhnout způsobem, který podporuje replikaci napříč verzemi.
To vše znamená, že nyní můžeme použít UDR v kombinaci s pg_upgrade k provedení online upgradu hlavní verze PostgreSQL s minimálními prostoji, v krátkém absolutním čase a s minimálním dopadem na běžící systém.
Příklad, jak to může vypadat v praxi:
- Proveďte pg_basebackup existující instance.
- Nastavte replikaci UDR mezi původní instancí a instancí vytvořenou pomocí basebackup.
- Pg_upgrade nové instance.
- Nechte UDR přehrát změny, ke kterým mezitím došlo.
- Přepněte provoz na novou instanci.
Jak na to s podrobnějšími pokyny najdete v příručce UDR Online Upgrade na PostgreSQL wiki. Zdroje UDR jsou dostupné v úložišti 2ndquadrant_bdr na PostgreSQL git serveru (bdr-plugin/next branch).
A konečně, protože UDR není jen online nástroj pro upgrade, ale také řešení replikace, lze jej použít pro vaše běžné potřeby replikace namísto fyzické streamingové replikace. Kromě toho poskytuje několik výhod, jako je možnost vytvářet dočasné tabulky, replikace z více databází OLTP do jedné databáze velkého datového skladu nebo replikace pouze části databáze.
Doufám, že toto úsilí bude znamenat, že úvahy o prostojích již nebudou problémem, pokud jde o upgrade z PostgreSQL 9.4 a vyšší na novou hlavní verzi.
Výzkum vedoucí k těmto výsledkům byl financován ze sedmého rámcového programu Evropské unie (FP7/2007-2013) na základě grantové dohody č. 318633.