Příprava serveru MySQL nebo MariaDB pro produkci – část druhá

V předchozím blogu jsme probrali několik tipů a triků, jak připravit server MySQL pro produkční použití z pohledu správce systému. Tento blogový příspěvek je pokračováním... 

Použijte nástroj pro zálohování databáze

Každý zálohovací nástroj má své výhody a nevýhody. Například Percona Xtrabackup (nebo MariaDB Backup pro MariaDB) může provádět fyzické horké zálohování bez uzamčení databází, ale lze jej obnovit pouze na stejnou verzi v jiné instanci. Zatímco pro mysqldump je křížově kompatibilní s ostatními hlavními verzemi MySQL a je mnohem jednodušší pro částečné zálohování, i když je relativně pomalejší během obnovy ve srovnání s Percona Xtrabackup na velkých databázích. MySQL 5.7 také zavádí mysqlpump, podobnou mysqldump s možnostmi paralelního zpracování pro urychlení procesu výpisu.

Nenechte si ujít konfiguraci všech těchto zálohovacích nástrojů na vašem serveru MySQL, protože jsou volně dostupné a velmi důležité pro obnovu dat. Protože mysqldump a mysqlpump jsou již zahrnuty v MySQL 5.7 a novějších, stačí nainstalovat Percona Xtrabackup (nebo MariaDB Backup pro MariaDB), ale vyžaduje to několik příprav, jak je znázorněno v následujících krocích:

Krok jedna

Ujistěte se, že je nainstalován zálohovací nástroj a jeho závislosti:

$ yum install -y epel-release
$ yum install -y socat pv percona-xtrabackup

Pro servery MariaDB použijte místo toho zálohu MariaDB:

$ yum install -y socat pv MariaDB-Backup

Krok dva

Vytvořte uživatele 'xtrabackup' na hlavním serveru, pokud neexistuje:

mysql> CREATE USER 'xtrabackup'@'localhost' IDENTIFIED BY 'Km4z9^sT2X';
mysql> GRANT RELOAD, LOCK TABLES, PROCESS, REPLICATION CLIENT ON *.* TO 'xtrabackup'@'localhost';

Krok tři

Vytvořte dalšího uživatele s názvem 'mysqldump' na hlavním serveru, pokud neexistuje. Tento uživatel bude použit pro 'mysqldump' a 'mysqlpump':

mysql> CREATE USER 'mysqldump'@'localhost' IDENTIFIED BY 'Km4z9^sT2X';
mysql> GRANT SELECT, SHOW VIEW, EVENT, TRIGGER, LOCK TABLES, RELOAD, REPLICATION CLIENT ON *.* TO 'mysqldump'@'localhost';

Krok čtyři

Přidejte přihlašovací údaje záložních uživatelů do konfiguračního souboru MySQL pod direktivou [xtrabackup], [mysqldump] a [mysqlpump]:

$ cat /etc/my.cnf

...

[xtrabackup]
user=xtrabackup
password='Km4z9^sT2X'

[mysqldump]
user=mysqldump
password='Km4z9^sT2X'

[mysqlpump]
user=mysqldump
password='Km4z9^sT2X'

Zadáním výše uvedených řádků nemusíme v příkazu pro zálohování zadávat uživatelské jméno a heslo, protože nástroj pro zálohování automaticky načte tyto možnosti konfigurace z hlavního konfiguračního souboru.

Předtím se ujistěte, že jsou zálohovací nástroje řádně otestovány. U Xtrabackup, který podporuje zálohování streamování přes síť, je třeba toto nejprve otestovat, abyste se ujistili, že lze správně navázat komunikační spojení mezi zdrojovým a cílovým serverem. Na cílovém serveru spusťte následující příkaz pro socat, aby naslouchal portu 9999 a byl připraven přijímat příchozí streamování:

$ socat -u tcp-listen:9999,reuseaddr stdout 2>/tmp/netcat.log | xbstream -x -C /var/lib/mysql

Potom vytvořte zálohu na zdrojovém serveru a streamujte ji na port 9999 na cílovém serveru:

$ innobackupex --socket=/var/lib/mysql/mysql.sock --stream=xbstream /var/lib/mysql/ | socat - TCP4:192.168.0.202:9999

Po provedení příkazu backup byste měli získat nepřetržitý proud výstupu. Počkejte, dokud neuvidíte řádek 'Dokončeno OK' označující úspěšné zálohování.

Pomocí pv můžeme omezit využití šířky pásma nebo vidět pokrok jako proces, který je přes něj veden potrubím. Pokud není povoleno žádné omezení, proces streamování obvykle nasytí síť, což by mohlo způsobit problémy s jinými servery při interakci s jinými servery ve stejném segmentu. Pomocí pv můžeme omezit proces streamování, než jej předáme streamovacímu nástroji, jako je socat nebo netcat. Následující příklad ukazuje, že záložní streamování bude omezeno na přibližně 80 MB/s pro příchozí i odchozí připojení:

$ innobackupex --slave-info --socket=/var/lib/mysql/mysql.sock --stream=xbstream /var/lib/mysql/ | pv -q -L 80m | socat - TCP4:192.168.0.202:9999

Streamování zálohy se běžně používá k vytvoření podřízeného zařízení nebo vzdálenému uložení zálohy na jiný server.

Pro mysqldump a mysqlpump můžeme testovat pomocí následujících příkazů:

$ mysqldump --set-gtid-purged=OFF --all-databases
$ mysqlpump --set-gtid-purged=OFF --all-databases

Ujistěte se, že ve výstupu vidíte řádky bez chyb.

Zátěžový test serveru

Zátěžové testování databázového serveru je důležité pro pochopení maximální kapacity, kterou můžeme u konkrétního serveru očekávat. To bude užitečné, když se v pozdější fázi blížíte k prahům nebo úzkým místům. Můžete použít mnoho nástrojů pro srovnávání dostupných na trhu, jako je mysqlslap, DBT2 a sysbench.

V tomto příkladu používáme sysbench k měření špičkového výkonu serveru, úrovně saturace a také teploty komponent při běhu v prostředí s vysokou databází. To vám dá základní představu o tom, jak dobrý server je, a předvídá pracovní zátěž, kterou server dokáže zpracovat pro naši aplikaci ve výrobě.

Chcete-li nainstalovat a nakonfigurovat sysbench, můžete jej zkompilovat ze zdroje nebo nainstalovat balíček z úložiště Percona:

$ yum install -y https://repo.percona.com/yum/percona-release-latest.noarch.rpm
$ yum install -y sysbench

Vytvořte schéma databáze a uživatele na serveru MySQL:

mysql> CREATE DATABASE sbtest;
mysql> CREATE USER 'sbtest'@'localhost' IDENTIFIED BY 'sysbenchP4ss';
mysql> GRANT ALL PRIVILEGES ON sbtest.* TO [email protected]'localhost';

Vygenerujte testovací data:

$ sysbench \
/usr/share/sysbench/oltp_common.lua \
--db-driver=mysql \
--mysql-host=localhost \
--mysql-user=sbtest \
--mysql-password=sysbenchP4ss \
--tables=50 \
--table-size=100000 \
prepare

Potom spusťte benchmark na 1 hodinu (3600 sekund):

$ sysbench \
/usr/share/sysbench/oltp_read_write.lua \
--report-interval=2 \
--threads=64 \
--max-requests=0 \
--db-driver=mysql \
--time=3600 \
--db-ps-mode=disable \
--mysql-host=localhost \
--mysql-user=sbtest \
--mysql-password=sysbenchP4ss \
--tables=50 \
--table-size=100000 \
run

Zatímco test běží, použijte iostat (dostupný v balíčku sysstat) v jiném terminálu ke sledování využití disku, šířky pásma, IOPS a čekání I/O:

$ yum install -y sysstat
$ iostat -x 60

avg-cpu:  %user %nice %system %iowait  %steal %idle
          40.55    0.00 55.27    4.18 0.00 0.00

Device:         rrqm/s wrqm/s     r/s w/s rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await svctm  %util
sda               0.19 6.18 1236.23  816.92 61283.83 14112.44    73.44 4.00 1.96 2.83    0.65 0.34 69.29

Výše uvedený výsledek bude vytištěn každých 60 sekund. Počkejte, až test skončí, a změřte průměr r/s (čtení/sekundu), w/s (zápis/sekundu), %iowait, %util, rkB/sa wkB/s (šířka pásma). Pokud zaznamenáváte relativně nízké využití disku, CPU, RAM nebo sítě, pravděpodobně budete muset zvýšit hodnotu "--threads" na ještě vyšší číslo, aby byly využity všechny zdroje na limit.

Zvažte následující aspekty, které se mají měřit:

• Dotazy za sekundu =souhrn Sysbench po dokončení testu v části statistiky SQL -> Dotazy -> Za sekundu.
• Latence dotazu =souhrn Sysbench po dokončení testu v části Latence (ms) -> 95. percentil.
• Disk IOPS =průměr r/s + w/s
• Využití disku =průměr %util
• Šířka pásma disku R/W =průměr rkB/s / průměr wkB/s
• Čekání IO disku =průměr %iowait
• Průměrné zatížení serveru =Průměrný průměr zatížení podle top příkazu.
• Využití procesoru MySQL =Průměrné využití procesoru podle údajů top příkazu.

Pomocí ClusterControl můžete snadno sledovat a získat výše uvedené informace prostřednictvím panelu Přehled uzlů, jak je znázorněno na následujícím snímku obrazovky:

Informace shromážděné během zátěžového testu lze navíc použít k vyladění MySQL a podle toho proměnné InnoDB jako innodb_buffer_pool_size, innodb_io_capacity, innodb_io_capacity_max, innodb_write_io_threads, innodb_read_io_threads a také max_connections.

Chcete-li se dozvědět více o benchmarku výkonu MySQL pomocí sysbench, podívejte se na tento blogový příspěvek Jak srovnávat výkon MySQL a MariaDB pomocí SysBench.

Použijte online nástroj pro změnu schématu

Změna schématu je v relačních databázích nevyhnutelná. Jak se aplikace postupem času rozrůstá a stává se náročnější, jistě vyžaduje určitou změnu struktury databáze. Existují některé operace DDL, které znovu sestaví tabulku, čímž zablokují spuštění jiných příkazů DML, a to by mohlo ovlivnit dostupnost vaší databáze, pokud provádíte strukturální změny na velké tabulce. Chcete-li zobrazit seznam blokujících operací DDL, podívejte se na tuto stránku dokumentace MySQL a vyhledejte operace, které mají "Povoluje souběžné DML" =Ne.

Pokud si nemůžete dovolit prostoje na produkčních serverech při provádění změny schématu, je pravděpodobně dobrý nápad nakonfigurovat online nástroj pro změnu schématu v rané fázi. V tomto příkladu nainstalujeme a nakonfigurujeme gh-ost, změnu online schématu vytvořenou Githubem. Gh-ost používá binární logovací proud k zachycení změn v tabulce a asynchronně je aplikuje na ghost tabulku.

Chcete-li nainstalovat gh-ost na box CentOS, jednoduše postupujte podle následujících kroků: 

Krok jedna

 Stáhněte si nejnovějšího ducha odtud: 

$ wget https://github.com/github/gh-ost/releases/download/v1.0.48/gh-ost-1.0.48-1.x86_64.rpm

Krok dva

Nainstalujte balíček:

$ yum localinstall gh-ost-1.0.48-1.x86_64.rpm 

Krok tři

Vytvořte databázového uživatele pro gh-ost, pokud neexistuje, a udělte mu patřičná oprávnění:

mysql> CREATE USER 'gh-ost'@'{host}' IDENTIFIED BY 'ghostP455';
mysql> GRANT ALTER, CREATE, DELETE, DROP, INDEX, INSERT, LOCK TABLES, SELECT, TRIGGER, UPDATE ON {db_name}.* TO 'gh-ost'@'{host}';
mysql> GRANT SUPER, REPLICATION SLAVE ON *.* TO 'gh-ost'@'{host}';

** Nahraďte {host} a {db_name} jejich příslušnými hodnotami. V ideálním případě je {hostitel} jedním z podřízených hostitelů, kteří provedou online změnu schématu. Podrobnosti naleznete v dokumentaci gh-ost.

Krok čtyři

Vytvořte konfigurační soubor gh-ost pro uložení uživatelského jména a hesla pod /root/.gh-ost.cnf:

[client]
user=gh-ost
password=ghostP455

Podobně můžete mít na databázovém serveru nakonfigurovanou změnu schématu Percona Toolkit Online Schema Change (pt-osc). Cílem je ujistit se, že jste s tímto nástrojem připraveni nejprve na databázovém serveru, na kterém bude tato operace v budoucnu pravděpodobně probíhat.

Využijte sadu nástrojů Percona

Percona Toolkit je sbírka pokročilých nástrojů příkazového řádku s otevřeným zdrojovým kódem vyvinutých společností Percona, které jsou navrženy tak, aby prováděly řadu serverů MySQL, MongoDB a PostgreSQL a systémových úloh, které jsou příliš obtížné nebo složité. provést ručně. Tyto nástroje se staly dokonalým zachráncem, který používají správci databází po celém světě k řešení nebo řešení technických problémů nalezených na serverech MySQL a MariaDB.

Chcete-li nainstalovat Percona Toolkit, jednoduše spusťte následující příkaz:

$ yum install https://repo.percona.com/yum/percona-release-latest.noarch.rpm
$ yum install percona-toolkit

V tomto balíčku je k dispozici více než 30 nástrojů. Některé z nich jsou speciálně navrženy pro MongoDB a PostgreSQL. Některé z nejpopulárnějších nástrojů pro odstraňování problémů s MySQL a ladění výkonu jsou pt-stalk, pt-mysql-summary, pt-query-digest, pt-table-checksum, pt-table-sync a pt-archiver. Tato sada nástrojů může správcům databází pomoci ověřit integritu replikace MySQL kontrolou konzistence hlavních a replikových dat, efektivně archivovat řádky, najít duplicitní indexy, analyzovat dotazy MySQL z protokolů a tcpdump a mnoho dalšího.

Následující příklad ukazuje výstup jednoho z nástrojů (pt-table-checksum), kde může provádět online kontrolu konzistence replikace prováděním dotazů na kontrolní součet na hlavním serveru, což vede k různým výsledkům u replik, které nejsou konzistentní s hlavním serverem:

$ pt-table-checksum --no-check-binlog-format --replicate-check-only
Checking if all tables can be checksummed ...
Starting checksum ...

Differences on mysql2.local

TABLE CHUNK CNT_DIFF CRC_DIFF CHUNK_INDEX LOWER_BOUNDARY UPPER_BOUNDARY
mysql.proc 1 0 1
mysql.tables_priv 1 0 1
mysql.user 1 1 1

Výše uvedený výstup ukazuje, že na podřízeném (mysql2.local) jsou 3 tabulky, které nejsou konzistentní s hlavním. Poté můžeme použít nástroj pt-table-sync k opravě chybějících dat z hlavního serveru nebo jednoduše znovu synchronizovat podřízené zařízení.

Uzamknout server

Po dokončení fáze konfigurace a přípravy můžeme izolovat databázový uzel od veřejné sítě a omezit přístup serveru na známé hostitele a sítě. Pokud máte více síťových rozhraní, můžete použít firewall (iptables, firewalld, ufw), skupiny zabezpečení, hosts.allow a/nebo hosts.deny nebo jednoduše zakázat síťové rozhraní obrácené k internetu.

U iptables je důležité zadat komentář pro každé pravidlo pomocí parametru '-m comment --comment':

$ iptables -A INPUT -p tcp -s 192.168.0.0/24 --dport 22 -m comment --comment 'Allow local net to SSH port' -j ACCEPT
$ iptables -A INPUT -p tcp -s 192.168.0.0/24 --dport 3306 -m comment --comment 'Allow local net to MySQL port' -j ACCEPT
$ iptables -A INPUT -p tcp -s 192.168.0.0/24 --dport 9999 -m comment --comment 'Allow local net to backup streaming port' -j ACCEPT
$ iptables -A INPUT -p tcp -s 0.0.0.0/0 -m comment --comment 'Drop everything apart from the above' -j DROP

Podobně pro Ubuntu's Firewall (ufw) musíme nejprve definovat výchozí pravidlo a poté můžeme vytvořit podobná pravidla pro MySQL/MariaDB podobná tomuto:

$ sudo ufw default deny incoming comment 'Drop everything apart from the above'
$ sudo ufw default allow outgoing comment 'Allow outgoing everything'
$ sudo ufw allow from 192.168.0.0/24 to any port 22 comment 'Allow local net to SSH port'
$ sudo ufw allow from 192.168.0.0/24 to any port 3306 comment 'Allow local net to MySQL port'
$ sudo ufw allow from 192.168.0.0/24 to any port 9999 comment 'Allow local net to backup streaming port'

Povolte bránu firewall:

$ ufw enable

Potom ověřte, zda jsou pravidla načtena správně:

$ ufw status verbose
Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)

New profiles: skip

To                         Action From
--                         ------ ----
22                         ALLOW IN 192.168.0.0/24             # Allow local net to SSH port
3306                       ALLOW IN 192.168.0.0/24             # Allow local net to MySQL port
9999                       ALLOW IN 192.168.0.0/24             # Allow local net to backup streaming port

Opět je velmi důležité specifikovat komentáře ke každému pravidlu, abychom pravidlu lépe porozuměli.

Pro omezení vzdáleného přístupu k databázi můžeme také použít server VPN, jak je uvedeno v tomto příspěvku na blogu, Použití OpenVPN k zabezpečení přístupu k vašemu databázovému clusteru v cloudu.

Závěr

Příprava produkčního serveru samozřejmě není snadný úkol, což jsme si ukázali v této sérii blogů. Pokud se obáváte, že byste to podělali, proč nepoužijete ClusterControl k nasazení svého databázového clusteru? ClusterControl má velmi dobré výsledky v nasazování databází a dosud umožnil více než 70 000 nasazení MySQL a MariaDB pro všechna prostředí.