sql >> Database >  >> RDS >> Mysql

Configuratie met hoge beschikbaarheid voor ClusterControl-knooppunten met behulp van CMON HA

In onze vorige blog hebben we ClusterControl CMON HA voor hoge beschikbaarheid van gedistribueerde databases besproken, geschreven door Krzysztof Ksiazek in twee afzonderlijke berichten. In deze blog bespreken we de distributie van nodes via on-prem en in een openbare cloud (met Google Cloud Platform (GCP)).

De reden dat we deze blog hebben geschreven, is omdat we vragen hebben ontvangen over het implementeren van een hoge-beschikbaarheidsinstantie van ClusterControl met CMON-knooppunt(en) op locatie en een ander CMON-knooppunt(en) op een ander datacenter (zoals een publieke cloud). In onze vorige blog ClusterControl CMON HA voor hoge beschikbaarheid van gedistribueerde databases, gebruikten we Galera-clusterknooppunten, maar deze keer gebruiken we MySQL-replicatie met Percona Server 5.7. Een ideale opstelling hiervoor is om altijd de communicatie van nodes van uw on-prem en uw nodes die zich in een openbare cloud bevinden via VPN of een beveiligd kanaal in te kapselen.

ClusterControl CMON HA bevindt zich in een vroeg stadium waarvoor we denken dat het nog niet volwassen genoeg is. Toch kan onze CMON HA u het gevoel van functionaliteit bieden voor het implementeren van een ClusterControl om deze maximaal beschikbaar te maken. Laten we verder gaan met hoe u de nodes kunt implementeren en instellen om de nodes on-prem via de openbare cloud te distribueren.

Wat is een CMON?

Laten we, voordat we naar het hoofdonderwerp gaan, eerst even voorstellen wat CMON is. CMON staat voor ClusterControl Controller, het 'primaire brein' van ClusterControl. Een backend-service die automatisering, beheer, bewaking van planningstaken en ook de HA-beschikbaarheid uitvoert. Gegevens die worden verzameld, worden opgeslagen in de CMON-database, waarvoor we MySQL-compatibele databases gebruiken als gegevensopslag.

De architecturale opzet

Sommigen van jullie kenden misschien niet de mogelijkheden van ClusterControl die het kan uitvoeren en kan niet worden ingesteld voor hoge beschikbaarheid. Als je meerdere ClusterControl (of CMON) nodes hebt draaien, is dat gratis mogelijk. U kunt mogelijk talloze ClusterControl-knooppunten uitvoeren wanneer u maar wilt.

Voor deze opstelling hebben we ClusterControl-knooppunten bovenop een ClusterControl om de databaseknooppunten te maken of te implementeren en een automatische failover te beheren wanneer er bijvoorbeeld een storing optreedt. Hoewel je MHA, Orchestrator of Maxscale kunt gebruiken om de automatische failover te beheren, maar voor efficiëntie en snelheid, zal ik ClusterControl gebruiken om de speciale dingen te doen die andere tools die ik heb genoemd niet hebben.

Dus laten we eens kijken naar het diagram voor deze opstelling:

De opstelling op basis van dat diagram laat zien dat bovenop CMON met drie knooppunten , een draaiende CMON (ClusterControl) is er bovenop die de automatische failover zal bewaken. Vervolgens kan HAProxy de balans tussen de bewaakte drie CMON-knooppunten laden, waarbij één knooppunt zich in een aparte regio bevindt die wordt gehost in GCP voor deze blog. Het is je misschien opgevallen dat we Keepalive niet hebben opgenomen, dat komt omdat we geen VIP onder GCP kunnen plaatsen omdat deze zich op een ander netwerk bevindt.

Zoals je misschien hebt gemerkt, plaatsen we in totaal drie knooppunten. CMON HA vereist dat we minimaal 3 nodes nodig hebben om door te gaan met een stemproces of zogenaamd quorum. Dus voor deze configuratie vereisen we dat je ten minste 3 nodes hebt om een ​​hogere beschikbaarheid te hebben.

On-Prem ClusterControl-knooppunten implementeren

In deze sectie verwachten we dat u uw ClusterControl-gebruikersinterface al hebt ingesteld of geïnstalleerd, die we zullen gebruiken om een ​​MySQL-replicatiecluster met drie knooppunten te implementeren met Percona Server.

Laten we eerst het cluster maken door een nieuwe MySQL-replicatie te implementeren, zoals hieronder weergegeven.

Houd er rekening mee dat ik hier Percona Server 5.7 gebruik, waarvoor de standaard setup door ClusterControl werkt efficiënt.

Definieer vervolgens de hostnaam of het IP-adres van uw nodes,

Op dit moment verwachten we dat u al een Master/slave-replicatie die wordt gehost of op locatie wordt uitgevoerd. De onderstaande schermafbeelding zou moeten laten zien hoe uw knooppunten eruit zullen zien:

ClusterControl instellen en installeren en CMON HA inschakelen op het eerste knooppunt

Uit deze vorige blog  ClusterControl CMON HA voor hoge beschikbaarheid van gedistribueerde databases hebben we in het kort de stappen gegeven om dit te doen. Laten we weer naar beneden gaan en de stappen uitvoeren zoals vermeld, maar voor deze specifieke Master/Slave-replicatie-opstelling.

Kies eerst een knooppunt dat u eerst ClusterControl wilt laten installeren (in deze opstelling installeer ik het eerst op knooppunt 192.168.70.80) en voer de onderstaande stappen uit.

Stap één

ClusterControl installeren

$ wget http://www.severalnines.com/downloads/CMON/install-cc

$ chmod +x install-cc

$ sudo ./install-cc   # omit sudo if you run as root

Houd er rekening mee dat zodra u wordt gevraagd dat een huidige mysql-instantie is gedetecteerd, u ClusterControl de bestaande mysqld moet laten gebruiken, aangezien dat een van onze doelen hier is voor CMON HA en voor deze setup om de heb MySQL al ingesteld.

Stap twee

Bind CMON niet alleen om toe te staan ​​via localhost, maar ook op het specifieke IP-adres (aangezien we HA inschakelen)

## edit /etc/default/CMON  and modify the line just like below or add the line if it doesn't exist

RPC_BIND_ADDRESSES="127.0.0.1,192.168.70.80"

Stap drie

Herstart vervolgens CMON,

service CMON restart

Stap vier

S9s CLI-tools installeren

$ wget http://repo.severalnines.com/s9s-tools/install-s9s-tools.sh

$ chmod 755 install-s9s-tools.sh

$ ./install-s9s-tools.sh

Tijdens deze installatie zal de s9s-tool een admin-gebruiker instellen die u kunt gebruiken bij het omgaan met het s9s-commando, net zoals het inschakelen van CMON HA.

Stap vijf

De CMON HA inschakelen

$ s9s controller --enable-CMON-ha

Stap zes

Wijzig ten slotte de /etc/my.cnf en voeg toe,

slave-skip-errors = 1062

onder de sectie [mysqld]. Vergeet na het toevoegen niet om mysql opnieuw te starten als,

service mysql restart

of

systemctl restart mysql

Momenteel is dit de beperking waarmee we worden geconfronteerd met CMON HA, omdat het probeert log-items in te voegen in de slave, maar dit kan voorlopig goed zijn.

ClusterControl instellen, installeren en CMON HA inschakelen op het tweede knooppunt

Eenvoudig als dat voor het eerste knooppunt. Nu, op het 2e knooppunt (192.168.70.70), moeten we dezelfde stappen uitvoeren, maar in plaats daarvan moeten we enkele aanpassingen in de stappen doen om deze HA mogelijk te maken.

Stap één

Kopieer de configuratie naar het 2e knooppunt (192.168.70.70) van het eerste knooppunt (192.168.70.80)

$ scp -r /etc/CMON* 192.168.70.70:/etc/

Stap twee

Bewerk in het 2e knooppunt /etc/CMON.cnf en zorg ervoor dat de host correct is geconfigureerd. bijv.

vi /etc/CMON.cnf

Wijs vervolgens hostnaam param toe als,

hostnaam=192.168.70.70

Stap drie

Installeer ClusterControl,

$ wget http://www.severalnines.com/downloads/CMON/install-cc

$ chmod +x install-cc

$ sudo ./install-cc   # omit sudo if you run as root

Sla echter de installatie van CMON (of ClusterControl Controller) over zodra u deze regel tegenkomt,

=> An existing Controller installation detected!

=> A re-installation of the Controller will overwrite the /etc/CMON.cnf file

=> Install the Controller? (y/N):

De rest, doe gewoon wat je hebt gedaan op het eerste knooppunt, zoals het instellen van de hostnaam, gebruik de bestaande mysqld-exemplaar, geef het MySQL-wachtwoord op en het wachtwoord voor je CMON dat moet zijn beide hebben hetzelfde wachtwoord met het eerste knooppunt.

Stap vier

S9s CLI-tools installeren

$ wget http://repo.severalnines.com/s9s-tools/install-s9s-tools.sh

$ chmod 755 install-s9s-tools.sh

$ ./install-s9s-tools.sh

Stap vijf

Kopieer de resterende configuratie van het 1e knooppunt naar het 2e knooppunt.

$ scp -r ~/.s9s/ 192.168.70.70:/root/

$ scp /etc/s9s.conf 192.168.70.70:/etc/

$ scp /var/www/html/clustercontrol/bootstrap.php 192.168.70.70:/var/www/html/clustercontrol/

Stap zes

Installeer clustercontrol-controller-pakket,

Voor Ubuntu/Debian,

$ apt install -y clustercontrol-controller

Voor RHEL/CentOS/Fedora,

$ yum install -y clustercontrol-controller

Stap zeven

Kopieer het /etc/default/CMON-bestand en wijzig het IP-adres voor het RPC-bindadres

scp /etc/default/CMON 192.168.70.70:/etc/default

RPC_BIND_ADDRESSES="127.0.0.1,10.0.0.103"

Herstart CMON dan als volgt,

service CMON restart

Stap acht

Wijzig /etc/my.cnf en voeg toe,

slave-skip-errors = 1062

onder de sectie [mysqld]. Vergeet na het toevoegen niet om mysql opnieuw te starten als,

service mysql restart

of

systemctl restart mysql

Momenteel is dit de beperking waarmee we worden geconfronteerd met CMON HA, omdat het probeert log-items in te voegen in de slave, maar dit kan voorlopig goed zijn.

Stap negen

Controleer ten slotte hoe de CMON HA-knooppunten eruit zien,

[[email protected] ~]#  s9s controller --list --long

S VERSION    OWNER GROUP NAME            IP PORT COMMENT

l 1.7.5.3735 system admins 192.168.70.80   192.168.70.80 9501 Acting as leader.

f 1.7.5.3735 system admins 192.168.70.70   192.168.70.70 9501 Accepting heartbeats.

Total: 2 controller(s)

Uw ClusterControl-knooppunt in de cloud implementeren

Zoals we eerder hebben vermeld, is de ideale opstelling voor communicatie om de pakketten via de VPN of een ander beveiligd kanaal in te kapselen. Als je je zorgen maakt over hoe je dit moet doen, bekijk dan onze vorige blog Multi-DC PostgreSQL:een stand-byknooppunt instellen op een andere geolocatie via een VPN, waarvoor we hebben besproken hoe je een eenvoudige VPN-configuratie kunt maken met behulp van OpenVPN.

Dus in deze sectie verwachten we dat je de VPN-verbinding al hebt ingesteld. Wat we nu gaan doen, is een slaaf toevoegen die we geacht worden de beschikbaarheid van CMON te distribueren naar Google Cloud Platform. Om dit te doen, gaat u naar Add Replication Slave, dat u kunt vinden door op het clusterpictogram in de rechterhoek te klikken. Bekijk hieronder hoe het eruit ziet:

Dit is hoe we eindigen met:

Nu, aangezien we een nieuwe slave hebben toegevoegd die wordt gehost onder GCP, u moet mogelijk opnieuw volgen wat we eerder op het 2e knooppunt hebben gedaan. Ik zal je doorverwijzen om die stappen te volgen en de instructies te volgen over hoe we het deden op het 2e knooppunt.

Zodra je het correct hebt, krijg je het volgende resultaat:

[[email protected] ~]# s9s controller --list --long

S VERSION    OWNER GROUP NAME            IP PORT COMMENT

l 1.7.5.3735 system admins 192.168.70.80   192.168.70.80 9501 Acting as leader.

f 1.7.5.3735 system admins 192.168.70.70   192.168.70.70 9501 Accepting heartbeats.

f 1.7.5.3735 system admins 10.142.0.39     10.142.0.39 9501 Accepting heartbeats.

waar in knooppunten 

  • 192.168.70.80 -  (node8) en woont op mijn locatie
  • 192.168.70.70 - (node7) en woont op mijn locatie
  • 10.142.0.39  - (gnode1) wordt gehost in GCP en in een andere regio

CMON HA in actie

Mijn collega Krzysztof Ksiazek heeft al de setup voor HA verzorgd met HAProxy hier op deze blog ClusterControl CMON HA voor Distributed Database High Availability - Part Two (GUI Access Setup).

Om de procedure vermeld in de blog te volgen, moet je ervoor zorgen dat je xinetd- en pathlib-pakketten hebt. U kunt xinetd en pathlib als volgt installeren,

$ sudo yum install -y xinetd python-pathlib.noarch

Zorg er ook voor dat u de CMONhachk hebt gedefinieerd in /etc/services zoals hieronder:

[[email protected] ~]# grep 'CMONhachk' /etc/services 

CMONhachk       9201/tcp

en zorg voor wijzigingen en herstart xinetd,

service xinetd restart

Ik sla de Keepalived- en HAProxy-procedure over en verwacht dat je dienovereenkomstig hebt ingesteld. Een afhaalpunt waarmee u rekening moet houden bij deze opstelling is dat het gebruik van Keepalive niet van toepassing kan zijn als u de VIP van on-prem naar het openbare cloudnetwerk verspreidt, omdat dit een totaal ander netwerk is.

Laten we nu eens kijken hoe CMON HA reageert als knooppunten niet beschikbaar zijn. Zoals eerder getoond, handelde node 192.168.70.80 (node8) als een leider, net zoals hieronder getoond:

Waarin de hoofdknooppuntdatabase ook laat zien dat node8 de master is van de ClusterControl-topologieweergave . Laten we proberen node8 te doden en kijken hoe CMON HA verder gaat,

Zoals u ziet, neemt gnode1 (GCP-knooppunt) de leiding over als knooppunt 8 naar beneden gaat. De HAProxy-resultaten controleren op het volgende,

en onze ClusterControl-knooppunten laten zien dat node8 niet beschikbaar is, terwijl GCP-knooppunt bezig is over als de meester,

Ten slotte, toegang tot mijn HAProxy-knooppunt dat draait op host 192.168.10.100 op poort 81 toont de volgende gebruikersinterface,

Conclusie

Onze ClusterControl CMON HA bestaat al sinds versie 1.7.2, maar het is ook een uitdaging voor ons geweest sinds verschillende vragen en voorkeuren over hoe dit te implementeren, zoals het gebruik van MySQL-replicatie over Galera Cluster.

Onze CMON HA is nog niet volwassen, maar is nu klaar om aan uw hoge beschikbaarheidsbehoeften te voldoen. Er kunnen verschillende benaderingen van toepassing zijn, zolang uw controles het juiste knooppunt bepalen dat actief is.

We raden u aan om CMON HA in te stellen en te implementeren en ons te laten weten hoe goed het aansluit bij uw behoeften, of als het probleem aanhoudt, laat ons dan weten hoe we u kunnen helpen aan uw hoge beschikbaarheidsbehoeften te voldoen.


  1. Partitiefunctie COUNT() OVER mogelijk met DISTINCT

  2. MySQL-equivalent van ORACLES rank()

  3. Hoe kan ik MySQL-queryresultaten in CSV-indeling uitvoeren?

  4. Is er zoiets als een zip()-functie in PostgreSQL die twee arrays combineert?