Co je nového v MariaDB MaxScale 2.4

MaxScale 2.4 byl vydán 21. prosince 2019 a ClusterControl 1.7.6 podporuje monitorování a správu až do této verze. Pro nasazení však ClusterControl podporuje pouze verzi 2.3. Člověk musí instanci upgradovat ručně a naštěstí jsou kroky upgradu velmi jednoduché. Stačí si stáhnout nejnovější verzi ze stránky stahování MariaDB MaxScale a provést příkaz k instalaci balíčku.

Následující příkazy ukazují, jak upgradovat ze stávajícího MaxScale 2.3 na MaxScale 2.4 na boxu CentOS 7:

$ wget https://dlm.mariadb.com/1067184/MaxScale/2.4.10/centos/7/x86_64/maxscale-2.4.10-1.centos.7.x86_64.rpm
$ systemctl stop maxscale
$ yum localinstall -y maxscale-2.4.10-1.centos.7.x86_64.rpm
$ systemctl start maxscale
$ maxscale --version
MaxScale 2.4.10

V tomto příspěvku na blogu upozorníme na některá pozoruhodná vylepšení a nové funkce této verze a na to, jak vypadá v praxi. Úplný seznam změn v MariaDB MaxScale 2.4 najdete v jeho changelogu.

Historie příkazů v interaktivním režimu

Jedná se v podstatě o malé vylepšení s velkým dopadem na správu MaxScale a efektivitu monitorování úloh. Interaktivní režim pro MaxCtrl má nyní svou historii příkazů. Historie příkazů vám snadno umožňuje opakovat provedený příkaz stisknutím šipky nahoru nebo dolů. Funkce Ctrl+R (vyvolání posledního příkazu odpovídající zadaným znakům) však stále chybí.

V předchozích verzích je třeba použít standardní režim shellu, aby bylo zajištěno, že příkazy jsou zachyceny souborem .bash_history.

Monitorování GTID pro galeramon

Toto je dobré vylepšení pro ty, kteří používají Galera Cluster s geografickou redundancí prostřednictvím asynchronní replikace, známé také jako replikace cluster-to-cluster nebo replikace MariaDB Galera Cluster přes replikaci MariaDB.

V MaxScale 2.3 a starších to vypadá takto, pokud jste povolili replikaci master-slave mezi klastry MariaDB:

Pro MaxScale 2.4 to nyní vypadá takto (pozor na Galera1 řádek):

Nyní je snadnější vidět stav replikace pro všechny uzly z MaxScale, bez nutnost opakovaně kontrolovat jednotlivé uzly.

SmartRouter

Toto je jedna z nových hlavních funkcí v MaxScale 2.4, kde je MaxScale nyní dostatečně chytrý, aby zjistil, který backendový server MariaDB je nejlepší pro zpracování dotazu. SmartRouter sleduje výkon nebo dobu provádění dotazů do clusterů. Měření se ukládají s kanonickým klíčem dotazu. Kanonickým dotazu je SQL se všemi uživatelem definovanými konstantami nahrazenými otazníky, například:

UPDATE `money_in` SET `accountholdername` = ? , `modifiedon` = ? , `status` = ? , `modifiedby` = ? WHERE `id` = ? 

Toto je velmi užitečná funkce, pokud provozujete MariaDB na geografické replikaci s více lokalitami nebo kombinaci úložišť MariaDB v jednom replikačním řetězci, například vyhrazený slave pro zpracování transakčních úloh (OLTP ) s úložištěm InnoDB a dalším vyhrazeným podřízeným zařízením pro zpracování analytických úloh (OLAP) s úložištěm Columnstore.

Předpokládejme, že máme dvě lokality – Sydney a Singapur, jak je znázorněno na následujícím diagramu:

Primární web se nachází v Singapuru a má MariaDB master a slave , zatímco další otrok pouze pro čtení se nachází v Sydney. Aplikace se připojí k instanci MaxScale umístěné v příslušné zemi s následujícím nastavením portu:

• Rozdělení pro čtení a zápis:3306
• Celý postup:3307
• Chytrý směrovač:3308

Naše definice služby SmarRouter a posluchače jsou:

[SmartQuery]
type=service
router=smartrouter
servers=DB_1,DB_2,DB_5
master=DB_1
user=maxscale
password=******

[SmartQuery-Listener]
type = listener
service = SmartQuery
protocol = mariadbclient
port = 3308

Restartujte MaxScale a začněte odesílat dotaz pouze pro čtení do obou uzlů MaxScale umístěných v Singapuru a Sydney. Pokud je dotaz zpracován routerem round-robin (port 3307), uvidíme, že dotaz je směrován na základě algoritmu round-robin:

(app)$ mysql -usbtest -p -h maxscale_sydney -P3307 -e 'SELECT COUNT(id),@@hostname FROM sbtest.sbtest1'
+-----------+--------------------+
| count(id) | @@hostname         |
+-----------+--------------------+
|   1000000 | mariadb_singapore2 |
+-----------+--------------------+

Z výše uvedeného můžeme říci, že Sydney's MaxScale předal výše uvedený dotaz našemu singapurskému otrokovi, což samo o sobě není nejlepší možnost směrování.

Když SmartRouter naslouchá na portu 3308, viděli bychom, že dotaz je směrován na nejbližší slave v Sydney:

(app)$ mysql -usbtest -p -h maxscale_sydney -P3308 -e 'SELECT COUNT(id),@@hostname FROM sbtest.sbtest1'
+-----------+-----------------+
| count(id) | @@hostname      |
+-----------+-----------------+
|   1000000 | mariadb_sydney1 |
+-----------+-----------------+

A pokud je stejný dotaz proveden na našem webu v Singapuru, bude přesměrován na otroka MariaDB v Singapuru:

(app)$ mysql -usbtest -p -h maxscale_singapore -P3308 -e 'SELECT COUNT(id),@@hostname FROM sbtest.sbtest1'
+-----------+--------------------+
| count(id) | @@hostname         |
+-----------+--------------------+
|   1000000 | mariadb_singapore2 |
+-----------+--------------------+

Má to však háček. Když SmartRouter uvidí čtecí dotaz, jehož kanonický nebyl dosud viděn, odešle dotaz všem clusterům. První odpověď ze shluku označí tento shluk jako nejlepší pro daný kanonický. Po obdržení první odpovědi jsou také zrušeny další dotazy. Odpověď je odeslána klientovi, jakmile všechny clustery odpoví na dotaz nebo zrušení.

To znamená, že chcete-li sledovat kanonický dotaz (normalizovaný dotaz) a měřit jeho výkon, pravděpodobně uvidíte, že úplně první dotaz selže při prvním spuštění, například:

(app)$ mysql -usbtest -p -h maxscale_sydney -P3308 -e 'SELECT COUNT(id),@@hostname FROM sbtest.sbtest1'
ERROR 2013 (HY000) at line 1: Lost connection to MySQL server during query

Z obecného protokolu v MariaDB Sydney můžeme říci, že první dotaz (ID 74) byl úspěšně proveden (připojit, dotazovat a ukončit), a to i přes chybu „Ztracené připojení“ z MaxScale:

  74 Connect  [email protected] as anonymous on 
  74 Query    SELECT COUNT(id),@@hostname FROM sbtest.sbtest1
  74 Quit

Zatímco identický následující dotaz byl správně zpracován a vrácen se správnou odpovědí:

(app)$ mysql -usbtest -p -h maxscale_sydney -P3308 -e 'SELECT COUNT(id),@@hostname FROM sbtest.sbtest1'
+-----------+------------------------+
| count(id) | @@hostname             |
+-----------+------------------------+
|   1000000 | mariadb_sydney.cluster |
+-----------+------------------------+

Při opětovném pohledu na obecný protokol v MariaDB Sydney (ID 75) došlo ke stejným událostem zpracování jako u prvního dotazu:

  75 Connect  [email protected] as anonymous on 
  75 Query    SELECT COUNT(id),@@hostname FROM sbtest.sbtest1
  75 Quit

Z tohoto pozorování můžeme usoudit, že příležitostně musí MaxScale selhat u prvního dotazu, aby mohl měřit výkon a být chytřejší pro následující identické dotazy. Vaše aplikace musí být schopna správně zpracovat tuto „první chybu“, než se vrátíte klientovi nebo zopakujte transakci.

Socket UNIX pro server

Existuje několik způsobů, jak se připojit k běžícímu serveru MySQL nebo MariaDB. Můžete použít standardní síťový TCP/IP s hostitelskou IP adresou a portem (vzdálené připojení), pojmenované kanály/sdílenou paměť v systému Windows nebo soubory soketů Unix v systémech založených na Unixu. Soubor soketu UNIX je speciální druh souboru, který usnadňuje komunikaci mezi různými procesy, což je v tomto případě klient MySQL a server. Soubor soketu je komunikace založená na souborech a nemůžete k soketu přistupovat z jiného počítače. Poskytuje rychlejší připojení než TCP/IP (žádná síťová režie) a bezpečnější přístup k připojení, protože jej lze použít pouze při připojení ke službě nebo procesu na stejném počítači.

Předpokládejme, že server MaxScale je nainstalován také na samotném serveru MariaDB, můžeme místo něj použít soubor soketu UNIX. V části Server odeberte nebo okomentujte řádek "address" a přidejte parametr socket s umístěním souboru socketu:

[DB_2]
type=server
protocol=mariadbbackend
#address=54.255.133.39
socket=/var/lib/mysql/mysql.sock

Před použitím výše uvedených změn musíme vytvořit uživatele MaxScale axscale z localhost. Na hlavním serveru:

MariaDB> CREATE USER 'maxscale'@'localhost' IDENTIFIED BY 'maxscalep4ss';
MariaDB> GRANT SELECT ON mysql.user TO 'maxscale'@'localhost';
MariaDB> GRANT SELECT ON mysql.db TO 'maxscale'@'localhost';
MariaDB> GRANT SELECT ON mysql.tables_priv TO 'maxscale'@'localhost';
MariaDB> GRANT SHOW DATABASES ON *.* TO 'maxscale'@'localhost';

Po restartu zobrazí MaxScale místo skutečné adresy cestu soketu UNIX a výpis serveru se zobrazí takto:

Jak vidíte, informace o stavu a GTID se načítají správně prostřednictvím připojení soketu. Všimněte si, že tento DB_2 stále naslouchá portu 3306 pro vzdálená připojení. To jen ukazuje, že MaxScale používá soket pro připojení k tomuto serveru pro monitorování.

Použití zásuvky je vždy lepší, protože umožňuje pouze místní připojení a je bezpečnější. Můžete také zavřít svůj server MariaDB ze sítě (např. --skip-networking) a nechat MaxScale zpracovat „externí“ připojení a přeposlat je na server MariaDB prostřednictvím souboru soketu UNIX.

Vypouštění serveru

V MaxScale 2.4 lze vyprázdnit backendové servery, což znamená, že stávající připojení lze nadále používat, ale k serveru nebudou vytvářena žádná nová. S funkcí vypouštění můžeme provádět ladnou údržbu, aniž by to ovlivnilo uživatelskou zkušenost ze strany aplikace. Všimněte si, že vyprázdnění serveru může trvat déle v závislosti na spuštěných dotazech, které je třeba řádně uzavřít.

Chcete-li vyprázdnit server, použijte následující příkaz:

Následný efekt může být jeden z následujících stavů:

• Vypouštění – Probíhá vypouštění serveru.
• Vypuštěno – Server byl vypuštěn. Server byl vyprázdněn a nyní počet připojení k serveru klesl na 0.
• Údržba – Probíhá údržba serveru.

Po vypuštění serveru je stav serveru MariaDB z pohledu MaxScale "Údržba":

Když je server v režimu údržby, nebudou k němu vytvořena žádná připojení a existující připojení budou uzavřena.

Závěr

MaxScale 2.4 přináší mnoho vylepšení a změn oproti předchozí verzi a je to nejlepší databázová proxy pro práci se servery MariaDB a všemi jejími součástmi.