Hoe MySQL Group Replication configureren op Ubuntu 20.04

Inleiding

MySQL-replicatie spiegelt betrouwbaar de gegevens en bewerkingen van de ene database naar de andere. Conventionele replicatie houdt in dat een primaire server is geconfigureerd om database schrijfbewerkingen te accepteren met secundaire servers die acties van het logboek van de primaire server kopiëren en toepassen op hun eigen gegevenssets. Deze secundaire servers kunnen worden gebruikt voor leesbewerkingen, maar kunnen meestal geen gegevensschrijfbewerkingen uitvoeren.

Group replication is een manier om een meer flexibel, fouttolerant replicatiemechanisme te implementeren. Dit proces houdt in dat een pool van servers wordt opgezet die elk betrokken zijn bij het zorgen dat gegevens correct worden gekopieerd. Als de primaire server problemen ondervindt, kunnen ledenverkiezingen een nieuwe primaire server uit de groep selecteren. Dit maakt het mogelijk dat de overgebleven knooppunten blijven werken, zelfs in geval van problemen. Lidmaatschapsonderhandelingen, foutdetectie en berichtaflevering worden verzorgd door een implementatie van het Paxos-consensusalgoritme.

In deze tutorial zult u MySQL-groepsreplicatie instellen met een set van drie Ubuntu 20.04-servers. Let op dat drie het minimumaantal MySQL-instanties is dat u nodig heeft om groepsreplicatie in MySQL te implementeren, terwijl negen het maximum is. Terwijl u door deze tutorial werkt, heeft u de mogelijkheid om de groep in te stellen als een single-primary of multi-primary replicatiegroep.

Opmerking: Database servers kunnen een van twee rollen hebben in een replicatie-opstelling: ze kunnen ofwel een primaire instantie (ook wel bekend als een bron instantie), waar gebruikers gegevens naar kunnen schrijven; of een repliek (of secundaire instantie), die een kopie van alle gegevens op de bron opslaat. Historisch gezien worden deze rollen in plaats daarvan aangeduid als de meester instantie en de slaaf instantie, respectievelijk. In een blogpost gepubliceerd in juli 2020, erkende het MySQL-team de negatieve oorsprong van deze terminologie en kondigde hun inspanningen aan om het databaseprogramma en de documentatie ervan bij te werken om meer inclusieve taal te gebruiken.

Dit is echter een lopend proces. Hoewel de documentatie van MySQL en veel van de commando’s in versie 8 van het programma zijn bijgewerkt om in plaats daarvan te verwijzen naar de servers in een replicatietopologie als de primaire en zijn secondaires (of de bron en zijn replica’s), zijn er plaatsen waar de negatieve terminologie nog steeds voorkomt. Deze handleiding zal waar mogelijk overschakelen naar de meer inclusieve terminologie, maar er zijn een paar gevallen waarin de oudere termen onvermijdelijk naar voren komen.

Vereisten

Om deze handleiding te voltooien, heeft u nodig:

  • Drie servers draaien op Ubuntu 20.04. Elk moet een niet-root beheerdersgebruiker hebben met sudo-rechten en een firewall geconfigureerd met UFW. Volg onze initial server setup handleiding voor Ubuntu 20.04 om elke server in te stellen.
  • MySQL geïnstalleerd op elke server. Deze handleiding gaat ervan uit dat je de nieuwste versie van MySQL gebruikt die beschikbaar is in de standaard Ubuntu repositories, wat op dit moment versie 8.0.28 is. Om dit op al je servers te installeren, volg onze handleiding over Hoe MySQL te installeren op Ubuntu 20.04 voor elke machine.

Om de zaken duidelijk te houden, zal deze handleiding verwijzen naar de drie servers als lid1, lid2, en lid3. In de voorbeelden in deze handleiding hebben deze leden de volgende IP-adressen:

Member IP address
member1 203.0.113.1
member2 203.0.113.2
member3 203.0.113.3

Alle commando’s die moeten worden uitgevoerd op lid1 hebben een blauwe achtergrond, zoals dit:

Evenzo zullen alle commando’s die moeten worden uitgevoerd op lid2 een rode achtergrond hebben:

En alle commando’s die moeten worden uitgevoerd op lid3 zullen een groene achtergrond hebben:

Tenslotte zullen alle commando’s die moeten worden uitgevoerd op elk van de drie servers een standaard achtergrond hebben:

Stap 1 — Genereren van een UUID om de MySQL-groep te identificeren

Voordat u het configuratiebestand van MySQL opent om de instellingen voor groepsreplicatie te configureren, moet u een UUID genereren die u kunt gebruiken om de MySQL-groep te identificeren die u gaat maken.

Op lid1, gebruik het uuidgen-commando om een geldige UUID voor de groep te genereren:

  1. uuidgen
Output
168dcb64-7cce-473a-b338-6501f305e561

Kopieer de waarde die u ontvangt, omdat u deze zo meteen moet gebruiken bij het configureren van een groepsnaam voor uw pool van servers.

Stap 2 — Instellen van groepsreplicatie in het MySQL-configuratiebestand

Nu bent u klaar om het configuratiebestand van MySQL aan te passen. Open het hoofdconfiguratiebestand van MySQL op elke MySQL-server met uw voorkeurteksteditor. Hier zullen we nano gebruiken:

  1. sudo nano /etc/mysql/my.cnf

Op Ubuntu wordt MySQL geïnstalleerd met een aantal verschillende bestanden die je kunt gebruiken om verschillende configuratiewijzigingen te definiëren. Standaard wordt het my.cnf-bestand alleen gebruikt om aanvullende bestanden uit submappen te sourcen. Je moet je eigen configuratie toevoegen onder de !includedir-regels. Dit stelt je in staat om instellingen uit de opgenomen bestanden te overschrijven.

Begin met het starten van een nieuwe sectie door een [mysqld]-kop toe te voegen en voeg vervolgens de instellingen toe die je nodig hebt om groepsreplicatie in te schakelen, zoals in het volgende voorbeeld wordt aangegeven. Let op dat deze instellingen zijn aangepast van de minimale instellingen die vereist zijn voor groepsreplicatie zoals beschreven in de officiële MySQL-documentatie. Het loose--voorvoegsel zorgt ervoor dat MySQL opties die het niet herkent, gracieus en zonder fouten kan verwerken. Je moet binnenkort enkele van deze instellingen invullen en aanpassen:

/etc/mysql/my.cnf
. . .
!includedir /etc/mysql/conf.d/
!includedir /etc/mysql/mysql.conf.d/

[mysqld]

# General replication settings
disabled_storage_engines="MyISAM,BLACKHOLE,FEDERATED,ARCHIVE,MEMORY"
gtid_mode = ON
enforce_gtid_consistency = ON
master_info_repository = TABLE
relay_log_info_repository = TABLE
binlog_checksum = NONE
log_slave_updates = ON
log_bin = binlog
binlog_format = ROW
transaction_write_set_extraction = XXHASH64
loose-group_replication_bootstrap_group = OFF
loose-group_replication_start_on_boot = OFF
loose-group_replication_ssl_mode = REQUIRED
loose-group_replication_recovery_use_ssl = 1

# Shared replication group configuration
loose-group_replication_group_name = ""
loose-group_replication_ip_whitelist = ""
loose-group_replication_group_seeds = ""

# Single or Multi-primary mode? Uncomment these two lines
# for multi-primary mode, where any host can accept writes
#loose-group_replication_single_primary_mode = OFF
#loose-group_replication_enforce_update_everywhere_checks = ON

# Host specific replication configuration
server_id = 
bind-address = ""
report_host = ""
loose-group_replication_local_address = ""

Om al deze configuratieopties met meer duidelijkheid uit te leggen, zijn ze opgesplitst in de volgende subsecties. Lees ze zorgvuldig door, omdat sommige secties je keuzes presenteren over hoe je je replicatiegroep wilt implementeren of je vragen om details in te voeren die specifiek zijn voor je eigen configuratie.

Standaard Groepsreplicatie-instellingen

De eerste sectie bevat algemene instellingen die vereist zijn voor groepsreplicatie en die geen aanpassing vereisen:

/etc/mysql/my.cnf
. . .
# Algemene replicatie-instellingen
disabled_storage_engines="MyISAM,BLACKHOLE,FEDERATED,ARCHIVE,MEMORY"
gtid_mode = ON
enforce_gtid_consistency = ON
master_info_repository = TABLE
relay_log_info_repository = TABLE
binlog_checksum = NONE
log_slave_updates = ON
log_bin = binlog
binlog_format = ROW
transaction_write_set_extraction = XXHASH64
loose-group_replication_bootstrap_group = OFF
loose-group_replication_start_on_boot = OFF
loose-group_replication_ssl_mode = REQUIRED
loose-group_replication_recovery_use_ssl = 1
. . .

Een specifieke vereiste voor groepsreplicatie in MySQL is dat de gegevens moeten worden opgeslagen in de InnoDB-opslag-engine. De MySQL-documentatie raadt aan om expliciet het gebruik van andere opslag-engines uit te schakelen die fouten kunnen veroorzaken op een manier zoals de eerste niet-uitgecommentarieerde regel in deze sectie.

De overige instellingen schakelen de wereldwijde transactie-ID’s in, configureren het binair loggen dat vereist is voor groepsreplicatie, en configureren SSL voor de groep. Deze configuratie stelt ook enkele andere items in die helpen bij herstel en opstarten. U hoeft niets te wijzigen in deze sectie en deze moet identiek zijn op al uw drie servers, dus u kunt doorgaan nadat u deze hebt toegevoegd.

Gedeelde groepsreproductie-instellingen

De tweede sectie stelt gedeelde instellingen in voor de groep. U moet dit één keer aanpassen en vervolgens dezelfde instellingen gebruiken op elk van uw knooppunten. Specifiek moet u de UUID van de groep toevoegen (die u hebt gemaakt in de vorige stap), een lijst van geautoriseerde groepsleden, en de seed-leden om contact op te nemen om de initiële gegevens te verkrijgen bij het toetreden tot de groep.

Stel de loose-group_replication_group_name in op de UUID-waarde die je eerder hebt gegenereerd met het uuidgen commando. Zorg ervoor dat je de UUID plaatst tussen het lege paar dubbele aanhalingstekens.

Vervolgens, stel loose-group_replication_ip_whitelist in op een lijst van al je MySQL-server IP-adressen, gescheiden door komma’s. De loose-group_replication_group_seeds instelling moet bijna hetzelfde zijn als de whitelist, maar moet een aangewezen groepsreproductiepoort toevoegen aan het einde van elk lid. Gebruik voor de doeleinden van deze handleiding de aanbevolen groepsreproductiepoort, 33061:

/etc/mysql/my.cnf
. . .
# Gedeelde configuratie van replicatiegroep
loose-group_replication_group_name = "168dcb64-7cce-473a-b338-6501f305e561"
loose-group_replication_ip_whitelist = "203.0.113.1,203.0.113.2,203.0.113.3"
loose-group_replication_group_seeds = ""203.0.113.1:33061,203.0.113.2:33061,203.0.113.3:33061"
. . .

Deze sectie moet hetzelfde zijn op elk van je MySQL-servers, dus zorg ervoor dat je deze zorgvuldig kopieert op elk.

Kiezen tussen enkele primaire of meerdere primaire servers

Vervolgens moet je beslissen of je een enkele primaire of meerdere primaire groep wilt configureren. In een configuratie met enkele primaire servers wijst MySQL een enkele primaire server aan (bijna altijd het eerste groepslid) om schrijfbewerkingen af te handelen. Een groep met meerdere primaire servers staat toe dat elk van de groepsleden schrijfbewerkingen uitvoert.

Als je een multi-primary groep wilt configureren, haal dan het commentaar weg bij de loose-group_replication_single_primary_mode en loose-group_replication_enforce_update_everywhere_checks richtlijnen. Dit zal een multi-primary groep opzetten. Voor een single primary groep, laat gewoon die twee regels gecommentarieerd:

/etc/mysql/my.cnf
. . .
# Single of Multi-primary modus? Haal het commentaar weg bij deze twee regels
# voor multi-primary modus, waar elk host schrijfopdrachten kan accepteren
#loose-group_replication_single_primary_mode = OFF
#loose-group_replication_enforce_update_everywhere_checks = ON
. . .

Deze instellingen moeten hetzelfde zijn op elk van je MySQL servers.

Je kunt deze instelling later wijzigen, maar nadat je dit hebt gedaan, moet je elke lid van je MySQL groep herstarten. Om over te schakelen naar de nieuwe configuratie, moet je elk van de MySQL instanties in de groep stoppen, elk lid starten met de nieuwe instellingen, en vervolgens de groep replicatie opnieuw opstarten. Dit heeft geen invloed op je gegevens, maar vereist een kleine periode van downtime.

Host-Specifieke Configuratie Instellingen

Het vierde gedeelte bevat instellingen die verschillend zullen zijn op elk van de servers, waaronder:

  • Het server-ID
  • Het adres om aan te binden
  • Het adres om aan andere leden te rapporteren
  • Het lokale replicatieadres en luisterpoort

De server_id directive moet worden ingesteld op een uniek nummer. Voor het eerste lid stelt u dit in op 1 en verhoogt u het nummer voor elke extra host. Stel bind-address en report_host in op het respectieve IP-adres van de server, zodat de MySQL-instantie luistert naar externe verbindingen en zijn adres correct rapporteert aan andere hosts. De loose-group_replication_local_address moet ook worden ingesteld op het huidige IP-adres van de server met de groepsreplicatiepoort (33061) toegevoegd aan het IP-adres.

Als voorbeeld, hier is dit gedeelte van de configuratie voor member1 met behulp van het voorbeeld-IP-adres:

/etc/mysql/my.cnf
. . .
# Hostspecifieke replicatieconfiguratie
server_id = 1
bind-address = "203.0.113.1"
report_host = "203.0.113.1"
loose-group_replication_local_address = "203.0.113.1:33061"

Voltooi dit proces op elk van uw MySQL-servers. Hier is de configuratie voor member2:

/etc/mysql/my.cnf
. . .
# Hostspecifieke replicatieconfiguratie
server_id = 2
bind-address = "203.0.113.2"
report_host = "203.0.113.2"
loose-group_replication_local_address = "203.0.113.2:33061"

En hier is de configuratie voor member3:

/etc/mysql/my.cnf
. . .
# Hostspecifieke replicatieconfiguratie
server_id = 3
bind-address = "203.0.113.3"
report_host = "203.0.113.3"
loose-group_replication_local_address = "203.0.113.3:33061"

Zorg ervoor dat u elk gemarkeerd IP-adres bijwerkt naar dat van de server waarvan u de configuratie bewerkt.

Wanneer u klaar bent, controleer dan dubbel of de gedeelde replicatie-instellingen hetzelfde zijn op elke host en of de hostspecifieke instellingen zijn aangepast voor elke host. Sla het bestand op elke host op en sluit het af wanneer u klaar bent. Als u nano hebt gebruikt om het bestand te bewerken, kunt u dit doen door op CTRL + X, Y en vervolgens ENTER te drukken.

Elk van de configuratiebestanden voor MySQL op uw servers bevat nu de richtlijnen die nodig zijn om MySQL-groepsreplicatie te starten. Om de nieuwe instellingen toe te passen op de MySQL-instantie, herstart u de service op elke van uw servers met het volgende commando:

  1. sudo systemctl restart mysql

Hiermee kunt u doorgaan met het inschakelen van externe toegang door de firewallregels van elke van uw servers bij te werken.

Stap 3 — Het bijwerken van de UFW-regels van elke server

Als u de vereiste handleiding voor de initiële serverconfiguratie hebt gevolgd, hebt u een firewall ingesteld op elke server waarop u MySQL hebt geïnstalleerd en toegang ingeschakeld voor het OpenSSH UFW-profiel. Dit is een belangrijke beveiligingsmaatregel, omdat deze firewalls momenteel verbindingen met elke poort op uw servers blokkeren, behalve ssh-verbindingen die sleutels presenteren die overeenkomen met die in het respectieve authorized_keys-bestand van elke server.

In het MySQL-configuratiebestand hebt u de service geconfigureerd om externe verbindingen te accepteren op de standaard poort 3306. U hebt ook 33061 gedefinieerd als de poort die leden moeten gebruiken voor replicatiecoördinatie.

Op elk van uw lidserver, moet u de toegang tot beide van deze poorten openen voor de andere leden in deze groep, zodat ze allemaal met elkaar kunnen communiceren. Om de toegang tot deze poorten op lid1 voor lid2 te openen, voert u de volgende ufw-opdrachten uit op lid1:

  1. sudo ufw allow from member2_server_ip to any port 3306
  2. sudo ufw allow from member2_server_ip to any port 33061

Zorg ervoor dat u lid2_server_ip wijzigt om het werkelijke IP-adres van uw lid2-server weer te geven. Vervolgens, om dezelfde poorten te openen voor lid3, voert u deze opdrachten uit:

  1. sudo ufw allow from member3_server_ip to any port 3306
  2. sudo ufw allow from member3_server_ip to any port 33061

Vervolgens, update de firewallregels voor uw andere twee servers. Voer de volgende opdrachten uit op lid2, waarbij u ervoor zorgt dat u de IP-adressen wijzigt om die van respectievelijk lid1 en lid3 weer te geven:

  1. sudo ufw allow from member1_server_ip to any port 3306
  2. sudo ufw allow from member1_server_ip to any port 33061
  3. sudo ufw allow from member3_server_ip to any port 3306
  4. sudo ufw allow from member3_server_ip to any port 33061

Voer tot slot deze twee opdrachten uit op lid3. Zorg er opnieuw voor dat u de juiste IP-adressen voor elke server invoert:

  1. sudo ufw allow from member1_server_ip to any port 3306
  2. sudo ufw allow from member1_server_ip to any port 33061
  3. sudo ufw allow from member2_server_ip to any port 3306
  4. sudo ufw allow from member2_server_ip to any port 33061

Na het toevoegen van deze UFW-regels, krijgen elk van uw drie MySQL-instanties toegang tot de poorten die worden gebruikt door MySQL op de andere twee servers.

Met toegang tot de MySQL-poorten open, kunt u nu een replicatiegebruiker maken en de groepsreplicatieplug-in inschakelen.

Stap 4 — Configuratie van Replicatiegebruikers en Inschakelen van de Groepsreplicatieplug-in

Om verbindingen met de andere servers in de replicatiegroep tot stand te brengen, moet elke MySQL-instantie een speciale replicatiegebruiker hebben.

Op elke van uw MySQL-servers, log in op uw MySQL-instantie met de beheerdersgebruiker om een interactieve sessie te starten:

  1. sudo mysql

Opmerking: Zorg ervoor dat u elk van de commando’s in deze sectie op elke van uw MySQL-instanties uitvoert.

Omdat elke server zijn eigen replicatiegebruiker zal hebben, moet u binair loggen uitschakelen tijdens het creatieproces. Anders zou, zodra de replicatie begint, de groep proberen de replicatiegebruiker van de primaire naar de andere servers te verspreiden, wat een conflict zou veroorzaken met de al aanwezige replicatiegebruiker. Voer het volgende commando uit vanaf de MySQL-prompt op elke van uw servers:

  1. SET SQL_LOG_BIN=0;

Nu kunt u een CREATE USER-statement uitvoeren om uw replicatiegebruiker te maken. Voer het volgende commando uit, dat een gebruiker met de naam repl aanmaakt. Dit commando specificeert dat de replicatiegebruiker moet verbinden met SSL. Zorg er ook voor dat u een veilig wachtwoord gebruikt in plaats van wachtwoord bij het maken van deze replicatiegebruiker:

  1. CREATE USER 'repl'@'%' IDENTIFIED BY 'password' REQUIRE SSL;

Vervolgens verleent u de nieuwe gebruiker replicatieprivileges op de server:

  1. GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%';

Vervolgens de privileges wissen om de wijzigingen door te voeren:

  1. FLUSH PRIVILEGES;

Daarna binair loggen opnieuw inschakelen om de normale operaties te hervatten:

  1. SET SQL_LOG_BIN=1;

Vervolgens stelt u het kanaal group_replication_recovery in om uw nieuwe replicatiegebruiker en bijbehorend wachtwoord te gebruiken. Elke server zal deze referenties dan gebruiken om zich aan te melden bij de groep:

  1. CHANGE REPLICATION SOURCE TO SOURCE_USER='repl', SOURCE_PASSWORD='password' FOR CHANNEL 'group_replication_recovery';

Opmerking: Als u een versie van MySQL gebruikt die ouder is dan 8.0.23, moet u de legacysyntax van MySQL gebruiken om dit in te stellen:

  1. CHANGE MASTER TO MASTER_USER='repl', MASTER_PASSWORD='password' FOR CHANNEL 'group_replication_recovery';

Met de replicatiegebruiker op zijn plaats, kunt u de group_replication-plug-in inschakelen om de groep voor te bereiden:

  1. INSTALL PLUGIN group_replication SONAME 'group_replication.so';

Controleer of de plug-in actief is door het volgende commando uit te voeren:

  1. SHOW PLUGINS;

De group_replication-plug-in verschijnt onder aan de lijst omdat het de meest recent toegevoegde plug-in is:

Output
+----------------------------+----------+--------------------+----------------------+---------+ | Name | Status | Type | Library | License | +----------------------------+----------+--------------------+----------------------+---------+ | | | | | | | . . . | . . . | . . . | . . . | . . . | | | | | | | | group_replication | ACTIVE | GROUP REPLICATION | group_replication.so | GPL | +----------------------------+----------+--------------------+----------------------+---------+ 45 rows in set (0.00 sec)

Deze uitvoer bevestigt dat de plug-in is geladen en momenteel actief is. Voordat u doorgaat naar de volgende stap, zorg ervoor dat u elk commando in deze sectie hebt uitgevoerd op elk van uw MySQL-instanties.

Stap 5 — Het starten van Groepsreplicatie

Nu elke MySQL-server een replicatiegebruiker heeft geconfigureerd en de groepsreplicatieplug-in is ingeschakeld, kunt u beginnen met het opstarten van uw groep.

Het bootstrappen van de Eerste Node

Om de groep op te starten, voltooit u de volgende stappen op een enkel lid van de groep. Voor demonstratiedoeleinden zal deze handleiding deze stappen voltooien op lid1

Groepsleden vertrouwen op bestaande leden om replicatiegegevens, actuele ledenlijsten en andere informatie te versturen bij het aanvankelijk toetreden tot de groep. Daarom moet je een iets andere procedure gebruiken om het initiële groepslid op te starten, zodat het weet dat het deze informatie niet van andere leden in zijn seed-lijst moet verwachten.

Als ingesteld, vertelt de variabele group_replication_bootstrap_group een lid dat het niet moet verwachten informatie te ontvangen van peers en in plaats daarvan een nieuwe groep moet oprichten en zichzelf moet verkiezen tot primair lid. Je kunt deze variabele inschakelen met het volgende commando:

  1. SET GLOBAL group_replication_bootstrap_group=ON;

Vervolgens kun je replicatie starten voor het initiële groepslid:

  1. START GROUP_REPLICATION;

Daarna kun je de variabele group_replication_bootstrap_group terugzetten op OFF, aangezien de enige situatie waarin dit passend is, is wanneer er geen bestaande groepsleden zijn:

  1. SET GLOBAL group_replication_bootstrap_group=OFF;

De groep zal worden gestart met deze server als enig lid. Verifieer dit door de vermeldingen binnen de tabel replication_group_members in de database performance_schema te controleren:

  1. SELECT * FROM performance_schema.replication_group_members;

Deze query zal een enkele rij teruggeven die het huidige host vertegenwoordigt:

Output
+---------------------------+--------------------------------------+---------------+-------------+--------------+-------------+----------------+----------------------------+ | CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION | MEMBER_COMMUNICATION_STACK | +---------------------------+--------------------------------------+---------------+-------------+--------------+-------------+----------------+----------------------------+ | group_replication_applier | 13324ab7-1b01-11e7-9dd1-22b78adaa992 | 203.0.113.1 | 3306 | ONLINE | PRIMARY | 8.0.28 | XCom | +---------------------------+--------------------------------------+---------------+-------------+--------------+-------------+----------------+----------------------------+ 1 row in set (0.00 sec)

De waarde ONLINE voor MEMBER_STATE geeft aan dat deze node volledig operationeel is binnen de groep.

Vervolgens maak je een testdatabase en -tabel met enkele voorbeeldgegevens. Zodra er meer leden aan deze groep worden toegevoegd, worden deze gegevens automatisch gerepliceerd naar hen.

Begin met het maken van een voorbeelddatabase met de naam playground:

  1. CREATE DATABASE playground;

Maak vervolgens een voorbeeldtabel met de naam equipment binnen de database playground met behulp van de volgende opdracht:

  1. CREATE TABLE playground.equipment (
  2. id INT NOT NULL AUTO_INCREMENT,
  3. type VARCHAR(50),
  4. quant INT,
  5. color VARCHAR(25),
  6. PRIMARY KEY(id)
  7. );

Deze tabel bevat de volgende vier kolommen:

  • id: Deze kolom bevat integerwaarden die automatisch toenemen, wat betekent dat je geen waarden voor deze kolom hoeft op te geven wanneer je de tabel laadt met voorbeeldgegevens
  • type: Deze kolom bevat stringwaarden die beschrijven wat voor soort speeltuinuitrusting de rij vertegenwoordigt
  • quant: Deze kolom bevat integerwaarden om de hoeveelheid van het gegeven type speeltuinuitrusting te vertegenwoordigen
  • color: Deze kolom bevat stringwaarden die de kleur van de gegeven uitrusting specificeren

Merk ook op dat de id-kolom is aangewezen als primaire sleutel van deze tabel. In MySQL moet elke tabel die gerepliceerd wordt naar een groep een kolom hebben die is aangewezen als de primaire sleutel van de tabel.

Voer tot slot de volgende opdracht uit om één rij met gegevens in de tabel in te voegen:

  1. INSERT INTO playground.equipment (type, quant, color) VALUES ("slide", 2, "blue");

Query de tabel om ervoor te zorgen dat de gegevens correct zijn ingevoerd:

  1. SELECT * FROM playground.equipment;
Output
+----+-------+-------+-------+ | id | type | quant | color | +----+-------+-------+-------+ | 1 | slide | 2 | blue | +----+-------+-------+-------+ 1 row in set (0.00 sec)

Nadat is geverifieerd dat deze server lid is van de groep en dat het schrijfrechten heeft, kunnen de andere servers zich bij de groep voegen.

Het opstarten van de overige knooppunten

Volgende, start groepsreplicatie op lid2. Aangezien je al een actief lid hebt, hoef je de groep niet te bootstrappen en kan dit lid direct meedoen:

  1. START GROUP_REPLICATION;

Op lid3, start de groepsreplicatie op dezelfde manier:

  1. START GROUP_REPLICATION;

Controleer de lidmaatschapslijst opnieuw op een van de drie servers. Deze keer worden er drie servers vermeld in de uitvoer:

  1. SELECT * FROM performance_schema.replication_group_members;
Output
+---------------------------+--------------------------------------+---------------+-------------+--------------+-------------+----------------+----------------------------+ | CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION | MEMBER_COMMUNICATION_STACK | +---------------------------+--------------------------------------+---------------+-------------+--------------+-------------+----------------+----------------------------+ | group_replication_applier | 13324ab7-1b01-11e7-9dd1-22b78adaa992 | 203.0.113.1 | 3306 | ONLINE | PRIMARY | 8.0.28 | XCom | | group_replication_applier | 1ae4b211-1b01-11e7-9d89-ceb93e1d5494 | 203.0.113.2 | 3306 | ONLINE | SECONDARY | 8.0.28 | XCom | | group_replication_applier | 157b597a-1b01-11e7-9d83-566a6de6dfef | 203.0.113.3 | 3306 | ONLINE | SECONDARY | 8.0.28 | XCom | +---------------------------+--------------------------------------+---------------+-------------+--------------+-------------+----------------+----------------------------+ 3 rows in set (0.00 sec)

Alle leden moeten een MEMBER_STATE-waarde hebben van ONLINE. Voor een nieuwe groep, als een van de knooppunten langer dan een paar seconden als RECOVERING wordt vermeld, is dit meestal een indicatie dat er een fout is opgetreden of dat er iets verkeerd is geconfigureerd. Controleer de logs op /var/log/mysql/error.log voor aanvullende informatie over wat er mis is gegaan.

Controleer vervolgens of de informatie van de testdatabase is gerepliceerd naar de nieuwe leden:

  1. SELECT * FROM playground.equipment;
Output
+----+-------+-------+-------+ | id | type | quant | color | +----+-------+-------+-------+ | 1 | slide | 2 | blue | +----+-------+-------+-------+ 1 row in set (0.01 sec)

Als de gegevens beschikbaar zijn op de nieuwe leden, betekent dit dat de groepsreplicatie correct werkt.

Stap 6 — Testen van schrijfcapaciteiten van nieuwe groepsleden

Vervolgens kun je proberen te schrijven naar de database vanaf je nieuwe replicatiegroepsleden. Of dit lukt of niet, hangt af van of je hebt gekozen voor configuratie van een enkele primaire of meerdere primaire groep.

Testen van schrijfbewerkingen in een enkele primaire omgeving

In een enkele primaire groep moet u verwachten dat alle schrijfbewerkingen vanaf een niet-primaire server worden geweigerd om redenen van consistentie. U kunt de huidige primaire op elk moment vinden door de volgende query uit te voeren op een willekeurig lid van uw replicatiegroep:

  1. SHOW STATUS LIKE '%primary%';
Output
+----------------------------------+--------------------------------------+ | Variable_name | Value | +----------------------------------+--------------------------------------+ | group_replication_primary_member | 13324ab7-1b01-11e7-9dd1-22b78adaa992 | +----------------------------------+--------------------------------------+ 1 row in set (0.01 sec)

De waarde van de query zal een MEMBER_ID zijn die u kunt koppelen aan een host door de lijst met groepsleden op te vragen zoals u eerder hebt gedaan:

  1. SELECT * FROM performance_schema.replication_group_members;
Output
+---------------------------+--------------------------------------+--------------+-------------+--------------+ | CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | +---------------------------+--------------------------------------+--------------+-------------+--------------+ | group_replication_applier | 13324ab7-1b01-11e7-9dd1-22b78adaa992 | 203.0.113.1 | 3306 | ONLINE | | group_replication_applier | 1ae4b211-1b01-11e7-9d89-ceb93e1d5494 | 203.0.113.2 | 3306 | ONLINE | | group_replication_applier | 157b597a-1b01-11e7-9d83-566a6de6dfef | 203.0.113.3 | 3306 | ONLINE | +---------------------------+--------------------------------------+--------------+-------------+--------------+ 3 rows in set (0.01 sec)

Zoals dit voorbeeldoutput aangeeft, is de host op 203.0.113.1member1 – momenteel de primaire server. Als u probeert te schrijven naar de database vanaf een ander lid, zal de bewerking mislukken:

  1. INSERT INTO playground.equipment (type, quant, color) VALUES ("swing", 10, "yellow");
Output
ERROR 1290 (HY000): The MySQL server is running with the --super-read-only option so it cannot execute this statement

Dit is verwacht omdat de groep momenteel is geconfigureerd met een enkele schrijfgeschikte primaire. Als de primaire server problemen heeft en de groep verlaat, zal de groep automatisch een nieuw lid kiezen om de primaire te zijn en schrijfbewerkingen accepteren.

Testen van schrijfbewerkingen in een multi-primaire omgeving

Voor groepen die zijn geconfigureerd in een multi-primaire oriëntatie, moet elk lid in staat zijn om schrijfbewerkingen naar de database te voltooien.

U kunt controleren of uw groep in multi-primaire modus werkt door opnieuw de waarde van de variabele group_replication_primary_member te controleren:

  1. SHOW STATUS LIKE '%primary%';
Output
+----------------------------------+-------+ | Variable_name | Value | +----------------------------------+-------+ | group_replication_primary_member | | +----------------------------------+-------+ 1 row in set (0.02 sec)

Als de variabele leeg is, betekent dit dat er geen aangewezen primaire host is en dat elk lid schrijfopdrachten moet kunnen accepteren.

Test dit op lid2 door te proberen wat gegevens naar de tabel equipment te schrijven:

  1. INSERT INTO playground.equipment (type, quant, color) VALUES ("swing", 10, "yellow");
Output
Query OK, 1 row affected (0.00 sec)

lid2 heeft de schrijfoperatie zonder fouten uitgevoerd.

Op lid3, voer de volgende query uit om te controleren of het nieuwe item is toegevoegd:

  1. SELECT * FROM playground.equipment;
Output
+----+-------+-------+--------+ | id | type | quant | color | +----+-------+-------+--------+ | 1 | slide | 2 | blue | | 2 | swing | 10 | yellow | +----+-------+-------+--------+ 2 rows in set (0.00 sec)

Dit bevestigt dat de schrijfopdracht van lid2 succesvol is gerepliceerd.

Test nu de schrijfcapaciteiten op lid3 door de volgende INSERT-verklaring uit te voeren:

  1. INSERT INTO playground.equipment (type, quant, color) VALUES ("seesaw", 3, "green");
Output
Query OK, 1 row affected (0.02 sec)

Keer terug naar lid1 en controleer of de schrijfoperaties van beide nieuwe leden zijn gerepliceerd:

  1. SELECT * FROM playground.equipment;
Output
+----+--------+-------+--------+ | id | type | quant | color | +----+--------+-------+--------+ | 1 | slide | 2 | blue | | 2 | swing | 10 | yellow | | 3 | seesaw | 3 | green | +----+--------+-------+--------+ 3 rows in set (0.01 sec)

Dit bevestigt dat replicatie in beide richtingen werkt en dat elk lid in staat is schrijfoperaties uit te voeren.

Stap 7 — De Groep Weer Omhoog Brengen

Zodra de groep is opgestart, kunnen individuele leden zich aansluiten en vertrekken zonder de beschikbaarheid te beïnvloeden, zolang er voldoende leden zijn om primaire servers te kiezen. Als echter bepaalde configuratiewijzigingen worden doorgevoerd (zoals overschakelen tussen enkelvoudige en multi-primaire omgevingen), of als alle leden van de groep vertrekken, moet je de groep opnieuw opstarten op dezelfde manier als je aanvankelijk deed.

Op lid1, stel de variabele group_replication_bootstrap_group in op ON:

  1. SET GLOBAL GROUP_REPLICATION_BOOTSTRAP_GROUP=ON;

Vervolgens initialiseer je de groep:

  1. START GROUP_REPLICATION;

Daarna kan je de variabele group_replication_bootstrap_group terugzetten naar OFF:

  1. SET GLOBAL GROUP_REPLICATION_BOOTSTRAP_GROUP=OFF;

Zodra het eerste lid de groep heeft gestart, kunnen andere leden zich aansluiten:

  1. START GROUP_REPLICATION;

Volg dit proces voor eventuele extra leden:

  1. START GROUP_REPLICATION;

De groep zou nu online moeten zijn met alle leden beschikbaar:

  1. SELECT * FROM performance_schema.replication_group_members;
Output
+---------------------------+--------------------------------------+--------------+-------------+--------------+ | CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | +---------------------------+--------------------------------------+--------------+-------------+--------------+ | group_replication_applier | 13324ab7-1b01-11e7-9dd1-22b78adaa992 | 203.0.113.1 | 3306 | ONLINE | | group_replication_applier | 1ae4b211-1b01-11e7-9d89-ceb93e1d5494 | 203.0.113.2 | 3306 | ONLINE | | group_replication_applier | 157b597a-1b01-11e7-9d83-566a6de6dfef | 203.0.113.3 | 3306 | ONLINE | +---------------------------+--------------------------------------+--------------+-------------+--------------+ 3 rows in set (0.01 sec)

Dit proces kan worden gebruikt om de groep opnieuw te starten wanneer dat nodig is.

Stap 8 — Automatisch lid worden van een groep bij het opstarten van MySQL

Met de huidige instellingen zal een lidserver bij het opnieuw opstarten niet automatisch weer lid worden van de groep. Als je wilt dat leden automatisch weer lid worden van de groep, kan je het configuratiebestand iets aanpassen.

De instelling die in deze stap wordt beschreven, is handig wanneer je wilt dat leden automatisch lid worden wanneer ze opstarten. Er zijn echter een paar dingen waar je op moet letten. Ten eerste heeft deze instelling alleen invloed wanneer de MySQL-instantie zelf wordt gestart. Als het lid uit de groep wordt verwijderd vanwege time-out problemen, maar de MySQL-instantie blijft online, zal het lid niet automatisch opnieuw lid worden.

Ten tweede kan het schadelijk zijn om deze instelling ingeschakeld te hebben bij het eerste opstarten van een groep. Wanneer er geen bestaande groep is om zich bij aan te sluiten, zal het MySQL-proces lang duren om te starten omdat het zal proberen contact te maken met andere, niet-bestaande leden om te initialiseren. Pas na een lange time-out zal het opgeven en normaal starten. Daarna moet je de bovenstaande procedure volgen om de groep op te starten.

Met de bovenstaande kanttekeningen in gedachten, als je nodes wilt configureren om automatisch lid te worden van de groep wanneer MySQL wordt gestart, open dan het hoofdconfiguratiebestand van MySQL:

  1. sudo nano /etc/mysql/my.cnf

Binnenin, zoek de variabele loose-group_replication_start_on_boot en zet deze op ON:

/etc/mysql/my.cnf

[mysqld]
. . .
loose-group_replication_start_on_boot = ON
. . .

Sla het bestand op en sluit het af wanneer je klaar bent. Het lid zou automatisch moeten proberen lid te worden van de groep de volgende keer dat de MySQL-instantie wordt gestart.

Conclusie

Door deze tutorial te voltooien, heb je geleerd hoe je MySQL groepsreplicatie configureert tussen drie Ubuntu 20.04-servers. Voor enkele primaire setups zullen de leden automatisch een schrijfgeschikte primaire kiezen wanneer dat nodig is. Voor multi-primaire groepen kan elk lid schrijven en updates uitvoeren.

Groepsreplicatie biedt een flexibele replicatietopologie waarmee leden zich naar wens kunnen aansluiten of verlaten, terwijl tegelijkertijd garanties worden geboden over gegevensconsistentie en berichtvolgorde. MySQL groepsreplicatie kan wat complexer zijn om te configureren, maar het biedt mogelijkheden die niet mogelijk zijn bij traditionele replicatie.

Source:
https://www.digitalocean.com/community/tutorials/how-to-configure-mysql-group-replication-on-ubuntu-20-04