Niezwykle ważne jest zainstalowanie i skonfigurowanie produkcyjnego serwera MySQL z niezbędnymi pakietami i narzędziami, aby zapewnić płynne działanie na dłuższą metę. Widzieliśmy wiele przypadków, w których rozwiązywanie problemów lub dostrajanie serwera produkcyjnego (zwłaszcza takiego bez publicznego dostępu do Internetu) jest często trudne z powodu braku niezbędnych narzędzi zainstalowanych na serwerze, aby pomóc zidentyfikować i rozwiązać problem.
W tej dwuczęściowej serii blogów przedstawimy 9 porad i wskazówek, jak przygotować serwer MySQL do użytku produkcyjnego z perspektywy administratora systemu. Wszystkie przykłady w tym poście na blogu są oparte na naszej dwuwęzłowej konfiguracji replikacji MySQL typu master-slave działającej na CentOS 7.
Zainstaluj niezbędne pakiety
Po instalacji pakietów klienta i serwera MySQL lub MariaDB musimy przygotować serwer MySQL/MariaDB ze wszystkimi niezbędnymi narzędziami, aby poradzić sobie ze wszystkimi operacjami administracyjnymi, zarządzania i monitorowania, które będą miały miejsce na serwer. Jeśli planujesz zablokować serwer MySQL w środowisku produkcyjnym, nieco trudniej będzie zainstalować je wszystkie ręcznie bez połączenia z Internetem.
Niektóre z ważnych pakietów, które powinny być zainstalowane na serwerze MySQL/MariaDB dla systemu Linux:
- Percona Xtrabackup/MariaDB Backup - Nieblokująca fizyczna kopia zapasowa serwera bazy danych.
- ntp/ntpdate — Synchronizuj czas serwera.
- pv — Monitoruj dane przez potok, może być również używany do ograniczania przepustowości.
- socat lub netcat — narzędzie do przesyłania strumieniowego danych, dobre do przesyłania strumieniowego kopii zapasowych.
- net-tools — Zbiór narzędzi do debugowania sieci dla systemu Linux.
- bind-utils — zbiór narzędzi do debugowania DNS dla systemu Linux.
- sysstat — Zbiór narzędzi do monitorowania wydajności dla systemu Linux.
- telnet — klient Telnet do sprawdzania dostępności usługi.
- mailx/mailutils — klient MTA.
- openssl — Zestaw narzędzi dla protokołów Transport Layer Security (TLS) i Secure Sockets Layer (SSL).
- rozpakuj — narzędzie do dekompresowania.
- htop - Narzędzie do monitorowania hosta.
- innotop - narzędzie do monitorowania MySQL.
- vim — Edytor tekstu z podświetlaniem składni (lub dowolny preferowany edytor tekstu).
- python-setuptools - menedżer pakietów Pythona.
- lm_sensors/ipmitool - Aby sprawdzić temperaturę komponentu serwera. Tylko serwer bare-metal.
Zauważ, że niektóre z sugerowanych pakietów są dostępne tylko w innych niż domyślne repozytoria pakietów, takich jak EPEL dla CentOS. Dlatego w przypadku instalacji opartej na 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 ipmitoolW przypadku instalacji opartej na APT:
$ apt-get install ntp pv socat htop innotop vim easy_install mailutils bind-utils sysstat net-tools telnet openssl lm_sensors ipmitoolW przypadku interfejsu wiersza poleceń MySQL możemy użyć innego narzędzia niż standardowy klient wiersza poleceń „mysql”, taki jak mycli, z automatycznym uzupełnianiem i podświetlaniem składni. Aby zainstalować pakiet, możemy użyć pip (menedżera pakietów Pythona):
$ pip install mycliDzięki mycli można zredukować wektor błędów ludzkich dzięki lepszej wizualizacji w przypadku serwera produkcyjnego, jak pokazano na poniższym zrzucie ekranu:
Znaczący monit powłoki
Ta część wygląda na niepotrzebną, ale prawdopodobnie uchroni Cię przed popełnianiem głupich błędów w produkcji. Jako ludzie jesteśmy skłonni do popełniania błędów, zwłaszcza podczas uruchamiania destrukcyjnych poleceń w intensywnym momencie, na przykład gdy serwer produkcyjny nie działa.
Spójrz na poniższy zrzut ekranu. Domyślnie monit bash PS1 (podstawowy monit) wygląda dość nudno:
Dobry monit PS1 powinien zawierać wyraźne informacje, aby administratorzy SysAdmins byli bardziej świadomi środowisko, serwer i bieżąca ścieżka, z którą aktualnie się mają do czynienia. W rezultacie można być bardziej ostrożnym i zawsze wiedzieć, czy znajduje się we właściwej ścieżce/serwerze/użytkowniku, aby wykonać polecenie.
Aby to osiągnąć, znajdź wiersz opisujący konfigurację PS1 (podstawowy znak zachęty), zwykle w /etc/bashrc wiersz 41:
[ "$PS1" = "\\s-\\v\\\$ " ] && PS1="[\[email protected]\h \W]\\$ "I zastąp go tym wierszem:
[ "$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\]]$ "Wyloguj się z terminala i zaloguj ponownie. Powinieneś teraz zobaczyć coś takiego w terminalu:
Jak pokazano na powyższym zrzucie ekranu, bieżący użytkownik (niebieski), serwer nazwa hosta (zielony), warstwa produkcyjna (pogrubiona w kolorze czerwonym z białym tłem) wraz z pełną ścieżką bieżącego katalogu (żółty) zapewnia lepsze podsumowanie bieżącej sesji, w której ważne informacje można łatwo odróżnić różnymi kolorami.
Możesz użyć tego bezpłatnego narzędzia online, aby dostosować monit bash do swoich upodobań.
MOTD
Jeżeli zarządzasz klastrem baz danych z wieloma rolami, takimi jak replikacja MySQL lub MariaDB, często pojawia się to niepokój podczas bezpośredniego administrowania jednym z hostów, ponieważ musimy wykonać dodatkowe kontrole, aby sprawdzić, czy węzeł, w którym się znajdujemy, jest tym, którym naprawdę chcemy administrować. Topologia replikacji staje się coraz bardziej złożona w miarę skalowania klastra bazy danych, a w klastrze może występować wiele ról, takich jak serwer pośredniczący, serwer binlog, master kopii zapasowej z replikacją częściowo zsynchronizowaną, jednostki podrzędne tylko do odczytu, a także serwer weryfikacji kopii zapasowych.
Będzie o wiele lepiej, jeśli będziemy mogli uzyskać podsumowanie stanu bazy danych za każdym razem, gdy jesteśmy na tym konkretnym serwerze, tylko po to, aby dać nam informacje na temat tego, z czym mamy do czynienia. Możemy wykorzystać Message of the Day (MOTD) Linuksa, aby zautomatyzować to zachowanie za każdym razem, gdy logujemy się na serwer. Używanie domyślnego /etc/motd jest dobre tylko w przypadku zawartości statycznej, co nie jest tym, czego naprawdę chcemy, jeśli chcemy raportować bieżący stan serwera MySQL.
Aby osiągnąć podobny wynik, możemy użyć prostego skryptu Bash, aby wygenerować sensowny wynik MOTD podsumowujący nasz serwer MySQL/MariaDB, na przykład:
$ 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
fiWybierz jedną z ról MySQL, główną lub podrzędną w wierszu 8 lub 9 i zapisz skrypt. Ten skrypt wymaga pliku opcji MySQL do przechowywania poświadczeń użytkownika bazy danych, więc musimy go najpierw utworzyć:
$ vim ~/.my.cnfI dodaj następujące wiersze:
[client]
user=root
password='YourRootP4ssw0rd'Zastąp część dotyczącą hasła aktualnym hasłem root MySQL. Następnie zastosuj do skryptu uprawnienia do wykonywania:
$ chmod 755 ~/.motd.shPrzetestuj wykonywalny skrypt, czy generuje poprawne dane wyjściowe, czy nie:
$ ~/.motd.shJeśli dane wyjściowe wyglądają dobrze (brak błędów i ostrzeżeń), dodaj skrypt do ~/.bash_profile, aby został automatycznie załadowany po zalogowaniu się użytkownika:
$ whoami
root
$ echo '~/.motd.sh' >> ~/.bash_profileZaloguj się ponownie do terminala i powinieneś zobaczyć coś takiego na masterze:
Na urządzeniu podrzędnym powinieneś zobaczyć coś takiego:
Zauważ, że ten skrypt został napisany specjalnie dla prostego replikacja typu master-slave. Prawdopodobnie będziesz musiał zmodyfikować skrypt, jeśli masz bardziej złożoną konfigurację lub chcesz użyć innej technologii klastrowania MySQL, takiej jak Galera Cluster, Group Replication lub NDB Cluster. Chodzi o to, aby pobrać stan węzła bazy danych i informacje zaraz po zalogowaniu, dzięki czemu jesteśmy świadomi aktualnego stanu serwera bazy danych, nad którym pracujemy.
Czujniki i temperatura
Ta część jest często ignorowana przez wielu administratorów systemu. Monitorowanie temperatury jest kluczowe, ponieważ nie chcemy być zaskoczeni, jeśli serwer zachowuje się niespodziewanie podczas przegrzewania. Serwer fizyczny zwykle składa się z setek części elektronicznych sklejonych ze sobą w pudełku i jest wrażliwy na zmiany temperatury. Jeden niesprawny wentylator może wzrosnąć, aby temperatura procesora osiągnęła swój sztywny limit, co w końcu spowoduje skrócenie zegara procesora i wpłynie na wydajność przetwarzania danych jako całości.
Do tego celu możemy wykorzystać pakiet lm-sensors. Aby go zainstalować, po prostu wykonaj:
$ yum install lm-sensors # apt-get install lm-sensors for APTNastępnie uruchom program sensor-detect, aby automatycznie określić, które moduły jądra należy załadować, aby najefektywniej korzystać z lm_sensors:
$ sensors-detectOdpowiada na wszystkie pytania (zwykle wystarczy zaakceptować wszystkie sugerowane odpowiedzi). Niektóre hosty, takie jak maszyny wirtualne lub kontenery, nie obsługują tego modułu. Czujniki naprawdę muszą być na poziomie hostów (goły metal). Sprawdź tę listę, aby uzyskać więcej informacji.
Następnie uruchom polecenie sensory:
$ 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)Powyższy wynik pokazuje ogólną temperaturę procesora wraz z każdym rdzeniem procesora. Innym narzędziem, którego możemy użyć do sprawdzenia ogólnego stanu komponentów serwera, jest ipmitool. Aby zainstalować, po prostu wykonaj:
$ yum -y install ipmitoolUruchamiając następujące polecenie, możemy określić ogólny stan komponentów fizycznych na serwerze:
$ 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 | okLista jest długa, ale nie wymaga wyjaśnień i powinieneś być w stanie nadzorować ogólny stan komponentów serwera. Mogą wystąpić przypadki, w których niektóre wentylatory nie działają z pełną prędkością, co powoduje wzrost temperatury procesora. W celu rozwiązania problemu może być wymagana wymiana sprzętu.
Należy zauważyć, że moduł jądra Intelligent Platform Management Interface (IPMI) wymaga włączenia kontrolera zarządzania płytą główną (BMC) na płycie głównej. Użyj dmesg, aby sprawdzić, czy jest dostępny:
$ dmesg | grep -i bmc
[ 8.063470] ipmi_si IPI0001:00: Found new BMC (man_id: 0x000000, prod_id: 0x02f3, dev_id: 0x20)W przeciwnym razie sprawdź ustawienia BIOS serwera, jeśli ten kontroler jest wyłączony.
Na razie to wszystko. Część druga tej serii blogów obejmie 5 pozostałych tematów, takich jak konfiguracja narzędzia do tworzenia kopii zapasowych, testy warunków skrajnych i blokada serwera.
