In het eerste deel van deze blog hebben we een overzicht gegeven van de nieuwe Streaming Replication-functie in MySQL Galera Cluster. In deze blog laten we je zien hoe je dit kunt inschakelen en bekijken we de resultaten.
Streaming-replicatie inschakelen
Het wordt ten zeerste aanbevolen om streamingreplicatie op sessieniveau in te schakelen voor de specifieke transacties die interactie hebben met uw toepassing/client.
Zoals vermeld in de vorige blog, logt Galera zijn schrijfsets in de wsrep_streaming_log-tabel in de MySQL-database. Dit kan een prestatieknelpunt creëren, vooral wanneer een rollback nodig is. Dit betekent niet dat u Streaming Replication niet kunt gebruiken, het betekent alleen dat u uw toepassingsclient efficiënt moet ontwerpen wanneer u Streaming Replication gebruikt, zodat u betere prestaties krijgt. Toch is het het beste om Streaming Replication te hebben voor het afhandelen en verminderen van grote transacties.
Als u streamingreplicatie inschakelt, moet u de replicatie-eenheid en het aantal eenheden definiëren om te gebruiken bij het vormen van de transactiefragmenten. Twee parameters besturen deze variabelen:wsrep_trx_fragment_unit en wsrep_trx_fragment_size.
Hieronder ziet u een voorbeeld van hoe u deze twee parameters instelt:
SET SESSION wsrep_trx_fragment_unit='statements';
SET SESSION wsrep_trx_fragment_size=3;In dit voorbeeld is het fragment ingesteld op drie instructies. Voor elke drie verklaringen van een transactie zal het knooppunt een fragment genereren, repliceren en certificeren.
Je kunt kiezen tussen een paar replicatie-eenheden bij het vormen van fragmenten:
- bytes - Dit definieert de fragmentgrootte in bytes.
- rijen - Dit definieert de fragmentgrootte als het aantal rijen dat het fragment bijwerkt.
- uitspraken - Dit definieert de fragmentgrootte als het aantal uitspraken in een fragment.
Kies de replicatie-eenheid en fragmentgrootte die het beste passen bij de specifieke bewerking die u wilt uitvoeren.
Streaming-replicatie in actie
Zoals besproken in onze andere blog over het afhandelen van grote transacties in Mariadb 10.4, hebben we op basis van deze criteria uitgevoerd en getest hoe streaming-replicatie presteerde indien ingeschakeld...
- Basislijn, stel globaal in wsrep_trx_fragment_size=0;
- stel globaal wsrep_trx_fragment_unit='rijen' in; stel globaal wsrep_trx_fragment_size=1 in;
- stel globale wsrep_trx_fragment_unit='statements' in; stel globaal wsrep_trx_fragment_size=1 in;
- stel globale wsrep_trx_fragment_unit='statements' in; stel globaal in wsrep_trx_fragment_size=5;
En de resultaten zijn
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%)Voor dit voorbeeld gebruiken we Percona XtraDB Cluster 8.0.15 rechtstreeks vanuit hun testtak met de Percona-XtraDB-Cluster_8.0.15.5-27dev.4.2_Linux.x86_64.ssl102.tar.gz bouwen.
We hebben toen een Galera-cluster met 3 knooppunten geprobeerd met onderstaande hosts-info:
testnode11 = 192.168.10.110
testnode12 = 192.168.10.120
testnode13 = 192.168.10.130We hebben vooraf een tabel ingevuld uit mijn sysbench-database en geprobeerd een zeer grote rij te verwijderen.
[email protected][sbtest]#> select count(*) from sbtest1;
+----------+
| count(*) |
+----------+
| 12608218 |
+----------+
1 row in set (25.55 sec)Eerst draaiend zonder streamingreplicatie,
[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)Rennen,
[email protected][sbtest]#> delete from sbtest1 where id >= 2000000;We kregen uiteindelijk een terugdraaiing...
---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 >= 2000000ClusterControl-dashboards gebruiken om een overzicht te krijgen van enige indicatie van flow control, aangezien de transactie tot de commit-tijd uitsluitend op de master (active-writer) node wordt uitgevoerd, is er geen indicatie van activiteit voor flow control:
In het geval u zich dit afvraagt, de huidige versie van ClusterControl nog niet hebben directe ondersteuning voor PXC 8.0 met Galera Cluster 4 (omdat het nog experimenteel is). U kunt het echter proberen te importeren... maar er zijn kleine aanpassingen nodig om uw Dashboards correct te laten werken.
Terug naar het zoekproces. Het mislukte toen het terugdraaide!
[email protected][sbtest]#> delete from sbtest1 where id >= 2000000;
ERROR 1180 (HY000): Got error 5 - 'Transaction size exceed set threshold' during COMMITongeacht de wsrep_max_ws_rows of 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)Het bereikte uiteindelijk de drempel.
Gedurende deze tijd is de systeemtabel mysql.wsrep_streaming_log leeg, wat aangeeft dat streamingreplicatie niet plaatsvindt of is ingeschakeld,
[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)en dat is geverifieerd op de andere 2 nodes (testnode12 en testnode13).
Laten we nu proberen het in te schakelen met 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)Wat te verwachten als Galera Cluster Streaming Replicatie is ingeschakeld?
Als de query is uitgevoerd in testnode11,
[email protected][sbtest]#> delete from sbtest1 where id >= 2000000;Wat er gebeurt, is dat de transactie stuk voor stuk wordt gefragmenteerd, afhankelijk van de ingestelde waarde van de variabele wsrep_trx_fragment_size. Laten we dit controleren in de andere knooppunten:
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)Opmerkelijk is dat de stroomregeling zojuist is geactiveerd!
En de WSREP-wachtrijen voor het verzenden/ontvangen zijn ook toegenomen:
Host testnode12 (192.168.10.120) 
Host testnode13 (192.168.10.130)Laten we nu meer van het resultaat uitwerken uit de tabel 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)vervolgens het resultaat nemen van,
[email protected][sbtest]#> select count(*) from mysql.wsrep_streaming_log;
+----------+
| count(*) |
+----------+
| 38899 |
+----------+
1 row in set (0.40 sec)Het vertelt hoeveel fragment is gerepliceerd met behulp van Streaming Replication. Laten we nu wat elementaire wiskunde doen:
[email protected][sbtest]#> select 3876500/38899.0;
+-----------------+
| 3876500/38899.0 |
+-----------------+
| 99.6555 |
+-----------------+
1 row in set (0.03 sec)Ik neem de logboekvermeldingen voor ongedaan maken van het resultaat SHOW ENGINE INNODB STATUS\G en deel vervolgens het totale aantal mysql.wsrep_streaming_log-records. Zoals ik het eerder heb ingesteld, heb ik wsrep_trx_fragment_size=100 gedefinieerd. Het resultaat laat zien hoeveel de totale gerepliceerde logs momenteel door Galera worden verwerkt.
Het is belangrijk om te weten wat Streaming Replication probeert te bereiken... "het knooppunt breekt de transactie in fragmenten, certificeert en repliceert ze op de slaves terwijl de transactie nog in voortgang. Eenmaal gecertificeerd, kan het fragment niet langer worden afgebroken door conflicterende transacties."
De fragmenten worden beschouwd als transacties, die zijn doorgegeven aan de resterende knooppunten binnen het cluster, de gefragmenteerde transactie certificeren en vervolgens de schrijfsets toepassen. Dit betekent dat zodra uw grote transactie is gecertificeerd of prioriteit heeft gekregen, alle inkomende verbindingen die mogelijk vastlopen, moeten wachten tot de transacties zijn voltooid.
Nu, het oordeel over het verwijderen van een enorme tafel?
[email protected][sbtest]#> delete from sbtest1 where id >= 2000000;
Query OK, 12034538 rows affected (30 min 36.96 sec)Het is succesvol voltooid zonder enige fout!
Hoe ziet het eruit in de andere knooppunten? In 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)Het stopt bij een totaal van 120345 fragmenten, en als we de berekening opnieuw doen voor de laatst vastgelegde ongedaan maken log-items (ongedaan maken logs zijn ook hetzelfde van de master),
[email protected][sbtest]#> select 12154883/120345.0; +-------------------+
| 12154883/120345.0 |
+-------------------+
| 101.0003 |
+-------------------+
1 row in set (0.00 sec)We hadden dus in totaal 120345 transacties worden gefragmenteerd om te verwijderen 12034538 rijen.
Als je klaar bent met het gebruiken of inschakelen van Stream Replication, vergeet dan niet om het uit te schakelen, want het zal altijd enorme transacties registreren en veel prestatie-overhead toevoegen aan je cluster. Om het uit te schakelen, voert u gewoon
. uit[email protected][sbtest]#> set wsrep_trx_fragment_size=0;
Query OK, 0 rows affected (0.04 sec)Conclusie
Als streamingreplicatie is ingeschakeld, is het belangrijk dat u kunt bepalen hoe groot uw fragmentgrootte kan zijn en welke eenheid u moet kiezen (bytes, rijen, instructies).
Het is ook erg belangrijk dat je het op sessieniveau moet uitvoeren en natuurlijk moet bepalen wanneer je alleen Streaming Replicatie hoeft te gebruiken.
Tijdens het uitvoeren van deze tests heeft het verwijderen van een groot aantal rijen naar een enorme tabel met Streaming Replication ingeschakeld een merkbaar hoge piek in schijfgebruik en CPU-gebruik veroorzaakt. Het RAM-geheugen was stabieler, maar dit kan vanwege de verklaring die we hebben uitgevoerd niet echt een geheugenconflict zijn.
Het is veilig om te zeggen dat streamingreplicatie prestatieknelpunten kan veroorzaken bij het omgaan met grote records, dus het gebruik ervan moet met de juiste beslissing en zorg gebeuren.
Ten slotte, als u Streaming Replicatie gebruikt, vergeet dan niet om dit altijd uit te schakelen zodra u dit in die huidige sessie heeft gedaan om ongewenste problemen te voorkomen.