V první části tohoto blogu jsme poskytli přehled nové funkce Streaming Replication v MySQL Galera Cluster. V tomto blogu vám ukážeme, jak to povolit, a podíváme se na výsledky.
Povolení replikace streamování
Důrazně doporučujeme povolit replikaci streamování na úrovni relace pro konkrétní transakce, které interagují s vaší aplikací/klientem.
Jak bylo uvedeno v předchozím blogu, Galera protokoluje své zápisové sady do tabulky wsrep_streaming_log v databázi MySQL. To má potenciál vytvořit úzké hrdlo výkonu, zvláště když je potřeba vrácení zpět. To neznamená, že nemůžete používat replikaci datových proudů, znamená to pouze, že při používání replikace streamování potřebujete efektivně navrhnout svého aplikačního klienta, abyste dosáhli lepšího výkonu. Přesto je nejlepší mít Streaming Replication pro řešení a omezení velkých transakcí.
Povolení replikace datových proudů vyžaduje, abyste definovali replikační jednotku a počet jednotek, které se mají použít při vytváření fragmentů transakce. Tyto proměnné řídí dva parametry:wsrep_trx_fragment_unit a wsrep_trx_fragment_size.
Níže je uveden příklad, jak nastavit tyto dva parametry:
SET SESSION wsrep_trx_fragment_unit='statements';
SET SESSION wsrep_trx_fragment_size=3;V tomto příkladu je fragment nastaven na tři příkazy. Pro každé tři příkazy z transakce uzel vygeneruje, replikuje a certifikuje fragment.
Při vytváření fragmentů si můžete vybrat mezi několika replikačními jednotkami:
- bajtů - Toto definuje velikost fragmentu v bajtech.
- řádky - Toto definuje velikost fragmentu jako počet řádků, které fragment aktualizuje.
- výroky - Toto definuje velikost fragmentu jako počet příkazů ve fragmentu.
Vyberte replikační jednotku a velikost fragmentu, které nejlépe vyhovují konkrétní operaci, kterou chcete spustit.
Streamování replikace v akci
Jak je uvedeno v našem jiném blogu o zpracování velkých transakcí v Mariadb 10.4, provedli jsme a otestovali, jak fungovala streamovací replikace, když byla povolena na základě tohoto kritéria...
- Základní hodnota, nastavte globální hodnotu wsrep_trx_fragment_size=0;
- set global wsrep_trx_fragment_unit='rows'; nastavit globální wsrep_trx_fragment_size=1;
- set global wsrep_trx_fragment_unit='příkazy'; nastavit globální wsrep_trx_fragment_size=1;
- set global wsrep_trx_fragment_unit='příkazy'; nastavit globální wsrep_trx_fragment_size=5;
A výsledky jsou
Transactions: 82.91 per sec., queries: 1658.27 per sec. (100%)
Transactions: 54.72 per sec., queries: 1094.43 per sec. (66%)
Transactions: 54.76 per sec., queries: 1095.18 per sec. (66%)
Transactions: 70.93 per sec., queries: 1418.55 per sec. (86%)Pro tento příklad používáme Percona XtraDB Cluster 8.0.15 přímo z jejich testovací větve pomocí Percona-XtraDB-Cluster_8.0.15.5-27dev.4.2_Linux.x86_64.ssl102.tar.gz stavět.
Potom jsme vyzkoušeli 3-uzlový cluster Galera s informacemi o hostitelích níže:
testnode11 = 192.168.10.110
testnode12 = 192.168.10.120
testnode13 = 192.168.10.130Předvyplnili jsme tabulku z mé databáze sysbench a pokusili jsme se odstranit velmi velké řádky.
[email protected][sbtest]#> select count(*) from sbtest1;
+----------+
| count(*) |
+----------+
| 12608218 |
+----------+
1 row in set (25.55 sec)Nejprve běží bez replikace streamování
[email protected][sbtest]#> select @@wsrep_trx_fragment_unit, @@wsrep_trx_fragment_size, @@innodb_lock_wait_timeout;
+---------------------------+---------------------------+----------------------------+
| @@wsrep_trx_fragment_unit | @@wsrep_trx_fragment_size | @@innodb_lock_wait_timeout |
+---------------------------+---------------------------+----------------------------+
| bytes | 0 | 50000 |
+---------------------------+---------------------------+----------------------------+
1 row in set (0.00 sec)Potom spusťte
[email protected][sbtest]#> delete from sbtest1 where id >= 2000000;Nicméně jsme nakonec dostali vrácení zpět...
---TRANSACTION 648910, ACTIVE 573 sec rollback
mysql tables in use 1, locked 1
ROLLING BACK 164858 lock struct(s), heap size 18637008, 12199395 row lock(s), undo log entries 11961589
MySQL thread id 183, OS thread handle 140041167468288, query id 79286 localhost 127.0.0.1 root wsrep: replicating and certifying write set(-1)
delete from sbtest1 where id >= 2000000Pomocí panelů ClusterControl Dashboard shromáždíte přehled o všech indikacích řízení toku, protože transakce běží pouze na hlavním uzlu (aktivního zapisovače) až do okamžiku potvrzení, neexistuje žádný náznak aktivity pro řízení toku:
V případě, že vás to zajímá, aktuální verze ClusterControl zatím mají přímou podporu pro PXC 8.0 s Galera Cluster 4 (jelikož je stále experimentální). Můžete se však pokusit jej importovat... ale potřebuje drobné úpravy, aby vaše řídicí panely fungovaly správně.
Zpět na proces dotazu. Selhalo, když se vrátilo zpět!
[email protected][sbtest]#> delete from sbtest1 where id >= 2000000;
ERROR 1180 (HY000): Got error 5 - 'Transaction size exceed set threshold' during COMMITbez ohledu na wsrep_max_ws_rows nebo wsrep_max_ws_size,
[email protected][sbtest]#> select @@global.wsrep_max_ws_rows, @@global.wsrep_max_ws_size/(1024*1024*1024);
+----------------------------+---------------------------------------------+
| @@global.wsrep_max_ws_rows | @@global.wsrep_max_ws_size/(1024*1024*1024) |
+----------------------------+---------------------------------------------+
| 0 | 2.0000 |
+----------------------------+---------------------------------------------+
1 row in set (0.00 sec)Nakonec dosáhl prahu.
Během této doby je systémová tabulka mysql.wsrep_streaming_log prázdná, což znamená, že streamovací replikace neprobíhá nebo není povolena,
[email protected][sbtest]#> select count(*) from mysql.wsrep_streaming_log;
+----------+
| count(*) |
+----------+
| 0 |
+----------+
1 row in set (0.01 sec)
[email protected][sbtest]#> select count(*) from mysql.wsrep_streaming_log;
+----------+
| count(*) |
+----------+
| 0 |
+----------+
1 row in set (0.00 sec)a to je ověřeno na dalších 2 uzlech (testnode12 a testnode13).
Nyní to zkusme povolit pomocí Streaming Replication
[email protected][sbtest]#> select @@wsrep_trx_fragment_unit, @@wsrep_trx_fragment_size, @@innodb_lock_wait_timeout;
+---------------------------+---------------------------+----------------------------+
| @@wsrep_trx_fragment_unit | @@wsrep_trx_fragment_size | @@innodb_lock_wait_timeout |
+---------------------------+---------------------------+----------------------------+
| bytes | 0 | 50000 |
+---------------------------+---------------------------+----------------------------+
1 row in set (0.00 sec)
[email protected][sbtest]#> set wsrep_trx_fragment_unit='rows'; set wsrep_trx_fragment_size=100;
Query OK, 0 rows affected (0.00 sec)
Query OK, 0 rows affected (0.00 sec)
[email protected][sbtest]#> select @@wsrep_trx_fragment_unit, @@wsrep_trx_fragment_size, @@innodb_lock_wait_timeout;
+---------------------------+---------------------------+----------------------------+
| @@wsrep_trx_fragment_unit | @@wsrep_trx_fragment_size | @@innodb_lock_wait_timeout |
+---------------------------+---------------------------+----------------------------+
| rows | 100 | 50000 |
+---------------------------+---------------------------+----------------------------+
1 row in set (0.00 sec)Co lze očekávat, když je povolena replikace streamování Galera Cluster?
Když byl dotaz proveden v testnode11,
[email protected][sbtest]#> delete from sbtest1 where id >= 2000000;Co se stane, je fragmentace transakce kousek po kousku v závislosti na nastavené hodnotě proměnné wsrep_trx_fragment_size. Pojďme to zkontrolovat v ostatních uzlech:
Hostitel testnode12
[email protected][sbtest]#> pager sed -n '/TRANSACTIONS/,/FILE I\/O/p'; show engine innodb status\G nopager; show global status like 'wsrep%flow%'; select count(*) from mysql.wsrep_streaming_log;
PAGER set to 'sed -n '/TRANSACTIONS/,/FILE I\/O/p''
TRANSACTIONS
------------
Trx id counter 567148
Purge done for trx's n:o < 566636 undo n:o < 0 state: running but idle
History list length 44
LIST OF TRANSACTIONS FOR EACH SESSION:
..
...
---TRANSACTION 421740651985200, not started
0 lock struct(s), heap size 1136, 0 row lock(s)
---TRANSACTION 553661, ACTIVE 190 sec
18393 lock struct(s), heap size 2089168, 1342600 row lock(s), undo log entries 1342600
MySQL thread id 898, OS thread handle 140266050008832, query id 216824 wsrep: applied write set (-1)
--------
FILE I/O
1 row in set (0.08 sec)
PAGER set to stdout
+----------------------------------+--------------+
| Variable_name | Value |
+----------------------------------+--------------+
| wsrep_flow_control_paused_ns | 211197844753 |
| wsrep_flow_control_paused | 0.133786 |
| wsrep_flow_control_sent | 633 |
| wsrep_flow_control_recv | 878 |
| wsrep_flow_control_interval | [ 173, 173 ] |
| wsrep_flow_control_interval_low | 173 |
| wsrep_flow_control_interval_high | 173 |
| wsrep_flow_control_status | OFF |
+----------------------------------+--------------+
8 rows in set (0.00 sec)
+----------+
| count(*) |
+----------+
| 13429 |
+----------+
1 row in set (0.04 sec)
Hostitel testnode13
[email protected][sbtest]#> pager sed -n '/TRANSACTIONS/,/FILE I\/O/p'; show engine innodb status\G nopager; show global status like 'wsrep%flow%'; select count(*) from mysql.wsrep_streaming_log;
PAGER set to 'sed -n '/TRANSACTIONS/,/FILE I\/O/p''
TRANSACTIONS
------------
Trx id counter 568523
Purge done for trx's n:o < 567824 undo n:o < 0 state: running but idle
History list length 23
LIST OF TRANSACTIONS FOR EACH SESSION:
..
...
---TRANSACTION 552701, ACTIVE 216 sec
21587 lock struct(s), heap size 2449616, 1575700 row lock(s), undo log entries 1575700
MySQL thread id 936, OS thread handle 140188019226368, query id 600980 wsrep: applied write set (-1)
--------
FILE I/O
1 row in set (0.28 sec)
PAGER set to stdout
+----------------------------------+--------------+
| Variable_name | Value |
+----------------------------------+--------------+
| wsrep_flow_control_paused_ns | 210755642443 |
| wsrep_flow_control_paused | 0.0231273 |
| wsrep_flow_control_sent | 1653 |
| wsrep_flow_control_recv | 3857 |
| wsrep_flow_control_interval | [ 173, 173 ] |
| wsrep_flow_control_interval_low | 173 |
| wsrep_flow_control_interval_high | 173 |
| wsrep_flow_control_status | OFF |
+----------------------------------+--------------+
8 rows in set (0.01 sec)
+----------+
| count(*) |
+----------+
| 15758 |
+----------+
1 row in set (0.03 sec)Viditelně se právě aktivovalo řízení toku!
A také odesílané/přijímané fronty WSREP:
Hostitel testnode12 (192.168.10.120) 
Hostitel testnode13 (192.168.10.130)Nyní pojďme rozpracovat výsledek z tabulky mysql.wsrep_streaming_log,
[email protected][sbtest]#> pager sed -n '/TRANSACTIONS/,/FILE I\/O/p'|tail -8; show engine innodb status\G nopager;
PAGER set to 'sed -n '/TRANSACTIONS/,/FILE I\/O/p'|tail -8'
MySQL thread id 134822, OS thread handle 140041167468288, query id 0 System lock
---TRANSACTION 649008, ACTIVE 481 sec
mysql tables in use 1, locked 1
53104 lock struct(s), heap size 6004944, 3929602 row lock(s), undo log entries 3876500
MySQL thread id 183, OS thread handle 140041167468288, query id 105367 localhost 127.0.0.1 root updating
delete from sbtest1 where id >= 2000000
--------
FILE I/O
1 row in set (0.01 sec)poté převezme výsledek,
[email protected][sbtest]#> select count(*) from mysql.wsrep_streaming_log;
+----------+
| count(*) |
+----------+
| 38899 |
+----------+
1 row in set (0.40 sec)Říká, kolik fragmentů bylo replikováno pomocí Streaming Replication. Nyní si pojďme udělat základní matematiku:
[email protected][sbtest]#> select 3876500/38899.0;
+-----------------+
| 3876500/38899.0 |
+-----------------+
| 99.6555 |
+-----------------+
1 row in set (0.03 sec)Přebírám položky protokolu zpět z výsledku SHOW ENGINE INNODB STATUS\G a poté vydělím celkový počet záznamů mysql.wsrep_streaming_log. Jak jsem to nastavil dříve, definoval jsem wsrep_trx_fragment_size=100. Výsledek vám ukáže, kolik celkových replikovaných protokolů aktuálně zpracovává Galera.
Je důležité vzít na vědomí, čeho se Streaming Replication snaží dosáhnout... "uzel rozdělí transakci na fragmenty, poté je certifikuje a replikuje na podřízených zařízeních, zatímco transakce stále probíhá pokrok. Po certifikaci již fragment nelze zrušit konfliktními transakcemi."
Fragmenty jsou považovány za transakce, které byly předány zbývajícím uzlům v clusteru, certifikují fragmentovanou transakci a poté aplikují sady zápisu. To znamená, že jakmile bude vaše velká transakce certifikována nebo upřednostněna, všechna příchozí připojení, která by mohla uváznout, budou muset počkat, dokud transakce neskončí.
Teď, verdikt smazání obrovské tabulky?
[email protected][sbtest]#> delete from sbtest1 where id >= 2000000;
Query OK, 12034538 rows affected (30 min 36.96 sec)Dokončí se úspěšně bez jakéhokoli selhání!
Jak to vypadá v ostatních uzlech? V testnode12,
[email protected][sbtest]#> pager sed -n '/TRANSACTIONS/,/FILE I\/O/p'|tail -8; show engine innodb status\G nopager; show global status like 'wsrep%flow%'; select count(*) from mysql.wsrep_streaming_log;
PAGER set to 'sed -n '/TRANSACTIONS/,/FILE I\/O/p'|tail -8'
0 lock struct(s), heap size 1136, 0 row lock(s)
---TRANSACTION 421740651985200, not started
0 lock struct(s), heap size 1136, 0 row lock(s)
---TRANSACTION 553661, ACTIVE (PREPARED) 2050 sec
165631 lock struct(s), heap size 18735312, 12154883 row lock(s), undo log entries 12154883
MySQL thread id 898, OS thread handle 140266050008832, query id 341835 wsrep: preparing to commit write set(215510)
--------
FILE I/O
1 row in set (0.46 sec)
PAGER set to stdout
+----------------------------------+--------------+
| Variable_name | Value |
+----------------------------------+--------------+
| wsrep_flow_control_paused_ns | 290832524304 |
| wsrep_flow_control_paused | 0 |
| wsrep_flow_control_sent | 0 |
| wsrep_flow_control_recv | 0 |
| wsrep_flow_control_interval | [ 173, 173 ] |
| wsrep_flow_control_interval_low | 173 |
| wsrep_flow_control_interval_high | 173 |
| wsrep_flow_control_status | OFF |
+----------------------------------+--------------+
8 rows in set (0.53 sec)
+----------+
| count(*) |
+----------+
| 120345 |
+----------+
1 row in set (0.88 sec)Zastaví se na celkovém počtu 120345 fragmentů, a pokud provedeme výpočet znovu s posledními zachycenými položkami protokolu vrácení zpět (protokoly zpět jsou stejné i z hlavního),
[email protected][sbtest]#> select 12154883/120345.0; +-------------------+
| 12154883/120345.0 |
+-------------------+
| 101.0003 |
+-------------------+
1 row in set (0.00 sec)Měli jsme tedy celkem 120345 transakce jsou fragmentovány za účelem odstranění 12034538 řádky.
Jakmile skončíte s používáním nebo povolením replikace datových proudů, nezapomeňte ji zakázat, protože bude vždy zaznamenávat velké transakce a zvyšuje výkon vašeho clusteru. Chcete-li jej zakázat, stačí spustit
[email protected][sbtest]#> set wsrep_trx_fragment_size=0;
Query OK, 0 rows affected (0.04 sec)Závěr
S povolenou replikací streamování je důležité, abyste byli schopni určit, jak velká může být velikost vašeho fragmentu a jakou jednotku musíte zvolit (bajty, řádky, příkazy).
Je také velmi důležité, abyste jej spouštěli na úrovni relace a samozřejmě identifikovali, kdy potřebujete použít pouze streamovací replikaci.
Při provádění těchto testů odstranění velkého počtu řádků z velké tabulky s povolenou replikací streamování znatelně způsobilo vysokou špičku využití disku a CPU. RAM byla stabilnější, ale to by vzhledem k prohlášení, které jsme provedli, nebylo příliš sporné o paměť.
S jistotou lze říci, že Streaming Replication může způsobit problémy s výkonem při práci s velkými záznamy, takže by se mělo jednat o správné rozhodnutí a opatrnost.
A konečně, pokud používáte replikaci streamování, nezapomeňte to vždy zakázat, jakmile to uděláte v aktuální relaci, abyste předešli nechtěným problémům.