In deel I hebben we een High Availability (HA)-framework voor MySQL-hosting geïntroduceerd en verschillende componenten en hun functionaliteit besproken. Nu, in deel II, zullen we de details bespreken van MySQL semi-synchrone replicatie en de gerelateerde configuratie-instellingen die ons helpen om redundantie en consistentie van de gegevens in onze HA-configuratie te garanderen. Zorg ervoor dat u terugkomt voor Deel III, waar we verschillende faalscenario's zullen bekijken die zich kunnen voordoen en de manier waarop het raamwerk reageert en herstelt van deze omstandigheden.
Wat is MySQL semisynchrone replicatie?
Simpel gezegd, in een MySQL semi-synchrone replicatieconfiguratie, voert de master transacties alleen door naar de storage-engine na ontvangst van bevestiging van ten minste één van de slaves. De slaven zouden alleen bevestiging geven nadat de gebeurtenissen zijn ontvangen en gekopieerd naar de relaislogboeken en ook naar de schijf zijn gewist. Dit garandeert dat voor alle transacties die zijn vastgelegd en teruggestuurd naar de klant, de gegevens op ten minste 2 knooppunten aanwezig zijn. De term 'semi' in semi-synchrone (replicatie) is te wijten aan het feit dat de master de transacties vastlegt zodra de gebeurtenissen zijn ontvangen en doorgespoeld naar het relaislogboek, maar niet noodzakelijkerwijs wordt vastgelegd in de gegevensbestanden op de slave. Dit in tegenstelling tot volledig synchrone replicatie, waarbij de transactie op zowel de slave als de master zou zijn uitgevoerd voordat de sessie terugkeert naar de client.
Semisynchrone replicatie, die standaard beschikbaar is in MySQL, helpt het HA-framework om gegevensconsistentie en redundantie voor vastgelegde transacties te garanderen. In het geval van een masterstoring, zouden alle transacties die op de master zijn uitgevoerd, zijn gerepliceerd naar ten minste één van de slaven (opgeslagen in de relaislogboeken). Als gevolg hiervan zou failover naar die slave verliesloos zijn omdat de slave up-to-date is (nadat de relaislogboeken van de slave volledig zijn leeggemaakt).
Replicatie en semisynchrone gerelateerde instellingen
Laten we enkele van de belangrijkste MySQL-instellingen bespreken die worden gebruikt om te zorgen voor optimaal gedrag voor hoge beschikbaarheid en gegevensconsistentie in ons raamwerk.
De uitvoeringssnelheid van de slaven beheren
De eerste overweging is om het 'semi'-gedrag van semi-synchrone replicatie af te handelen, wat alleen garandeert dat de gegevens zijn ontvangen en naar de relaislogboeken zijn doorgestuurd door de I/O-thread van de slaaf, maar niet noodzakelijkerwijs vastgelegd door de SQL-thread. Standaard is de SQL-thread in een MySQL-slave single-threaded en kan deze geen gelijke tred houden met de master die multi-threaded is. De voor de hand liggende impact hiervan is dat in het geval van een master-storing, de slave niet up-to-date zal zijn omdat de SQL-thread nog steeds de gebeurtenissen in het relaislogboek verwerkt. Dit zal het failover-proces vertragen, aangezien ons raamwerk verwacht dat de slaaf volledig up-to-date is voordat deze kan worden gepromoot. Dit is nodig om de consistentie van de gegevens te behouden. Om dit probleem aan te pakken, schakelen we slaves met meerdere threads in met de optie slave_parallel_workers om het aantal parallelle SQL-threads in te stellen om gebeurtenissen in de relaislogboeken te verwerken.
Daarnaast configureren we de onderstaande instellingen die ervoor zorgen dat de slave niet in een staat terechtkomt waarin de master zich niet bevond:
- slave-parallel-type =LOGICAL_CLOCK
- slave_preserve_commit_order =1
Dit geeft ons een sterkere gegevensconsistentie. Met deze instellingen kunnen we een betere parallellisatie en snelheid op de slave krijgen, maar als er te veel parallelle threads zijn, zal de overhead die gepaard gaat met de coördinatie tussen de threads ook toenemen en kan dit helaas de voordelen tenietdoen.
Een andere configuratie die we kunnen gebruiken om de efficiëntie van parallelle uitvoering op de slaves te vergroten, is door binlog_group_commit_sync_delay af te stemmen op de master. Door dit op master in te stellen, hebben de binaire log-items op de master en dus de relay-log-items op de slave batches van transacties die parallel kunnen worden verwerkt door de SQL-threads. Dit wordt in detail uitgelegd in de blog van J-F Gagné, waar hij naar dit gedrag verwijst als 'de master vertragen om de slaaf te versnellen' .
Als je je MySQL-implementaties beheert via de ScaleGrid-console, heb je de mogelijkheid om continu realtime waarschuwingen te volgen en te ontvangen over de replicatievertraging van de slaves. Het stelt u ook in staat om de bovenstaande parameters dynamisch af te stemmen om ervoor te zorgen dat de slaves hand in hand werken met de master, waardoor u zo min mogelijk tijd kwijt bent aan een failover-proces.
MySQL High Availability Framework uitgelegd - Deel IIKlik om te tweeten
Belangrijke opties voor semisynchrone replicatie
Semisynchrone MySQL-replicatie kan, door het ontwerp, terugvallen op de asynchrone modus op basis van de time-outinstellingen voor slavebevestiging of op basis van het aantal semi-synchrone slaves dat op elk moment beschikbaar is. De asynchrone modus biedt per definitie geen garantie dat vastgelegde transacties worden gerepliceerd naar de slave en daarom zou een verlies van de master leiden tot het verlies van gegevens die niet zijn gerepliceerd. Het standaardontwerp van het ScaleGrid HA-framework is om te voorkomen dat u terugvalt naar de asynchrone modus. Laten we de configuraties bekijken die dit gedrag beïnvloeden.
-
rpl_semi_sync_master_wait_for_slave_count
Deze optie wordt gebruikt om het aantal slaves te configureren dat een bevestiging moet sturen voordat een semi-synchrone master de transactie kan uitvoeren. In de master-slave-configuratie met 3 knooppunten stellen we dit in op 1, zodat we altijd de zekerheid hebben dat de gegevens beschikbaar zijn in ten minste één slave, terwijl we elke prestatie-impact vermijden die gepaard gaat met het wachten op bevestiging van beide slaven.
-
rpl_semi_sync_master_timeout
Deze optie wordt gebruikt om de hoeveelheid tijd in te stellen die een halfsynchrone master wacht op bevestiging van een slave voordat hij terugschakelt naar de asynchrone modus. We hebben dit ingesteld op een relatief hoge time-outwaarde, zodat er geen terugval is naar de asynchrone modus.
Aangezien we met 2 slaves werken en de rpl_semi_sync_master_wait_for_slave_count is ingesteld op 1, hebben we gemerkt dat ten minste één van de slaven binnen een redelijke tijd bevestigt en de master schakelt niet over naar asynchrone modus tijdens tijdelijke netwerkstoringen.
-
rpl_semi_sync_master_wait_no_slave
Dit bepaalt of de master wacht tot de time-outperiode die is geconfigureerd door rpl_semi_sync_master_timeout, is verstreken, zelfs als het aantal slaven daalt tot minder dan het aantal slaves dat is geconfigureerd door rpl_semi_sync_master_wait_for_slave_count tijdens de time-outperiode. We behouden de standaardwaarde AAN zodat de master niet terugvalt op asynchrone replicatie.
Impact van het verliezen van alle halfsynchrone slaven
Zoals we hierboven hebben gezien, voorkomt ons raamwerk dat de master overschakelt naar asynchrone replicatie als alle slaves uitvallen of onbereikbaar worden vanaf de master. De directe impact hiervan is dat schrijfbewerkingen vastlopen op de master, wat van invloed is op de beschikbaarheid van de service. Dit is in wezen zoals beschreven door de CAP-stelling over de beperkingen van elk gedistribueerd systeem. De stelling stelt dat we bij aanwezigheid van een netwerkpartitie ofwel beschikbaarheid ofwel consistentie moeten kiezen, maar niet beide. Netwerkpartitie kan in dit geval worden beschouwd als MySQL-slaves die zijn losgekoppeld van de master omdat ze down of onbereikbaar zijn.
Ons consistentiedoel is ervoor te zorgen dat voor alle vastgelegde transacties de gegevens beschikbaar zijn op ten minste 2 knooppunten. Als gevolg hiervan geeft het ScaleGrid HA-framework in dergelijke gevallen de voorkeur aan consistentie boven beschikbaarheid. Verdere schrijfbewerkingen worden niet geaccepteerd van clients, hoewel de MySQL-master nog steeds de leesverzoeken afhandelt. Dit is een bewuste ontwerpbeslissing die we hebben genomen als standaardgedrag, dat uiteraard kan worden geconfigureerd op basis van de toepassingsvereisten.
Abonneer je op de ScaleGrid-blog zodat je Deel III niet mist, waar we meer faalscenario's en herstelmogelijkheden van het MySQL HA-framework zullen bespreken . Blijf op de hoogte!!
