Det er ekstremt vigtigt at installere og konfigurere en produktions-MySQL-server med de nødvendige pakker og værktøjer til at udjævne driften i det lange løb. Vi har set mange tilfælde, hvor fejlfinding eller tuning af en produktionsserver (især en uden offentlig internetadgang) ofte er vanskelig på grund af manglen på nødvendige værktøjer installeret på serveren til at hjælpe med at identificere og løse problemet.
I denne todelte blogserie vil vi vise dig 9 tips og tricks til, hvordan du forbereder en MySQL-server til produktionsbrug fra et systemadministratorperspektiv. Alle eksempler i dette blogindlæg er baseret på vores to-node, master-slave MySQL-replikeringsopsætning, der kører på CentOS 7.
Installer essentielle pakker
Efter installationen af MySQL- eller MariaDB-klient- og serverpakker skal vi forberede MySQL/MariaDB-serveren med alle nødvendige værktøjer til at klare alle de administrations-, administrations- og overvågningsoperationer, der skal ske på serveren. Hvis du planlægger at låse MySQL-serveren i produktion, vil det være lidt sværere at installere dem alle manuelt uden internetforbindelse.
Nogle af de vigtige pakker, der bør installeres på MySQL/MariaDB-serveren til Linux:
- Percona Xtrabackup/MariaDB Backup - Ikke-blokerende fysisk backup af databaseserveren.
- ntp/ntpdate - Synkroniseringsserverens tid.
- pv - Overvåg data gennem en pipeline, kan også bruges til at drosle.
- socat eller netcat- Datastreamingværktøj, godt til streaming backup.
- net-tools - En samling netværksfejlfindingsværktøjer til Linux.
- bind-utils - En samling af DNS-fejlretningsværktøjer til Linux.
- sysstat - En samling af præstationsovervågningsværktøjer til Linux.
- telnet - Telnet-klient for at kontrollere servicens tilgængelighed.
- mailx/mailutils - MTA-klient.
- openssl - Toolkit til protokollerne Transport Layer Security (TLS) og Secure Sockets Layer (SSL).
- unzip - Udpak værktøj.
- htop - Værtsovervågningsværktøj.
- innotop - MySQL-overvågningsværktøj.
- vim - Teksteditor med syntaksfremhævning (eller en hvilken som helst foretrukket teksteditor).
- python-setuptools - Python-pakkehåndtering.
- lm_sensors/ipmitool - For at kontrollere serverkomponentens temperatur. Kun metalserver.
Bemærk, at nogle af de foreslåede pakker kun er tilgængelige i ikke-standardpakkedepoter som EPEL til CentOS. Derfor, for YUM-baseret installation:
$ 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 Mens til APT-baseret installation:
$ apt-get install ntp pv socat htop innotop vim easy_install mailutils bind-utils sysstat net-tools telnet openssl lm_sensors ipmitool Til MySQL-kommandolinjegrænsefladen kan vi bruge et andet værktøj end standard "mysql"-kommandolinjeklienten som mycli, med autofuldførelse og syntaksfremhævning. For at installere pakken kan vi bruge pip (Python-pakkehåndtering):
$ pip install mycli Med mycli kan man reducere den menneskelige fejlvektor med en bedre visualisering, når man har at gøre med produktionsserveren, som vist på følgende skærmbillede:
Meningsfuld Shell-prompt
Denne del ser unødvendig ud i første omgang, men den vil sandsynligvis redde dig fra at lave dumme fejl i produktionen. Som mennesker er vi tilbøjelige til at lave fejl, især når vi kører destruktive kommandoer i et intenst øjeblik, for eksempel når produktionsserveren er nede.
Tag et kig på følgende skærmbillede. Som standard ser bash PS1-prompten (primær prompt) ret kedelig ud:
En god PS1-prompt bør give tydelige oplysninger for at gøre SysAdmins mere opmærksomme på miljø, server og nuværende sti, som de i øjeblikket beskæftiger sig med. Som et resultat ville man være mere forsigtig og altid vide, om det er på den rigtige sti/server/bruger til at udføre kommandoen.
For at opnå dette skal du finde linjen, der beskriver PS1 (primær prompt) konfiguration, almindeligvis i /etc/bashrc linje 41:
[ "$PS1" = "\\s-\\v\\\$ " ] && PS1="[\[email protected]\h \W]\\$ " Og erstat den med denne linje:
[ "$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\]]$ " Log ud fra terminalen og log ind igen. Du skulle se noget som dette i terminalen nu:
Som vist på skærmbilledet ovenfor er den aktuelle bruger (blå), serverens værtsnavn (grøn), produktionsniveau (fed i rød farve med hvid baggrund), sammen med den fulde sti til den aktuelle mappe (gul) giver en bedre oversigt over den aktuelle session, hvor de vigtige oplysninger let kan skelnes med forskellige farver.
Du kan bruge dette gratis onlineværktøj til at tilpasse din bash-prompt, så den passer til din smag.
MOTD
Hvis du administrerer en databaseklynge med flere roller som MySQL- eller MariaDB-replikering, er det almindeligt altid at have denne angstfølelse, når du direkte administrerer en af værterne, fordi vi skal udføre ekstra kontrol for at verificere, at node, som vi er i, er den, vi virkelig ønsker at administrere. Replikeringstopologi har en tendens til at blive mere kompleks, efterhånden som din databaseklynge skaleres ud, og der kan være mange roller i en klynge som mellemliggende master, binlog-server, backup-master med semi-sync replikering, skrivebeskyttede slaver og også backup-verifikationsserver.
Det vil være meget bedre, hvis vi kan få en oversigt over databasetilstanden, når vi er på den pågældende server, bare for at give os et overblik over, hvad vi skal beskæftige os med. Vi kan bruge Linux's Message of the Day (MOTD) til at automatisere denne adfærd, når vi logger ind på serveren. At bruge standarden /etc/motd er kun godt for statisk indhold, hvilket ikke er det, vi virkelig ønsker, hvis vi vil rapportere den aktuelle tilstand af en MySQL-server.
For at opnå lignende resultat kan vi bruge et simpelt Bash-script til at producere et meningsfuldt MOTD-output for at opsummere vores MySQL/MariaDB-server, for eksempel:
$ 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 Vælg en af MySQL-rollerne, enten en master eller en slave på linje 8 eller 9, og gem scriptet. Dette script kræver MySQL-indstillingsfil for at gemme databasebrugeroplysningerne, så vi skal først oprette det:
$ vim ~/.my.cnf Og tilføj følgende linjer:
[client]
user=root
password='YourRootP4ssw0rd' Erstat adgangskodedelen med den faktiske MySQL root-adgangskode. Anvend derefter eksekverbar tilladelse til scriptet:
$ chmod 755 ~/.motd.sh Test det eksekverbare script, om det producerer det korrekte output eller ej:
$ ~/.motd.sh Hvis outputtet ser godt ud (ingen fejl eller advarsler), skal du tilføje scriptet til ~/.bash_profile, så det automatisk indlæses, når en bruger logger ind:
$ whoami
root
$ echo '~/.motd.sh' >> ~/.bash_profile Log på terminalen igen, og du skulle se noget som dette på masteren:
Mens du er på slaven, skulle du se noget som dette:
Bemærk, at dette script er specifikt skrevet til en simpel MySQL/MariaDB one- tier-slave-replikering. Du er sandsynligvis nødt til at ændre scriptet, hvis du har en mere kompleks opsætning, eller du vil bruge anden MySQL-klyngeteknologi som Galera Cluster, Group Replication eller NDB Cluster. Ideen er at hente databasenodens status og information lige når vi loggede på, så vi er opmærksomme på den aktuelle tilstand af databaseserveren, som vi arbejder på.
Følere og temperatur
Denne del bliver almindeligvis ignoreret af mange SysAdmins. Overvågning af temperaturerne er afgørende, da vi ikke ønsker at få en stor overraskelse, hvis serveren opfører sig uventet ved overophedning. En fysisk server består almindeligvis af hundredvis af elektroniske dele limet sammen i en kasse og er følsomme over for temperaturændringer. En defekt køleblæser kan stige til en CPU-temperatur for at nå dens hårde grænse, hvilket i sidste ende får CPU-uret til at blive droslet ned og påvirker databehandlingens ydeevne som helhed.
Vi kan bruge lm-sensorer pakken til dette formål. For at installere det, skal du blot gøre:
$ yum install lm-sensors # apt-get install lm-sensors for APT Kør derefter sensors-detect-programmet for automatisk at bestemme, hvilke kernemoduler du skal indlæse for at bruge lm_sensors mest effektivt:
$ sensors-detect Besvarer alle spørgsmål (accepter normalt alle de foreslåede svar). Nogle værter som virtuelle maskiner eller containere understøtter ikke dette modul. Sensorer skal virkelig være på værtsniveau (barmetal). Tjek denne liste for at få flere oplysninger.
Kør derefter sensorkommandoen:
$ 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) Ovenstående resultat viser den overordnede CPU-temperatur sammen med hver CPU-kerne. Et andet værktøj, som vi kan bruge til at se den overordnede tilstand af serverkomponenterne, er ipmitool. For at installere skal du blot gøre:
$ yum -y install ipmitool Ved at køre følgende kommando kan vi fortælle den overordnede tilstand af de fysiske komponenter på serveren:
$ 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 Listen er lang, men er selvforklarende, og du bør være i stand til at overskue de overordnede serverkomponenters tilstand. Der kan være tilfælde, hvor nogle af blæserne ikke kører på fuld hastighed, hvilket så øger CPU-temperaturen. Det kan være nødvendigt at udskifte hardware for at løse problemet.
Bemærk, at kernemodulet Intelligent Platform Management Interface (IPMI) kræver, at Baseboard Management Controller (BMC) er aktiveret på bundkortet. Brug dmesg til at bekræfte, om den er tilgængelig:
$ dmesg | grep -i bmc
[ 8.063470] ipmi_si IPI0001:00: Found new BMC (man_id: 0x000000, prod_id: 0x02f3, dev_id: 0x20) Ellers skal du kontrollere serverens BIOS-indstilling, hvis denne controller er deaktiveret.
Det var det for nu. Anden del af denne blogserie vil dække de resterende 5 emner som konfiguration af sikkerhedskopieringsværktøj, stresstest og serverlåsning.