sql >> Database >  >> RDS >> MariaDB

Galera Cluster Recovery 101 - Een diepe duik in netwerkpartitionering

Een van de coole functies in Galera is automatische node-provisioning en lidmaatschapscontrole. Als een knoop punt faalt of de communicatie verliest, wordt het automatisch uit het cluster verwijderd en blijft het onoperationeel. Zolang de meeste nodes nog communiceren (Galera noemt deze pc - primaire component), is er een zeer grote kans dat de defecte node automatisch opnieuw kan deelnemen, opnieuw kan synchroniseren en de replicatie kan hervatten zodra de connectiviteit terug is.

Over het algemeen zijn alle Galera-knooppunten gelijk. Ze hebben dezelfde dataset en dezelfde rol als masters, en kunnen tegelijkertijd lezen en schrijven verwerken, dankzij Galera-groepscommunicatie en op certificering gebaseerde replicatie-plug-in. Daarom is er eigenlijk geen failover vanuit het oogpunt van de database vanwege dit evenwicht. Alleen vanaf de toepassingskant waarvoor failover vereist is, om de niet-operationele knooppunten over te slaan terwijl het cluster is gepartitioneerd.

In deze blogpost gaan we kijken hoe Galera Cluster knooppunt- en clusterherstel uitvoert in het geval dat er netwerkpartities optreden. Even terzijde:we hebben een tijdje terug een soortgelijk onderwerp behandeld in deze blogpost. Codership heeft het herstelconcept van Galera in detail uitgelegd op de documentatiepagina, Node Failure and Recovery.

Knooppuntstoring en uitzetting

Om het herstel te begrijpen, moeten we eerst begrijpen hoe Galera het falen van de node en het uitzettingsproces detecteert. Laten we dit in een gecontroleerd testscenario stoppen, zodat we het ontruimingsproces beter kunnen begrijpen. Stel dat we een Galera-cluster met drie knooppunten hebben, zoals hieronder geïllustreerd:

De volgende opdracht kan worden gebruikt om onze Galera-provideropties op te halen:

mysql> SHOW VARIABLES LIKE 'wsrep_provider_options'\G

Het is een lange lijst, maar we hoeven ons alleen te concentreren op enkele parameters om het proces uit te leggen:

evs.inactive_check_period = PT0.5S; 
evs.inactive_timeout = PT15S; 
evs.keepalive_period = PT1S; 
evs.suspect_timeout = PT5S; 
evs.view_forget_timeout = P1D;
gmcast.peer_timeout = PT3S;

Allereerst volgt Galera de ISO 8601-opmaak om de duur weer te geven. P1D betekent dat de duur één dag is, terwijl PT15S betekent dat de duur 15 seconden is (let op de tijdaanduiding, T, die voorafgaat aan de tijdwaarde). Bijvoorbeeld als men evs.view_forget_timeout . wil verhogen op anderhalve dag zou men P1DT12H of PT36H instellen.

Aangezien niet alle hosts zijn geconfigureerd met firewallregels, gebruiken we het volgende script met de naam block_galera.sh op galera2 om een ​​netwerkstoring van/naar dit knooppunt te simuleren:

#!/bin/bash
# block_galera.sh
# galera2, 192.168.55.172

iptables -I INPUT -m tcp -p tcp --dport 4567 -j REJECT
iptables -I INPUT -m tcp -p tcp --dport 3306 -j REJECT
iptables -I OUTPUT -m tcp -p tcp --dport 4567 -j REJECT
iptables -I OUTPUT -m tcp -p tcp --dport 3306 -j REJECT
# print timestamp
date

Door het script uit te voeren, krijgen we de volgende uitvoer:

$ ./block_galera.sh
Wed Jul  4 16:46:02 UTC 2018

De gerapporteerde tijdstempel kan worden beschouwd als het begin van de clusterpartitionering, waarbij we galera2 verliezen, terwijl galera1 en galera3 nog steeds online en toegankelijk zijn. Op dit moment ziet onze Galera Cluster-architectuur er ongeveer zo uit:

Vanuit gepartitioneerd knooppuntperspectief

Op galera2 ziet u enkele afdrukken in het MySQL-foutlogboek. Laten we ze opsplitsen in verschillende delen. De downtime begon rond 16:46:02 UTC-tijd en na gmcast.peer_timeout=PT3S , verschijnt het volgende:

2018-07-04 16:46:05 140454904243968 [Note] WSREP: (62116b35, 'tcp://0.0.0.0:4567') connection to peer 8b2041d6 with addr tcp://192.168.55.173:4567 timed out, no messages seen in PT3S
2018-07-04 16:46:05 140454904243968 [Note] WSREP: (62116b35, 'tcp://0.0.0.0:4567') turning message relay requesting on, nonlive peers: tcp://192.168.55.173:4567
2018-07-04 16:46:06 140454904243968 [Note] WSREP: (62116b35, 'tcp://0.0.0.0:4567') connection to peer 737422d6 with addr tcp://192.168.55.171:4567 timed out, no messages seen in PT3S
2018-07-04 16:46:06 140454904243968 [Note] WSREP: (62116b35, 'tcp://0.0.0.0:4567') reconnecting to 8b2041d6 (tcp://192.168.55.173:4567), attempt 0

Bij het passeren van evs.suspect_timeout =PT5S , beide knooppunten galera1 en galera3 worden door galera2 als dood vermoed:

2018-07-04 16:46:07 140454904243968 [Note] WSREP: evs::proto(62116b35, OPERATIONAL, view_id(REG,62116b35,54)) suspecting node: 8b2041d6
2018-07-04 16:46:07 140454904243968 [Note] WSREP: evs::proto(62116b35, OPERATIONAL, view_id(REG,62116b35,54)) suspected node without join message, declaring inactive
2018-07-04 16:46:07 140454904243968 [Note] WSREP: (62116b35, 'tcp://0.0.0.0:4567') reconnecting to 737422d6 (tcp://192.168.55.171:4567), attempt 0
2018-07-04 16:46:08 140454904243968 [Note] WSREP: evs::proto(62116b35, GATHER, view_id(REG,62116b35,54)) suspecting node: 737422d6
2018-07-04 16:46:08 140454904243968 [Note] WSREP: evs::proto(62116b35, GATHER, view_id(REG,62116b35,54)) suspected node without join message, declaring inactive

Vervolgens zal Galera de huidige clusterweergave en de positie van dit knooppunt herzien:

2018-07-04 16:46:09 140454904243968 [Note] WSREP: view(view_id(NON_PRIM,62116b35,54) memb {
        62116b35,0
} joined {
} left {
} partitioned {
        737422d6,0
        8b2041d6,0
})
2018-07-04 16:46:09 140454904243968 [Note] WSREP: view(view_id(NON_PRIM,62116b35,55) memb {
        62116b35,0
} joined {
} left {
} partitioned {
        737422d6,0
        8b2041d6,0
})

Met de nieuwe clusterweergave zal Galera quorumberekeningen uitvoeren om te beslissen of dit knooppunt deel uitmaakt van de primaire component. Als de nieuwe component "primair =nee" ziet, zal Galera de status van het lokale knooppunt verlagen van SYNCED naar OPEN:

2018-07-04 16:46:09 140454288942848 [Note] WSREP: New COMPONENT: primary = no, bootstrap = no, my_idx = 0, memb_num = 1
2018-07-04 16:46:09 140454288942848 [Note] WSREP: Flow-control interval: [16, 16]
2018-07-04 16:46:09 140454288942848 [Note] WSREP: Trying to continue unpaused monitor
2018-07-04 16:46:09 140454288942848 [Note] WSREP: Received NON-PRIMARY.
2018-07-04 16:46:09 140454288942848 [Note] WSREP: Shifting SYNCED -> OPEN (TO: 2753699)

Met de laatste wijziging in de clusterweergave en de knooppuntstatus, retourneert Galera de clusterweergave en de algemene status na de ontruiming zoals hieronder:

2018-07-04 16:46:09 140454222194432 [Note] WSREP: New cluster view: global state: 55238f52-41ee-11e8-852f-3316bdb654bc:2753699, view# -1: non-Primary, number of nodes: 1, my index: 0, protocol version 3
2018-07-04 16:46:09 140454222194432 [Note] WSREP: wsrep_notify_cmd is not defined, skipping notification.

U kunt zien dat de volgende globale status van galera2 in deze periode is gewijzigd:

mysql> SELECT * FROM information_schema.global_status WHERE variable_name IN ('WSREP_CLUSTER_STATUS','WSREP_LOCAL_STATE_COMMENT','WSREP_CLUSTER_SIZE','WSREP_EVS_DELAYED','WSREP_READY');
+---------------------------+-----------------------------------------------------------------------------------------------------------------------------------+
| VARIABLE_NAME             | VARIABLE_VALUE                                                                                                                    |
+---------------------------+-----------------------------------------------------------------------------------------------------------------------------------+
| WSREP_CLUSTER_SIZE        | 1                                                                                                                                 |
| WSREP_CLUSTER_STATUS      | non-Primary                                                                                                                       |
| WSREP_EVS_DELAYED         | 737422d6-7db3-11e8-a2a2-bbe98913baf0:tcp://192.168.55.171:4567:1,8b2041d6-7f62-11e8-87d5-12a76678131f:tcp://192.168.55.173:4567:2 |
| WSREP_LOCAL_STATE_COMMENT | Initialized                                                                                                                       |
| WSREP_READY               | OFF                                                                                                                               |
+---------------------------+-----------------------------------------------------------------------------------------------------------------------------------+

Op dit moment is de MySQL/MariaDB-server op galera2 nog steeds toegankelijk (database luistert op 3306 en Galera op 4567) en kunt u de mysql-systeemtabellen opvragen en de databases en tabellen opsommen. Wanneer u echter in de niet-systeemtabellen springt en een eenvoudige query als deze maakt:

mysql> SELECT * FROM sbtest1;
ERROR 1047 (08S01): WSREP has not yet prepared node for application use

U krijgt onmiddellijk een foutmelding dat WSREP is geladen maar niet klaar voor gebruik door dit knooppunt, zoals gerapporteerd door wsrep_ready toestand. Dit komt doordat het knooppunt de verbinding met de primaire component verliest en het in de niet-operationele status komt (de status van het lokale knooppunt is gewijzigd van SYNCED in OPEN). Het lezen van gegevens van knooppunten in een niet-operationele status wordt als verouderd beschouwd, tenzij u wsrep_dirty_reads=ON instelt om lezen toe te staan, hoewel Galera nog steeds elk commando verwerpt dat de database wijzigt of bijwerkt.

Ten slotte zal Galera oneindig blijven luisteren en opnieuw verbinding maken met andere leden op de achtergrond:

2018-07-04 16:47:12 140454904243968 [Note] WSREP: (62116b35, 'tcp://0.0.0.0:4567') reconnecting to 8b2041d6 (tcp://192.168.55.173:4567), attempt 30
2018-07-04 16:47:13 140454904243968 [Note] WSREP: (62116b35, 'tcp://0.0.0.0:4567') reconnecting to 737422d6 (tcp://192.168.55.171:4567), attempt 30
2018-07-04 16:48:20 140454904243968 [Note] WSREP: (62116b35, 'tcp://0.0.0.0:4567') reconnecting to 8b2041d6 (tcp://192.168.55.173:4567), attempt 60
2018-07-04 16:48:22 140454904243968 [Note] WSREP: (62116b35, 'tcp://0.0.0.0:4567') reconnecting to 737422d6 (tcp://192.168.55.171:4567), attempt 60

Het ontruimingsproces door Galera-groepscommunicatie voor het gepartitioneerde knooppunt tijdens netwerkprobleem kan als volgt worden samengevat:

  1. Verbreekt de verbinding met het cluster na gmcast.peer_timeout .
  2. Verdenkt andere nodes na evs.suspect_timeout .
  3. Haalt de nieuwe clusterweergave op.
  4. Voert quorumberekening uit om de status van het knooppunt te bepalen.
  5. Verlaagt het knooppunt van SYNCED naar OPEN.
  6. Pogingen om opnieuw verbinding te maken met de primaire component (andere Galera-knooppunten) op de achtergrond.

Vanuit het perspectief van de primaire component

Op respectievelijk galera1 en galera3, na gmcast.peer_timeout=PT3S , verschijnt het volgende in het MySQL-foutlogboek:

2018-07-04 16:46:05 139955510687488 [Note] WSREP: (8b2041d6, 'tcp://0.0.0.0:4567') turning message relay requesting on, nonlive peers: tcp://192.168.55.172:4567
2018-07-04 16:46:06 139955510687488 [Note] WSREP: (8b2041d6, 'tcp://0.0.0.0:4567') reconnecting to 62116b35 (tcp://192.168.55.172:4567), attempt 0

Nadat het evs.suspect_timeout =PT5S is gepasseerd , galera2 wordt door galera3 (en galera1) als dood vermoed:

2018-07-04 16:46:10 139955510687488 [Note] WSREP: evs::proto(8b2041d6, OPERATIONAL, view_id(REG,62116b35,54)) suspecting node: 62116b35
2018-07-04 16:46:10 139955510687488 [Note] WSREP: evs::proto(8b2041d6, OPERATIONAL, view_id(REG,62116b35,54)) suspected node without join message, declaring inactive

Galera controleert of de andere nodes reageren op de groepscommunicatie op galera3, het ontdekt dat galera1 zich in de primaire en stabiele toestand bevindt:

2018-07-04 16:46:11 139955510687488 [Note] WSREP: declaring 737422d6 at tcp://192.168.55.171:4567 stable
2018-07-04 16:46:11 139955510687488 [Note] WSREP: Node 737422d6 state prim

Galera herziet de clusterweergave van dit knooppunt (galera3):

2018-07-04 16:46:11 139955510687488 [Note] WSREP: view(view_id(PRIM,737422d6,55) memb {
        737422d6,0
        8b2041d6,0
} joined {
} left {
} partitioned {
        62116b35,0
})
2018-07-04 16:46:11 139955510687488 [Note] WSREP: save pc into disk

Galera verwijdert vervolgens het gepartitioneerde knooppunt van de primaire component:

2018-07-04 16:46:11 139955510687488 [Note] WSREP: forgetting 62116b35 (tcp://192.168.55.172:4567)

De nieuwe primaire component bestaat nu uit twee knooppunten, galera1 en galera3:

2018-07-04 16:46:11 139955502294784 [Note] WSREP: New COMPONENT: primary = yes, bootstrap = no, my_idx = 1, memb_num = 2

De primaire component zal de status onderling uitwisselen om overeenstemming te bereiken over de nieuwe clusterweergave en globale status:

2018-07-04 16:46:11 139955502294784 [Note] WSREP: STATE EXCHANGE: Waiting for state UUID.
2018-07-04 16:46:11 139955510687488 [Note] WSREP: (8b2041d6, 'tcp://0.0.0.0:4567') turning message relay requesting off
2018-07-04 16:46:11 139955502294784 [Note] WSREP: STATE EXCHANGE: sent state msg: b3d38100-7f66-11e8-8e70-8e3bf680c993
2018-07-04 16:46:11 139955502294784 [Note] WSREP: STATE EXCHANGE: got state msg: b3d38100-7f66-11e8-8e70-8e3bf680c993 from 0 (192.168.55.171)
2018-07-04 16:46:11 139955502294784 [Note] WSREP: STATE EXCHANGE: got state msg: b3d38100-7f66-11e8-8e70-8e3bf680c993 from 1 (192.168.55.173)

Galera berekent en verifieert het quorum van de staatsuitwisseling tussen online leden:

2018-07-04 16:46:11 139955502294784 [Note] WSREP: Quorum results:
        version    = 4,
        component  = PRIMARY,
        conf_id    = 27,
        members    = 2/2 (joined/total),
        act_id     = 2753703,
        last_appl. = 2753606,
        protocols  = 0/8/3 (gcs/repl/appl),
        group UUID = 55238f52-41ee-11e8-852f-3316bdb654bc
2018-07-04 16:46:11 139955502294784 [Note] WSREP: Flow-control interval: [23, 23]
2018-07-04 16:46:11 139955502294784 [Note] WSREP: Trying to continue unpaused monitor

Galera werkt de nieuwe clusterweergave en globale status bij na uitzetting van galera2:

2018-07-04 16:46:11 139955214169856 [Note] WSREP: New cluster view: global state: 55238f52-41ee-11e8-852f-3316bdb654bc:2753703, view# 28: Primary, number of nodes: 2, my index: 1, protocol version 3
2018-07-04 16:46:11 139955214169856 [Note] WSREP: wsrep_notify_cmd is not defined, skipping notification.
2018-07-04 16:46:11 139955214169856 [Note] WSREP: REPL Protocols: 8 (3, 2)
2018-07-04 16:46:11 139955214169856 [Note] WSREP: Assign initial position for certification: 2753703, protocol version: 3
2018-07-04 16:46:11 139956691814144 [Note] WSREP: Service thread queue flushed.
Clean up the partitioned node (galera2) from the active list:
2018-07-04 16:46:14 139955510687488 [Note] WSREP: cleaning up 62116b35 (tcp://192.168.55.172:4567)

Op dit moment zullen zowel galera1 als galera3 een vergelijkbare wereldwijde status rapporteren:

mysql> SELECT * FROM information_schema.global_status WHERE variable_name IN ('WSREP_CLUSTER_STATUS','WSREP_LOCAL_STATE_COMMENT','WSREP_CLUSTER_SIZE','WSREP_EVS_DELAYED','WSREP_READY');
+---------------------------+------------------------------------------------------------------+
| VARIABLE_NAME             | VARIABLE_VALUE                                                   |
+---------------------------+------------------------------------------------------------------+
| WSREP_CLUSTER_SIZE        | 2                                                                |
| WSREP_CLUSTER_STATUS      | Primary                                                          |
| WSREP_EVS_DELAYED         | 1491abd9-7f6d-11e8-8930-e269b03673d8:tcp://192.168.55.172:4567:1 |
| WSREP_LOCAL_STATE_COMMENT | Synced                                                           |
| WSREP_READY               | ON                                                               |
+---------------------------+------------------------------------------------------------------+

Ze vermelden het problematische lid in de wsrep_evs_delayed toestand. Aangezien de lokale status "Gesynchroniseerd" is, zijn deze knooppunten operationeel en kunt u de clientverbindingen van galera2 naar elk van hen omleiden. Als deze stap onhandig is, overweeg dan om een ​​load balancer voor de database te gebruiken om het verbindingseindpunt van de clients te vereenvoudigen.

Knooppuntherstel en deelname

Een gepartitioneerd Galera-knooppunt blijft oneindig proberen verbinding te maken met de primaire component. Laten we de iptables-regels op galera2 doorspoelen om het verbinding te laten maken met de resterende knooppunten:

# on galera2
$ iptables -F

Zodra het knooppunt verbinding kan maken met een van de knooppunten, zal Galera automatisch beginnen met het opnieuw tot stand brengen van de groepscommunicatie:

2018-07-09 10:46:34 140075962705664 [Note] WSREP: (1491abd9, 'tcp://0.0.0.0:4567') connection established to 8b2041d6 tcp://192.168.55.173:4567
2018-07-09 10:46:34 140075962705664 [Note] WSREP: (1491abd9, 'tcp://0.0.0.0:4567') connection established to 737422d6 tcp://192.168.55.171:4567
2018-07-09 10:46:34 140075962705664 [Note] WSREP: declaring 737422d6 at tcp://192.168.55.171:4567 stable
2018-07-09 10:46:34 140075962705664 [Note] WSREP: declaring 8b2041d6 at tcp://192.168.55.173:4567 stable

Knooppunt galera2 maakt dan verbinding met een van de primaire componenten (in dit geval is galera1, knooppunt-ID 737422d6) om de huidige clusterweergave en knooppuntenstatus te krijgen:

2018-07-09 10:46:34 140075962705664 [Note] WSREP: Node 737422d6 state prim
2018-07-09 10:46:34 140075962705664 [Note] WSREP: view(view_id(PRIM,1491abd9,142) memb {
        1491abd9,0
        737422d6,0
        8b2041d6,0
} joined {
} left {
} partitioned {
})
2018-07-09 10:46:34 140075962705664 [Note] WSREP: save pc into disk

Galera zal dan een staatsuitwisseling uitvoeren met de rest van de leden die de Primaire Component kunnen vormen:

2018-07-09 10:46:34 140075954312960 [Note] WSREP: New COMPONENT: primary = yes, bootstrap = no, my_idx = 0, memb_num = 3
2018-07-09 10:46:34 140075954312960 [Note] WSREP: STATE_EXCHANGE: sent state UUID: 4b23eaa0-8322-11e8-a87e-fe4e0fce2a5f
2018-07-09 10:46:34 140075954312960 [Note] WSREP: STATE EXCHANGE: sent state msg: 4b23eaa0-8322-11e8-a87e-fe4e0fce2a5f
2018-07-09 10:46:34 140075954312960 [Note] WSREP: STATE EXCHANGE: got state msg: 4b23eaa0-8322-11e8-a87e-fe4e0fce2a5f from 0 (192.168.55.172)
2018-07-09 10:46:34 140075954312960 [Note] WSREP: STATE EXCHANGE: got state msg: 4b23eaa0-8322-11e8-a87e-fe4e0fce2a5f from 1 (192.168.55.171)
2018-07-09 10:46:34 140075954312960 [Note] WSREP: STATE EXCHANGE: got state msg: 4b23eaa0-8322-11e8-a87e-fe4e0fce2a5f from 2 (192.168.55.173)

De staatsuitwisseling stelt galera2 in staat om het quorum te berekenen en het volgende resultaat te produceren:

2018-07-09 10:46:34 140075954312960 [Note] WSREP: Quorum results:
        version    = 4,
        component  = PRIMARY,
        conf_id    = 71,
        members    = 2/3 (joined/total),
        act_id     = 2836958,
        last_appl. = 0,
        protocols  = 0/8/3 (gcs/repl/appl),
        group UUID = 55238f52-41ee-11e8-852f-3316bdb654bc

Galera zal dan de status van het lokale knooppunt promoveren van OPEN naar PRIMAIR, om de knooppuntverbinding met de primaire component te starten en tot stand te brengen:

2018-07-09 10:46:34 140075954312960 [Note] WSREP: Flow-control interval: [28, 28]
2018-07-09 10:46:34 140075954312960 [Note] WSREP: Trying to continue unpaused monitor
2018-07-09 10:46:34 140075954312960 [Note] WSREP: Shifting OPEN -> PRIMARY (TO: 2836958)

Zoals gemeld door de bovenstaande regel, berekent Galera de kloof over hoe ver het knooppunt zich achter het cluster bevindt. Dit knooppunt vereist statusoverdracht om schrijfsetnummer 2836958 van 2761994 in te halen:

2018-07-09 10:46:34 140075929970432 [Note] WSREP: State transfer required:
        Group state: 55238f52-41ee-11e8-852f-3316bdb654bc:2836958
        Local state: 55238f52-41ee-11e8-852f-3316bdb654bc:2761994
2018-07-09 10:46:34 140075929970432 [Note] WSREP: New cluster view: global state: 55238f52-41ee-11e8-852f-3316bdb654bc:2836958, view# 72: Primary, number of nodes:
3, my index: 0, protocol version 3
2018-07-09 10:46:34 140075929970432 [Warning] WSREP: Gap in state sequence. Need state transfer.
2018-07-09 10:46:34 140075929970432 [Note] WSREP: wsrep_notify_cmd is not defined, skipping notification.
2018-07-09 10:46:34 140075929970432 [Note] WSREP: REPL Protocols: 8 (3, 2)
2018-07-09 10:46:34 140075929970432 [Note] WSREP: Assign initial position for certification: 2836958, protocol version: 3

Galera bereidt de IST-listener voor op poort 4568 op dit knooppunt en vraagt ​​elk gesynchroniseerd knooppunt in het cluster om donor te worden. In dit geval kiest Galera automatisch galera3 (192.168.55.173), of het kan ook een donor kiezen uit de lijst onder wsrep_sst_donor (indien gedefinieerd) voor de synchronisatiebewerking:

2018-07-09 10:46:34 140075996276480 [Note] WSREP: Service thread queue flushed.
2018-07-09 10:46:34 140075929970432 [Note] WSREP: IST receiver addr using tcp://192.168.55.172:4568
2018-07-09 10:46:34 140075929970432 [Note] WSREP: Prepared IST receiver, listening at: tcp://192.168.55.172:4568
2018-07-09 10:46:34 140075954312960 [Note] WSREP: Member 0.0 (192.168.55.172) requested state transfer from '*any*'. Selected 2.0 (192.168.55.173)(SYNCED) as donor.

Vervolgens wordt de status van het lokale knooppunt gewijzigd van PRIMARY in JOINER. In dit stadium wordt galera2 verleend met een statusoverdrachtsverzoek en begint het schrijfsets in de cache op te slaan:

2018-07-09 10:46:34 140075954312960 [Note] WSREP: Shifting PRIMARY -> JOINER (TO: 2836958)
2018-07-09 10:46:34 140075929970432 [Note] WSREP: Requesting state transfer: success, donor: 2
2018-07-09 10:46:34 140075929970432 [Note] WSREP: GCache history reset: 55238f52-41ee-11e8-852f-3316bdb654bc:2761994 -> 55238f52-41ee-11e8-852f-3316bdb654bc:2836958
2018-07-09 10:46:34 140075929970432 [Note] WSREP: GCache DEBUG: RingBuffer::seqno_reset(): full reset

Knooppunt galera2 begint de ontbrekende schrijfsets te ontvangen van de gcache van de geselecteerde donor (galera3):

2018-07-09 10:46:34 140075954312960 [Note] WSREP: 2.0 (192.168.55.173): State transfer to 0.0 (192.168.55.172) complete.
2018-07-09 10:46:34 140075929970432 [Note] WSREP: Receiving IST: 74964 writesets, seqnos 2761994-2836958
2018-07-09 10:46:34 140075593627392 [Note] WSREP: Receiving IST...  0.0% (    0/74964 events) complete.
2018-07-09 10:46:34 140075954312960 [Note] WSREP: Member 2.0 (192.168.55.173) synced with group.
2018-07-09 10:46:34 140075962705664 [Note] WSREP: (1491abd9, 'tcp://0.0.0.0:4567') connection established to 737422d6 tcp://192.168.55.171:4567
2018-07-09 10:46:41 140075962705664 [Note] WSREP: (1491abd9, 'tcp://0.0.0.0:4567') turning message relay requesting off
2018-07-09 10:46:44 140075593627392 [Note] WSREP: Receiving IST... 36.0% (27008/74964 events) complete.
2018-07-09 10:46:54 140075593627392 [Note] WSREP: Receiving IST... 71.6% (53696/74964 events) complete.
2018-07-09 10:47:02 140075593627392 [Note] WSREP: Receiving IST...100.0% (74964/74964 events) complete.
2018-07-09 10:47:02 140075929970432 [Note] WSREP: IST received: 55238f52-41ee-11e8-852f-3316bdb654bc:2836958
2018-07-09 10:47:02 140075954312960 [Note] WSREP: 0.0 (192.168.55.172): State transfer from 2.0 (192.168.55.173) complete.

Zodra alle ontbrekende schrijfsets zijn ontvangen en toegepast, zal Galera galera2 promoten als JOINED tot seqno 2837012:

2018-07-09 10:47:02 140075954312960 [Note] WSREP: Shifting JOINER -> JOINED (TO: 2837012)
2018-07-09 10:47:02 140075954312960 [Note] WSREP: Member 0.0 (192.168.55.172) synced with group.

Het knooppunt past alle schrijfsets in de cache toe in de slave-wachtrij en voltooit het inhalen van het cluster. De slave-wachtrij is nu leeg. Galera zal galera2 promoten naar SYNCED, wat aangeeft dat de node nu operationeel is en klaar is om klanten te bedienen:

2018-07-09 10:47:02 140075954312960 [Note] WSREP: Shifting JOINED -> SYNCED (TO: 2837012)
2018-07-09 10:47:02 140076605892352 [Note] WSREP: Synchronized with group, ready for connections

Op dit moment zijn alle knooppunten weer operationeel. U kunt dit verifiëren door de volgende verklaringen op galera2 te gebruiken:

mysql> SELECT * FROM information_schema.global_status WHERE variable_name IN ('WSREP_CLUSTER_STATUS','WSREP_LOCAL_STATE_COMMENT','WSREP_CLUSTER_SIZE','WSREP_EVS_DELAYED','WSREP_READY');
+---------------------------+----------------+
| VARIABLE_NAME             | VARIABLE_VALUE |
+---------------------------+----------------+
| WSREP_CLUSTER_SIZE        | 3              |
| WSREP_CLUSTER_STATUS      | Primary        |
| WSREP_EVS_DELAYED         |                |
| WSREP_LOCAL_STATE_COMMENT | Synced         |
| WSREP_READY               | ON             |
+---------------------------+----------------+

De wsrep_cluster_size gerapporteerd als 3 en de clusterstatus is Primair, wat aangeeft dat galera2 deel uitmaakt van de primaire component. De wsrep_evs_delayed is ook gewist en de lokale staat is nu gesynchroniseerd.

De herstelprocesstroom voor het gepartitioneerde knooppunt tijdens netwerkproblemen kan als volgt worden samengevat:

  1. Herstelt groepscommunicatie met andere nodes.
  2. Haalt de clusterweergave op van een van de primaire componenten.
  3. Voert statusuitwisseling uit met de primaire component en berekent het quorum.
  4. Verandert de status van het lokale knooppunt van OPEN in PRIMAIR.
  5. Berekent de opening tussen het lokale knooppunt en het cluster.
  6. Verandert de status van het lokale knooppunt van PRIMARY in JOINER.
  7. Bereidt IST luisteraar/ontvanger op poort 4568.
  8. Verzoekt staatsoverdracht via IST en kiest een donor.
  9. Begint met het ontvangen en toepassen van de ontbrekende schrijfset van de gcache van de gekozen donor.
  10. Verandert de status van het lokale knooppunt van JOINER in JOINED.
  11. Haalt het cluster in door de in de cache opgeslagen schrijfsets in de slave-wachtrij toe te passen.
  12. Verandert de status van het lokale knooppunt van JOINED in SYNCED.

Clusterfout

Een Galera-cluster wordt als mislukt beschouwd als er geen primaire component (pc) beschikbaar is. Overweeg een vergelijkbare Galera-cluster met drie knooppunten zoals weergegeven in het onderstaande diagram:

Een cluster wordt als operationeel beschouwd als alle knooppunten of de meerderheid van de knooppunten online zijn. Online betekent dat ze elkaar kunnen zien via Galera's replicatieverkeer of groepscommunicatie. Als er geen verkeer van en naar het knooppunt komt, stuurt het cluster een hartslagbaken naar het knooppunt om tijdig te reageren. Anders wordt het in de lijst met vertragingen of verdachten geplaatst, afhankelijk van hoe het knooppunt reageert.

Als een knooppunt uitvalt, laten we zeggen knooppunt C, blijft het cluster operationeel omdat knooppunt A en B nog steeds in quorum zijn met 2 stemmen op 3 om een ​​primaire component te vormen. U zou de volgende clusterstatus op A en B moeten krijgen:

mysql> SHOW STATUS LIKE 'wsrep_cluster_status';
+----------------------+---------+
| Variable_name        | Value   |
+----------------------+---------+
| wsrep_cluster_status | Primary |
+----------------------+---------+

Stel dat een primaire schakelaar kapot is gegaan, zoals geïllustreerd in het volgende diagram:

Op dit punt verliest elk afzonderlijk knooppunt de communicatie met elkaar en wordt de clusterstatus op alle knooppunten gerapporteerd als niet-primair (zoals in het vorige geval met galera2 is gebeurd). Elk knooppunt zou het quorum berekenen en ontdekken dat het de minderheid is (1 stem van de 3) en daarmee het quorum verliezen, wat betekent dat er geen primaire component wordt gevormd en bijgevolg weigeren alle knooppunten om gegevens te verstrekken. Dit wordt beschouwd als een clusterfout.

Zodra het netwerkprobleem is opgelost, zal Galera automatisch de communicatie tussen leden herstellen, de status van de knooppunten uitwisselen en de mogelijkheid bepalen om de primaire component te hervormen door de status van de knooppunten, UUID's en seqno's te vergelijken. Als de kans er is, zal Galera de primaire componenten samenvoegen zoals weergegeven in de volgende regels:

2018-06-27  0:16:57 140203784476416 [Note] WSREP: New COMPONENT: primary = yes, bootstrap = no, my_idx = 2, memb_num = 3
2018-06-27  0:16:57 140203784476416 [Note] WSREP: STATE EXCHANGE: Waiting for state UUID.
2018-06-27  0:16:57 140203784476416 [Note] WSREP: STATE EXCHANGE: sent state msg: 5885911b-795c-11e8-8683-931c85442c7e
2018-06-27  0:16:57 140203784476416 [Note] WSREP: STATE EXCHANGE: got state msg: 5885911b-795c-11e8-8683-931c85442c7e from 0 (192.168.55.171)
2018-06-27  0:16:57 140203784476416 [Note] WSREP: STATE EXCHANGE: got state msg: 5885911b-795c-11e8-8683-931c85442c7e from 1 (192.168.55.172)
2018-06-27  0:16:57 140203784476416 [Note] WSREP: STATE EXCHANGE: got state msg: 5885911b-795c-11e8-8683-931c85442c7e from 2 (192.168.55.173)
2018-06-27  0:16:57 140203784476416 [Warning] WSREP: Quorum: No node with complete state:

        Version      : 4
        Flags        : 0x3
        Protocols    : 0 / 8 / 3
        State        : NON-PRIMARY
        Desync count : 0
        Prim state   : SYNCED
        Prim UUID    : 5224a024-791b-11e8-a0ac-8bc6118b0f96
        Prim  seqno  : 5
        First seqno  : 112714
        Last  seqno  : 112725
        Prim JOINED  : 3
        State UUID   : 5885911b-795c-11e8-8683-931c85442c7e
        Group UUID   : 55238f52-41ee-11e8-852f-3316bdb654bc
        Name         : '192.168.55.171'
        Incoming addr: '192.168.55.171:3306'

        Version      : 4
        Flags        : 0x2
        Protocols    : 0 / 8 / 3
        State        : NON-PRIMARY
        Desync count : 0
        Prim state   : SYNCED
        Prim UUID    : 5224a024-791b-11e8-a0ac-8bc6118b0f96
        Prim  seqno  : 5
        First seqno  : 112714
        Last  seqno  : 112725
        Prim JOINED  : 3
        State UUID   : 5885911b-795c-11e8-8683-931c85442c7e
        Group UUID   : 55238f52-41ee-11e8-852f-3316bdb654bc
        Name         : '192.168.55.172'
        Incoming addr: '192.168.55.172:3306'

        Version      : 4
        Flags        : 0x2
        Protocols    : 0 / 8 / 3
        State        : NON-PRIMARY
        Desync count : 0
        Prim state   : SYNCED
        Prim UUID    : 5224a024-791b-11e8-a0ac-8bc6118b0f96
        Prim  seqno  : 5
        First seqno  : 112714
        Last  seqno  : 112725
        Prim JOINED  : 3
        State UUID   : 5885911b-795c-11e8-8683-931c85442c7e
        Group UUID   : 55238f52-41ee-11e8-852f-3316bdb654bc
        Name         : '192.168.55.173'
        Incoming addr: '192.168.55.173:3306'

2018-06-27  0:16:57 140203784476416 [Note] WSREP: Full re-merge of primary 5224a024-791b-11e8-a0ac-8bc6118b0f96 found: 3 of 3.
2018-06-27  0:16:57 140203784476416 [Note] WSREP: Quorum results:
        version    = 4,
        component  = PRIMARY,
        conf_id    = 5,
        members    = 3/3 (joined/total),
        act_id     = 112725,
        last_appl. = 112722,
        protocols  = 0/8/3 (gcs/repl/appl),
        group UUID = 55238f52-41ee-11e8-852f-3316bdb654bc
2018-06-27  0:16:57 140203784476416 [Note] WSREP: Flow-control interval: [28, 28]
2018-06-27  0:16:57 140203784476416 [Note] WSREP: Trying to continue unpaused monitor
2018-06-27  0:16:57 140203784476416 [Note] WSREP: Restored state OPEN -> SYNCED (112725)
2018-06-27  0:16:57 140202564110080 [Note] WSREP: New cluster view: global state: 55238f52-41ee-11e8-852f-3316bdb654bc:112725, view# 6: Primary, number of nodes: 3, my index: 2, protocol version 3

A good indicator to know if the re-bootstrapping process is OK is by looking at the following line in the error log:

[Note] WSREP: Synchronized with group, ready for connections

ClusterControl Auto Recovery

ClusterControl comes with node and cluster automatic recovery features, because it oversees and understands the state of all nodes in the cluster. Automatic recovery is by default enabled if the cluster is deployed using ClusterControl. To enable or disable the cluster, simply clicking on the power icon in the summary bar as shown below:

Green icon means automatic recovery is turned on, while red is the opposite. You can monitor the recovery progress from the Activity -> Jobs dialog, like in this case, galera2 was totally inaccessible due to firewall blocking, thus forcing ClusterControl to report the following:

The recovery process will only be commencing after a graceful timeout (30 seconds) to give Galera node a chance to recover itself beforehand. If ClusterControl fails to recover a node or cluster, it will first pull all MySQL error logs from all accessible nodes and will raise the necessary alarms to notify the user via email or by pushing critical events to the third-party integration modules like PagerDuty, VictorOps or Slack. Manual intervention is then required. For Galera Cluster, ClusterControl will keep on trying to recover the failure until you mark the node as under maintenance, or disable the automatic recovery feature.

ClusterControl's automatic recovery is one of most favorite features as voted by our users. It helps you to take the necessary actions quickly, with a complete report on what has been attempted and recommendation steps to troubleshoot further on the issue. For users with support subscriptions, you can look for extra hands by escalating this issue to our technical support team for assistance.

Conclusie

Galera automatic node recovery and membership control are neat features to simplify the cluster management, improve the database reliability and reduce the risk of human error, as commonly haunting other open-source database replication technology like MySQL Replication, Group Replication and PostgreSQL Streaming/Logical Replication.


  1. Een lijst met databases retourneren in SQLite

  2. Gefaseerde APPL_TOP in Oracle Applications R12

  3. Rijnummer per groep in mysql

  4. Hoe sqlcmd &bcp op Ubuntu te installeren