In de vorige blog hebben we enkele tips en trucs besproken om een MySQL-server voor te bereiden op productiegebruik vanuit het perspectief van een systeembeheerder. Deze blogpost is het vervolg...
Gebruik een databaseback-uptool
Elke back-uptool heeft zijn eigen voor- en nadelen. Percona Xtrabackup (of MariaDB Backup voor MariaDB) kan bijvoorbeeld een fysieke hot-back-up uitvoeren zonder de databases te vergrendelen, maar deze kan alleen worden hersteld naar dezelfde versie op een andere instantie. Terwijl het voor mysqldump cross-compatibel is met andere MySQL-hoofdversies en veel eenvoudiger voor gedeeltelijke back-up, hoewel het relatief langzamer is tijdens herstel in vergelijking met Percona Xtrabackup op grote databases. MySQL 5.7 introduceert ook mysqlpump, vergelijkbaar met mysqldump met parallelle verwerkingsmogelijkheden om het dumpproces te versnellen.
Mis het niet om al deze back-uptools in uw MySQL-server te configureren, aangezien ze vrij beschikbaar zijn en zeer essentieel zijn voor gegevensherstel. Aangezien mysqldump en mysqlpump al zijn opgenomen in MySQL 5.7 en later, hoeven we alleen Percona Xtrabackup (of MariaDB Backup voor MariaDB) te installeren, maar het vereist enige voorbereidingen, zoals weergegeven in de volgende stappen:
Stap één
Zorg ervoor dat de back-uptool en zijn afhankelijkheden zijn geïnstalleerd:
$ yum install -y epel-release
$ yum install -y socat pv percona-xtrabackupGebruik voor MariaDB-servers in plaats daarvan MariaDB Backup:
$ yum install -y socat pv MariaDB-BackupStap twee
Maak gebruiker 'xtrabackup' op master als deze niet bestaat:
mysql> CREATE USER 'xtrabackup'@'localhost' IDENTIFIED BY 'Km4z9^sT2X';
mysql> GRANT RELOAD, LOCK TABLES, PROCESS, REPLICATION CLIENT ON *.* TO 'xtrabackup'@'localhost';Stap drie
Maak een andere gebruiker met de naam 'mysqldump' op master als deze niet bestaat. Deze gebruiker wordt gebruikt voor 'mysqldump' en 'mysqlpump':
mysql> CREATE USER 'mysqldump'@'localhost' IDENTIFIED BY 'Km4z9^sT2X';
mysql> GRANT SELECT, SHOW VIEW, EVENT, TRIGGER, LOCK TABLES, RELOAD, REPLICATION CLIENT ON *.* TO 'mysqldump'@'localhost';Stap vier
Voeg de inloggegevens van de back-upgebruikers toe aan het MySQL-configuratiebestand onder de richtlijnen [xtrabackup], [mysqldump] en [mysqlpump]:
$ cat /etc/my.cnf
...
[xtrabackup]
user=xtrabackup
password='Km4z9^sT2X'
[mysqldump]
user=mysqldump
password='Km4z9^sT2X'
[mysqlpump]
user=mysqldump
password='Km4z9^sT2X'Door de bovenstaande regels op te geven, hoeven we geen gebruikersnaam en wachtwoord op te geven in de back-upopdracht, omdat de back-uptool deze configuratie-opties automatisch laadt vanuit het hoofdconfiguratiebestand.
Zorg ervoor dat de back-uptools vooraf goed zijn getest. Voor Xtrabackup die back-upstreaming via het netwerk ondersteunt, moet dit eerst worden getest om er zeker van te zijn dat de communicatieverbinding tussen de bron- en doelserver correct tot stand kan worden gebracht. Voer op de doelserver de volgende opdracht uit zodat socat naar poort 9999 luistert en klaar is om inkomende streaming te accepteren:
$ socat -u tcp-listen:9999,reuseaddr stdout 2>/tmp/netcat.log | xbstream -x -C /var/lib/mysqlMaak vervolgens een back-up op de bronserver en stream deze naar poort 9999 op de doelserver:
$ innobackupex --socket=/var/lib/mysql/mysql.sock --stream=xbstream /var/lib/mysql/ | socat - TCP4:192.168.0.202:9999Je zou een continue uitvoerstroom moeten krijgen na het uitvoeren van de back-upopdracht. Wacht tot je de regel 'Completed OK' ziet die een geslaagde back-up aangeeft.
Met pv kunnen we het bandbreedtegebruik afremmen of de voortgang zien als een proces dat er doorheen wordt geleid. Gewoonlijk zal het streamingproces het netwerk verzadigen als er geen beperking is ingeschakeld en dit kan problemen veroorzaken met andere servers om te communiceren met andere servers in hetzelfde segment. Met pv kunnen we het streamingproces vertragen voordat we het doorgeven aan de streamingtool zoals socat of netcat. Het volgende voorbeeld laat zien dat de back-upstreaming wordt beperkt tot ongeveer 80 MB/s voor zowel inkomende als uitgaande verbindingen:
$ innobackupex --slave-info --socket=/var/lib/mysql/mysql.sock --stream=xbstream /var/lib/mysql/ | pv -q -L 80m | socat - TCP4:192.168.0.202:9999Het streamen van een back-up wordt vaak gebruikt om een slave te stagen of om de back-up op afstand op een andere server op te slaan.
Voor mysqldump en mysqlpump kunnen we testen met de volgende commando's:
$ mysqldump --set-gtid-purged=OFF --all-databases
$ mysqlpump --set-gtid-purged=OFF --all-databasesZorg ervoor dat u niet-foutieve regels ziet verschijnen in de uitvoer.
Stresstest op de server
Het stresstesten van de databaseserver is belangrijk om de maximale capaciteit te begrijpen die we kunnen verwachten voor de specifieke server. Dit is handig wanneer u in een later stadium drempels of knelpunten nadert. U kunt veel benchmarking-tools gebruiken die op de markt beschikbaar zijn, zoals mysqlslap, DBT2 en sysbench.
In dit voorbeeld gebruiken we sysbench om de topprestaties van de server, het verzadigingsniveau en ook de temperatuur van de componenten te meten terwijl we draaien in een omgeving met een hoge database-werkbelasting. Dit geeft u een goed beeld van hoe goed de server is en anticipeert op de werklast die de server kan verwerken voor onze applicatie in productie.
Om sysbench te installeren en configureren, kunt u het compileren vanaf de broncode of het pakket installeren vanuit de Percona-repository:
$ yum install -y https://repo.percona.com/yum/percona-release-latest.noarch.rpm
$ yum install -y sysbenchMaak het databaseschema en de gebruiker op de MySQL-server:
mysql> CREATE DATABASE sbtest;
mysql> CREATE USER 'sbtest'@'localhost' IDENTIFIED BY 'sysbenchP4ss';
mysql> GRANT ALL PRIVILEGES ON sbtest.* TO [email protected]'localhost';Genereer de testgegevens:
$ sysbench \
/usr/share/sysbench/oltp_common.lua \
--db-driver=mysql \
--mysql-host=localhost \
--mysql-user=sbtest \
--mysql-password=sysbenchP4ss \
--tables=50 \
--table-size=100000 \
prepareVoer vervolgens de benchmark 1 uur (3600 seconden) uit:
$ sysbench \
/usr/share/sysbench/oltp_read_write.lua \
--report-interval=2 \
--threads=64 \
--max-requests=0 \
--db-driver=mysql \
--time=3600 \
--db-ps-mode=disable \
--mysql-host=localhost \
--mysql-user=sbtest \
--mysql-password=sysbenchP4ss \
--tables=50 \
--table-size=100000 \
runTerwijl de test loopt, gebruikt u iostat (beschikbaar in het sysstat-pakket) in een andere terminal om het schijfgebruik, de bandbreedte, IOPS en I/O te controleren, wacht:
$ yum install -y sysstat
$ iostat -x 60
avg-cpu: %user %nice %system %iowait %steal %idle
40.55 0.00 55.27 4.18 0.00 0.00
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0.19 6.18 1236.23 816.92 61283.83 14112.44 73.44 4.00 1.96 2.83 0.65 0.34 69.29Het bovenstaande resultaat wordt elke 60 seconden afgedrukt. Wacht tot de test is voltooid en neem het gemiddelde van r/s (lezen/seconde), w/s (schrijven/seconde), %iowait, %util, rkB/s en wkB/s (bandbreedte). Als u een relatief laag gebruik van schijf, CPU, RAM of netwerk ziet, moet u waarschijnlijk de waarde "--threads" verhogen naar een nog hoger aantal, zodat alle bronnen tot het uiterste worden benut.
Denk aan de volgende aspecten waaraan moet worden gemeten:
- Queries per Second =Sysbench-samenvatting zodra de test is voltooid onder SQL-statistieken -> Query's -> Per sec.
- Querylatentie =Sysbench-samenvatting zodra de test is voltooid onder Latentie (ms) -> 95e percentiel.
- Schijf-IOPS =gemiddelde van r/s + w/s
- Schijfgebruik =gemiddelde van %util
- Schijfbandbreedte R/W =Gemiddelde van rkB/s / Gemiddelde van wkB/s
- Disk IO wait =gemiddelde van %iowait
- Gemiddelde serverbelasting =Gemiddelde belasting zoals gerapporteerd door top commando.
- MySQL CPU-gebruik =gemiddeld CPU-gebruik zoals gerapporteerd door top commando.
Met ClusterControl kunt u de bovenstaande informatie eenvoudig observeren en verkrijgen via het paneel Nodes Overview, zoals weergegeven in de volgende schermafbeelding:
Bovendien kan de informatie die tijdens de stresstest is verzameld, worden gebruikt om MySQL af te stemmen en InnoDB-variabelen dienovereenkomstig zoals innodb_buffer_pool_size, innodb_io_capacity, innodb_io_capacity_max, innodb_write_io_threads, innodb_read_io_threads en ook max_connections.
Voor meer informatie over MySQL-prestatiebenchmark met sysbench, bekijk deze blogpost, Hoe de prestaties van MySQL en MariaDB te benchmarken met SysBench.
Gebruik een online tool voor het wijzigen van schema's
Schemaverandering is iets dat onvermijdelijk is in relationele databases. Naarmate de applicatie groeit en in de loop van de tijd veeleisender wordt, vereist het zeker enige structuurverandering in de database. Er zijn enkele DDL-bewerkingen die de tabel opnieuw opbouwen, waardoor andere DML-instructies worden geblokkeerd en dit kan van invloed zijn op de beschikbaarheid van uw database als u structurele wijzigingen aanbrengt in een enorme tabel. Om de lijst met blokkerende DDL-bewerkingen te zien, gaat u naar deze MySQL-documentatiepagina en zoekt u naar bewerkingen met "Permits Concurrent DML" =No.
Als u zich geen downtime op de productieservers kunt veroorloven bij het uitvoeren van schemawijzigingen, is het waarschijnlijk een goed idee om het online hulpprogramma voor schemawijziging in een vroeg stadium te configureren. In dit voorbeeld installeren en configureren we gh-ost, een online schemawijziging gebouwd door Github. Gh-ost gebruikt de binaire logstroom om tabelwijzigingen vast te leggen en past deze asynchroon toe op de spooktabel.
Volg de volgende stappen om gh-ost op een CentOS-box te installeren:
Stap één
Download de nieuwste gh-ost hier:
$ wget https://github.com/github/gh-ost/releases/download/v1.0.48/gh-ost-1.0.48-1.x86_64.rpmStap twee
Installeer het pakket:
$ yum localinstall gh-ost-1.0.48-1.x86_64.rpm Stap drie
Maak een databasegebruiker voor gh-ost als deze niet bestaat, en verleen deze met de juiste rechten:
mysql> CREATE USER 'gh-ost'@'{host}' IDENTIFIED BY 'ghostP455';
mysql> GRANT ALTER, CREATE, DELETE, DROP, INDEX, INSERT, LOCK TABLES, SELECT, TRIGGER, UPDATE ON {db_name}.* TO 'gh-ost'@'{host}';
mysql> GRANT SUPER, REPLICATION SLAVE ON *.* TO 'gh-ost'@'{host}';** Vervang de {host} en {db_name} door hun juiste waarden. Idealiter is de {host} een van de slave-hosts die de online schemawijziging zal uitvoeren. Raadpleeg de gh-ost-documentatie voor details.
Stap vier
Maak een gh-ost-configuratiebestand om de gebruikersnaam en het wachtwoord op te slaan onder /root/.gh-ost.cnf:
[client]
user=gh-ost
password=ghostP455Op dezelfde manier kunt u Percona Toolkit Online Schema Change (pt-osc) configureren op de databaseserver. Het idee is om ervoor te zorgen dat u met deze tool eerst voorbereid bent op de databaseserver die deze bewerking in de toekomst waarschijnlijk zal uitvoeren.
Gebruik de Percona Toolkit
Percona Toolkit is een verzameling geavanceerde open source opdrachtregelprogramma's, ontwikkeld door Percona, die zijn ontworpen om een verscheidenheid aan MySQL-, MongoDB- en PostgreSQL-server- en systeemtaken uit te voeren die te moeilijk of te complex zijn om handmatig uitvoeren. Deze tools zijn de ultieme redder geworden en worden door DBA's over de hele wereld gebruikt om technische problemen op MySQL- en MariaDB-servers aan te pakken of op te lossen.
Om Percona Toolkit te installeren, voert u gewoon de volgende opdracht uit:
$ yum install https://repo.percona.com/yum/percona-release-latest.noarch.rpm
$ yum install percona-toolkitEr zijn meer dan 30 tools beschikbaar in dit pakket. Sommige zijn specifiek ontworpen voor MongoDB en PostgreSQL. Enkele van de meest populaire tools voor MySQL-probleemoplossing en prestatie-afstemming zijn pt-stalk, pt-mysql-summary, pt-query-digest, pt-table-checksum, pt-table-sync en pt-archiver. Deze toolkit kan DBA's helpen bij het verifiëren van de MySQL-replicatie-integriteit door de consistentie van master- en replicagegevens te controleren, rijen efficiënt te archiveren, dubbele indexen te vinden, MySQL-query's uit logbestanden en tcpdump te analyseren en nog veel meer.
Het volgende voorbeeld toont een van de tools (pt-table-checksum)-uitvoer waar het de consistentiecontrole van online replicatie kan uitvoeren door checksum-query's op de master uit te voeren, wat verschillende resultaten oplevert op replica's die niet consistent zijn met de master:
$ pt-table-checksum --no-check-binlog-format --replicate-check-only
Checking if all tables can be checksummed ...
Starting checksum ...
Differences on mysql2.local
TABLE CHUNK CNT_DIFF CRC_DIFF CHUNK_INDEX LOWER_BOUNDARY UPPER_BOUNDARY
mysql.proc 1 0 1
mysql.tables_priv 1 0 1
mysql.user 1 1 1De bovenstaande uitvoer laat zien dat er 3 tabellen op de slave (mysql2.local) zijn die niet consistent zijn met de master. We kunnen dan de pt-table-sync tool gebruiken om de ontbrekende data van de master op te lossen, of gewoon de slave opnieuw synchroniseren.
Vergrendel de server
Eindelijk, nadat de configuratie- en voorbereidingsfase is voltooid, kunnen we het databaseknooppunt isoleren van het openbare netwerk en de servertoegang beperken tot bekende hosts en netwerken. U kunt firewall (iptables, firewalld, ufw), beveiligingsgroepen, hosts.allow en/of hosts.deny gebruiken of gewoon de netwerkinterface uitschakelen die naar internet is gericht als u meerdere netwerkinterfaces heeft.
Voor iptables is het belangrijk om voor elke regel een opmerking op te geven met de vlag '-m comment --comment':
$ iptables -A INPUT -p tcp -s 192.168.0.0/24 --dport 22 -m comment --comment 'Allow local net to SSH port' -j ACCEPT
$ iptables -A INPUT -p tcp -s 192.168.0.0/24 --dport 3306 -m comment --comment 'Allow local net to MySQL port' -j ACCEPT
$ iptables -A INPUT -p tcp -s 192.168.0.0/24 --dport 9999 -m comment --comment 'Allow local net to backup streaming port' -j ACCEPT
$ iptables -A INPUT -p tcp -s 0.0.0.0/0 -m comment --comment 'Drop everything apart from the above' -j DROPNet als voor Ubuntu's Firewall (ufw), moeten we eerst de standaardregel definiëren en dan kunnen we vergelijkbare regels maken voor MySQL/MariaDB, vergelijkbaar met deze:
$ sudo ufw default deny incoming comment 'Drop everything apart from the above'
$ sudo ufw default allow outgoing comment 'Allow outgoing everything'
$ sudo ufw allow from 192.168.0.0/24 to any port 22 comment 'Allow local net to SSH port'
$ sudo ufw allow from 192.168.0.0/24 to any port 3306 comment 'Allow local net to MySQL port'
$ sudo ufw allow from 192.168.0.0/24 to any port 9999 comment 'Allow local net to backup streaming port'Schakel de firewall in:
$ ufw enableControleer vervolgens of de regels correct zijn geladen:
$ ufw status verbose
Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)
New profiles: skip
To Action From
-- ------ ----
22 ALLOW IN 192.168.0.0/24 # Allow local net to SSH port
3306 ALLOW IN 192.168.0.0/24 # Allow local net to MySQL port
9999 ALLOW IN 192.168.0.0/24 # Allow local net to backup streaming portNogmaals, het is erg belangrijk om opmerkingen bij elke regel op te geven, zodat we de regel beter kunnen begrijpen.
Voor beperking van externe databasetoegang kunnen we ook een VPN-server gebruiken, zoals weergegeven in deze blogpost, OpenVPN gebruiken om toegang tot uw databasecluster in de cloud te beveiligen.
Conclusie
Het voorbereiden van een productieserver is natuurlijk geen gemakkelijke taak, wat we in deze blogserie hebben laten zien. Als u bang bent dat u het verprutst, waarom gebruikt u ClusterControl dan niet om uw databasecluster te implementeren? ClusterControl heeft een zeer goede staat van dienst op het gebied van database-implementatie en heeft tot nu toe meer dan 70.000 MySQL- en MariaDB-implementaties voor alle omgevingen mogelijk gemaakt.