Een cluster-naar-cluster-replicatie configureren voor Percona XtraDB-cluster of MariaDB-cluster

In een vorige blog hebben we een nieuwe ClusterControl 1.7.4-functie aangekondigd met de naam Cluster-naar-Cluster-replicatie. Het automatiseert het hele proces van het opzetten van een DR-cluster buiten uw primaire cluster, met replicatie daartussenin. Raadpleeg het bovengenoemde blogbericht voor meer gedetailleerde informatie.

In deze blog gaan we kijken hoe we deze nieuwe functie voor een bestaand cluster kunnen configureren. Voor deze taak gaan we ervan uit dat u ClusterControl hebt geïnstalleerd en dat het hoofdcluster ermee is geïmplementeerd.

Vereisten voor het hoofdcluster

Er zijn enkele vereisten voor het hoofdcluster om het te laten werken:

Percona XtraDB Cluster versie 5.6.x en later, of MariaDB Galera Cluster versie 10.x en later.
GTID ingeschakeld.
Binaire logboekregistratie ingeschakeld op ten minste één databaseknooppunt.
De back-upreferenties moeten hetzelfde zijn voor het hoofdcluster en het slavecluster.

Het hoofdcluster voorbereiden

Het hoofdcluster moet worden voorbereid om deze nieuwe functie te gebruiken. Het vereist configuratie van zowel ClusterControl als Database.

ClusterControl-configuratie

Controleer in het databaseknooppunt de back-upgebruikersreferenties die zijn opgeslagen in /etc/my.cnf.d/secrets-backup.cnf (voor op RedHat gebaseerd besturingssysteem) of in /etc/mysql/secrets-backup .cnf (voor op Debian gebaseerd besturingssysteem).

$ cat /etc/my.cnf.d/secrets-backup.cnf

# Security credentials for backup.

[mysqldump]

user=backupuser

password=cYj0GFBEdqdreZEl



[xtrabackup]

user=backupuser

password=cYj0GFBEdqdreZEl



[mysqld]

wsrep_sst_auth=backupuser:cYj0GFBEdqdreZEl

Bewerk in het ClusterControl-knooppunt het /etc/cmon.d/cmon_ID.cnf-configuratiebestand (waarbij ID het Cluster-ID-nummer is) en zorg ervoor dat het dezelfde referenties bevat die zijn opgeslagen in secrets-backup. cnf.

$ cat /etc/cmon.d/cmon_8.cnf

backup_user=backupuser

backup_user_password=cYj0GFBEdqdreZEl

basedir=/usr

cdt_path=/

cluster_id=8

...

Elke wijziging in dit bestand vereist een herstart van de cmon-service:

$ service cmon restart

Controleer de databasereplicatieparameters om er zeker van te zijn dat GTID en binaire logboekregistratie zijn ingeschakeld.

Databaseconfiguratie

Controleer in het databaseknooppunt het bestand /etc/my.cnf (voor op RedHat gebaseerd besturingssysteem) of /etc/mysql/my.cnf (voor op Debian gebaseerd besturingssysteem) om de configuratie met betrekking tot de replicatieproces.

Percona XtraDB:

$ cat /etc/my.cnf

# REPLICATION SPECIFIC

server_id=4002

binlog_format=ROW

log_bin = /var/lib/mysql-binlog/binlog

log_slave_updates = ON

gtid_mode = ON

enforce_gtid_consistency = true

relay_log = relay-log

expire_logs_days = 7

MariaDB Galera-cluster:

$ cat /etc/my.cnf

# REPLICATION SPECIFIC

server_id=9000

binlog_format=ROW

log_bin = /var/lib/mysql-binlog/binlog

log_slave_updates = ON

relay_log = relay-log

wsrep_gtid_domain_id=9000

wsrep_gtid_mode=ON

gtid_domain_id=9000

gtid_strict_mode=ON

gtid_ignore_duplicates=ON

expire_logs_days = 7

In plaats van de configuratiebestanden te controleren, kunt u controleren of dit is ingeschakeld in de gebruikersinterface van ClusterControl. Ga naar ClusterControl -> Cluster selecteren -> Knooppunten. Daar zou je zoiets als dit moeten hebben:

De "Master"-rol die in het eerste knooppunt is toegevoegd, betekent dat de binaire logboekregistratie is ingeschakeld.

Binaire logboekregistratie inschakelen

Als u binaire logboekregistratie niet hebt ingeschakeld, gaat u naar ClusterControl -> Cluster selecteren -> Knooppunten -> Knooppuntacties -> Binaire logboekregistratie inschakelen.

Vervolgens moet u de bewaring van de binaire logbestanden en het pad specificeren het. U moet ook aangeven of u wilt dat ClusterControl het databaseknooppunt opnieuw opstart nadat u het hebt geconfigureerd, of dat u het liever zelf opnieuw opstart.

Houd er rekening mee dat het inschakelen van binaire logboekregistratie altijd een herstart van de databaseservice vereist .

Het slavecluster maken vanuit de ClusterControl GUI

Als u een nieuw slavecluster wilt maken, gaat u naar ClusterControl -> Cluster selecteren -> Clusteracties -> Slavecluster maken.

Het slavecluster kan worden gemaakt door gegevens te streamen van het huidige mastercluster of door een bestaande back-up te gebruiken.

In deze sectie moet u ook het hoofdknooppunt van het huidige cluster kiezen van waaruit de gegevens worden gerepliceerd.

Als u naar de volgende stap gaat, moet u Gebruiker, Sleutel of Wachtwoord en poort om via SSH verbinding te maken met uw servers. U heeft ook een naam nodig voor uw Slave Cluster en als u wilt dat ClusterControl de bijbehorende software en configuraties voor u installeert.

Na het instellen van de SSH-toegangsinformatie, moet u de databaseleverancier en versie, datadir, databasepoort en het beheerderswachtwoord. Zorg ervoor dat u dezelfde leverancier/versie en referenties gebruikt als gebruikt door het hoofdcluster. Je kunt ook aangeven welke repository je wilt gebruiken.

In deze stap moet u servers toevoegen aan het nieuwe Slave-cluster. Voor deze taak kunt u zowel het IP-adres als de hostnaam van elk databaseknooppunt invoeren.

U kunt de status van het maken van uw nieuwe Slave-cluster volgen via de ClusterControl activiteitenmonitor. Zodra de taak is voltooid, kunt u het cluster zien in het hoofdscherm van ClusterControl.

Cluster-naar-cluster replicatie beheren met behulp van de ClusterControl GUI

Nu uw Cluster-naar-Cluster-replicatie actief is, kunt u verschillende acties uitvoeren op deze topologie met ClusterControl.

Active-Active Clusters configureren

Zoals u kunt zien, is het Slave-cluster standaard ingesteld in de modus Alleen-lezen. Het is mogelijk om de alleen-lezen-vlag op de knooppunten één voor één uit te schakelen vanuit de gebruikersinterface van ClusterControl, maar houd er rekening mee dat Active-Active-clustering alleen wordt aanbevolen als toepassingen alleen onsamenhangende gegevenssets op beide clusters raken, aangezien MySQL/MariaDB dat niet doet bieden elke conflictdetectie of -oplossing.

Als u de modus Alleen-lezen wilt uitschakelen, gaat u naar ClusterControl -> Slave selecteren Cluster -> Knooppunten. Selecteer in deze sectie elk knooppunt en gebruik de optie Alleen-lezen uitschakelen.

Een slavencluster opnieuw opbouwen

Om inconsistenties te voorkomen, als u een Slave-cluster opnieuw wilt opbouwen, moet dit een Alleen-lezen-cluster zijn, dit betekent dat alle knooppunten in de Alleen-lezen-modus moeten staan.

Ga naar ClusterControl -> Selecteer Slave-cluster -> Knooppunten -> Kies de Knooppunt verbonden met het hoofdcluster -> Knooppuntacties -> Replicatieslave opnieuw opbouwen.

Topologiewijzigingen

Als je de volgende topologie hebt:

En om de een of andere reden wilt u het replicatieknooppunt in de Master wijzigen TROS. Het is mogelijk om het masterknooppunt dat door het slavecluster wordt gebruikt, te wijzigen in een ander masterknooppunt in het mastercluster.

Om als een masterknooppunt te worden beschouwd, moet binaire logboekregistratie zijn ingeschakeld .

Ga naar ClusterControl -> Selecteer Slave-cluster -> Knooppunten -> Kies de Knooppunt verbonden met de Master Cluster -> Knooppuntacties -> Stop Slave/Start Slave.

Stop/Start replicatieslave

U kunt replicatieslaves op een gemakkelijke manier stoppen en starten met ClusterControl.

Ga naar ClusterControl -> Selecteer Slave-cluster -> Knooppunten -> Kies de Knooppunt verbonden met de Master Cluster -> Knooppuntacties -> Stop Slave/Start Slave.

Replicatie-slave resetten

Met deze actie kun je het replicatieproces resetten met RESET SLAVE of RESET SLAVE ALL. Het verschil tussen beide is dat RESET SLAVE geen enkele replicatieparameter zoals masterhost, poort en inloggegevens verandert. Om deze informatie te verwijderen, moet u RESET SLAVE ALL gebruiken waarmee alle replicatieconfiguratie wordt verwijderd, dus als u deze opdracht gebruikt, wordt de koppeling Cluster-naar-clusterreplicatie vernietigd.

Voordat u deze functie gebruikt, moet u het replicatieproces stoppen (raadpleeg de vorige functie).

Ga naar ClusterControl -> Selecteer Slave-cluster -> Knooppunten -> Kies de Knooppunt verbonden met het mastercluster -> Knooppuntacties -> Slave resetten/Alle slaven resetten.

Cluster-naar-cluster-replicatie beheren met de ClusterControl CLI

In het vorige gedeelte hebt u kunnen zien hoe u een Cluster-naar-Cluster-replicatie kunt beheren met behulp van de ClusterControl-gebruikersinterface. Laten we nu eens kijken hoe we dit kunnen doen met behulp van de opdrachtregel.

Opmerking:zoals we aan het begin van deze blog vermeldden, gaan we ervan uit dat je ClusterControl hebt geïnstalleerd en dat het hoofdcluster ermee is geïmplementeerd.

Maak het slavencluster

Laten we eerst een voorbeeldopdracht bekijken om een slavecluster te maken met behulp van de ClusterControl CLI:

$ s9s cluster --create --cluster-name=Galera1rep --cluster-type=galera  --provider-version=10.4 --nodes="192.168.100.166;192.168.100.167;192.168.100.168"  --os-user=root --os-key-file=/root/.ssh/id_rsa --db-admin=root --db-admin-passwd=xxxxxxxx --vendor=mariadb --remote-cluster-id=11 --log

Nu heb je je maak-slave-proces aan de gang, laten we elke gebruikte parameter bekijken:

Cluster:om clusters op te sommen en te manipuleren.
Maken:maak en installeer een nieuw cluster.
Clusternaam:de naam van het nieuwe slavencluster.
Clustertype:het type cluster dat moet worden geïnstalleerd.
Provider-versie:de softwareversie.
Knooppunten:lijst met de nieuwe knooppunten in het slavecluster.
Os-user:de gebruikersnaam voor de SSH-commando's.
Os-key-file:het sleutelbestand dat moet worden gebruikt voor SSH-verbinding.
Db-admin:de gebruikersnaam van de databasebeheerder.
Db-admin-passwd:Het wachtwoord voor de databasebeheerder.
Remote-cluster-id:hoofdcluster-ID voor de cluster-naar-cluster-replicatie.
Log:wacht en volg taakberichten.

Als u de vlag --log gebruikt, kunt u de logboeken in realtime bekijken:

Verifying job parameters.

Checking ssh/sudo on 3 hosts.

All 3 hosts are accessible by SSH.

192.168.100.166: Checking if host already exists in another cluster.

192.168.100.167: Checking if host already exists in another cluster.

192.168.100.168: Checking if host already exists in another cluster.

192.168.100.157:3306: Binary logging is enabled.

192.168.100.158:3306: Binary logging is enabled.

Creating the cluster with the following:

wsrep_cluster_address = 'gcomm://192.168.100.166,192.168.100.167,192.168.100.168'

Calling job: setupServer(192.168.100.166).

192.168.100.166: Checking OS information.

…

Caching config files.

Job finished, all the nodes have been added successfully.

Active-Active Clusters configureren

Zoals je eerder kon zien, kun je de Alleen-lezen-modus in het nieuwe cluster uitschakelen door deze in elk knooppunt uit te schakelen, dus laten we eens kijken hoe je dit vanaf de opdrachtregel kunt doen.

$ s9s node --set-read-write --nodes="192.168.100.166" --cluster-id=16 --log

Laten we elke parameter eens bekijken:

Knooppunt:om knooppunten te verwerken.
Set-read-write:stel het knooppunt in op de lees-schrijfmodus.
Knooppunten:het knooppunt waar het moet worden gewijzigd.
Cluster-id:de ID van het cluster waarin het knooppunt zich bevindt.

Dan zie je:

192.168.100.166:3306: Setting read_only=OFF.

Een slavencluster opnieuw opbouwen

U kunt een slavecluster opnieuw opbouwen met de volgende opdracht:

$ s9s replication --stage --master="192.168.100.157:3306" --slave="192.168.100.166:3306" --cluster-id=19 --remote-cluster-id=11 --log

De parameters zijn:

Replicatie:voor het bewaken en controleren van gegevensreplicatie.
Stage:een replicatieslave uitvoeren/opnieuw bouwen.
Master:de replicatiemaster in de mastercluster.
Slaaf:de replicatieslave in het slavecluster.
Cluster-id:de slave-cluster-ID.
Remote-cluster-id:de hoofdcluster-ID.
Log:wacht en volg taakberichten.

Het takenlogboek zou er ongeveer zo uit moeten zien:

Rebuild replication slave 192.168.100.166:3306 from master 192.168.100.157:3306.

Remote cluster id = 11

Shutting down Galera Cluster.

192.168.100.166:3306: Stopping node.

192.168.100.166:3306: Stopping mysqld (timeout=60, force stop after timeout=true).

192.168.100.166: Stopping MySQL service.

192.168.100.166: All processes stopped.

192.168.100.166:3306: Stopped node.

192.168.100.167:3306: Stopping node.

192.168.100.167:3306: Stopping mysqld (timeout=60, force stop after timeout=true).

192.168.100.167: Stopping MySQL service.

192.168.100.167: All processes stopped.

…

192.168.100.157:3306: Changing master to 192.168.100.166:3306.

192.168.100.157:3306: Changed master to 192.168.100.166:3306

192.168.100.157:3306: Starting slave.

192.168.100.157:3306: Collecting replication statistics.

192.168.100.157:3306: Started slave successfully.

192.168.100.166:3306: Starting node

Writing file '192.168.100.167:/etc/mysql/my.cnf'.

Writing file '192.168.100.167:/etc/mysql/secrets-backup.cnf'.

Writing file '192.168.100.168:/etc/mysql/my.cnf'.

Topologiewijzigingen

U kunt uw topologie wijzigen met een ander knooppunt in het hoofdcluster van waaruit de gegevens worden gerepliceerd, zodat u bijvoorbeeld het volgende kunt uitvoeren:

$ s9s replication --failover --master="192.168.100.161:3306" --slave="192.168.100.163:3306" --cluster-id=10 --remote-cluster-id=9 --log

Laten we de gebruikte parameters eens bekijken.

Replicatie:voor het bewaken en controleren van gegevensreplicatie.
Failover:neem de rol van meester over van een mislukte/oude meester.
Master:de nieuwe replicatiemaster in het hoofdcluster.
Slaaf:de replicatieslave in het slavecluster.
Cluster-id:de ID van het slavencluster.
Remote-Cluster-id:de ID van het hoofdcluster.
Log:wacht en volg taakberichten.

Je ziet dit logboek:

192.168.100.161:3306 belongs to cluster id 9.

192.168.100.163:3306: Changing master to 192.168.100.161:3306

192.168.100.163:3306: My master is 192.168.100.160:3306.

192.168.100.161:3306: Sanity checking replication master '192.168.100.161:3306[cid:9]' to be used by '192.168.100.163[cid:139814070386698]'.

192.168.100.161:3306: Executing GRANT REPLICATION SLAVE ON *.* TO 'cmon_replication'@'192.168.100.163'.

Setting up link between  192.168.100.161:3306 and 192.168.100.163:3306

192.168.100.163:3306: Stopping slave.

192.168.100.163:3306: Successfully stopped slave.

192.168.100.163:3306: Setting up replication using MariaDB GTID: 192.168.100.161:3306->192.168.100.163:3306.

192.168.100.163:3306: Changing Master using master_use_gtid=slave_pos.

192.168.100.163:3306: Changing master to 192.168.100.161:3306.

192.168.100.163:3306: Changed master to 192.168.100.161:3306

192.168.100.163:3306: Starting slave.

192.168.100.163:3306: Collecting replication statistics.

192.168.100.163:3306: Started slave successfully.

192.168.100.160:3306: Flushing logs to update 'SHOW SLAVE HOSTS'

Stop/Start replicatieslave

U kunt op deze manier stoppen om de gegevens van het hoofdcluster te repliceren:

$ s9s replication --stop --slave="192.168.100.166:3306" --cluster-id=19 --log

Je ziet dit:

192.168.100.166:3306: Ensuring the datadir '/var/lib/mysql' exists and is owned by 'mysql'.

192.168.100.166:3306: Stopping slave.

192.168.100.166:3306: Successfully stopped slave.

En nu kun je het opnieuw beginnen:

$ s9s replication --start --slave="192.168.100.166:3306" --cluster-id=19 --log

Dus je zult zien:

192.168.100.166:3306: Ensuring the datadir '/var/lib/mysql' exists and is owned by 'mysql'.

192.168.100.166:3306: Starting slave.

192.168.100.166:3306: Collecting replication statistics.

192.168.100.166:3306: Started slave successfully.

Laten we nu eens kijken naar de gebruikte parameters.

Replicatie:voor het bewaken en controleren van gegevensreplicatie.
Stop/Start:om de slave te laten stoppen/starten met repliceren.
Slaaf:het replicatie-slaveknooppunt.
Cluster-id:de ID van het cluster waarin het slave-knooppunt zich bevindt.
Log:wacht en volg taakberichten.

Replicatie-slave resetten

Met deze opdracht kun je het replicatieproces resetten met RESET SLAVE of RESET SLAVE ALL. Raadpleeg voor meer informatie over deze opdracht het gebruik hiervan in het vorige gedeelte over de gebruikersinterface van ClusterControl.

Voordat u deze functie gebruikt, moet u het replicatieproces stoppen (raadpleeg de vorige opdracht).

RESET SLAVE:

$ s9s replication --reset  --slave="192.168.100.166:3306" --cluster-id=19 --log

Het logboek zou moeten zijn als:

192.168.100.166:3306: Ensuring the datadir '/var/lib/mysql' exists and is owned by 'mysql'.

192.168.100.166:3306: Executing 'RESET SLAVE'.

192.168.100.166:3306: Command 'RESET SLAVE' succeeded.

RESET ALLE SLAVEN:

$ s9s replication --reset --force  --slave="192.168.100.166:3306" --cluster-id=19 --log

En dit logboek zou moeten zijn:

192.168.100.166:3306: Ensuring the datadir '/var/lib/mysql' exists and is owned by 'mysql'.

192.168.100.166:3306: Executing 'RESET SLAVE /*!50500 ALL */'.

192.168.100.166:3306: Command 'RESET SLAVE /*!50500 ALL */' succeeded.

Laten we eens kijken naar de gebruikte parameters voor zowel RESET SLAVE als RESET SLAVE ALL.

Replicatie:voor het bewaken en controleren van gegevensreplicatie.
Reset:reset de slave-node.
Forceer:met deze vlag gebruikt u de opdracht RESET SLAVE ALL op de slave-node.
Slaaf:het replicatie-slaveknooppunt.
Cluster-id:de slave-cluster-ID.
Log:wacht en volg taakberichten.

Conclusie

Met deze nieuwe ClusterControl-functie kunt u snel Cluster-naar-Cluster-replicatie maken en deze op een gemakkelijke en vriendelijke manier beheren. Deze omgeving zal je database/clustertopologie verbeteren en zou handig zijn voor een Disaster Recovery Plan, testomgeving en nog meer opties die in de overzichtsblog worden genoemd.