Подготовка на MySQL или MariaDB сървър за производство - част втора

В предишния блог разгледахме някои съвети и трикове за подготовка на MySQL сървър за производствена употреба от гледна точка на системния администратор. Тази публикация в блога е продължението... 

Използвайте инструмент за архивиране на база данни

Всеки инструмент за архивиране има своите предимства и недостатъци. Например, Percona Xtrabackup (или MariaDB Backup за MariaDB) може да извърши физическо горещо архивиране без да заключва базите данни, но може да бъде възстановено до същата версия само на друг екземпляр. Докато за mysqldump, той е кръстосано съвместим с други основни версии на MySQL и много по-опростен за частично архивиране, въпреки че е сравнително по-бавен по време на възстановяване в сравнение с Percona Xtrabackup на големи бази данни. MySQL 5.7 също така въвежда mysqlpump, подобен на mysqldump с възможности за паралелна обработка за ускоряване на процеса на изхвърляне.

Не пропускайте да конфигурирате всички тези инструменти за архивиране във вашия MySQL сървър, тъй като те са свободно достъпни и много критични за възстановяване на данни. Тъй като mysqldump и mysqlpump вече са включени в MySQL 5.7 и по-нови, ние просто трябва да инсталираме Percona Xtrabackup (или MariaDB Backup за MariaDB), но това изисква известна подготовка, както е показано в следните стъпки:

Първа стъпка

Уверете се, че инструментът за архивиране и неговите зависимости са инсталирани:

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

За сървъри на MariaDB използвайте MariaDB Backup вместо това:

$ yum install -y socat pv MariaDB-Backup

Втора стъпка

Създайте потребител 'xtrabackup' на master, ако не съществува:

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

Трета стъпка

Създайте друг потребител, наречен 'mysqldump' на master, ако не съществува. Този потребител ще бъде използван за 'mysqldump' и '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';

Четвърта стъпка

Добавете идентификационните данни на резервните потребители в конфигурационния файл на MySQL под директивата [xtrabackup], [mysqldump] и [mysqlpump]:

$ cat /etc/my.cnf

...

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

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

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

Като посочим горните редове, не е необходимо да указваме потребителско име и парола в командата за архивиране, тъй като инструментът за архивиране автоматично ще зареди тези опции за конфигурация от основния конфигурационен файл.

Уверете се, че инструментите за архивиране са правилно тествани предварително. За Xtrabackup, който поддържа стрийминг на архивиране през мрежа, това трябва да се тества първо, за да се уверите, че комуникационната връзка може да бъде установена правилно между изходния и целевия сървър. На целевия сървър изпълнете следната команда за socat, за да прослуша порт 9999 и да сте готови да приемете входящ стрийминг:

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

След това създайте резервно копие на изходния сървър и го предавайте поточно към порт 9999 на целевия сървър:

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

Трябва да получите непрекъснат поток от продукция след изпълнение на командата за архивиране. Изчакайте, докато видите реда „Completed OK“, показващ успешно архивиране.

С pv можем да ограничим използването на честотната лента или да видим напредъка като процес, който се предава през него. Обикновено процесът на поточно предаване ще насити мрежата, ако не е активирано дроселиране и това може да доведе до проблеми с други сървъри да взаимодействат с друг в същия сегмент. Използвайки pv, можем да ограничим процеса на поточно предаване, преди да го предадем на инструмента за стрийминг като socat или netcat. Следният пример показва, че резервното поточно предаване ще бъде ограничено около 80 MB/s както за входящи, така и за изходящи връзки:

$ 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

Поточното архивиране обикновено се използва за създаване на подчинен или съхраняване на архива от разстояние на друг сървър.

За mysqldump и mysqlpump можем да тестваме със следните команди:

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

Уверете се, че виждате редове без грешка в изхода.

Стрес тест на сървъра

Стрес тестването на сървъра на базата данни е важно, за да разберем максималния капацитет, който можем да предвидим за конкретния сървър. Това ще стане полезно, когато на по-късен етап наближавате прагове или тесни места. Можете да използвате много инструменти за сравнителен анализ, налични на пазара, като mysqlslap, DBT2 и sysbench.

В този пример използваме sysbench за измерване на пиковата производителност на сървъра, нивото на насищане, както и температурата на компонентите, докато работим в среда с високо натоварване на базата данни. Това ще ви даде обща представа за това колко добър е сървърът и ще предвидите работното натоварване, което сървърът може да обработи за нашето приложение в производството.

За да инсталирате и конфигурирате sysbench, можете да го компилирате от източника или да инсталирате пакета от хранилището на Percona:

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

Създайте схемата на базата данни и потребителя на MySQL сървъра:

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

Генерирайте тестовите данни:

$ 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

След това стартирайте бенчмарка за 1 час (3600 секунди):

$ 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

Докато тестът се изпълнява, използвайте iostat (наличен в пакета sysstat) в друг терминал, за да наблюдавате използването на диска, честотната лента, IOPS и I/O изчакване:

$ 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

Горният резултат ще се отпечатва на всеки 60 секунди. Изчакайте, докато тестът завърши и вземете средната стойност от r/s (четене/секунда), w/s (запис/секунда), %iowait, %util, rkB/s и wkB/s (пропускателна способност). Ако виждате сравнително ниско използване на диск, процесор, RAM или мрежа, вероятно трябва да увеличите стойността на „--threads“ до още по-голямо число, така че да използва всички ресурси до краен предел.

Помислете за следните аспекти, които трябва да бъдат измерени:

• Запитвания в секунда =обобщение на Sysbench след завършване на теста под SQL статистика -> Заявки -> В секунда.
• Закъснение на заявката =Резюме на Sysbench след завършване на теста под Закъснение (ms) -> 95-ти персентил.
• IOPS на диска =Средна стойност на r/s + w/s
• Използване на диска =Средно от %util
• Пропускателна способност на диска R/W =Средно rkB/s / Средно wkB/s
• Диск IO чакане =Средно на %iowait
• Средно натоварване на сървъра =Средно натоварване, отчетено от команда top.
• Използване на MySQL CPU =Средно използване на CPU, както се отчита от командата top.

С ClusterControl можете лесно да наблюдавате и получавате горната информация чрез панела за преглед на възлите, както е показано на следната екранна снимка:

Освен това информацията, събрана по време на стрес теста, може да се използва за настройка на MySQL и съответно променливи InnoDB като innodb_buffer_pool_size, innodb_io_capacity, innodb_io_capacity_max, innodb_write_io_threads, innodb_read_io_threads и също max_connections.

За да научите повече за сравнителния анализ на производителността на MySQL с помощта на sysbench, вижте тази публикация в блога Как да сравните производителността на MySQL и MariaDB с помощта на SysBench.

Използвайте онлайн инструмент за промяна на схема

Промяната на схемата е нещо, което е неизбежно в релационните бази данни. Тъй като приложението се разраства и става по-взискателно с течение на времето, то със сигурност изисква известна промяна в структурата на базата данни. Има някои DDL операции, които ще изградят отново таблицата, като по този начин блокират изпълнението на други DML изрази и това може да повлияе на наличността на вашата база данни, ако извършвате структурни промени в огромна таблица. За да видите списъка с блокиращи DDL операции, разгледайте тази страница с документация на MySQL и потърсете операции, които имат „Разрешаване на едновременно DML“ =Не.

Ако не можете да си позволите престой на производствените сървъри, когато извършвате промяна на схемата, вероятно е добра идея да конфигурирате онлайн инструмента за промяна на схеми на ранен етап. В този пример ние инсталираме и конфигурираме gh-ost, онлайн промяна на схемата, създадена от Github. Gh-ost използва двоичния дневник за улавяне на промените в таблицата и асинхронно ги прилага към таблицата ghost.

За да инсталирате gh-ost на кутия CentOS, просто изпълнете следните стъпки: 

Първа стъпка

 Изтеглете най-новия gh-ost от тук: 

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

Втора стъпка

Инсталирайте пакета:

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

Трета стъпка

Създайте потребител на база данни за gh-ost, ако не съществува, и го предоставете с подходящи привилегии:

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

** Заменете {host} и {db_name} с техните подходящи стойности. В идеалния случай {host} е един от подчинените хостове, който ще извърши промяната на онлайн схемата. Вижте документацията на ghost за подробности.

Четвърта стъпка

Създайте конфигурационен файл gh-ost, за да съхранявате потребителското име и паролата под /root/.gh-ost.cnf:

[client]
user=gh-ost
password=ghostP455

По подобен начин можете да конфигурирате Percona Toolkit Online Schema Change (pt-osc) на сървъра на базата данни. Идеята е да се уверите, че сте подготвени с този инструмент първо на сървъра на база данни, който вероятно ще изпълнява тази операция в бъдеще.

Използвайте Percona Toolkit

Percona Toolkit е колекция от усъвършенствани инструменти за команден ред с отворен код, разработени от Percona, които са проектирани да изпълняват различни MySQL, MongoDB и PostgreSQL сървърни и системни задачи, които са твърде трудни или сложни за изпълнява ръчно. Тези инструменти се превърнаха в най-добрия спасител, използван от DBA по целия свят за справяне или решаване на технически проблеми, открити в MySQL и MariaDB сървъри.

За да инсталирате Percona Toolkit, просто изпълнете следната команда:

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

В този пакет има над 30 налични инструмента. Някои от тях са специално проектирани за MongoDB и PostgreSQL. Някои от най-популярните инструменти за отстраняване на неизправности и настройка на производителността на MySQL са pt-stalk, pt-mysql-summary, pt-query-digest, pt-table-checksum, pt-table-sync и pt-archiver. Този инструментариум може да помогне на администраторите на база данни да проверят целостта на репликацията на MySQL чрез проверка на последователността на главните и репликационните данни, ефективно архивиране на редове, намиране на дублиращи се индекси, анализиране на MySQL заявки от регистрационни файлове и tcpdump и много други.

Следният пример показва изход на един от инструментите (pt-table-checksum), където може да извърши проверка на последователността на онлайн репликация чрез изпълнение на заявки за контролна сума на главния, което дава различни резултати за реплики, които са несъвместими с главния:

$ 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

Гореният изход показва, че има 3 таблици на подчинения (mysql2.local), които са несъвместими с главния. След това можем да използваме инструмента за синхронизиране на pt-table, за да коригираме липсващите данни от главния или просто да синхронизираме отново подчинения.

Заключете сървъра

Накрая, след като етапът на конфигуриране и подготовка приключи, можем да изолираме възела на базата данни от публичната мрежа и да ограничим достъпа на сървъра до известни хостове и мрежи. Можете да използвате защитна стена (iptables, firewalld, ufw), групи за сигурност, hosts.allow и/или hosts.deny или просто да деактивирате мрежовия интерфейс, който е обърнат към интернет, ако имате няколко мрежови интерфейса.

За iptables е важно да посочите коментар за всяко правило с помощта на флага '-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

По същия начин за защитната стена на Ubuntu (ufw), първо трябва да дефинираме правилото по подразбиране и след това можем да създадем подобни правила за MySQL/MariaDB, подобни на това:

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

Активиране на защитната стена:

$ ufw enable

След това проверете дали правилата са заредени правилно:

$ 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

Отново е много важно да посочите коментари за всяко правило, за да ни помогнете да разберем по-добре правилото.

За ограничаване на отдалечен достъп до база данни можем също да използваме VPN сървър, както е показано в тази публикация в блога, Използване на OpenVPN за защитен достъп до вашия клъстер от база данни в облака.

Заключение

Подготовката на производствен сървър очевидно не е лесна задача, което показахме в тази серия от блогове. Ако се притеснявате, че ще прецакате, защо не използвате ClusterControl, за да разположите своя клъстер от база данни? ClusterControl има много добър опит в разгръщането на база данни и е активирал повече от 70 000 MySQL и MariaDB внедрявания за всички среди до момента.