Het afhandelen van grote transacties was altijd een pijnpunt in Galera Cluster. De manier waarop Galera-schrijfsetcertificering werkt, veroorzaakt problemen wanneer transacties lang zijn of wanneer een enkele rij vaak op meerdere knooppunten wordt gewijzigd. Als gevolg hiervan moeten transacties worden teruggedraaid en opnieuw worden geprobeerd, wat leidt tot prestatiedalingen. Gelukkig is dit probleem verholpen in Galera 4, een nieuwe release van Galera van Codership. Deze bibliotheek wordt gebruikt in MariaDB 10.4, dus het installeren van MariaDB 10.4 is de gemakkelijkste manier om de nieuw geïntroduceerde functies te testen. In deze blogpost bekijken we hoe de streamingreplicatie kan worden gebruikt om problemen te verhelpen die in eerdere Galera-versies een standaardprobleem waren.
We zullen drie knooppunten van MariaDB Galera-clusterversie 10.4.6 gebruiken, die wordt geleverd met Galera-versie van 26.4.2.
MariaDB [(none)]> show global status like 'wsrep_provider%';
+-----------------------------+------------------------------------------------------------------------------------------------------------------------------------------------+
| Variable_name | Value |
+-----------------------------+------------------------------------------------------------------------------------------------------------------------------------------------+
| wsrep_provider_capabilities | :MULTI_MASTER:CERTIFICATION:PARALLEL_APPLYING:TRX_REPLAY:ISOLATION:PAUSE:CAUSAL_READS:INCREMENTAL_WRITESET:UNORDERED:PREORDERED:STREAMING:NBO: |
| wsrep_provider_name | Galera |
| wsrep_provider_vendor | Codership Oy <[email protected]> |
| wsrep_provider_version | 26.4.2(r4498) |
+-----------------------------+------------------------------------------------------------------------------------------------------------------------------------------------+
4 rows in set (0.001 sec)Er zijn drie belangrijke pijnpunten waarmee streaming-replicatie moet worden omgegaan:
- Lange transacties
- Grote transacties
- Hotspots in tafels
Laten we ze een voor een bekijken en kijken hoe streaming-replicatie ons kan helpen om ermee om te gaan, maar laten we ons eerst concentreren op de certificering van de schrijfset - de hoofdoorzaak van deze problemen die zich voordoen.
Writeset-certificering in Galera-cluster
Galera-cluster bestaat uit meerdere beschrijfbare knooppunten. Elke transactie die op het Galera-cluster wordt uitgevoerd, vormt een schrijfset. Elke schrijfset moet voor certificering naar alle knooppunten in het cluster worden verzonden - een proces dat ervoor zorgt dat alle knooppunten een bepaalde transactie kunnen toepassen. Schrijfsets moeten worden uitgevoerd op alle clusterknooppunten, dus als er een conflict is, kan de transactie niet worden doorgevoerd. Wat zijn typische redenen waarom de transactie niet kan worden uitgevoerd? Welnu, de drie punten die we eerder noemden:
- Lange transacties - de transactie duurt langer, de kans is groter dat in de tussentijd een ander knooppunt updates uitvoert die uiteindelijk in conflict zullen komen met de schrijfset en ervoor zorgen dat deze de certificering niet doorstaat
- Grote transacties - ten eerste zijn grote transacties ook langer dan kleine, dus dat veroorzaakt het eerste probleem. Het tweede probleem, dat strikt verband houdt met de grote transacties, is het volume van de wijzigingen. Er zullen meer rijen worden bijgewerkt, maar het is waarschijnlijker dat schrijven op een ander knooppunt zal resulteren in een conflict en dat de hele transactie moet worden teruggedraaid.
- Hotspots in tabellen - het is waarschijnlijker dat een bepaalde rij wordt bijgewerkt, meer waarschijnlijk dat een dergelijke update tegelijkertijd op meerdere knooppunten zal plaatsvinden, wat ertoe leidt dat sommige transacties worden teruggedraaid
Het belangrijkste probleem hier is dat Galera geen vergrendeling op andere knooppunten introduceert dan het oorspronkelijke knooppunt waarop de transactie werd geopend. Het certificeringsproces is gebaseerd op de hoop dat als één knooppunt een transactie zou kunnen uitvoeren, anderen dat ook zouden moeten kunnen. Het is waar, maar zoals we hebben besproken, zijn er hoekgevallen waarin de kans dat dit gebeurt aanzienlijk wordt verminderd.
In Galera 4, met streamingreplicatie, is het gedrag veranderd en worden alle vergrendelingen in alle knooppunten genomen. Transacties worden opgesplitst in delen en elk deel wordt gecertificeerd op alle knooppunten. Na succesvolle certificering worden rijen vergrendeld op alle knooppunten in het cluster. Er zijn een aantal variabelen die bepalen hoe dit precies wordt gedaan - wsrep_trx_fragment_size en wsrep_trx_fragment_unit bepalen hoe groot het fragment moet zijn en hoe het moet worden gedefinieerd. Het is een zeer fijnmazige controle:u kunt de fragmenteenheid definiëren als bytes, statements of rijen, wat het mogelijk maakt om de certificering uit te voeren voor elke rij die in de transactie is gewijzigd. Laten we eens kijken hoe u in het echte leven kunt profiteren van de streamingreplicatie.
Werken met de streamingreplicatie
Laten we eens kijken naar het volgende scenario. We moeten een transactie uitvoeren die minstens 30 seconden duurt:
BEGIN; UPDATE sbtest.sbtest1 SET k = k - 2 WHERE id < 2000 ; UPDATE sbtest.sbtest1 SET k = k + 1 WHERE id < 2000 ; UPDATE sbtest.sbtest1 SET k = k + 1 WHERE id < 2000 ; SELECT SLEEP(30); COMMIT;Vervolgens, terwijl het actief is, zullen we SQL uitvoeren die vergelijkbare rijen raakt. Dit wordt uitgevoerd op een ander knooppunt:
BEGIN; UPDATE sbtest.sbtest1 SET k = k - 1 WHERE id < 20 ; UPDATE sbtest.sbtest1 SET k = k + 1 WHERE id < 20 ; COMMIT;Wat zou het resultaat zijn?
De eerste transactie wordt teruggedraaid zodra de tweede is uitgevoerd:
MariaDB [sbtest]> BEGIN; UPDATE sbtest.sbtest1 SET k = k - 2 WHERE id < 2000 ; UPDATE sbtest.sbtest1 SET k = k + 1 WHERE id < 2000 ; UPDATE sbtest.sbtest1 SET k = k + 1 WHERE id < 2000 ; SELECT SLEEP(30); COMMIT;
Query OK, 0 rows affected (0.001 sec)
Query OK, 667 rows affected (0.020 sec)
Rows matched: 667 Changed: 667 Warnings: 0
Query OK, 667 rows affected (0.010 sec)
Rows matched: 667 Changed: 667 Warnings: 0
Query OK, 667 rows affected (0.009 sec)
Rows matched: 667 Changed: 667 Warnings: 0
ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction
Query OK, 0 rows affected (0.001 sec)De transactie op het tweede knooppunt is gelukt:
MariaDB [(none)]> BEGIN; UPDATE sbtest.sbtest1 SET k = k - 1 WHERE id < 20 ; UPDATE sbtest.sbtest1 SET k = k + 1 WHERE id < 20 ; COMMIT;
Query OK, 0 rows affected (0.000 sec)
Query OK, 7 rows affected (0.002 sec)
Rows matched: 7 Changed: 7 Warnings: 0
Query OK, 7 rows affected (0.001 sec)
Rows matched: 7 Changed: 7 Warnings: 0
Query OK, 0 rows affected (0.004 sec)Wat we kunnen doen om dit te voorkomen, is door streamingreplicatie te gebruiken voor de eerste transactie. We zullen Galera vragen om elke rijwijziging te certificeren:
MariaDB [sbtest]> BEGIN; SET SESSION wsrep_trx_fragment_size=1 ; SET SESSION wsrep_trx_fragment_unit='rows' ; UPDATE sbtest.sbtest1 SET k = k - 2 WHERE id < 2000 ; UPDATE sbtest.sbtest1 SET k = k + 1 WHERE id < 2000 ; UPDATE sbtest.sbtest1 SET k = k + 1 WHERE id < 2000 ; SELECT SLEEP(30); COMMIT; SET SESSION wsrep_trx_fragment_size=0;
Query OK, 0 rows affected (0.001 sec)
Query OK, 0 rows affected (0.000 sec)
Query OK, 0 rows affected (0.000 sec)
Query OK, 667 rows affected (1.757 sec)
Rows matched: 667 Changed: 667 Warnings: 0
Query OK, 667 rows affected (1.708 sec)
Rows matched: 667 Changed: 667 Warnings: 0
Query OK, 667 rows affected (1.685 sec)
Rows matched: 667 Changed: 667 Warnings: 0Zoals je kunt zien, werkte het deze keer prima. Op het tweede knooppunt:
MariaDB [(none)]> BEGIN; UPDATE sbtest.sbtest1 SET k = k - 1 WHERE id < 20 ; UPDATE sbtest.sbtest1 SET k = k + 1 WHERE id < 20 ; COMMIT;
Query OK, 0 rows affected (0.000 sec)
Query OK, 7 rows affected (33.942 sec)
Rows matched: 7 Changed: 7 Warnings: 0
Query OK, 7 rows affected (0.001 sec)
Rows matched: 7 Changed: 7 Warnings: 0
Query OK, 0 rows affected (0.026 sec)Wat interessant is, je kunt zien dat de UPDATE bijna 34 seconden duurde om uit te voeren - dit werd veroorzaakt door het feit dat de eerste transactie, via de streamingreplicatie, alle gewijzigde rijen op alle knooppunten blokkeerde en onze tweede transactie moest wachten op de eerste om te voltooien, ook al werden beide transacties op verschillende knooppunten uitgevoerd.
Dit is het eigenlijk als het gaat om de streaming-replicatie. Afhankelijk van de vereisten en het verkeer kunt u het op een minder strikte manier gebruiken - we hebben elke rij gecertificeerd, maar u kunt dat wijzigen in elke n-de rij of elke verklaring. U kunt zelfs beslissen over de hoeveelheid gegevens die u wilt certificeren. Dit zou voldoende moeten zijn om aan de vereisten van uw omgeving te voldoen.
Er zijn nog een paar dingen die we willen dat u in gedachten houdt en onthoudt. Allereerst is streaming-replicatie geenszins een oplossing die standaard zou moeten worden gebruikt. Dit is de reden waarom het standaard is uitgeschakeld. Het aanbevolen gebruiksscenario is om handmatig te beslissen over transacties die baat zouden hebben bij de streamingreplicatie en deze op sessieniveau in te schakelen. Dit is de reden waarom onze voorbeelden eindigen met:
SET SESSION wsrep_trx_fragment_size=0;Deze instructie (wsrep_trx_fragment_size instelt op 0) schakelt streaming-replicatie uit voor de huidige sessie.
Nog iets dat het waard is om te onthouden:als u streamingreplicatie gebruikt, wordt de tabel 'wsrep_streaming_log' in het schema 'mysql' gebruikt om de gegevens die worden gestreamd permanent op te slaan. Met behulp van deze tabel kunt u een idee krijgen van de gegevens die via streaming-replicatie over het cluster worden overgedragen.
Tot slot het optreden. Dit is ook een van de redenen waarom u niet altijd gebruik wilt maken van streaming-replicatie. De belangrijkste reden daarvoor is vergrendeling - met streamingreplicatie moet u rijvergrendelingen op alle knooppunten verkrijgen. Dit kost tijd om de vergrendelingen te krijgen en als u de transactie moet terugdraaien, zal dit ook alle knooppunten onder druk zetten om het terugdraaien uit te voeren. We hebben een zeer snelle test uitgevoerd van de prestatie-impact die de streamingreplicatie heeft. De omgeving is strikt een testomgeving, dus ga er niet vanuit dat die resultaten hetzelfde zijn op de hardware van productiekwaliteit, het is meer aan u om te zien wat de impact zou kunnen zijn.
We hebben vier scenario's getest:
- 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;
We gebruikten de sysbench r/w-test:
sysbench /root/sysbench/src/lua/oltp_read_write.lua --threads=4 --events=0 --time=300 --mysql-host=10.0.0.141 --mysql-user=sbtest --mysql-password=sbtest --mysql-port=3306 --tables=32 --report-interval=1 --skip-trx=off --table-size=100000 --db-ps-mode=disable runDe resultaten zijn:
- Transacties:82,91 per sec., zoekopdrachten:1658,27 per sec. (100%)
- Transacties:54,72 per sec., queries:1094,43 per sec. (66%)
- Transacties:54,76 per sec., queries:1095,18 per sec. (66%)
- Transacties:70,93 per sec., queries:1418,55 per sec. (86%)
Zoals u kunt zien, is de impact aanzienlijk, de prestaties dalen zelfs met 33%.
We hopen dat je deze blogpost informatief vond en dat het je enig inzicht heeft gegeven in de streamingreplicatie die wordt geleverd met Galera 4 en MariaDB 10.4. We hebben geprobeerd gebruiksgevallen en mogelijke nadelen van deze nieuwe technologie te bespreken.