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

Изключително важно е да инсталирате и конфигурирате производствен MySQL сървър с необходимите пакети и инструменти за изглаждане на операциите в дългосрочен план. Виждали сме много случаи, при които отстраняването на неизправности или настройката на производствен сървър (особено такъв без публичен достъп до интернет) обикновено е трудно поради липсата на необходимите инструменти, инсталирани на сървъра, които да помогнат за идентифициране и разрешаване на проблема.

В тази серия от блогове от две части ще ви покажем 9 съвета и трика как да подготвите MySQL сървър за производствена употреба от гледна точка на системния администратор. Всички примери в тази публикация в блога са базирани на нашата настройка на MySQL репликация с два възела, главен-подчинен, работеща на CentOS 7.

Инсталиране на основни пакети

След инсталирането на MySQL или MariaDB клиентски и сървърни пакети, трябва да подготвим MySQL/MariaDB сървъра с всички необходими инструменти, за да се справим с всички операции по администриране, управление и наблюдение, които ще се случат на сървърът. Ако планирате да заключите MySQL сървъра в производство, ще бъде малко по-трудно да ги инсталирате ръчно без интернет връзка.

Някои от важните пакети, които трябва да бъдат инсталирани на MySQL/MariaDB сървъра за Linux:

Percona Xtrabackup/MariaDB Backup – Неблокиращо физическо архивиране на сървъра на базата данни.
ntp/ntpdate – Времето на сървъра за синхронизиране.
pv - Наблюдаване на данните чрез конвейер, може да се използва и за регулиране.
socat или netcat – Инструмент за поточно предаване на данни, добър за поточно архивиране.
net-tools – Колекция от инструменти за отстраняване на грешки в мрежата за Linux.
bind-utils – Колекция от инструменти за отстраняване на грешки в DNS за Linux.
sysstat – Колекция от инструменти за наблюдение на производителността за Linux.
telnet – Telnet клиент за проверка на достъпността на услугата.
mailx/mailutils - MTA клиент.
openssl – Инструментариум за протоколите за защита на транспортния слой (TLS) и слоя на защитени гнезда (SSL).
разархивирайте – инструмент за декомпресиране.
htop – Инструмент за наблюдение на хост.
innotop – инструмент за наблюдение на MySQL.
vim – Текстов редактор с подчертаване на синтаксиса (или всеки предпочитан текстов редактор).
python-setuptools – мениджър на пакети на Python.
lm_sensors/ipmitool - За да проверите температурата на компонента на сървъра. Само голи сървъри.

Имайте предвид, че някои от предложените пакети са налични само в хранилища на пакети, които не са по подразбиране, като EPEL за CentOS. Следователно, за YUM-базирана инсталация:

$ yum install epel-release
$ yum install -y wget ntp pv socat htop innotop vim mailx bind-utils net-tools telnet sysstat openssl python-setuptools lm_sensors ipmitool

Докато за APT-базирана инсталация:

$ apt-get install ntp pv socat htop innotop vim easy_install mailutils bind-utils sysstat net-tools telnet openssl lm_sensors ipmitool

За интерфейса на командния ред на MySQL можем да използваме друг инструмент, различен от стандартния клиент на командния ред "mysql", като mycli, с автоматично довършване и подчертаване на синтаксиса. За да инсталираме пакета, можем да използваме pip (мениджър на пакети Python):

$ pip install mycli

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

Съсмислена подкана за обвивка

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

Разгледайте следната екранна снимка. По подразбиране подканата на bash PS1 (основната подкана) изглежда доста скучна:

Добрата подкана за PS1 трябва да предоставя ясно изразена информация, за да накара администраторите на Sys Admin да осъзнаят по-добре среда, сървър и текущ път, с който се занимават в момента. В резултат на това човек ще бъде по-внимателен и винаги ще знае дали е на правилния път/сървър/потребител, за да изпълни командата.

За да постигнете това, намерете реда, който описва конфигурацията на PS1 (първична подкана), обикновено в /etc/bashrc ред 41:

  [ "$PS1" = "\\s-\\v\\\$ " ] && PS1="[\[email protected]\h \W]\\$ "

И го заменете с този ред:

  [ "$PS1" = "\\s-\\v\\\$ " ] && PS1="[\[\e[36m\]\u\[\e[m\]@\[\e[32m\]\h\[\e[m\]\[\e[31;47m\]Production\[\e[m\]: \[\e[33m\]\w\[\e[m\]]$ "

Излезте от терминала и влезте отново. Сега трябва да видите нещо подобно в терминала:

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

Можете да използвате този безплатен онлайн инструмент, за да персонализирате подканата за bash според вашия вкус.

MOTD

Ако управлявате клъстер от база данни с множество роли като MySQL или MariaDB репликация, обичайно е винаги да имаме това тревожно чувство, когато директно администрираме един от хостовете, защото трябва да извършим допълнителни проверки, за да проверим дали възел, в който се намираме, е този, който наистина искаме да администрираме. Топологията на репликация има тенденция да става по-сложна, тъй като клъстерът на базата ви данни се мащабира и може да има много роли в клъстер като междинен главен, binlog сървър, резервен главен с полу-синхронизирана репликация, подчинени устройства само за четене и също сървър за проверка на архивиране.

Ще бъде много по-добре, ако можем да получим обобщение на състоянието на базата данни винаги, когато сме на този конкретен сървър, само за да ни дадем представа с какво ще се справим. Можем да използваме Съобщението на деня (MOTD) на Linux, за да автоматизираме това поведение всеки път, когато влизаме в сървъра. Използването на /etc/motd по подразбиране е добро само за статично съдържание, което не е това, което наистина искаме, ако искаме да докладваме текущото състояние на MySQL сървър.

За да постигнем подобен резултат, можем да използваме прост Bash скрипт, за да произведем смислен MOTD изход, за да обобщим нашия MySQL/MariaDB сървър, например:

$ vim ~/.motd.sh
#!/bin/bash
# Auto-generate MOTD for MySQL/MariaDB Replication
# .motd.sh, to be executed under ~/.bash_profile

#####
# Preferred role of the node, pick one
#PREFER_ROLE='Slave'
PREFER_ROLE='Master'
#####

HOSTNAME=$(hostname)
UPTIME=$(uptime -p)
MYSQL_COMMAND='mysql --connect-timeout=2 -A -Bse'
MYSQL_READONLY=$(${MYSQL_COMMAND} 'SHOW GLOBAL VARIABLES LIKE "read_only"' | awk {'print $2'})
TIER='Production'
MAIN_IP=$(hostname -I | awk {'print $1'})
CHECK_MYSQL_REPLICATION=$(${MYSQL_COMMAND} 'SHOW SLAVE STATUS\G' | egrep 'Slave_.*_Running: Yes$')
MYSQL_MASTER=$(${MYSQL_COMMAND} 'SHOW SLAVE STATUS\G' | grep Master_Host | awk {'print $2'})
# The following requires show_compatibility_56=1 for MySQL 5.7 and later
MYSQL_UPTIME=$(${MYSQL_COMMAND} 'SELECT TIME_FORMAT(SEC_TO_TIME(VARIABLE_VALUE ),"%Hh %im")  AS Uptime FROM information_schema.GLOBAL_STATUS WHERE VARIABLE_NAME="Uptime"')

# coloring
bold=$(tput bold)
red=$(tput setaf 1)
green=$(tput setaf 2)
normal=$(tput sgr0)

MYSQL_SHOW=1
if [ $MYSQL_READONLY == 'ON' ]; then
        CURRENT_MYSQL_ROLE='Slave'
        if ${MYSQL_COMMAND} 'SHOW SLAVE STATUS\G' | egrep 'Slave_.*_Running: Yes$' &>/dev/null ; then
                lag=$(${MYSQL_COMMAND} 'SHOW SLAVE STATUS\G' | egrep 'Seconds_Behind_Master:' | awk {'print $2'})
                if [ $lag -eq 0 ]; then
                        REPLICATION_STATUS="${green}Healthy  "
                else
                        if [ $lag == 'NULL' ]; then
                                REPLICATION_STATUS=${red}Unhealthy
                        else
                                REPLICATION_STATUS="${red}Lagging ${lag}s"
                        fi
                fi
        else
                REPLICATION_STATUS=${red}Unhealthy
        fi

elif [ $MYSQL_READONLY == 'OFF' ]; then
        CURRENT_MYSQL_ROLE='Master'
        SLAVE_HOSTS=$(${MYSQL_COMMAND} 'SHOW SLAVE HOSTS' | awk {'print $1'})
else
        MYSQL_SHOW=0
fi

if [ $TIER == 'Production' ]; then
        TIER=${green}Production
fi

if [ $PREFER_ROLE == $CURRENT_MYSQL_ROLE ]; then
        MYSQL_ROLE=${green}$CURRENT_MYSQL_ROLE
else
        MYSQL_ROLE=${red}$CURRENT_MYSQL_ROLE
fi

echo
echo "HOST INFO"
echo "========="
echo -e "  Hostname       : ${bold}$HOSTNAME${normal} \t Server Uptime  : ${bold}$UPTIME${normal}"
echo -e "  IP Address       : ${bold}$MAIN_IP${normal} \t Tier           : ${bold}$TIER${normal}"
echo
if [ $MYSQL_SHOW -eq 1 ]; then
        echo "MYSQL STATE"
        echo "==========="
        echo -e "  Current role      : ${bold}$MYSQL_ROLE${normal} \t\t Read-only      : ${bold}$MYSQL_READONLY${normal}"
        echo -e "  Preferred role    : ${bold}$PREFER_ROLE${normal} \t\t DB Uptime      : ${bold}$MYSQL_UPTIME${normal}"
        if [ $CURRENT_MYSQL_ROLE == 'Slave' ]; then
                echo -e "  Replication state : ${bold}$REPLICATION_STATUS${normal} \t Current Master : ${bold}$MYSQL_MASTER${normal}"
        else
                echo -e "  Slave Hosts(s) ID : "
                for i in $SLAVE_HOSTS; do
                        echo -e "      - ${bold}$i${normal} \t"; done
        fi
        echo
fi

Изберете една от MySQL ролите, главна или подчинена на ред 8 или 9 и запазете скрипта. Този скрипт изисква файл с опция MySQL, за да съхранява потребителските идентификационни данни на базата данни, така че първо трябва да го създадем:

$ vim ~/.my.cnf

И добавете следните редове:

[client]
user=root
password='YourRootP4ssw0rd'

Заменете частта с паролата с действителната парола за root на MySQL. След това приложете разрешение за изпълним файл към скрипта:

$ chmod 755 ~/.motd.sh

Тествайте изпълнимия скрипт дали произвежда правилния изход или не:

$ ~/.motd.sh

Ако изходът изглежда добре (няма грешки или предупреждения), добавете скрипта в ~/.bash_profile, така че да се зарежда автоматично, когато потребител влезе:

$ whoami
root
$ echo '~/.motd.sh' >> ~/.bash_profile

Влезте отново в терминала и трябва да видите нещо подобно на главната страница:

Докато сте на подчинения, трябва да видите нещо подобно:

Обърнете внимание, че този скрипт е написан специално за обикновен MySQL/MariaDB един- ниво главен-подчинен репликация. Вероятно ще трябва да модифицирате скрипта, ако имате по-сложна настройка или искате да използвате друга технология за клъстериране на MySQL като Galera Cluster, Group Replication или NDB Cluster. Идеята е да извлечем състоянието и информацията на възела на базата данни точно когато влезем, така че да сме наясно с текущото състояние на сървъра на базата данни, върху който работим.

Сензори и температура

Тази част обикновено се игнорира от много системни администратори. Следенето на температурите е от решаващо значение, тъй като не искаме да получим голяма изненада, ако сървърът се държи неочаквано при прегряване. Физическият сървър обикновено се състои от стотици електронни части, залепени заедно в кутия и са чувствителни към температурни промени. Един неуспешен вентилатор за охлаждане може да повиши температурата на процесора, за да достигне твърдата си граница, което в крайна сметка води до намаляване на честотата на процесора и се отразява на производителността на обработка на данни като цяло.

За тази цел можем да използваме пакета lm-sensors. За да го инсталирате, просто направете:

$ yum install lm-sensors # apt-get install lm-sensors for APT

След това стартирайте програмата за откриване на сензори, за да определите автоматично кои модули на ядрото трябва да заредите, за да използвате lm_sensors най-ефективно:

$ sensors-detect

Отговаря на всички въпроси (обикновено просто приема всички предложени отговори). Някои хостове като виртуални машини или контейнери не поддържат този модул. Сензорите наистина трябва да са на ниво домакин (гол метал). Вижте този списък за повече информация.

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

$ sensors
i350bb-pci-0203
Adapter: PCI adapter
loc1:         +53.0°C (high = +120.0°C, crit = +110.0°C)

power_meter-acpi-0
Adapter: ACPI interface
power1:        4.29 MW (interval =   1.00 s)

coretemp-isa-0000
Adapter: ISA adapter
Package id 0:  +55.0°C (high = +85.0°C, crit = +95.0°C)
Core 0:        +45.0°C (high = +85.0°C, crit = +95.0°C)
Core 1:        +51.0°C (high = +85.0°C, crit = +95.0°C)
Core 2:        +47.0°C (high = +85.0°C, crit = +95.0°C)
Core 3:        +51.0°C (high = +85.0°C, crit = +95.0°C)
Core 4:        +49.0°C (high = +85.0°C, crit = +95.0°C)
Core 5:        +48.0°C (high = +85.0°C, crit = +95.0°C)
Core 8:        +47.0°C (high = +85.0°C, crit = +95.0°C)
Core 9:        +49.0°C (high = +85.0°C, crit = +95.0°C)
Core 10:       +48.0°C (high = +85.0°C, crit = +95.0°C)
Core 11:       +48.0°C (high = +85.0°C, crit = +95.0°C)
Core 12:       +46.0°C (high = +85.0°C, crit = +95.0°C)
Core 13:       +49.0°C (high = +85.0°C, crit = +95.0°C)

coretemp-isa-0001
Adapter: ISA adapter
Package id 1:  +53.0°C (high = +85.0°C, crit = +95.0°C)
Core 0:        +46.0°C (high = +85.0°C, crit = +95.0°C)
Core 1:        +48.0°C (high = +85.0°C, crit = +95.0°C)
Core 2:        +47.0°C (high = +85.0°C, crit = +95.0°C)
Core 3:        +45.0°C (high = +85.0°C, crit = +95.0°C)
Core 4:        +46.0°C (high = +85.0°C, crit = +95.0°C)
Core 5:        +47.0°C (high = +85.0°C, crit = +95.0°C)
Core 8:        +47.0°C (high = +85.0°C, crit = +95.0°C)
Core 9:        +45.0°C (high = +85.0°C, crit = +95.0°C)
Core 10:       +45.0°C (high = +85.0°C, crit = +95.0°C)
Core 11:       +46.0°C (high = +85.0°C, crit = +95.0°C)
Core 12:       +46.0°C (high = +85.0°C, crit = +95.0°C)
Core 13:       +46.0°C (high = +85.0°C, crit = +95.0°C)

Горният резултат показва общата температура на процесора, заедно с всяко негово ядро на процесора. Друг инструмент, който можем да използваме, за да видим цялостното състояние на компонентите на сървъра, е ipmitool. За да инсталирате, просто направете:

$ yum -y install ipmitool

Като изпълним следната команда, можем да кажем общото състояние на физическите компоненти в сървъра:

$ ipmitool sdr list full
Inlet_Temp       | 20 degrees C   | ok
PCIe_Inlet_Temp  | 37 degrees C   | ok
Outlet_Temp      | 20 degrees C   | ok
CPU0_VR_Temp     | 39 degrees C   | ok
CPU1_VR_Temp     | 41 degrees C   | ok
CPU0_Temp        | 55 degrees C   | ok
CPU1_Temp        | 52 degrees C   | ok
PCH_Temp         | 58 degrees C   | ok
DIMMG0_Temp      | 35 degrees C   | ok
DIMMG1_Temp      | 32 degrees C   | ok
PSU0_Temp        | 0 degrees C    | ok
PSU1_Temp        | 0 degrees C    | ok
SYS_3.3V         | 3.30 Volts     | ok
SYS_5V           | 5 Volts        | ok
SYS_12V          | 12.10 Volts    | ok
CPU0_VCORE       | 1.79 Volts     | ok
CPU1_VCORE       | 1.79 Volts     | ok
CPU0_DDR_VDD     | 1.23 Volts     | ok
CPU1_DDR_VDD     | 1.23 Volts     | ok
SYS_FAN1_Speed   | 4018 RPM   | ok
SYS_FAN2_Speed   | 4116 RPM   | ok
SYS_FAN3_Speed   | 4116 RPM   | ok
SYS_FAN4_Speed   | 4116 RPM   | ok
SYS_FAN5_Speed   | 4018 RPM   | ok
SYS_FAN6_Speed   | 4116 RPM   | ok
SYS_FAN7_Speed   | 4018 RPM   | ok
SYS_FAN8_Speed   | 4116 RPM   | ok
SYS_FAN9_Speed   | 4018 RPM   | ok
SYS_FAN10_Speed  | 4116 RPM   | ok
SYS_FAN11_Speed  | 4116 RPM   | ok
SYS_FAN12_Speed  | 4116 RPM   | ok
SYS_FAN13_Speed  | 4116 RPM   | ok
SYS_FAN14_Speed  | 4214 RPM   | ok
Airflow_rate     | 16 CFM     | ok
PSU1_PIN         | 0 Watts    | ok
PSU2_PIN         | 0 Watts    | ok
PSU1_POUT        | 0 Watts    | ok
PSU2_POUT        | 0 Watts    | ok
PSU1_IIN         | 0 Amps     | ok
PSU2_IIN         | 0 Amps     | ok
PSU1_VIN         | 0 Volts    | ok
PSU2_VIN         | 0 Volts    | ok
CPU_Power        | 63 Watts   | ok
MEM_Power        | 8 Watts    | ok
Total_Power      | 0 Watts    | ok
BP_Power         | 8 Watts    | ok
FAN_Power        | 6 Watts    | ok
MB_Power         | 0 Watts    | ok

Списъкът е дълъг, но се обяснява сам и трябва да можете да наблюдавате цялостното състояние на сървърните компоненти. Може да има случаи, когато някои от вентилаторите не работят на пълна скорост, което след това повишава температурата на процесора. Може да се наложи смяна на хардуера за отстраняване на проблема.

Обърнете внимание, че модулът на ядрото на интерфейса за управление на интелигентната платформа (IPMI) изисква контролер за управление на базовата платка (BMC) да бъде активиран на дънната платка. Използвайте dmesg, за да проверите дали е наличен:

$ dmesg | grep -i bmc
[    8.063470] ipmi_si IPI0001:00: Found new BMC (man_id: 0x000000, prod_id: 0x02f3, dev_id: 0x20)

В противен случай проверете настройките на BIOS на сървъра, ако този контролер е деактивиран.

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

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

Инсталиране на основни пакети

Съсмислена подкана за обвивка

MOTD

Сензори и температура