Novinky v MariaDB 10.1 a jak upgradovat

MariaDB je ve Fedoře primární implementací MySQL již několik releasů. V minulých částech minisérie jsme viděli, jak se MariaDB instaluje a jak se dá použít například z Pythonu. Pojďme se dnes podívat, jaké zajímavé novinky jsou pro nás připraveny v poslední verzi, která je nyní ve Fedoře 24 a jak správným způsobem upgradovat z předchozí verze.

Upgrade na MariaDB 10.1

Ve Fedoře 23 je stále MariaDB 10.0 a měnit se to nebude, neboť verze 10.1 a 10.0 nejsou kompatibilní. Upgrade na 10.1 je nicméně vcelku jednoduchý, i když to není úplně bez práce.

Kvůli výše zmíněné kompatibilitě a zachování vždy jedné verze v rámci jednoho releasu Fedory, se s upgradem MariaDB nejčastěji setkáte po upgradu systému. Po tom, co se při upgradu systému aktualizují RPM balíky, bychom u MariaDB měli věnovat pozornost některým volbám konfigurace (https://mariadb.com/kb/en/mariadb/upgrading-from-mariadb-100-to-101/), které mohou mezi major verzemi být odstraněný a tím pádem mohou být příčinou pádu démona. Ve verzi 10.1 byla podle dokumentace odebrána pouze volba rpl_recovery_rank, takže pokud se nachází v některém konfiguračním souboru v /etc/my.cnf.d/ adresáři nebo v /etc/my.cnf samotném, odeberte ji.

Nyní můžeme spustit démona a následně mysql_upgrade utilitku:

$ sudo systemctl start mariadb
$ mysql_upgrade -p

Ta upraví případné interní struktury, aby další DDL operace probíhaly v pořádku nad daty, které momentální verze démona očekává. Parametr -p dá utilitě vědět, že chceme pro autentizaci zadat heslo.

Pokud upgradujeme ze starší verze než 10.0, upstream nedává žádné záruky, přestože se někteří pokouší o upgrade například z 5.5 na 10.1 a můžeme se o takových pokusech dočíst na internetových fórech. To může v mnoha případech fungovat, ale jistotu mít nebudeme. Proto je doporučené vždy upgradovat pouze z předchozí major verze. Pokud mluvíme o major verzi, myslíme tím například 10.0 a 10.1, neboť to jsou verze, které jsou obecně nekompatibilní. První číslo verze je tím pádem jen marketing a zvětšuje se pokud je do nové verze přidána nějaká extra parádní novinka.

Máme tedy upgrade úspěšně za sebou a pojďme se podívat na ty slíbené novinky.

Galera replikace dostupná v MariaDB 10.1

Galera replikace je synchronní multi-master replikační řešení, které je alternativou ke klasickému master-slave řešení. Oproti master-master potom dovoluje spojit nejen dva, ale několik serverů, z nichž žádný nebude speciální. Podpora Galera replikace, která byla dříve k dispozici jako samostatný patch, případně v samostatné větvi, je nyní integrována do hlavní větve. I v předchozích verzích Fedory byla Galera k dispozici, nicméně jednalo se právě o extra balík mariadb-galera-server.

Znamená to, že všichni uživatelé MariaDB 10.1 mohou začít využívat Galera replikaci již po instalaci pluginu a změně konfigurace, bez potřeby reinstalovat balíky nebo dokonce kompilovat vlastní zdroj. Více o tomto typu replikace snad časem v samostatném článku.

Konzistentní podpora pro IF EXISTS, IF NOT EXISTS a OR REPLACE klauzule

Může se to zdát jako něco, co tu je již odjakživa, nicméně není tomu tak. Mnoho uživatelů určitě stále využívá triky, kdy místo CREATE USER IF NOT EXISTS používají GRANT klauzuli pro zajištění, že uživatel bude vytvořen a klauzule bude fungovat i v případě, že již existuje. Nyní máme konečně k dispozici klauzule, které SQL příkazy zpřehlední a často zjednoduší -- například takto:

CREATE OR REPLACE DATABASE ;
CREATE DATABASE IF NOT EXISTS ;
CREATE USER IF NOT EXISTS 'franta'@'localhost' IDENTIFIED BY 'secret';
CREATE OR REPLACE USER 'franta'@'localhost' IDENTIFIED BY 'secret';
DROP USER IF EXISTS 'franta'@'localhost';

Podobně klauzule fungují i u dalších příklazů CREATE a DROP.

Password Validation Plugin

Vše, co se týká bezpečnosti, by mělo být děláno poctivě, tedy alespoň by se mělo. Pokud chceme uživatele donutit používat silná hesla, musíme implementovat nějaký mechanismus kontroly. Jako u mnoha jiných problémů, můžeme kontrolu provádět buďto v aplikaci a nebo přímo v databázi. V aplikaci je to celkem přímočaré, ale sdílet stejný mechanismus napříč aplikacemi není jednoduché a například aktualizace seznamu zakázaných hesel v několika aplikacích na mnoha serverech může nakonec vypadat jako noční můra. Další variantou je tedy provádět kontrolu na úrovni databáze, což ale v předchozích verzích nebylo zdaleka tak přímočaré.

S novým pluginem na kontrolu hesel (password validation) se to stává hračkou a nejen že mechanismus můžeme nasadit bez výraznějších změn v aplikačním kódu, můžeme tak právě i centralizovat kontrolu a například slovník zakázaných hesel sdílet jednoduše na jednom místě. Nasazení pluginu s hesly provedeme nejjednodušším způsobem takto:

INSTALL PLUGIN simple_password_check;

Snaha o změnu hesla, která neodpovídá nastaveným pravidlům potom vyústí chybu, jako je tato:

SET PASSWORD FOR 'franta'@'%' = PASSWORD('111');
ERROR 1819 (HY000): Your password does not satisfy the current policy requirements

Aplikace tedy musí s takovým případem počítat a rozumně zareagovat. Pro komplexnější použití můžete prozkoumat dokumentaci na https://mariadb.com/kb/en/mariadb/password-validation/.

Šifrování zapisovaných dat (Data at Rest encryption)

Můžete se ptát, jaká novinka, když už data v MariaDB šifrujeme dávno. Ano, šifrovat data spojení lze pomocí SSL, což uchrání data při pokusu odposlechnout je nebo je po cestě změnit. Jakmile se ale útočník dostane k souborům databáze, přečíst je není problém. Využít symetrické šifrování pomocí funkcí lze pro vybrané hodnoty, ale dělat to pro veškerá data by bylo velmi nepraktické a také neefektivní.

O co tedy jde u Data at rest encryption? Jde o to, že nyní máme nově možnost utajit data na disku jednoduše tak, že databázový server je efektivně zašifruje těsně před uložením na disk. Kromě dat tabulek lze navíc šifrovat i logy. Můžeme dokonce selektivně vybrat jen některé tabulky, neboť i přes velkou efektivitu symetrického šifrování je nutné uvědomit si, že to stále něco bude stát.

Pro šifrování lze využít více klíčů, které mohou být uloženy v souboru, který je taktéž zašifrovaný a my serveru předáme pouze tento hlavní klíč.

Jak tedy na to? Pro jednoduchost použijeme následující soubor s klíči, který je nezašifrovaný:

# this is a comment
1;770A8A65DA156D24EE2A093277530142
18;F5502320F8429037B8DAEF761B189D12F5502320F8429037B8DAEF761B189D12

Potom přidáme konfiguraci démona tímto způsobem:

[mysqld]
plugin-load-add=file_key_management.so
file-key-management
file-key-management-filename = /mount/usb1/keys.txt
innodb-encrypt-tables
innodb-encrypt-log
innodb-encryption-threads=4
encrypt-tmp-files

Po startu serveru je možné vytvořit tabulku, jejíž data se budou před zapsáním do souboru šifrovat, a to takto:

CREATE TABLE mytable (a int, b varchar(10)) ENCRYPTED=YES ENCRYPTION_KEY_ID=5;

Jak si můžeme všimnout, klíče se načítají ze souboru, který je v čase spouštění serveru namountovaný z usb, nicméně po startu je možné soubor odstranit a tím pádem zabránit dodatečnému přečtení klíčů. Více o této novince na https://mariadb.com/kb/en/mariadb/data-at-rest-encryption/.

Komprese stránek u InnoDB/XtraDB enginů

Obdobně jako šifrovat, můžeme data dnes nejběžněji užívaných enginů InnoDB/XtraDB před zápisem na disk i komprimovat. Zajímavých výsledků dosáhneme samozřejmě u dat málo variabilních a pro dosažení nejlepších výsledků můžeme volit z celé řady kompresních algoritmů. Nicméně jakmile jednou zvolíme kompresní algoritmus, zvolíme ho pro všechna data, takže není možné volit jiné algoritmy pro různé tabulky nebo databáze.

Pro zapnutí šifrování nejdříve nastavíme zvolenou kompresi v konfiguraci:

[mysqld]
innodb_compression_algorithm=lz4;

Potom můžeme nastavit u vybraných tabulek, že budou tímto algoritmem šifrovány:

CREATE TABLE users(user_id INT, name VARCHAR(200)) ENGINE=innodb page_compressed=1;

Kompresní algoritmy v MariaDB 10.1 jsou zlib, lz4, lzo, lzma, bzip2 a snappy. Více informací nalezneme na https://mariadb.com/kb/en/mariadb/compression/.

Tolik výběr nejzajímavějších novinek, nicméně ve verzi 10.1 samozřejmě najdeme více. Například zlepšení škálovatelnosti, rychlosti a efektivity na různých úrovních se nemusím zmiňovat, neboť každá verze přináší malé krůčky v těchto oblastech. Jsou to krůčky malé, ale kupředu a to je důležité.