Ръководство за поточно репликация на клъстер на MySQL Galera:част втора

В първата част на този блог предоставихме преглед на новата функция за поточно репликация в MySQL Galera Cluster. В този блог ще ви покажем как да го активирате и ще разгледаме резултатите.

Активиране на поточно репликация

Силно препоръчително е да активирате поточно репликация на ниво сесия за конкретните транзакции, които взаимодействат с вашето приложение/клиент.

Както беше посочено в предишния блог, Galera регистрира своите набори за запис в таблицата wsrep_streaming_log в базата данни на MySQL. Това има потенциал да създаде затруднение в производителността, особено когато е необходимо връщане назад. Това не означава, че не можете да използвате поточно репликация, това просто означава, че трябва да проектирате ефективно клиента на приложението си, когато използвате поточно репликация, за да получите по-добра производителност. Все пак е най-добре да имате поточно репликация за справяне и намаляване на големи транзакции.

Активирането на поточно репликация изисква да дефинирате единицата за репликация и броя на единиците, които да използвате при формиране на фрагментите на транзакцията. Два параметъра контролират тези променливи:wsrep_trx_fragment_unit и wsrep_trx_fragment_size.

По-долу е даден пример как да зададете тези два параметъра:

SET SESSION wsrep_trx_fragment_unit='statements';

SET SESSION wsrep_trx_fragment_size=3;

В този пример фрагментът е настроен на три израза. За всеки три израза от транзакция възелът ще генерира, репликира и сертифицира фрагмент.

Можете да избирате между няколко единици за репликация, когато формирате фрагменти:

байтове - Това определя размера на фрагмента в байтове.
редове - Това определя размера на фрагмента като броя на редовете, които фрагментът актуализира.
изявления - Това определя размера на фрагмента като броя на изразите във фрагмент.

Изберете единицата за репликация и размера на фрагмента, които най-добре отговарят на конкретната операция, която искате да изпълните.

Поточно репликация в действие

Както беше обсъдено в другия ни блог относно обработката на големи транзакции в Mariadb 10.4, ние изпълнихме и тествахме как се представя поточно репликацията, когато е активирана въз основа на този критерий...

Основна линия, задайте глобално wsrep_trx_fragment_size=0;
задаване глобално wsrep_trx_fragment_unit='редове'; задайте глобален wsrep_trx_fragment_size=1;
задаване глобално wsrep_trx_fragment_unit='изявления'; задайте глобален wsrep_trx_fragment_size=1;
задаване глобално wsrep_trx_fragment_unit='изявления'; задайте глобален wsrep_trx_fragment_size=5;

И резултатите са

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%)

За този пример използваме Percona XtraDB Cluster 8.0.15 направо от техния тестов клон, използвайки Percona-XtraDB-Cluster_8.0.15.5-27dev.4.2_Linux.x86_64.ssl102.tar.gz изграждане

След това опитахме клъстер Galera с 3 възела с информация за хостове по-долу:

testnode11 = 192.168.10.110

testnode12 = 192.168.10.120

testnode13 = 192.168.10.130

Предварително попълнихме таблица от моята база данни sysbench и се опитахме да изтрием много големи редове.

[email protected][sbtest]#> select count(*) from sbtest1;

+----------+

| count(*) |

+----------+

| 12608218 |

+----------+

1 row in set (25.55 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 |

+---------------------------+---------------------------+----------------------------+

| bytes                     | 0 |                         50000 |

+---------------------------+---------------------------+----------------------------+

1 row in set (0.00 sec)

След това стартирайте,

[email protected][sbtest]#> delete from sbtest1 where id >= 2000000;

В крайна сметка обаче получихме връщане назад...

---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 >= 2000000

Използване на табла за управление на ClusterControl за събиране на общ преглед на всяка индикация за контрол на потока, тъй като транзакцията се изпълнява единствено на главния (активен записващ) възел до момента на извършване, няма никакви индикации за активност за контрол на потока:

В случай, че се чудите, текущата версия на ClusterControl все още не имат директна поддръжка за PXC 8.0 с Galera Cluster 4 (тъй като все още е експериментален). Можете обаче да опитате да го импортирате... но се нуждае от малки промени, за да накара вашите табла за управление да работят правилно.

Обратно към процеса на заявка. Не успя, тъй като се върна!

[email protected][sbtest]#> delete from sbtest1 where id >= 2000000;

ERROR 1180 (HY000): Got error 5 - 'Transaction size exceed set threshold' during COMMIT

независимо от wsrep_max_ws_rows или 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)

В крайна сметка достигна прага.

През това време системната таблица mysql.wsrep_streaming_log е празна, което показва, че поточно репликацията не се извършва или е активирана,

[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)

и това е проверено на другите 2 възела (testnode12 и testnode13).

Сега нека опитаме да го активираме с поточно репликация,

[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)

Какво да очаквате, когато поточно репликацията на Galera Cluster е активирана?

Когато заявката е извършена в testnode11,

[email protected][sbtest]#> delete from sbtest1 where id >= 2000000;

Това, което се случва, е, че фрагментира транзакцията част по част в зависимост от зададената стойност на променлива wsrep_trx_fragment_size. Нека проверим това в другите възли:

Host 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)

Host 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)

Забележимо, контролът на потока току-що се включи!

И опашките за изпращане/получаване на WSREP също се засилват:

Host testnode12 (192.168.10.120)

Host testnode13 (192.168.10.130)

Сега, нека да разгледаме повече резултата от таблицата 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)

след това вземане на резултата от,

[email protected][sbtest]#> select count(*) from mysql.wsrep_streaming_log;

+----------+

| count(*) |

+----------+

|    38899 |

+----------+

1 row in set (0.40 sec)

Показва колко фрагмент е репликиран с помощта на поточно репликация. Сега, нека направим някои основни математики:

[email protected][sbtest]#> select 3876500/38899.0;

+-----------------+

| 3876500/38899.0 |

+-----------------+

|         99.6555 |

+-----------------+

1 row in set (0.03 sec)

Вземам записите в дневника за отмяна от резултата SHOW ENGINE INNODB STATUS\G и след това разделям общия брой на записите mysql.wsrep_streaming_log. Както го зададох по-рано, дефинирах wsrep_trx_fragment_size=100. Резултатът ще ви покаже колко общите репликирани регистрационни файлове в момента се обработват от Galera.

Важно е да се отбележи какво се опитва да постигне Streaming Replication... "възелът разбива транзакцията на фрагменти, след което ги сертифицира и репликира на подчинените, докато транзакцията все още е в напредък. След като бъде сертифициран, фрагментът вече не може да бъде прекъснат от конфликтни транзакции."

Фрагментите се считат за транзакции, които са били предадени на останалите възли в клъстера, удостоверявайки фрагментираната транзакция, след което прилагайки наборите за запис. Това означава, че след като вашата голяма транзакция бъде сертифицирана или приоритетна, всички входящи връзки, които евентуално биха могли да имат блокиране, ще трябва да изчакат, докато транзакциите приключат.

Сега, присъдата за изтриване на огромна таблица?

[email protected][sbtest]#> delete from sbtest1 where id >= 2000000;

Query OK, 12034538 rows affected (30 min 36.96 sec)

Завършва успешно без никакъв провал!

Как изглежда в другите възли? В 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)

Спира на общо 120345 фрагмента и ако направим изчисленията отново за последните заснети записи в дневника за отмяна (регистрационните файлове за отмяна са същите и от главния),

[email protected][sbtest]#> select 12154883/120345.0;                                                                                                                                                   +-------------------+

| 12154883/120345.0 |

+-------------------+

|          101.0003 |

+-------------------+

1 row in set (0.00 sec)

Така че имахме общо 120345 транзакциите се фрагментират за изтриване на 12034538 редове.

След като приключите с използването или активирането на поточно репликация, не забравяйте да го деактивирате, тъй като то винаги ще регистрира огромни транзакции и добавя много режийни разходи за производителност към вашия клъстер. За да го деактивирате, просто стартирайте

[email protected][sbtest]#> set wsrep_trx_fragment_size=0;

Query OK, 0 rows affected (0.04 sec)

Заключение

С активирана поточно репликация е важно да можете да определите колко голям може да бъде размерът на вашия фрагмент и каква единица трябва да изберете (байтове, редове, изрази).

Също така е много важно да го стартирате на ниво сесия и разбира се да определите кога трябва да използвате само поточно репликация.

Докато се извършват тези тестове, изтриването на голям брой редове в огромна таблица с активирана поточно репликация забележимо доведе до висок пик на използване на диска и използване на процесора. RAM паметта беше по-стабилна, но това може да се дължи на изявлението, което направихме, не е силно спор за памет.

Може да се каже, че поточно репликацията може да причини затруднения в производителността при работа с големи записи, така че използването му трябва да се прави с подходящо решение и внимателно.

Накрая, ако използвате поточно репликация, не забравяйте винаги да деактивирате това, веднъж направено в текущата сесия, за да избегнете нежелани проблеми.