Forberedelse af en MySQL- eller MariaDB-server til produktion - Anden del

I den forrige blog har vi dækket nogle tips og tricks til at forberede en MySQL-server til produktionsbrug fra et systemadministratorperspektiv. Dette blogindlæg er fortsættelsen... 

Brug et værktøj til databasesikkerhedskopiering

Hvert backupværktøj har sine egne fordele og ulemper. For eksempel kan Percona Xtrabackup (eller MariaDB Backup for MariaDB) udføre en fysisk hot-backup uden at låse databaserne, men den kan kun gendannes til den samme version på en anden instans. Mens det for mysqldump er krydskompatibelt med andre MySQL større versioner og meget enklere til delvis backup, selvom det er relativt langsommere under gendannelse sammenlignet med Percona Xtrabackup på store databaser. MySQL 5.7 introducerer også mysqlpump, der ligner mysqldump med parallelle behandlingsmuligheder for at fremskynde dump-processen.

Gå ikke glip af at konfigurere alle disse sikkerhedskopieringsværktøjer på din MySQL-server, da de er frit tilgængelige og meget kritiske for datagendannelse. Da mysqldump og mysqlpump allerede er inkluderet i MySQL 5.7 og senere, skal vi blot installere Percona Xtrabackup (eller MariaDB Backup for MariaDB), men det kræver nogle forberedelser, som vist i følgende trin:

Trin 1

Sørg for, at sikkerhedskopieringsværktøjet og dets afhængigheder er installeret:

$ yum install -y epel-release
$ yum install -y socat pv percona-xtrabackup

For MariaDB-servere, brug MariaDB Backup i stedet:

$ yum install -y socat pv MariaDB-Backup

Trin to

Opret bruger 'xtrabackup' på master, hvis den ikke findes:

mysql> CREATE USER 'xtrabackup'@'localhost' IDENTIFIED BY 'Km4z9^sT2X';
mysql> GRANT RELOAD, LOCK TABLES, PROCESS, REPLICATION CLIENT ON *.* TO 'xtrabackup'@'localhost';

Trin tre

Opret en anden bruger kaldet 'mysqldump' på master, hvis den ikke eksisterer. Denne bruger vil blive brugt til 'mysqldump' og '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';

Trin fire

Tilføj sikkerhedskopieringsbrugernes legitimationsoplysninger i MySQL-konfigurationsfilen under [xtrabackup], [mysqldump] og [mysqlpump]-direktivet:

$ cat /etc/my.cnf

...

[xtrabackup]
user=xtrabackup
password='Km4z9^sT2X'

[mysqldump]
user=mysqldump
password='Km4z9^sT2X'

[mysqlpump]
user=mysqldump
password='Km4z9^sT2X'

Ved at specificere ovenstående linjer behøver vi ikke at angive brugernavn og adgangskode i backup-kommandoen, da backup-værktøjet automatisk indlæser disse konfigurationsmuligheder fra hovedkonfigurationsfilen.

Sørg for, at sikkerhedskopieringsværktøjerne er korrekt testet på forhånd. For Xtrabackup, som understøtter backup-streaming via netværk, skal dette først testes for at sikre, at kommunikationsforbindelsen kan etableres korrekt mellem kilde- og destinationsserveren. På destinationsserveren skal du køre følgende kommando for at socat lytter til port 9999 og er klar til at acceptere indgående streaming:

$ socat -u tcp-listen:9999,reuseaddr stdout 2>/tmp/netcat.log | xbstream -x -C /var/lib/mysql

Opret derefter en sikkerhedskopi på kildeserveren og stream den til port 9999 på destinationsserveren:

$ innobackupex --socket=/var/lib/mysql/mysql.sock --stream=xbstream /var/lib/mysql/ | socat - TCP4:192.168.0.202:9999

Du bør få en kontinuerlig strøm af output efter at have udført backup-kommandoen. Vent, indtil du ser linjen 'Completed OK', der indikerer en vellykket sikkerhedskopiering.

Med pv kan vi begrænse båndbreddeforbruget eller se fremskridtet som en proces, der føres igennem det. Normalt vil streamingprocessen mætte netværket, hvis ingen throttleting er aktiveret, og dette kan forårsage problemer med andre servere til at interagere med en anden i samme segment. Ved at bruge pv kan vi drosle streamingprocessen, før vi sender den til streamingværktøjet som socat eller netcat. Følgende eksempel viser, at backup-streaming vil blive droslet omkring 80 MB/s for både indgående og udgående forbindelser:

$ innobackupex --slave-info --socket=/var/lib/mysql/mysql.sock --stream=xbstream /var/lib/mysql/ | pv -q -L 80m | socat - TCP4:192.168.0.202:9999

Streaming af en sikkerhedskopi bruges almindeligvis til at iscenesætte en slave eller gemme sikkerhedskopien eksternt på en anden server.

For mysqldump og mysqlpump kan vi teste med følgende kommandoer:

$ mysqldump --set-gtid-purged=OFF --all-databases
$ mysqlpump --set-gtid-purged=OFF --all-databases

Sørg for, at du ser ikke-fejl-linjer vises i outputtet.

Stresstest serveren

Stresstest af databaseserveren er vigtig for at forstå den maksimale kapacitet, som vi kan forudse for den pågældende server. Dette vil blive nyttigt, når du nærmer dig tærskler eller flaskehalse på et senere tidspunkt. Du kan bruge mange benchmarkingværktøjer, der er tilgængelige på markedet, såsom mysqlslap, DBT2 og sysbench.

I dette eksempel bruger vi sysbench til at måle serverens højeste ydeevne, mætningsniveau og også komponenternes temperatur, mens de kører i et miljø med høj databasearbejdsbelastning. Dette vil give dig en grundlæggende forståelse af, hvor god serveren er, og forudse den arbejdsbyrde, som serveren kan behandle for vores applikation i produktion.

For at installere og konfigurere sysbench kan du kompilere det fra kilden eller installere pakken fra Percona-lageret:

$ yum install -y https://repo.percona.com/yum/percona-release-latest.noarch.rpm
$ yum install -y sysbench

Opret databaseskemaet og brugeren på MySQL-serveren:

mysql> CREATE DATABASE sbtest;
mysql> CREATE USER 'sbtest'@'localhost' IDENTIFIED BY 'sysbenchP4ss';
mysql> GRANT ALL PRIVILEGES ON sbtest.* TO [email protected]'localhost';

Generer testdataene:

$ sysbench \
/usr/share/sysbench/oltp_common.lua \
--db-driver=mysql \
--mysql-host=localhost \
--mysql-user=sbtest \
--mysql-password=sysbenchP4ss \
--tables=50 \
--table-size=100000 \
prepare

Kør derefter benchmark i 1 time (3600 sekunder):

$ 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 \
run

Mens testen kører, skal du bruge iostat (tilgængelig i sysstat-pakken) i en anden terminal til at overvåge diskudnyttelsen, båndbredden, IOPS og I/O-vent:

$ 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.29

Ovenstående resultat vil blive udskrevet hvert 60. sekund. Vent, indtil testen er færdig, og tag gennemsnittet af r/s (læser/sekund), w/s (skriver/sekund), %iowait, %util, rkB/s og wkB/s (båndbredde). Hvis du ser en relativt lav udnyttelse af disk, CPU, RAM eller netværk, skal du sandsynligvis øge "--tråde"-værdien til et endnu højere tal, så det vil udnytte alle ressourcerne til det yderste.

Overvej følgende aspekter, der skal måles på:

• Forespørgsler pr. sekund =Sysbench-oversigt, når testen er fuldført under SQL-statistik -> Forespørgsler -> Per sek.
• Forespørgselsforsinkelse =Sysbench-oversigt, når testen er fuldført under forsinkelse (ms) -> 95. percentil.
• Disk IOPS =Gennemsnit af r/s + w/s
• Diskudnyttelse =Gennemsnit af %util
• Diskbåndbredde R/W =Gennemsnit af rkB/s / Gennemsnit af wkB/s
• Disk IO wait =Gennemsnit af %iowait
• Gennemsnitlig serverbelastning =Gennemsnitlig belastningsgennemsnit som rapporteret af topkommando.
• MySQL CPU-brug =Gennemsnitlig CPU-udnyttelse som rapporteret af topkommando.

Med ClusterControl kan du nemt observere og få ovenstående information via panelet Nodes Overview, som vist på følgende skærmbillede:

Desuden kan informationen indsamlet under stresstesten bruges til at tune MySQL og InnoDB-variabler tilsvarende som innodb_buffer_pool_size, innodb_io_capacity, innodb_io_capacity_max, innodb_write_io_threads, innodb_read_io_threads og også max_connections.

For at lære mere om MySQL-ydeevnebenchmark ved hjælp af sysbench, tjek dette blogindlæg, Sådan benchmarker du ydelse af MySQL &MariaDB ved hjælp af SysBench.

Brug et onlineskemaændringsværktøj

Skemaændring er noget, der er uundgåeligt i relationelle databaser. Efterhånden som applikationen vokser og bliver mere krævende over tid, kræver det bestemt en strukturændring af databasen. Der er nogle DDL-operationer, der vil genopbygge tabellen og dermed blokere andre DML-sætninger til at køre, og dette kan påvirke din databases tilgængelighed, hvis du udfører strukturelle ændringer på en enorm tabel. For at se listen over blokerende DDL-operationer, tjek denne MySQL-dokumentationsside og se efter operationer, der har "Permits Concurrent DML" =No.

Hvis du ikke har råd til nedetid på produktionsserverne, når du udfører skemaændring, er det sandsynligvis en god idé at konfigurere online skemaændringsværktøjet på et tidligt tidspunkt. I dette eksempel installerer og konfigurerer vi gh-ost, en online skemaændring bygget af Github. Gh-ost bruger den binære logstrøm til at fange tabelændringer og anvender dem asynkront på spøgelsestabellen.

For at installere gh-ost på en CentOS-boks skal du blot følge følgende trin: 

Trin et

 Download seneste gh-ost herfra: 

$ wget https://github.com/github/gh-ost/releases/download/v1.0.48/gh-ost-1.0.48-1.x86_64.rpm

Trin to

Installer pakken:

$ yum localinstall gh-ost-1.0.48-1.x86_64.rpm 

Trin tre

Opret en databasebruger til gh-ost, hvis den ikke findes, og giv den med de rette rettigheder:

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}';

** Erstat {host} og {db_name} med deres passende værdier. Ideelt set er {host} en af ​​slaveværterne, der vil udføre online-skemaændringen. Se gh-ost-dokumentationen for detaljer.

Trin fire

Opret gh-ost-konfigurationsfil for at gemme brugernavnet og adgangskoden under /root/.gh-ost.cnf:

[client]
user=gh-ost
password=ghostP455

På samme måde kan du få Percona Toolkit Online Schema Change (pt-osc) konfigureret på databaseserveren. Ideen er at sikre dig, at du er forberedt med dette værktøj først på databaseserveren, som sandsynligvis vil køre denne operation i fremtiden.

Brug Percona Toolkit

Percona Toolkit er en samling af avancerede open source-kommandolinjeværktøjer, udviklet af Percona, der er udviklet til at udføre en række MySQL-, MongoDB- og PostgreSQL-server- og systemopgaver, der er for vanskelige eller komplekse til at udføres manuelt. Disse værktøjer er blevet den ultimative redningsmand, brugt af DBA'er over hele verden til at løse eller løse tekniske problemer fundet i MySQL- og MariaDB-servere.

For at installere Percona Toolkit skal du blot køre følgende kommando:

$ yum install https://repo.percona.com/yum/percona-release-latest.noarch.rpm
$ yum install percona-toolkit

Der er over 30 værktøjer tilgængelige i denne pakke. Nogle af dem er specielt designet til MongoDB og PostgreSQL. Nogle af de mest populære værktøjer til MySQL-fejlfinding og ydelsesjustering er pt-stalk, pt-mysql-summary, pt-query-digest, pt-table-checksum, pt-table-sync og pt-archiver. Dette værktøjssæt kan hjælpe DBA'er med at verificere MySQL-replikeringsintegritet ved at kontrollere master- og replikadatakonsistens, effektivt arkivere rækker, finde duplikerede indekser, analysere MySQL-forespørgsler fra logfiler og tcpdump og meget mere.

Følgende eksempel viser et af værktøjerne (pt-table-checksum) output, hvor det kan udføre online replikeringskonsistenstjek ved at udføre checksum-forespørgsler på masteren, hvilket giver forskellige resultater på replikaer, der er inkonsistente med masteren:

$ 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 1

Ovenstående output viser, at der er 3 tabeller på slaven (mysql2.local), som ikke er i overensstemmelse med masteren. Vi kan derefter bruge pt-table-sync-værktøjet til at lappe de manglende data fra masteren eller blot gensynkronisere slaven igen.

Lås serveren

Til sidst, efter at konfigurations- og forberedelsesstadiet er afsluttet, kan vi isolere databasenoden fra det offentlige netværk og begrænse serveradgangen til kendte værter og netværk. Du kan bruge firewall (iptables, firewalld, ufw), sikkerhedsgrupper, hosts.allow og/eller hosts.deny eller blot deaktivere netværksgrænsefladen, der vender mod internettet, hvis du har flere netværksgrænseflader.

For iptables er det vigtigt at angive en kommentar for hver regel ved at bruge flaget '-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 DROP

På samme måde for Ubuntu's Firewall (ufw), skal vi først definere standardreglen og derefter kan oprette en lignende regler for MySQL/MariaDB, der ligner denne:

$ 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'

Aktiver firewallen:

$ ufw enable

Bekræft derefter, at reglerne er indlæst korrekt:

$ 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 port

Igen, det er meget vigtigt at angive kommentarer til hver regel for at hjælpe os med at forstå reglen bedre.

Til begrænsning af ekstern databaseadgang kan vi også bruge VPN-server som vist i dette blogindlæg, Brug af OpenVPN til at sikre adgang til din databaseklynge i skyen.

Konklusion

At forberede en produktionsserver er naturligvis ikke en nem opgave, som vi har vist i denne blogserie. Hvis du er bekymret for, at du ville skrue op, hvorfor bruger du så ikke ClusterControl til at implementere din databaseklynge? ClusterControl har en meget god track record i databaseimplementering og har aktiveret mere end 70.000 MySQL- og MariaDB-implementeringer til alle miljøer til dato.