ProxySQL je jedním z nejlepších serverů proxy pro MySQL. Zavedlo velké množství možností pro správce databází. Umožnil tvarovat databázový provoz zpožďováním, ukládáním do mezipaměti nebo přepisováním dotazů za běhu. Lze jej také použít k vytvoření prostředí, ve kterém nebude mít převzetí služeb při selhání vliv na aplikace a bude pro ně transparentní. Nejdůležitější funkce ProxySQL jsme již probrali v předchozích příspěvcích na blogu:
- Jak používat ClusterControl a ProxySQL pro ukládání dotazů do mezipaměti
- Jak vytvořit SQL firewall pomocí ClusterControl a ProxySQL
- Jak nasadit cluster ProxySQL
- Jak snadno nasadit replikační prostředí MySQL s ProxySQL pro vysokou dostupnost
Máme dokonce výukový program pokrývající ProxySQL, který ukazuje, jak jej lze použít v nastaveních MySQL a MariaDB.
Poměrně nedávno byl vydán ProxySQL 2.0.3, což je opravná verze pro řadu 2.0. Chyby se opravují a zdá se, že řada 2.0 začíná získávat trakci, kterou si zaslouží. V tomto příspěvku na blogu bychom rádi probrali hlavní změny zavedené v ProxySQL 2.0.
Kauzální čtení pomocí GTID
Všichni, kdo se museli potýkat se zpožděním replikace a potýkali se se scénáři čtení po zápisu, které jsou ovlivněny zpožděním replikace, budou s touto funkcí rozhodně velmi spokojeni. V replikačních prostředích MySQL bylo doposud jediným způsobem, jak zajistit kauzální čtení, čtení z hlavního serveru (a nezáleží na tom, zda používáte asynchronní nebo semisynchronní replikaci). Další možností bylo zvolit Galeru, která měla možnost vynutit si kauzální čtení od té doby, jako vždy (nejprve to bývalo wsrep-causal-reads a nyní je to wsrep-sync-wait). Poměrně nedávno (v 8.0.14) replikace MySQL Group získala podobnou funkci. Pravidelná replikace však sama o sobě nemůže vyřešit tento problém. Naštěstí je tu ProxySQL a přináší nám možnost definovat na základě pravidla pro každý dotaz s tím, co čte hostitelská skupina, která odpovídá pravidlu dotazu, které by mělo být konzistentní. Implementace je dodávána s ProxySQL binlog reader a může pracovat s formátem ROW binlog pro MySQL 5.7 a novější. Vzhledem k nedostatku požadovaných funkcí v MariaDB je podporován pouze Oracle MySQL. Tato funkce a její technické detaily byly vysvětleny na oficiálním blogu ProxySQL.
SSL pro připojení frontend
ProxySQL vždy podporovalo backendové připojení SSL, ale postrádalo šifrování SSL pro připojení od klientů. Vzhledem k doporučenému vzoru nasazení to nebylo tak velké, že by bylo třeba umístit ProxySQL na aplikační uzly a použít zabezpečený Unixový soket pro připojení z aplikace k proxy. Toto je stále doporučení, zvláště pokud používáte ProxySQL pro cachování dotazů (Unixové sockety jsou rychlejší než TCP připojení, a to i lokální a s cache je dobré se vyhnout zavádění zbytečné latence). Dobré je, že s ProxySQL 2.0 je nyní na výběr, protože zavedla podporu SSL pro příchozí připojení. Můžete to snadno povolit nastavením mysql-have_ssl na „true“. Povolení SSL nemá nepřijatelný dopad na výkon. Na rozdíl od výsledků z oficiálního blogu ProxySQL je pokles výkonu velmi nízký.
Nativní podpora pro Galera Cluster
Galera Cluster je podporován ProxySQL téměř od začátku, ale zatím to bylo provedeno prostřednictvím externího skriptu, který byl (obvykle) volán z interního plánovače ProxySQL. Bylo na skriptu, aby se ujistil, že konfigurace ProxySQL byla správná, zapisovač (nebo zapisovače) byl správně detekován a nakonfigurován v hostitelské skupině pro zapisovače. Skript byl schopen detekovat různé stavy, které může mít uzel Galera (Primární, Neprimární, Synchronizovaný, Donor/Desync, Joining, Joined) a podle toho označit uzel buď jako dostupný, nebo ne. Hlavním problémem je, že původní scénář nikdy nebyl zamýšlen jako něco jiného než důkaz konceptu napsaný v Bash. Přesto, jak byl distribuován spolu s ProxySQL, začal být vylepšován, upravován externími přispěvateli. Jiní (jako Percona) se zabývali vytvářením vlastních skriptů, dodávaných s jejich softwarem. Některé opravy byly zavedeny do skriptu z úložiště ProxySQL, některé byly zavedeny do verze skriptu Percona. To vedlo ke zmatkům, a přestože všechny běžně používané skripty zvládly 95 % případů použití, žádný z populárních ve skutečnosti nepokrýval všechny různé situace a proměnné, které může cluster Galera skončit. Naštěstí ProxySQL 2.0 přichází s nativní podporou pro Galera Cluster. Díky tomu podporuje ProxySQL interně replikaci MySQL, replikaci skupin MySQL a nyní Galera Cluster. Způsob, jakým se to dělá, je velmi podobný. Rádi bychom pokryli konfiguraci této funkce, protože nemusí být na první pohled jasná.
Stejně jako u replikace MySQL a replikace skupin MySQL byla v ProxySQL vytvořena tabulka:
mysql> show create table mysql_galera_hostgroups\G
*************************** 1. row ***************************
table: mysql_galera_hostgroups
Create Table: CREATE TABLE mysql_galera_hostgroups (
writer_hostgroup INT CHECK (writer_hostgroup>=0) NOT NULL PRIMARY KEY,
backup_writer_hostgroup INT CHECK (backup_writer_hostgroup>=0 AND backup_writer_hostgroup<>writer_hostgroup) NOT NULL,
reader_hostgroup INT NOT NULL CHECK (reader_hostgroup<>writer_hostgroup AND backup_writer_hostgroup<>reader_hostgroup AND reader_hostgroup>0),
offline_hostgroup INT NOT NULL CHECK (offline_hostgroup<>writer_hostgroup AND offline_hostgroup<>reader_hostgroup AND backup_writer_hostgroup<>offline_hostgroup AND offline_hostgroup>=0),
active INT CHECK (active IN (0,1)) NOT NULL DEFAULT 1,
max_writers INT NOT NULL CHECK (max_writers >= 0) DEFAULT 1,
writer_is_also_reader INT CHECK (writer_is_also_reader IN (0,1,2)) NOT NULL DEFAULT 0,
max_transactions_behind INT CHECK (max_transactions_behind>=0) NOT NULL DEFAULT 0,
comment VARCHAR,
UNIQUE (reader_hostgroup),
UNIQUE (offline_hostgroup),
UNIQUE (backup_writer_hostgroup))
1 row in set (0.00 sec)Existuje mnoho nastavení ke konfiguraci a my je projdeme jedno po druhém. Za prvé, existují čtyři hostitelské skupiny:
- Writer_hostgroup – bude obsahovat všechny zapisovače (s read_only=0) až do nastavení „max_writers“. Ve výchozím nastavení je to pouze jeden zapisovatel
- Backup_writer_hostgroup – obsahuje zbývající spisovatele (read_only=0), kteří zbyli po přidání „max_writers“ do skupiny Writer_hostgroup
- Reader_hostgroup – obsahuje čtenáře (read_only=1), může také obsahovat záložní zapisovače, podle nastavení „writer_is_also_reader“
- Offline_hostgroup – obsahuje uzly, které byly považovány za nepoužitelné (buď offline nebo ve stavu, který jim znemožňuje zpracovávat provoz)
Pak máme zbývající nastavení:
- Aktivní – zda je záznam v mysql_galera_hostgroups aktivní nebo ne
- Max_writers – kolik uzlů lze umístit do skupiny Writer_hostgroup
- Writer_is_also_reader – pokud je nastaveno na 0, zapisovatelé (read_only=0) nebudou zařazeni do reader_hostgroup. Je-li nastaveno na 1, zapisovače (pouze pro čtení=0) budou umístěny do skupiny hostitelů čtenářů. Pokud je nastaveno na 2, uzly ze skupiny backup_writer_hostgroup budou vloženy do reader_hostgroup. Tento je trochu složitý, proto uvedeme příklad později v tomto blogovém příspěvku
- Max_transactions_behind – na základě wsrep_local_recv_queue, maximální fronty, která je přijatelná. Pokud fronta na uzlu překročí max_transactions_behind, daný uzel bude označen jako SHUNNED a nebude dostupný pro provoz
Hlavním překvapením může být manipulace se čtečkami, která je odlišná od toho, jak fungoval skript obsažený v ProxySQL. Za prvé, co musíte mít na paměti, je skutečnost, že ProxySQL používá read_only=1 k rozhodnutí, zda je uzel čtečkou nebo ne. To je běžné v nastaveních replikace, ne tak běžné v Galeře. Proto s největší pravděpodobností budete chtít použít nastavení 'writer_is_also_reader' ke konfiguraci toho, jak mají být čtenáři přidáni do reader_hostgroup. Uvažujme tři uzly Galera, všechny mají read_only=0. Máme také max_writers=1, protože chceme směrovat všechny zápisy do jednoho uzlu. Mysql_galera_hostgroups jsme nakonfigurovali následovně:
SELECT * FROM mysql_galera_hostgroups\G
*************************** 1. row ***************************
writer_hostgroup: 10
backup_writer_hostgroup: 30
reader_hostgroup: 20
offline_hostgroup: 40
active: 1
max_writers: 1
writer_is_also_reader: 0
max_transactions_behind: 0
comment: NULL
1 row in set (0.00 sec)Pojďme si projít všechny možnosti:
Writer_is_also_reader=0
mysql> SELECT hostgroup_id, hostname FROM runtime_mysql_servers;
+--------------+------------+
| hostgroup_id | hostname |
+--------------+------------+
| 10 | 10.0.0.103 |
| 30 | 10.0.0.101 |
| 30 | 10.0.0.102 |
+--------------+------------+
3 rows in set (0.00 sec)Tento výsledek je jiný, než byste viděli ve skriptech – tam byste měli zbývající uzly označené jako čtenáři. Vzhledem k tomu, že nechceme, aby autoři byli čtenáři, a vzhledem k tomu, že neexistuje žádný uzel s read_only=1, nebudou nakonfigurováni žádní čtenáři. Jeden zapisovač (podle max_writers), zbývající uzly ve skupině backup_writer_hostgroup.
Writer_is_also_reader=1
mysql> SELECT hostgroup_id, hostname FROM runtime_mysql_servers;
+--------------+------------+
| hostgroup_id | hostname |
+--------------+------------+
| 10 | 10.0.0.103 |
| 20 | 10.0.0.101 |
| 20 | 10.0.0.102 |
| 20 | 10.0.0.103 |
| 30 | 10.0.0.101 |
| 30 | 10.0.0.102 |
+--------------+------------+
6 rows in set (0.00 sec)Zde chceme, aby naši autoři vystupovali jako čtenáři, proto budou všichni (aktivní i záložní) zařazeni do skupiny reader_hostgroup.
Writer_is_also_reader=2
mysql> SELECT hostgroup_id, hostname FROM runtime_mysql_servers;
+--------------+------------+
| hostgroup_id | hostname |
+--------------+------------+
| 10 | 10.0.0.103 |
| 20 | 10.0.0.101 |
| 20 | 10.0.0.102 |
| 30 | 10.0.0.101 |
| 30 | 10.0.0.102 |
+--------------+------------+
5 rows in set (0.00 sec)Toto je nastavení pro ty, kteří nechtějí, aby jejich aktivní spisovatel zpracovával čtení. V tomto případě budou pro čtení použity pouze uzly ze skupiny backup_writer_hostgroup. Mějte prosím také na paměti, že pokud nastavíte max_writers na jinou hodnotu, počet čtenářů se změní. Pokud bychom to nastavili na 3, nebyly by žádné záložní zapisovače (všechny uzly by skončily v hostitelské skupině pro zapisovače), takže by opět nebyly žádné uzly v hostitelské skupině čtečky.
Samozřejmě budete chtít nakonfigurovat pravidla dotazu podle konfigurace hostitelské skupiny. Tento proces zde nebudeme procházet, jak to lze provést, si můžete ověřit v blogu ProxySQL. Pokud byste chtěli vyzkoušet, jak to funguje v prostředí Dockeru, máme blog, který popisuje, jak spustit Galera cluster a ProxySQL 2.0 na Dockeru.
Další změny
To, co jsme popsali výše, jsou nejpozoruhodnější vylepšení v ProxySQL 2.0. Existuje mnoho dalších, podle changelogu. Za zmínku stojí vylepšení týkající se mezipaměti dotazů (například přidání PROXYSQL FLUSH QUERY CACHE) a změna, která umožňuje ProxySQL spoléhat se na super_read_only při určování master a slave v nastavení replikace.
Doufáme, že tento krátký přehled změn v ProxySQL 2.0 vám pomůže určit, kterou verzi ProxySQL byste měli používat. Mějte prosím na paměti, že větev 1.4, i když nezíská žádné nové funkce, je stále udržována.