sql >> Databáze >  >> RDS >> MariaDB

Příprava serveru MySQL nebo MariaDB pro produkci – část první

Je nesmírně důležité nainstalovat a nakonfigurovat produkční server MySQL s nezbytnými balíčky a nástroji, aby se operace z dlouhodobého hlediska vyhladily. Viděli jsme mnoho případů, kdy je řešení problémů nebo ladění produkčního serveru (zejména serveru bez veřejného přístupu k internetu) obvykle obtížné kvůli nedostatku nezbytných nástrojů nainstalovaných na serveru, které by pomohly identifikovat a vyřešit problém.

V tomto dvoudílném seriálu blogů vám ukážeme 9 tipů a triků, jak připravit server MySQL pro produkční použití z pohledu správce systému. Všechny příklady v tomto příspěvku na blogu jsou založeny na našem dvouuzlovém nastavení replikace MySQL typu master-slave běžícím na CentOS 7.

Instalovat základní balíčky

Po instalaci klientských a serverových balíčků MySQL nebo MariaDB potřebujeme připravit server MySQL/MariaDB se všemi potřebnými nástroji, aby zvládl všechny operace správy, správy a monitorování, které se budou dít na server. Pokud plánujete uzamknout server MySQL ve výrobě, bude o něco těžší je všechny nainstalovat ručně bez připojení k internetu.

Některé z důležitých balíčků, které by měly být nainstalovány na serveru MySQL/MariaDB pro Linux:

  • Percona Xtrabackup/MariaDB Backup – Neblokující fyzická záloha databázového serveru.
  • ntp/ntpdate – čas synchronizačního serveru.
  • pv – Monitorování dat prostřednictvím potrubí, lze jej také použít pro omezení.
  • socat nebo netcat- Nástroj pro streamování dat, vhodný pro zálohování streamování.
  • net-tools – Sbírka síťových ladicích nástrojů pro Linux.
  • bind-utils – Sbírka nástrojů pro ladění DNS pro Linux.
  • sysstat – Sbírka nástrojů pro sledování výkonu pro Linux.
  • telnet – klient Telnet pro kontrolu dosažitelnosti služby.
  • mailx/mailutils – klient MTA.
  • openssl – sada nástrojů pro protokoly Transport Layer Security (TLS) a Secure Sockets Layer (SSL).
  • unzip – nástroj pro rozbalení.
  • htop – nástroj pro monitorování hostitele.
  • innotop – nástroj pro monitorování MySQL.
  • vim – Textový editor se zvýrazněním syntaxe (nebo jakýkoli preferovaný textový editor).
  • python-setuptools – správce balíčků Pythonu.
  • lm_sensors/ipmitool – Kontrola teploty serverové komponenty. Pouze bare-metal server.

Všimněte si, že některé z navrhovaných balíčků jsou k dispozici pouze v jiných než výchozích úložištích balíčků, jako je EPEL pro CentOS. Proto pro instalaci založenou 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 ipmitool

Při instalaci založené na APT:

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

Pro rozhraní příkazového řádku MySQL můžeme použít jiný nástroj než standardního klienta příkazového řádku "mysql", jako je mycli, s automatickým doplňováním a zvýrazněním syntaxe. K instalaci balíčku můžeme použít pip (správce balíčků Pythonu):

$ pip install mycli

S mycli lze snížit vektor lidské chyby pomocí lepší vizualizace při práci s produkčním serverem, jak ukazuje následující snímek obrazovky:

Smysluplná výzva shellu

Tato část se v první řadě zdá zbytečná, ale pravděpodobně vás zachrání před hloupými chybami ve výrobě. Jako člověk jsme náchylní k chybám, zvláště když spouštíme destruktivní příkazy během intenzivního okamžiku, například když je produkční server mimo provoz.

Podívejte se na následující snímek obrazovky. Ve výchozím nastavení vypadá výzva bash PS1 (primární výzva) docela nudně:

Dobrá výzva PS1 by měla poskytovat zřetelné informace, aby si SysAdmins více uvědomili prostředí, server a aktuální cestu, se kterou se aktuálně zabývají. V důsledku toho by byl člověk opatrnější a vždy věděl, zda je k provedení příkazu na správné cestě/serveru/uživateli.

Abyste toho dosáhli, najděte řádek popisující konfiguraci PS1 (primární výzva), obvykle v /etc/bashrc řádek 41:

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

A nahraďte jej tímto řádkem:

  [ "$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\]]$ "

Odhlaste se z terminálu a znovu se přihlaste. Nyní byste měli v terminálu vidět něco takového:

Jak je vidět na snímku obrazovky výše, aktuální uživatel (modrý), server název hostitele (zelená), úroveň produkce (tučné v červené barvě s bílým pozadím) spolu s úplnou cestou k aktuálnímu adresáři (žlutá) poskytuje lepší přehled aktuální relace, kde jsou důležité informace snadno rozlišitelné různými barvami.

Tento bezplatný online nástroj můžete použít k přizpůsobení výzvy bash podle svého vkusu.

MOTD

Pokud spravujete databázový klastr s více rolemi, jako je replikace MySQL nebo MariaDB, je běžné, že při přímé správě jednoho z hostitelů máte vždy tento úzkostný pocit, protože musíme provést dodatečné kontroly, abychom ověřili, že uzel, ve kterém se nacházíme, je ten, který skutečně chceme spravovat. Topologie replikace má tendenci být složitější, jak se váš databázový klastr škáluje a v klastru může být mnoho rolí, jako je střední hlavní server, binlogový server, záložní hlavní server s polosynchronní replikací, podřízené jednotky pouze pro čtení a také server pro ověřování záloh.

Bude mnohem lepší, když budeme moci získat souhrn stavu databáze, kdykoli jsme na tomto konkrétním serveru, jen abychom měli přehled o tom, čím se budeme zabývat. Můžeme využít Linux's Message of the Day (MOTD) k automatizaci tohoto chování, kdykoli se přihlásíme na server. Použití výchozího /etc/motd je dobré pouze pro statický obsah, což ve skutečnosti nechceme, pokud chceme hlásit aktuální stav serveru MySQL.

Abychom dosáhli podobného výsledku, můžeme použít jednoduchý Bash skript k vytvoření smysluplného výstupu MOTD pro shrnutí našeho serveru MySQL/MariaDB, například:

$ 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

Vyberte jednu z rolí MySQL, buď hlavní nebo podřízenou na řádku 8 nebo 9, a uložte skript. Tento skript vyžaduje soubor voleb MySQL k uložení přihlašovacích údajů uživatele databáze, takže jej musíme nejprve vytvořit:

$ vim ~/.my.cnf

A přidejte následující řádky:

[client]
user=root
password='YourRootP4ssw0rd'

Nahraďte část hesla skutečným heslem root MySQL. Potom použijte pro skript oprávnění ke spuštění:

$ chmod 755 ~/.motd.sh

Otestujte spustitelný skript, zda vytváří správný výstup nebo ne:

$ ~/.motd.sh

Pokud výstup vypadá dobře (žádné chyby nebo varování), přidejte skript do ~/.bash_profile, aby se automaticky načetl, když se uživatel přihlásí:

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

Přihlaste se znovu k terminálu a na hlavním serveru byste měli vidět něco takového:

Zatímco na slave, měli byste vidět něco takového:

Všimněte si, že tento skript je speciálně napsán pro jednoduchý MySQL/MariaDB- replikace typu master-slave. Pokud máte složitější nastavení, nebo chcete použít jinou technologii clusteringu MySQL, jako je Galera Cluster, Group Replication nebo NDB Cluster, pravděpodobně budete muset skript upravit. Cílem je načíst stav databázového uzlu a informace hned, když se přihlásíme, abychom věděli o aktuálním stavu databázového serveru, na kterém pracujeme.

Sensory a teplota

Tuto část běžně ignoruje mnoho SysAdminů. Sledování teplot je klíčové, protože nechceme být velkým překvapením, pokud se server při přehřátí chová neočekávaně. Fyzický server se běžně skládá ze stovek elektronických součástí slepených dohromady v krabici a jsou citlivé na změny teploty. Jeden selhávající chladicí ventilátor by mohl zvýšit teplotu procesoru a narazit na svůj tvrdý limit, což nakonec způsobí snížení taktu procesoru a ovlivní výkon zpracování dat jako celek.

K tomuto účelu můžeme použít balíček lm-sensors. Chcete-li jej nainstalovat, jednoduše postupujte takto:

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

Potom spusťte program sensors-detect, který automaticky určí, které moduly jádra je třeba načíst, abyste mohli lm_sensors používat co nejefektivněji:

$ sensors-detect

Odpovídá na všechny otázky (obvykle stačí přijmout všechny navrhované odpovědi). Někteří hostitelé, jako jsou virtuální stroje nebo kontejnery, tento modul nepodporují. Senzory skutečně musí být na úrovni hostitelů (holý kov). Další informace naleznete v tomto seznamu.

Poté spusťte příkaz sensors:

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

Výše uvedený výsledek ukazuje celkovou teplotu CPU spolu s každým jádrem CPU. Dalším nástrojem, který můžeme použít k zobrazení celkového stavu komponent serveru, je ipmitool. Chcete-li nainstalovat, jednoduše postupujte takto:

$ yum -y install ipmitool

Spuštěním následujícího příkazu můžeme zjistit celkový stav fyzických komponent na serveru:

$ 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

Seznam je dlouhý, ale je samozřejmý a měli byste být schopni dohlížet na celkový stav serverových komponent. Mohou nastat případy, kdy některé ventilátory neběží na plnou rychlost, což následně zvyšuje teplotu CPU. K vyřešení problému může být nutná výměna hardwaru.

Všimněte si, že modul jádra Intelligent Platform Management Interface (IPMI) vyžaduje, aby byl na základní desce povolen řadič Baseboard Management Controller (BMC). Použijte dmesg k ověření, zda je k dispozici:

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

Pokud je tento řadič deaktivován, zkontrolujte nastavení BIOS serveru.

To je prozatím vše. Druhá část této série blogů pokryje zbývajících 5 témat, jako je konfigurace nástroje pro zálohování, zátěžové testy a uzamčení serveru.


  1. Jak změnit název databáze na serveru SQL pomocí T-SQL

  2. Příklady CURTIME() – MySQL

  3. Používáte Excel pro svou databázi? Zde je důvod, proč byste měli upgradovat na přístup

  4. Sloupec Postgresql nebyl nalezen, ale zobrazuje se v popisu