sql >> Database >  >> RDS >> MariaDB

Een MariaDB Galera-cluster runnen zonder orkestratietools - DB Container Management:deel twee

Zoals we in het eerste deel van deze blog zagen, speelt een sterk consistent databasecluster zoals Galera niet goed samen met containerorkestratietools zoals Kubernetes of Swarm. We hebben je laten zien hoe je Galera implementeert en procesbeheer configureert voor Docker, zodat je volledige controle behoudt over het gedrag. Deze blogpost is het vervolg daarop, we gaan ons verdiepen in de werking en het onderhoud van het cluster.

Om enkele van de belangrijkste punten uit deel 1 van deze blog samen te vatten, hebben we een Galera-cluster met drie knooppunten geïmplementeerd, met ProxySQL en Keepalived op drie verschillende Docker-hosts, waarbij alle MariaDB-instanties als Docker-containers worden uitgevoerd. Het volgende diagram illustreert de uiteindelijke implementatie:

Graceful Shutdown

Om een ​​sierlijke MySQL-afsluiting uit te voeren, is de beste manier om SIGTERM (signaal 15) naar de container te sturen:

$ docker kill -s 15 {db_container_name}

Als u het cluster wilt afsluiten, herhaalt u de bovenstaande opdracht op alle databasecontainers, één knooppunt tegelijk. Het bovenstaande is vergelijkbaar met het uitvoeren van "systemctl stop mysql" in systemd-service voor MariaDB. Het gebruik van de "docker stop"-opdracht is behoorlijk riskant voor de databaseservice omdat het 10 seconden wacht en Docker SIGKILL forceert als deze duur wordt overschreden (tenzij u een juiste --time-out gebruikt waarde).

Het laatste knooppunt dat netjes wordt afgesloten, heeft de seqno niet gelijk aan -1 en safe_to_bootstrap vlag is ingesteld op 1 in de /{datadir volume}/grastate.dat van de Docker-host, bijvoorbeeld op host2:

$ cat /containers/mariadb2/datadir/grastate.dat
# GALERA saved state
version: 2.1
uuid:    e70b7437-645f-11e8-9f44-5b204e58220b
seqno:   7099
safe_to_bootstrap: 1

De meest geavanceerde node detecteren

Als het cluster niet correct werd afgesloten, of als het knooppunt dat u probeerde te bootstrappen niet het laatste knooppunt was dat het cluster verliet, zou u waarschijnlijk een van de Galera-knooppunten niet kunnen opstarten en zou de volgende fout kunnen optreden :

2016-11-07 01:49:19 5572 [ERROR] WSREP: It may not be safe to bootstrap the cluster from this node.
It was not the last one to leave the cluster and may not contain all the updates.
To force cluster bootstrap with this node, edit the grastate.dat file manually and set safe_to_bootstrap to 1 .

Galera eert de node die safe_to_bootstrap . heeft vlag ingesteld op 1 als het eerste referentieknooppunt. Dit is de veiligste manier om gegevensverlies te voorkomen en ervoor te zorgen dat het juiste knooppunt altijd wordt opgestart.

Als je de fout hebt gekregen, moeten we eerst het meest geavanceerde knooppunt vinden voordat we het knooppunt oppikken als het eerste dat moet worden opgestart. Maak een tijdelijke container (met --rm vlag), wijs het toe aan dezelfde datadir en configuratiemap van de eigenlijke databasecontainer met twee MySQL-opdrachtvlaggen, --wsrep_recover en --wsrep_cluster_address . Als we bijvoorbeeld het laatste vastgelegde nummer van mariadb1 willen weten, moeten we uitvoeren:

$ docker run --rm --name mariadb-recover \
        --env MYSQL_ROOT_PASSWORD="PM7%[email protected]^1" \
        --volume /containers/mariadb1/datadir:/var/lib/mysql \
        --volume /containers/mariadb1/conf.d:/etc/mysql/conf.d \
        mariadb:10.2.15 \
        --wsrep_recover \
        --wsrep_cluster_address=gcomm://
2018-06-12  4:46:35 139993094592384 [Note] mysqld (mysqld 10.2.15-MariaDB-10.2.15+maria~jessie) starting as process 1 ...
2018-06-12  4:46:35 139993094592384 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
...
2018-06-12  4:46:35 139993094592384 [Note] Plugin 'FEEDBACK' is disabled.
2018-06-12  4:46:35 139993094592384 [Note] Server socket created on IP: '::'.
2018-06-12  4:46:35 139993094592384 [Note] WSREP: Recovered position: e70b7437-645f-11e8-9f44-5b204e58220b:7099

De laatste regel is wat we zoeken. MariaDB drukt de cluster-UUID af en het volgnummer van de meest recentelijk vastgelegde transactie. Het knooppunt met het hoogste nummer wordt beschouwd als het meest geavanceerde knooppunt. Omdat we --rm . hebben gespecificeerd , wordt de container automatisch verwijderd zodra deze wordt afgesloten. Herhaal de bovenstaande stap op elke Docker-host door het --volume . te vervangen pad naar de respectieve databasecontainervolumes.

Nadat u de door alle databasecontainers gerapporteerde waarde hebt vergeleken en hebt besloten welke container het meest actuele knooppunt is, wijzigt u de safe_to_bootstrap markeer handmatig naar 1 binnen /{datadir volume}/grastate.dat. Laten we zeggen dat alle knooppunten hetzelfde exacte volgnummer rapporteren, we kunnen gewoon mariadb3 kiezen om te worden opgestart door de safe_to_bootstrap te wijzigen waarde op 1:

$ vim /containers/mariadb3/datadir/grasate.dat
...
safe_to_bootstrap: 1

Sla het bestand op en start het opstarten van de cluster vanaf dat knooppunt, zoals beschreven in het volgende hoofdstuk.

Bootstrapping van de cluster

Het bootstrappen van de cluster is vergelijkbaar met de eerste opdracht voor het uitvoeren van docker die we gebruikten toen we de cluster voor de eerste keer opstartten. Als mariadb1 het gekozen bootstrap-knooppunt is, kunnen we eenvoudig de gemaakte bootstrap-container opnieuw uitvoeren:

$ docker start mariadb0 # on host1

Anders, als de bootstrap-container niet bestaat op het gekozen knooppunt, laten we zeggen op host2, voer dan het bootstrap container-commando uit en wijs de bestaande volumes van mariadb2 toe. We gebruiken mariadb0 als de containernaam op host2 om aan te geven dat het een bootstrap-container is:

$ docker run -d \
        --name mariadb0 \
        --hostname mariadb0.weave.local \
        --net weave \
        --publish "3306" \
        --publish "4444" \
        --publish "4567" \
        --publish "4568" \
        $(weave dns-args) \
        --env MYSQL_ROOT_PASSWORD="PM7%[email protected]^1" \
        --volume /containers/mariadb2/datadir:/var/lib/mysql \
        --volume /containers/mariadb2/conf.d:/etc/mysql/mariadb.conf.d \
        mariadb:10.2.15 \
        --wsrep_cluster_address=gcomm:// \
        --wsrep_sst_auth="root:PM7%[email protected]^1" \
        --wsrep_node_address=mariadb0.weave.local

U zult merken dat deze opdracht iets korter is in vergelijking met de vorige bootstrap-opdracht die in deze handleiding wordt beschreven. Aangezien we de proxysql-gebruiker al hebben aangemaakt in onze eerste bootstrap-opdracht, kunnen we deze twee omgevingsvariabelen overslaan:

  • --env MYSQL_USER=proxysql
  • --env MYSQL_PASSWORD=proxysqlwachtwoord

Start vervolgens de resterende MariaDB-containers, verwijder de bootstrap-container en start de bestaande MariaDB-container op de bootstrap-host. In principe zou de volgorde van de commando's zijn:

$ docker start mariadb1 # on host1
$ docker start mariadb3 # on host3
$ docker stop mariadb0 # on host2
$ docker start mariadb2 # on host2

Op dit punt is het cluster gestart en draait het op volle capaciteit.

Bronnenbeheer

Geheugen is een zeer belangrijke hulpbron in MySQL. Dit is waar de buffers en caches worden opgeslagen, en het is van cruciaal belang voor MySQL om de impact van het te vaak raken van de schijf te verminderen. Aan de andere kant is swappen slecht voor de MySQL-prestaties. Standaard zijn er geen resourcebeperkingen voor de actieve containers. Containers gebruiken zoveel van een bepaalde bron als de kernel van de host toestaat. Een ander belangrijk ding is de bestandsdescriptorlimiet. U kunt de limiet van de open bestandsdescriptor, of "nofile" verhogen tot iets hogers om tegemoet te komen aan het aantal bestanden dat de MySQL-server tegelijkertijd kan openen. Dit op een hoge waarde instellen kan geen kwaad.

Om de geheugentoewijzing te beperken en de bestandsdescriptorlimiet voor onze databasecontainer te verhogen, zou men --memory toevoegen , --memory-swap en --ulimit parameters in het "docker run" commando:

$ docker kill -s 15 mariadb1
$ docker rm -f mariadb1
$ docker run -d \
        --name mariadb1 \
        --hostname mariadb1.weave.local \
        --net weave \
        --publish "3306:3306" \
        --publish "4444" \
        --publish "4567" \
        --publish "4568" \
        $(weave dns-args) \
        --memory 16g \
        --memory-swap 16g \
        --ulimit nofile:16000:16000 \
        --env MYSQL_ROOT_PASSWORD="PM7%[email protected]^1" \
        --volume /containers/mariadb1/datadir:/var/lib/mysql \
        --volume /containers/mariadb1/conf.d:/etc/mysql/mariadb.conf.d \
        mariadb:10.2.15 \
        --wsrep_cluster_address=gcomm://mariadb0.weave.local,mariadb1.weave.local,mariadb2.weave.local,mariadb3.weave.local \
        --wsrep_sst_auth="root:PM7%[email protected]^1" \
        --wsrep_node_address=mariadb1.weave.local

Houd er rekening mee dat als --memory-swap is ingesteld op dezelfde waarde als --memory , en --geheugen is ingesteld op een positief geheel getal, heeft de container geen toegang tot swap. Als --memory-swap niet is ingesteld, wordt containerwissel standaard ingesteld op --memory vermenigvuldig met 2. Als --geheugen en --memory-swap zijn ingesteld op dezelfde waarde, voorkomt dit dat containers een swap gebruiken. Dit komt omdat --memory-swap is de hoeveelheid gecombineerd geheugen en swap die kan worden gebruikt, terwijl --memory is alleen de hoeveelheid fysiek geheugen die kan worden gebruikt.

Sommige containerbronnen, zoals geheugen en CPU, kunnen dynamisch worden bestuurd via de opdracht "docker update", zoals in het volgende voorbeeld wordt getoond om het geheugen van container mariadb1 on-the-fly te upgraden naar 32G:

$ docker update \
    --memory 32g \
    --memory-swap 32g \
    mariadb1

Vergeet niet de my.cnf dienovereenkomstig af te stemmen op de nieuwe specificaties. Configuratiebeheer wordt uitgelegd in de volgende sectie.

Configuratiebeheer

De meeste MySQL/MariaDB-configuratieparameters kunnen tijdens runtime worden gewijzigd, wat betekent dat u niet opnieuw hoeft op te starten om de wijzigingen toe te passen. Bekijk de MariaDB-documentatiepagina voor meer informatie. De parameter die wordt vermeld met "Dynamisch:Ja" betekent dat de variabele onmiddellijk wordt geladen na wijziging zonder dat de MariaDB-server opnieuw hoeft te worden opgestart. Stel anders de parameters in het aangepaste configuratiebestand in de Docker-host in. Breng bijvoorbeeld op mariadb3 de wijzigingen aan in het volgende bestand:

$ vim /containers/mariadb3/conf.d/my.cnf

En start vervolgens de databasecontainer opnieuw om de wijziging toe te passen:

$ docker restart mariadb3

Controleer of de container het proces start door naar de docker-logboeken te kijken. Voer deze bewerking op één knooppunt tegelijk uit als u clusterbrede wijzigingen wilt aanbrengen.

Back-up

Het maken van een logische back-up is vrij eenvoudig, omdat de MariaDB-afbeelding ook wordt geleverd met binair mysqldump. U gebruikt gewoon de opdracht "docker exec" om de mysqldump uit te voeren en de uitvoer naar een bestand te sturen dat gerelateerd is aan het hostpad. De volgende opdracht voert mysqldump-back-up uit op mariadb2 en slaat het op in /backups/mariadb2 in host2:

$ docker exec -it mariadb2 mysqldump -uroot -p --single-transaction > /backups/mariadb2/dump.sql

Binaire back-up zoals Percona Xtrabackup of MariaDB Backup vereist het proces om rechtstreeks toegang te krijgen tot de MariaDB-gegevensdirectory. U moet deze tool ofwel in de container installeren, of via de machinehost, of u moet een speciale afbeelding voor dit doel gebruiken, zoals de "perconalab/percona-xtrabackup"-afbeelding om de back-up te maken en deze op te slaan in /tmp/backup op de Docker-host:

$ docker run --rm -it \
    -v /containers/mariadb2/datadir:/var/lib/mysql \
    -v /tmp/backup:/xtrabackup_backupfiles \
    perconalab/percona-xtrabackup \
    --backup --host=mariadb2 --user=root --password=mypassword

Je kunt de container ook stoppen met innodb_fast_shutdown stel in op 0 en kopieer over het datadir-volume naar een andere locatie in de fysieke host:

$ docker exec -it mariadb2 mysql -uroot -p -e 'SET GLOBAL innodb_fast_shutdown = 0'
$ docker kill -s 15 mariadb2
$ cp -Rf /containers/mariadb2/datadir /backups/mariadb2/datadir_copied
$ docker start mariadb2

Herstellen

Herstellen is vrij eenvoudig voor mysqldump. Je kunt de stdin eenvoudig omleiden naar de container vanaf de fysieke host:

$ docker exec -it mariadb2 mysql -uroot -p < /backups/mariadb2/dump.sql

U kunt ook de standaard mysql-clientopdrachtregel op afstand gebruiken met de juiste hostnaam en poortwaarde in plaats van deze "docker exec"-opdracht:

$ mysql -uroot -p -h127.0.0.1 -P3306 < /backups/mariadb2/dump.sql

Voor Percona Xtrabackup en MariaDB Backup moeten we de back-up vooraf voorbereiden. Hiermee wordt de back-up doorgestuurd naar het tijdstip waarop de back-up was voltooid. Laten we zeggen dat onze Xtrabackup-bestanden zich onder /tmp/backup van de Docker-host bevinden, om het eenvoudig voor te bereiden:

$ docker run --rm -it \
    -v mysql-datadir:/var/lib/mysql \
    -v /tmp/backup:/xtrabackup_backupfiles \
    perconalab/percona-xtrabackup \
    --prepare --target-dir /xtrabackup_backupfiles

De voorbereide back-up onder /tmp/backup van de Docker-host kan dan worden gebruikt als de MariaDB-datadir voor een nieuwe container of cluster. Laten we zeggen dat we het herstel alleen willen verifiëren op een zelfstandige MariaDB-container, we zouden het volgende uitvoeren:

$ docker run -d \
    --name mariadb-restored \
    --env MYSQL_ROOT_PASSWORD="PM7%[email protected]^1" \
    -v /tmp/backup:/var/lib/mysql \
    mariadb:10.2.15

Als u een back-up hebt gemaakt met de stop- en kopieeraanpak, kunt u eenvoudig de datadir dupliceren en de gedupliceerde map gebruiken als een volumetoewijzing aan MariaDB-datadir om op een andere container te draaien. Laten we zeggen dat de back-up is gekopieerd onder /backups/mariadb2/datadir_copied, we kunnen een nieuwe container uitvoeren door het volgende uit te voeren:

$ mkdir -p /containers/mariadb-restored/datadir
$ cp -Rf /backups/mariadb2/datadir_copied /containers/mariadb-restored/datadir
$ docker run -d \
    --name mariadb-restored \
    --env MYSQL_ROOT_PASSWORD="PM7%[email protected]^1" \
    -v /containers/mariadb-restored/datadir:/var/lib/mysql \
    mariadb:10.2.15

De MYSQL_ROOT_PASSWORD moet overeenkomen met het daadwerkelijke root-wachtwoord voor die specifieke back-up.

Multiplenines MySQL op Docker:hoe u uw database kunt containeriserenOntdek alles wat u moet weten wanneer u overweegt een MySQL-service uit te voeren bovenop Docker-containervirtualisatieDownload de whitepaper

Upgrade databaseversie

Er zijn twee soorten upgrades:een interne upgrade of een logische upgrade.

In-place upgrade omvat het afsluiten van de MariaDB-server, het vervangen van de oude binaire bestanden door de nieuwe binaire bestanden en vervolgens het starten van de server in de oude gegevensmap. Eenmaal gestart, moet u mysql_upgrade . uitvoeren script om alle systeemtabellen te controleren en te upgraden en ook om de gebruikerstabellen te controleren.

De logische upgrade omvat het exporteren van SQL uit de huidige versie met behulp van een logisch back-uphulpprogramma zoals mysqldump, het uitvoeren van de nieuwe container met de geüpgradede versiebinaire bestanden en het vervolgens toepassen van de SQL op de nieuwe MySQL/MariaDB-versie. Het is vergelijkbaar met de back-up- en herstelbenadering die in de vorige sectie is beschreven.

Niettemin is het een goede benadering om altijd een back-up van uw database te maken voordat u destructieve bewerkingen uitvoert. De volgende stappen zijn vereist bij het upgraden van de huidige afbeelding, MariaDB 10.1.33 naar een andere hoofdversie, MariaDB 10.2.15 op mariadb3 staat op host3:

  1. Maak een back-up van de database. Het maakt niet uit fysieke of logische back-up, maar de laatste met behulp van mysqldump wordt aanbevolen.

  2. Download de nieuwste afbeelding waarnaar we willen upgraden:

    $ docker pull mariadb:10.2.15

  3. Stel innodb_fast_shutdown in op 0 voor onze databasecontainer:

    $ docker exec -it mariadb3 mysql -uroot -p -e 'SET GLOBAL innodb_fast_shutdown = 0'

  4. Graceful sluit de databasecontainer af:

    $ docker kill --signal=TERM mariadb3

  5. Maak een nieuwe container met de nieuwe afbeelding voor onze databasecontainer. Houd de rest van de parameters intact, behalve het gebruik van de nieuwe containernaam (anders zou het conflicteren):

    $ docker run -d \
        --name mariadb3-new \
        --hostname mariadb3.weave.local \
        --net weave \
        --publish "3306:3306" \
        --publish "4444" \
        --publish "4567" \
        --publish "4568" \
        $(weave dns-args) \
        --env MYSQL_ROOT_PASSWORD="PM7%[email protected]^1" \
        --volume /containers/mariadb3/datadir:/var/lib/mysql \
        --volume /containers/mariadb3/conf.d:/etc/mysql/mariadb.conf.d \
        mariadb:10.2.15 \
        --wsrep_cluster_address=gcomm://mariadb0.weave.local,mariadb1.weave.local,mariadb2.weave.local,mariadb3.weave.local \
        --wsrep_sst_auth="root:PM7%[email protected]^1" \
        --wsrep_node_address=mariadb3.weave.local

  6. Voer het mysql_upgrade-script uit:

    $ docker exec -it mariadb3-new mysql_upgrade -uroot -p

  7. Als er geen fouten zijn opgetreden, verwijdert u de oude container, mariadb3 (de nieuwe is mariadb3-new):

    $ docker rm -f mariadb3

  8. Anders, als het upgradeproces tussendoor mislukt, kunnen we terugvallen op de vorige container:

    $ docker stop mariadb3-new
$ docker start mariadb3

Een grote versie-upgrade kan op dezelfde manier worden uitgevoerd als de kleine versie-upgrade, behalve dat u er rekening mee moet houden dat MySQL/MariaDB alleen een grote upgrade van de vorige versie ondersteunt. Als u MariaDB 10.0 gebruikt en wilt upgraden naar 10.2, moet u eerst upgraden naar MariaDB 10.1, gevolgd door een andere upgradestap naar MariaDB 10.2.

Let op de configuratiewijzigingen die worden geïntroduceerd en beëindigd tussen de belangrijkste versies.

Failover

In Galera zijn alle knooppunten meesters en hebben ze dezelfde rol. Met ProxySQL in beeld, wordt automatisch een failover uitgevoerd voor verbindingen die door deze gateway gaan, zolang er een primaire component voor Galera Cluster actief is (dat wil zeggen, een meerderheid van de knooppunten is actief). De toepassing merkt geen verschil als een databaseknooppunt uitvalt, omdat ProxySQL de verbindingen eenvoudigweg omleidt naar de andere beschikbare knooppunten.

Als de applicatie rechtstreeks verbinding maakt met de MariaDB waarbij ProxySQL wordt omzeild, moet de failover worden uitgevoerd aan de kant van de applicatie door te verwijzen naar het volgende beschikbare knooppunt, op voorwaarde dat het databaseknooppunt aan de volgende voorwaarden voldoet:

  • Status wsrep_local_state_comment is gesynchroniseerd (de status "Desynced/Donor" is ook mogelijk, alleen als wsrep_sst_method is xtrabackup, xtrabackup-v2 of mariabackup).
  • Status wsrep_cluster_status is primair.

In Galera betekent een beschikbaar knooppunt niet dat het in orde is totdat de bovenstaande status is geverifieerd.

Uitschalen

Om uit te schalen, kunnen we een nieuwe container in hetzelfde netwerk maken en hetzelfde aangepaste configuratiebestand gebruiken voor de bestaande container op die specifieke host. Laten we bijvoorbeeld zeggen dat we de vierde MariaDB-container op host3 willen toevoegen, we kunnen hetzelfde configuratiebestand gebruiken dat is aangekoppeld voor mariadb3, zoals geïllustreerd in het volgende diagram:

Voer de volgende opdracht uit op host3 om uit te schalen:

$ docker run -d \
        --name mariadb4 \
        --hostname mariadb4.weave.local \
        --net weave \
        --publish "3306:3307" \
        --publish "4444" \
        --publish "4567" \
        --publish "4568" \
        $(weave dns-args) \
        --env MYSQL_ROOT_PASSWORD="PM7%[email protected]^1" \
        --volume /containers/mariadb4/datadir:/var/lib/mysql \
        --volume /containers/mariadb3/conf.d:/etc/mysql/mariadb.conf.d \
        mariadb:10.2.15 \
        --wsrep_cluster_address=gcomm://mariadb1.weave.local,mariadb2.weave.local,mariadb3.weave.local,mariadb4.weave.local \
        --wsrep_sst_auth="root:PM7%[email protected]^1" \
        --wsrep_node_address=mariadb4.weave.local

Zodra de container is gemaakt, wordt deze toegevoegd aan het cluster en wordt SST uitgevoerd. Het is toegankelijk via poort 3307 extern of buiten het Weave-netwerk, of poort 3306 binnen de host of binnen het Weave-netwerk. Het is niet meer nodig om mariadb0.weave.local in het clusteradres op te nemen. Zodra het cluster is uitgeschaald, moeten we de nieuwe MariaDB-container toevoegen aan de ProxySQL-taakverdelingsset via de beheerdersconsole:

$ docker exec -it proxysql1 mysql -uadmin -padmin -P6032
mysql> INSERT INTO mysql_servers(hostgroup_id,hostname,port) VALUES (10,'mariadb4.weave.local',3306);
mysql> INSERT INTO mysql_servers(hostgroup_id,hostname,port) VALUES (20,'mariadb4.weave.local',3306);
mysql> LOAD MYSQL SERVERS TO RUNTIME;
mysql> SAVE MYSQL SERVERS TO DISK;

Herhaal de bovenstaande opdrachten op de tweede ProxySQL-instantie.

Ten slotte, voor de laatste stap (u kunt dit deel overslaan als u de instructie "SAVE .. TO DISK" in ProxySQL al hebt uitgevoerd), voegt u de volgende regel toe aan proxysql.cnf om deze persistent te maken tijdens het opnieuw opstarten van de container op host1 en host2:

$ vim /containers/proxysql1/proxysql.cnf # host1
$ vim /containers/proxysql2/proxysql.cnf # host2

En voeg mariadb4-gerelateerde regels toe onder mysql_server-richtlijn:

mysql_servers =
(
        { address="mariadb1.weave.local" , port=3306 , hostgroup=10, max_connections=100 },
        { address="mariadb2.weave.local" , port=3306 , hostgroup=10, max_connections=100 },
        { address="mariadb3.weave.local" , port=3306 , hostgroup=10, max_connections=100 },
        { address="mariadb4.weave.local" , port=3306 , hostgroup=10, max_connections=100 },
        { address="mariadb1.weave.local" , port=3306 , hostgroup=20, max_connections=100 },
        { address="mariadb2.weave.local" , port=3306 , hostgroup=20, max_connections=100 },
        { address="mariadb3.weave.local" , port=3306 , hostgroup=20, max_connections=100 },
        { address="mariadb4.weave.local" , port=3306 , hostgroup=20, max_connections=100 }
)

Sla het bestand op en we zouden goed moeten zijn bij de volgende herstart van de container.

Verkleinen

Om te verkleinen, sluit u de container eenvoudig gracieus af. Het beste commando zou zijn:

$ docker kill -s 15 mariadb4
$ docker rm -f mariadb4

Onthoud dat als het databaseknooppunt het cluster onfatsoenlijk verliet, dit geen deel uitmaakte van het verkleinen en de quorumberekening zou beïnvloeden.

Om de container uit ProxySQL te verwijderen, voert u de volgende opdrachten uit op beide ProxySQL-containers. Bijvoorbeeld op proxysql1:

$ docker exec -it proxysql1 mysql -uadmin -padmin -P6032
mysql> DELETE FROM mysql_servers WHERE hostname="mariadb4.weave.local";
mysql> LOAD MYSQL SERVERS TO RUNTIME;
mysql> SAVE MYSQL SERVERS TO DISK;

U kunt dan ofwel het corresponderende item in proxysql.cnf verwijderen of het gewoon zo laten. Het zal hoe dan ook worden gedetecteerd als OFFLINE vanuit ProxySQL-oogpunt.

Samenvatting

Met Docker wordt het een beetje anders dan de conventionele manier om met MySQL- of MariaDB-servers om te gaan. Het afhandelen van stateful services zoals Galera Cluster is niet zo eenvoudig als stateless applicaties en vereist goede tests en planning.

In onze volgende blog over dit onderwerp zullen we de voor- en nadelen evalueren van het uitvoeren van Galera Cluster op Docker zonder orkestratietools.


  1. Verbinding maken met een Oracle-database met behulp van SQLAlchemy

  2. Een willekeurig getal genereren binnen een opgegeven bereik in SQLite

  3. Een alias gebruiken in een WHERE-component

  4. Interessante dingen over IN PLAATS VAN triggers