„Udržujte svou databázi upgradovanou na nejnovější verzi – je to pro vaši bezpečnost“ je něco, co můžete často slyšet jako dobrou radu a nejlepší postup, pokud jde o správu databáze. Na druhou stranu může být upgrade vaší databáze časově náročný úkol. Dokonce i upgrade menší verze vyžaduje, abyste před upgradem produkčního nastavení důkladně otestovali upgrade ve zkušebním prostředí. O co tedy jde? Pokud zaostáváte pouze za jednou vedlejší verzí, nemělo by to vadit, ne? No, možná ne... dokud se to nestane. A jste opravdu připraveni podstoupit takové riziko?
Začátkem tohoto roku byla v Galera Cluster (CVE-2021-27928) identifikována nová potenciálně nebezpečná chyba zabezpečení. Na první pohled vidíme, že závažnost byla označena jako vysoká, a když se do problému začneme vrtat dále, skutečně to vypadá vážně. Zdá se, že SUPER uživatel může spustit jakýkoli libovolný kód změnou proměnných wsrep_provider a wsrep_notify_cmd za běhu. Umožňuje uživateli načíst knihovnu .so a ukázat na skript, který server spustí. Jak si dokážete představit, není to dobrá situace. Jistě, musíte mít přístup k SUPER uživateli a potřebovali byste mít něco dostupného ke spuštění na databázovém uzlu, ale skutečnost, že Galera může být nakonfigurována tak, aby spouštěla libovolný kód jako uživatel 'mysql', je dost špatná na jeho vlastní.
Jako obvykle byly v případech, jako jsou tyto, vytvořeny opravy a byly odeslány nové verze softwaru, kterých se tato chyba zabezpečení nedotkne. Tento konkrétní problém byl opraven v MariaDB 10.5.9, 10.4.18, 10.3.28 a 10.2.37 a také v Percona XtraDB Cluster 5.6.51-28.46, Percona XtraDB Cluster 5.7.33-31.49 a CBconaD XtraDB Cluster 8.0.22-13.1. Zdá se, že se vše vrátilo do normálu. Správně?
Špatně. V produkci běží nespočet systémů, které ještě nebyly upgradovány na novou, neovlivněnou verzi. Tým podpory společnosti Somenines je v kontaktu s mnoha databázovými prostředími ve volné přírodě a neustále pracujeme s potenciálními zákazníky, abychom jim pomohli migrovat do prostředí spravovaného ClusterControl. Vidíme všechny druhy MySQL (a nejen MySQL) běžící v zastaralých verzích, někdy dokonce verze, které dosáhly konce své životnosti a již nedostávají bezpečnostní aktualizace. To by nemělo platit, zvláště pokud jste uživatelem ClusterControl.
ClusterControl přichází se sadou funkcí, které vám pomohou zůstat v obraze se všemi bezpečnostními opravami. Pojďme se na to podívat:
Za prvé, ClusterControl přichází s provozními zprávami, jednou z nich je zpráva o aktualizaci balíčku:
Stejně jako všechny provozní zprávy ClusterControl lze zprávu o aktualizaci balíčku naplánovat na být prováděny pravidelně a následně doručovány e-mailem. Bude obsahovat informace o verzích balíčků nainstalovaných na uzlech ao tom, zda existují nějaké aktualizace, které by měly být provedeny:
Zpráva o aktualizaci balíčku obsahuje seznam balíčků, které by měly být aktualizovány pro všechny databáze, loadbalancery, bezpečnostní opravy a jakékoli další balíčky nainstalované na uzlu. Pro všechny systémové balíčky je řešením upgradovat je pomocí standardních metod (apt, yum). Pokud jde o databáze a loadbalancery, ClusterControl přichází s funkcemi, které vám umožňují provádět upgrade menší verze přímo z uživatelského rozhraní.
Než se tam vydáme, předpokládejme, že je třeba databázi aktualizovat. Nechcete jen pokračovat a spouštět upgrade naslepo – může to potenciálně způsobit problémy vaší aplikaci. Nemělo by – menší verze nenarušují zpětnou kompatibilitu (kromě případů, kdy používáte MySQL 8.0 – pak ano, při přechodu z 8.0.x na 8.0.x+1 můžete očekávat cokoli); vždy je s tím však spojeno nějaké riziko. Co byste měli udělat jako první, je otestovat upgrade v samostatném prostředí.
Máme jednoduchý cluster MariaDB Galera s ProxySQL a Keepalived:
Rádi bychom vytvořili testovací cluster, abychom mohli otestovat upgrade proces. S ClusterControl je to stejně snadné jako použití úlohy Create Replica Cluster:
Můžeme získat čerstvá data ze stávajícího clusteru, nebo můžeme použít data ze zálohy.
Musíme také vybrat zdrojový uzel v produkčním clusteru:
Potom musíme projít běžným průvodcem nasazením, vybrat verzi a dodavatele databáze, definování hesla root a tak dále. Na závěr předáme uzly, na kterých bude cluster nainstalován.
V důsledku toho uvidíte v seznamu nový cluster s jasná známka toho, že se replikuje mimo produkční cluster. Jedna věc, která stojí za zmínku, ve výchozím nastavení použije ClusterControl nejnovější verze balíčků k vytvoření replikovaného clusteru. Pokud chcete dvakrát zkontrolovat pouze dotazy, stačí to. Pokud chcete projít celým procesem upgradu, budete muset označit starší verze balíčků MySQL, abyste mohli nainstalovat starou verzi (a poté je odepnout a otestovat upgrade).
Tak či onak, po úspěšných testech budete nakonec chtít provést upgrade. ClusterControl vám k tomu může pomoci:
V části Spravovat -> Upgrady najdete uživatelské rozhraní pro provedení upgradu .
Můžete použít „Vyhledat nové balíčky“ k obnovení databáze dostupných balíčky. Můžeme si také vybrat, které uzly chceme upgradovat a které služby:
Stačí potvrdit a je to – ClusterControl provede upgrade a získáte nejnovější verze balíčků.
Jak vidíte, díky ClusterControl je udržování vašich databází v aktuálním stavu snadné a přímočaré. Jediným krokem, který musíte zvládnout ručně, je správné testování. Jinak – vše ostatní za vás může provést ClusterControl. Máte zájem dozvědět se více o tom, jak vám ClusterControl může pomoci efektivně spravovat vaši databázi? Vyzkoušejte to zdarma na 30 dní.