Förbereda en MySQL- eller MariaDB-server för produktion - del två

I den tidigare bloggen har vi täckt några tips och tricks för att förbereda en MySQL-server för produktionsanvändning från ett systemadministratörsperspektiv. Det här blogginlägget är fortsättningen... 

Använd ett verktyg för databassäkerhetskopiering

Varje säkerhetskopieringsverktyg har sina egna fördelar och nackdelar. Till exempel kan Percona Xtrabackup (eller MariaDB Backup för MariaDB) utföra en fysisk hot-backup utan att låsa databaserna men den kan bara återställas till samma version på en annan instans. Medan för mysqldump är det korskompatibelt med andra MySQL-huvudversioner och mycket enklare för partiell säkerhetskopiering, även om det är relativt långsammare under återställning jämfört med Percona Xtrabackup på stora databaser. MySQL 5.7 introducerar också mysqlpump, liknande mysqldump med parallella bearbetningsmöjligheter för att påskynda dumpningsprocessen.

Missa inte att konfigurera alla dessa säkerhetskopieringsverktyg i din MySQL-server eftersom de är fritt tillgängliga och mycket viktiga för dataåterställning. Eftersom mysqldump och mysqlpump redan ingår i MySQL 5.7 och senare behöver vi bara installera Percona Xtrabackup (eller MariaDB Backup för MariaDB) men det kräver vissa förberedelser, som visas i följande steg:

Steg ett

Se till att säkerhetskopieringsverktyget och dess beroenden är installerade:

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

För MariaDB-servrar, använd MariaDB Backup istället:

$ yum install -y socat pv MariaDB-Backup

Steg två

Skapa användaren 'xtrabackup' på master om den inte finns:

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

Steg tre

Skapa en annan användare som heter 'mysqldump' på master om den inte finns. Denna användare kommer att användas för 'mysqldump' och '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';

Steg fyra

Lägg till säkerhetskopieringsanvändarnas autentiseringsuppgifter i MySQL-konfigurationsfilen under direktiven [xtrabackup], [mysqldump] och [mysqlpump]:

$ cat /etc/my.cnf

...

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

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

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

Genom att ange ovanstående rader behöver vi inte ange användarnamn och lösenord i backupkommandot eftersom säkerhetskopieringsverktyget automatiskt laddar dessa konfigurationsalternativ från huvudkonfigurationsfilen.

Se till att säkerhetskopieringsverktygen är ordentligt testade i förväg. För Xtrabackup som stöder backup-streaming via nätverk måste detta testas först för att säkerställa att kommunikationslänken kan upprättas korrekt mellan käll- och destinationsservern. På destinationsservern, kör följande kommando för att socat ska lyssna på port 9999 och redo att acceptera inkommande streaming:

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

Skapa sedan en säkerhetskopia på källservern och streama den till port 9999 på målservern:

$ 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 av utdata efter att ha utfört backupkommandot. Vänta tills du ser raden 'Completed OK' som indikerar en lyckad säkerhetskopiering.

Med pv kan vi strypa bandbreddsanvändningen eller se framstegen som en process som leds igenom den. Vanligtvis kommer streamingprocessen att mätta nätverket om ingen strypning är aktiverad och detta kan orsaka problem med andra servrar att interagera med en annan i samma segment. Med pv kan vi strypa streamingprocessen innan vi skickar den till streamingverktyget som socat eller netcat. Följande exempel visar att backupströmningen kommer att strypas runt 80 MB/s för både inkommande och utgående anslutningar:

$ 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

Strömning av en säkerhetskopia används vanligtvis för att iscensätta en slav eller lagra säkerhetskopian på distans på en annan server.

För mysqldump och mysqlpump kan vi testa med följande kommandon:

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

Se till att du ser icke-felrader visas i utdata.

Stresstesta servern

Stresstestning av databasservern är viktigt för att förstå den maximala kapacitet som vi kan förutse för den specifika servern. Detta kommer att bli användbart när du närmar dig trösklar eller flaskhalsar i ett senare skede. Du kan använda många benchmarkingverktyg som finns på marknaden som mysqlslap, DBT2 och sysbench.

I det här exemplet använder vi sysbench för att mäta serverns toppprestanda, mättnadsnivå och även komponenternas temperatur medan de körs i en miljö med hög databasarbetsbelastning. Detta kommer att ge dig en grundförståelse om hur bra servern är och förutse den arbetsbelastning som servern kan bearbeta för vår applikation i produktion.

För att installera och konfigurera sysbench kan du kompilera det från källan eller installera paketet från Percona-förrådet:

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

Skapa databasschemat och användaren på MySQL-servern:

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

Generera testdata:

$ 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 sedan riktmärket i 1 timme (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

Medan testet körs, använd iostat (tillgängligt i sysstat-paketet) i en annan terminal för att övervaka diskanvändning, bandbredd, IOPS och I/O-vänta:

$ 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

Ovanstående resultat kommer att skrivas ut var 60:e sekund. Vänta tills testet är klart och ta medelvärdet av r/s (läser/sekund), w/s (skriver/sekund), %iowait, %util, rkB/s och wkB/s (bandbredd). Om du ser ett relativt lågt utnyttjande av disk, CPU, RAM eller nätverk måste du antagligen öka värdet "--trådar" till ett ännu högre antal så att det kommer att använda alla resurser till det yttersta.

Tänk på att följande aspekter ska mätas:

• Frågor per sekund =Sysbench-sammanfattning när testet är klart under SQL-statistik -> Frågor -> Per sek.
• Frågefördröjning =Sysbench-sammanfattning när testet har slutförts under Latens (ms) -> 95:e percentilen.
• Disk IOPS =Genomsnitt av r/s + w/s
• Diskanvändning =Genomsnitt av %util
• Diskbandbredd R/W =Genomsnitt av rkB/s / Genomsnitt av wkB/s
• Disk IO wait =Genomsnitt av %iowait
• Genomsnittlig serverbelastning =Genomsnittligt belastningsmedel som rapporterats av toppkommandot.
• MySQL CPU-användning =Genomsnittlig CPU-användning som rapporterats av toppkommandot.

Med ClusterControl kan du enkelt observera och få ovanstående information via panelen Nodes Overview, som visas i följande skärmdump:

Dessutom kan informationen som samlades in under stresstestet användas för att ställa in MySQL och InnoDB-variabler i enlighet därmed som innodb_buffer_pool_size, innodb_io_capacity, innodb_io_capacity_max, innodb_write_io_threads, innodb_read_io_threads och även max_connections.

För att lära dig mer om MySQL prestandabenchmark med sysbench, kolla in det här blogginlägget, How to Benchmark Performance of MySQL &MariaDB Using SysBench.

Använd ett onlineverktyg för schemaändring

Schemaändring är något som är oundvikligt i relationsdatabaser. När applikationen växer och blir mer krävande med tiden, kräver den verkligen en strukturändring av databasen. Det finns vissa DDL-operationer som kommer att bygga om tabellen och blockera andra DML-satser att köra och detta kan påverka din databastillgänglighet om du utför strukturella förändringar på en stor tabell. För att se listan över blockerande DDL-operationer, kolla in den här MySQL-dokumentationssidan och leta efter operationer som har "Permits Concurrent DML" =No.

Om du inte har råd med driftstopp på produktionsservrarna när du utför schemaändringar är det förmodligen en bra idé att konfigurera onlineschemaändringsverktyget i ett tidigt skede. I det här exemplet installerar och konfigurerar vi gh-ost, en online-schemaändring byggd av Github. Gh-ost använder den binära loggströmmen för att fånga tabelländringar och applicerar dem asynkront på spöktabellen.

För att installera gh-ost på en CentOS-box, följ helt enkelt följande steg: 

Steg ett

 Ladda ned senaste gh-ost härifrån: 

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

Steg två

Installera paketet:

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

Steg tre

Skapa en databasanvändare för gh-ost om den inte finns, och ge den med rätt behörighet:

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

** Ersätt {host} och {db_name} med deras lämpliga värden. Helst är {host} en av slavvärdarna som kommer att utföra onlineschemaändringen. Se gh-ost-dokumentationen för detaljer.

Steg fyra

Skapa gh-ost-konfigurationsfil för att lagra användarnamn och lösenord under /root/.gh-ost.cnf:

[client]
user=gh-ost
password=ghostP455

På samma sätt kan du ha Percona Toolkit Online Schema Change (pt-osc) konfigurerat på databasservern. Tanken är att se till att du är förberedd med det här verktyget först på databasservern som sannolikt kommer att köra den här operationen i framtiden.

Använd Percona Toolkit

Percona Toolkit är en samling avancerade kommandoradsverktyg med öppen källkod, utvecklade av Percona, som är konstruerade för att utföra en mängd olika MySQL-, MongoDB- och PostgreSQL-server- och systemuppgifter som är för svåra eller komplexa för att utföra manuellt. Dessa verktyg har blivit den ultimata räddaren, som används av DBA:er runt om i världen för att lösa eller lösa tekniska problem som finns i MySQL- och MariaDB-servrar.

För att installera Percona Toolkit, kör helt enkelt följande kommando:

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

Det finns över 30 verktyg tillgängliga i detta paket. Några av dem är speciellt designade för MongoDB och PostgreSQL. Några av de mest populära verktygen för MySQL-felsökning och prestandajustering är pt-stalk, pt-mysql-summary, pt-query-digest, pt-table-checksum, pt-table-sync och pt-archiver. Denna verktygslåda kan hjälpa DBA:er att verifiera MySQL-replikeringsintegritet genom att kontrollera huvud- och replikdatakonsistens, effektivt arkivera rader, hitta dubbletter av index, analysera MySQL-frågor från loggar och tcpdump och mycket mer.

Följande exempel visar ett av verktygen (pt-table-checksum) utdata där det kan utföra online-replikeringskonsistenskontroll genom att köra kontrollsummafrågor på mastern, vilket ger olika resultat på repliker som är inkonsekventa med mastern:

$ 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

Ovanstående utdata visar att det finns 3 tabeller på slaven (mysql2.local) som är inkonsekventa med mastern. Vi kan sedan använda verktyget pt-table-sync för att korrigera de saknade data från mastern, eller helt enkelt synkronisera om slaven en gång till.

Lås ner servern

Slutligen, efter att konfigurations- och förberedelsestadiet är klart, kan vi isolera databasnoden från det offentliga nätverket och begränsa serveråtkomsten till kända värdar och nätverk. Du kan använda brandvägg (iptables, brandvägg, ufw), säkerhetsgrupper, hosts.allow och/eller hosts.deny eller helt enkelt inaktivera nätverksgränssnittet som är vänt mot internet om du har flera nätverksgränssnitt.

För iptables är det viktigt att ange en kommentar för varje regel med flaggan '-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å liknande sätt för Ubuntus brandvägg (ufw), måste vi först definiera standardregeln och sedan kan skapa liknande regler för MySQL/MariaDB som liknar denna:

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

Aktivera brandväggen:

$ ufw enable

Kontrollera sedan att reglerna är korrekt inlästa:

$ 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

Återigen, det är mycket viktigt att ange kommentarer på varje regel för att hjälpa oss att förstå regeln bättre.

För begränsning av åtkomst till fjärrdatabas kan vi också använda VPN-server som visas i detta blogginlägg, Använda OpenVPN för att säkra åtkomst till ditt databaskluster i molnet.

Slutsats

Att förbereda en produktionsserver är uppenbarligen ingen lätt uppgift, vilket vi har visat i den här bloggserien. Om du är orolig för att du skulle skruva upp, varför använder du inte ClusterControl för att distribuera ditt databaskluster? ClusterControl har en mycket bra meritlista inom databasdistribution och har möjliggjort mer än 70 000 MySQL- och MariaDB-distributioner för alla miljöer hittills.