Es ist äußerst wichtig, einen Produktions-MySQL-Server mit den erforderlichen Paketen und Tools zu installieren und zu konfigurieren, um den Betrieb langfristig reibungslos zu gestalten. Wir haben viele Fälle gesehen, in denen die Fehlerbehebung oder Optimierung eines Produktionsservers (insbesondere eines Servers ohne öffentlichen Internetzugang) im Allgemeinen schwierig ist, da auf dem Server die erforderlichen Tools zur Identifizierung und Lösung des Problems nicht installiert sind.
In dieser zweiteiligen Blogserie zeigen wir Ihnen 9 Tipps und Tricks, wie Sie einen MySQL-Server aus Sicht eines Systemadministrators für den Produktionseinsatz vorbereiten. Alle Beispiele in diesem Blogbeitrag basieren auf unserem Zwei-Knoten-Master-Slave-MySQL-Replikations-Setup, das auf CentOS 7 ausgeführt wird.
Grundlegende Pakete installieren
Nach der Installation von MySQL- oder MariaDB-Client- und -Serverpaketen müssen wir den MySQL/MariaDB-Server mit allen erforderlichen Tools vorbereiten, um alle Verwaltungs-, Verwaltungs- und Überwachungsvorgänge zu bewältigen, die stattfinden werden der Kellner. Wenn Sie vorhaben, den MySQL-Server in der Produktion zu sperren, wird es etwas schwieriger, sie alle ohne Internetverbindung manuell zu installieren.
Einige der wichtigen Pakete, die auf dem MySQL/MariaDB-Server für Linux installiert werden sollten:
- Percona Xtrabackup/MariaDB Backup – Nicht blockierendes physisches Backup des Datenbankservers.
- ntp/ntpdate - Uhrzeit des Synchronisierungsservers.
- pv - Überwacht Daten über eine Pipeline, kann auch zum Drosseln verwendet werden.
- socat oder netcat – Daten-Streaming-Tool, gut für Streaming-Backup.
- net-tools - Eine Sammlung von Netzwerk-Debugging-Tools für Linux.
- bind-utils - Eine Sammlung von DNS-Debugging-Tools für Linux.
- sysstat - Eine Sammlung von Leistungsüberwachungstools für Linux.
- telnet - Telnet-Client, um die Erreichbarkeit des Dienstes zu prüfen.
- mailx/mailutils - MTA-Client.
- openssl - Toolkit für die Protokolle Transport Layer Security (TLS) und Secure Sockets Layer (SSL).
- unzip - Dekomprimierungstool.
- htop - Hostüberwachungstool.
- innotop - MySQL-Überwachungstool.
- vim - Texteditor mit Syntaxhervorhebung (oder ein beliebiger bevorzugter Texteditor).
- python-setuptools - Python-Paketmanager.
- lm_sensors/ipmitool – Um die Temperatur der Serverkomponente zu prüfen. Nur Bare-Metal-Server.
Beachten Sie, dass einige der vorgeschlagenen Pakete nur in nicht standardmäßigen Paketrepositorys wie EPEL für CentOS verfügbar sind. Daher für die YUM-basierte 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 ipmitoolWährend für die APT-basierte Installation:
$ apt-get install ntp pv socat htop innotop vim easy_install mailutils bind-utils sysstat net-tools telnet openssl lm_sensors ipmitoolFür die MySQL-Befehlszeilenschnittstelle können wir ein anderes Tool als den standardmäßigen "mysql"-Befehlszeilenclient wie mycli mit automatischer Vervollständigung und Syntaxhervorhebung verwenden. Um das Paket zu installieren, können wir pip (Python-Paketmanager) verwenden:
$ pip install mycliMit mycli kann man den menschlichen Fehlervektor mit einer besseren Visualisierung beim Umgang mit Produktionsservern reduzieren, wie im folgenden Screenshot gezeigt:
Sinnvolle Shell-Eingabeaufforderung
Dieser Teil sieht auf den ersten Blick unnötig aus, aber er wird Sie wahrscheinlich davor bewahren, dumme Fehler in der Produktion zu machen. Als Mensch neigen wir dazu, Fehler zu machen, besonders wenn wir in intensiven Momenten zerstörerische Befehle ausführen, beispielsweise wenn der Produktionsserver ausgefallen ist.
Sehen Sie sich den folgenden Screenshot an. Standardmäßig sieht die Bash-PS1-Eingabeaufforderung (primäre Eingabeaufforderung) ziemlich langweilig aus:
Eine gute PS1-Eingabeaufforderung sollte deutliche Informationen bereitstellen, um SysAdmins darauf aufmerksam zu machen Umgebung, Server und aktueller Pfad, mit dem sie sich gerade beschäftigen. Infolgedessen wäre man vorsichtiger und wüsste immer, ob es der richtige Pfad/Server/Benutzer ist, um den Befehl auszuführen.
Um dies zu erreichen, suchen Sie die Zeile, die die Konfiguration von PS1 (primäre Eingabeaufforderung) beschreibt, üblicherweise in /etc/bashrc Zeile 41:
[ "$PS1" = "\\s-\\v\\\$ " ] && PS1="[\[email protected]\h \W]\\$ "Und ersetzen Sie es durch diese Zeile:
[ "$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\]]$ "Loggen Sie sich vom Terminal ab und wieder ein. Sie sollten jetzt im Terminal so etwas sehen:
Wie im Screenshot oben gezeigt, der aktuelle Benutzer (blau), server's Hostname (grün), Produktionsebene (fett in roter Farbe mit weißem Hintergrund) zusammen mit dem vollständigen Pfad des aktuellen Verzeichnisses (gelb) bietet eine bessere Zusammenfassung der aktuellen Sitzung, wobei die wichtigen Informationen durch unterschiedliche Farben leicht unterscheidbar sind.
Mit diesem kostenlosen Online-Tool können Sie Ihren Bash-Prompt nach Ihrem Geschmack anpassen.
MOTD
Wenn Sie einen Datenbankcluster mit mehreren Rollen wie MySQL- oder MariaDB-Replikation verwalten, ist es üblich, immer dieses ängstliche Gefühl zu haben, wenn Sie einen der Hosts direkt verwalten, weil wir zusätzliche Überprüfungen durchführen müssen, um zu überprüfen, ob die Knoten, in dem wir uns befinden, ist derjenige, den wir wirklich verwalten möchten. Die Replikationstopologie wird tendenziell komplexer, wenn Ihr Datenbankcluster skaliert wird, und es könnte viele Rollen in einem Cluster geben, wie z>
Es ist viel besser, wenn wir immer eine Zusammenfassung des Datenbankstatus erhalten, wenn wir uns auf diesem bestimmten Server befinden, nur um uns einen Überblick darüber zu geben, womit wir uns befassen werden. Wir können Linux Message of the Day (MOTD) verwenden, um dieses Verhalten zu automatisieren, wenn wir uns beim Server anmelden. Die Verwendung der Standardeinstellung /etc/motd ist nur gut für statische Inhalte, was wir nicht wirklich wollen, wenn wir den aktuellen Zustand eines MySQL-Servers melden wollen.
Um ein ähnliches Ergebnis zu erzielen, können wir ein einfaches Bash-Skript verwenden, um eine aussagekräftige MOTD-Ausgabe zu erzeugen, um unseren MySQL/MariaDB-Server zusammenzufassen, zum Beispiel:
$ 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
fiWählen Sie eine der MySQL-Rollen, entweder Master oder Slave in Zeile 8 oder 9 und speichern Sie das Skript. Dieses Skript benötigt eine MySQL-Optionsdatei, um die Anmeldeinformationen des Datenbankbenutzers zu speichern, also müssen wir sie zuerst erstellen:
$ vim ~/.my.cnfUnd fügen Sie die folgenden Zeilen hinzu:
[client]
user=root
password='YourRootP4ssw0rd'Ersetzen Sie den Passwortteil durch das tatsächliche MySQL-Root-Passwort. Wenden Sie dann die Ausführungsberechtigung auf das Skript an:
$ chmod 755 ~/.motd.shTesten Sie das ausführbare Skript, ob es die richtige Ausgabe erzeugt oder nicht:
$ ~/.motd.shWenn die Ausgabe gut aussieht (keine Fehler oder Warnungen), fügen Sie das Skript in ~/.bash_profile ein, damit es automatisch geladen wird, wenn sich ein Benutzer anmeldet:
$ whoami
root
$ echo '~/.motd.sh' >> ~/.bash_profileMelden Sie sich erneut am Terminal an und Sie sollten auf dem Master so etwas sehen:
Während Sie auf dem Slave sind, sollten Sie so etwas sehen:
Beachten Sie, dass dieses Skript speziell für ein einfaches MySQL/MariaDB-Skript geschrieben wurde. Tier-Master-Slave-Replikation. Sie müssen das Skript wahrscheinlich ändern, wenn Sie ein komplexeres Setup haben oder andere MySQL-Clustering-Technologien wie Galera Cluster, Group Replication oder NDB Cluster verwenden möchten. Die Idee ist, den Status und die Informationen des Datenbankknotens direkt nach der Anmeldung abzurufen, damit wir den aktuellen Status des Datenbankservers kennen, an dem wir arbeiten.
Sensoren und Temperatur
Dieser Teil wird üblicherweise von vielen SysAdmins ignoriert. Die Überwachung der Temperaturen ist entscheidend, da wir keine große Überraschung erleben möchten, wenn sich der Server bei Überhitzung unerwartet verhält. Ein physischer Server besteht üblicherweise aus Hunderten von elektronischen Teilen, die in einer Box zusammengeklebt sind und empfindlich auf Temperaturänderungen reagieren. Ein ausgefallener Lüfter kann die CPU-Temperatur an ihre Grenze bringen, was schließlich dazu führt, dass der CPU-Takt heruntergefahren wird und die Datenverarbeitungsleistung insgesamt beeinträchtigt wird.
Dazu können wir das Paket lm-sensors verwenden. Um es zu installieren, tun Sie einfach:
$ yum install lm-sensors # apt-get install lm-sensors for APTFühren Sie dann das Sensorerkennungsprogramm aus, um automatisch festzustellen, welche Kernelmodule Sie laden müssen, um lm_sensors am effektivsten zu nutzen:
$ sensors-detectBeantwortet alle Fragen (normalerweise akzeptiert man einfach alle vorgeschlagenen Antworten). Einige Hosts wie virtuelle Maschinen oder Container unterstützen dieses Modul nicht. Sensoren müssen sich wirklich auf der Ebene der Hosts (Bare-Metal) befinden. Weitere Informationen finden Sie in dieser Liste.
Führen Sie dann den Sensorbefehl aus:
$ 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)Das obige Ergebnis zeigt die CPU-Gesamttemperatur zusammen mit jedem CPU-Kern. Ein weiteres Tool, mit dem wir den Gesamtzustand der Serverkomponenten anzeigen können, ist ipmitool. Führen Sie zur Installation einfach Folgendes aus:
$ yum -y install ipmitoolDurch Ausführen des folgenden Befehls können wir den Gesamtzustand der physischen Komponenten im Server ermitteln:
$ 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 | okDie Liste ist lang, aber selbsterklärend und Sie sollten in der Lage sein, den Gesamtzustand der Serverkomponenten zu überwachen. Es kann Fälle geben, in denen einige der Lüfter nicht mit voller Geschwindigkeit laufen, was dann die CPU-Temperatur erhöht. Möglicherweise ist ein Austausch der Hardware erforderlich, um das Problem zu beheben.
Beachten Sie, dass das Kernelmodul Intelligent Platform Management Interface (IPMI) erfordert, dass der Baseboard Management Controller (BMC) auf dem Motherboard aktiviert ist. Verwenden Sie dmesg, um zu überprüfen, ob es verfügbar ist:
$ dmesg | grep -i bmc
[ 8.063470] ipmi_si IPI0001:00: Found new BMC (man_id: 0x000000, prod_id: 0x02f3, dev_id: 0x20)Überprüfen Sie andernfalls die BIOS-Einstellung des Servers, ob dieser Controller deaktiviert ist.
Das war es fürs Erste. Teil zwei dieser Blogserie behandelt die verbleibenden 5 Themen wie Backup-Tool-Konfiguration, Belastungstests und Serversperrung.
