È estremamente importante installare e configurare un server MySQL di produzione con i pacchetti e gli strumenti necessari per semplificare le operazioni a lungo termine. Abbiamo visto molti casi in cui la risoluzione dei problemi o l'ottimizzazione di un server di produzione (soprattutto uno senza accesso a Internet pubblico) è comunemente difficile a causa della mancanza degli strumenti necessari installati sul server per aiutare a identificare e risolvere il problema.
In questa serie di blog in due parti, ti mostreremo 9 suggerimenti e trucchi su come preparare un server MySQL per l'utilizzo in produzione dal punto di vista dell'amministratore di sistema. Tutti gli esempi in questo post del blog si basano sulla nostra configurazione di replica MySQL master-slave a due nodi in esecuzione su CentOS 7.
Installa i pacchetti essenziali
Dopo l'installazione dei pacchetti client e server MySQL o MariaDB, dobbiamo preparare il server MySQL/MariaDB con tutti gli strumenti necessari per far fronte a tutte le operazioni di amministrazione, gestione e monitoraggio che avverranno su il server. Se hai intenzione di bloccare il server MySQL in produzione, sarà un po' più difficile installarli tutti manualmente senza la connessione a Internet.
Alcuni dei pacchetti importanti che dovrebbero essere installati sul server MySQL/MariaDB per Linux:
- Percona Xtrabackup/MariaDB Backup - Backup fisico non bloccante del server del database.
- ntp/ntpdate - Sincronizza l'ora del server.
- pv - Monitora i dati attraverso una pipeline, può essere utilizzato anche per la limitazione.
- socat o netcat- Strumento per lo streaming di dati, ottimo per il backup in streaming.
- net-tools - Una raccolta di strumenti di debug di rete per Linux.
- bind-utils - Una raccolta di strumenti di debug DNS per Linux.
- sysstat - Una raccolta di strumenti di monitoraggio delle prestazioni per Linux.
- telnet - Client Telnet per verificare la raggiungibilità del servizio.
- mailx/mailutils - client MTA.
- openssl - Toolkit per i protocolli Transport Layer Security (TLS) e Secure Sockets Layer (SSL).
- decomprimi - Decomprimi lo strumento.
- htop - Strumento di monitoraggio dell'host.
- innotop - Strumento di monitoraggio MySQL.
- vim - Editor di testo con evidenziazione della sintassi (o qualsiasi editor di testo preferito).
- python-setuptools - Gestore di pacchetti Python.
- lm_sensors/ipmitool - Per controllare la temperatura del componente del server. Solo server bare-metal.
Tieni presente che alcuni dei pacchetti suggeriti sono disponibili solo in repository di pacchetti non predefiniti come EPEL per CentOS. Pertanto, per l'installazione basata su 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 ipmitoolMentre per l'installazione basata su APT:
$ apt-get install ntp pv socat htop innotop vim easy_install mailutils bind-utils sysstat net-tools telnet openssl lm_sensors ipmitoolPer l'interfaccia della riga di comando di MySQL, possiamo usare un altro strumento diverso dal client standard della riga di comando "mysql" come mycli, con il completamento automatico e l'evidenziazione della sintassi. Per installare il pacchetto, possiamo usare pip (gestore di pacchetti Python):
$ pip install mycliCon mycli, è possibile ridurre il vettore di errore umano con una migliore visualizzazione quando si ha a che fare con il server di produzione, come mostrato nella schermata seguente:
Avviso di shell significativo
Questa parte sembra non necessaria in primo luogo, ma probabilmente ti eviterà di commettere errori stupidi nella produzione. Come esseri umani, siamo inclini a commettere errori soprattutto quando eseguiamo comandi distruttivi durante un momento intenso, ad esempio quando il server di produzione è inattivo.
Dai un'occhiata allo screenshot seguente. Per impostazione predefinita, il prompt di bash PS1 (prompt primario) sembra piuttosto noioso:
Un buon prompt PS1 dovrebbe fornire informazioni distinte per rendere gli amministratori di sistema più consapevoli del ambiente, server e percorso corrente con cui hanno a che fare. Di conseguenza, si sarebbe più attenti e si saprebbe sempre se si trova nel percorso/server/utente corretto per eseguire il comando.
Per ottenere ciò, trova la riga che descrive la configurazione di PS1 (prompt primario), comunemente in /etc/bashrc riga 41:
[ "$PS1" = "\\s-\\v\\\$ " ] && PS1="[\[email protected]\h \W]\\$ "E sostituiscilo con questa riga:
[ "$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\]]$ "Esci dal terminale e riaccedi di nuovo. Dovresti vedere qualcosa del genere nel terminale ora:
Come mostrato nella schermata sopra, l'utente corrente (blu), il server hostname (verde), Livello di produzione (grassetto in colore rosso con sfondo bianco), insieme al percorso completo della directory corrente (giallo) fornisce un riepilogo migliore della sessione corrente in cui le informazioni importanti sono facilmente distinguibili con colori diversi.
Puoi utilizzare questo strumento online gratuito per personalizzare il tuo prompt bash, in base ai tuoi gusti.
MOTD
Se gestisci un cluster di database con più ruoli come la replica di MySQL o MariaDB, è comune avere sempre questa sensazione di ansia quando si amministra direttamente uno degli host perché è necessario eseguire ulteriori controlli per verificare che il il nodo in cui ci troviamo è quello che vogliamo veramente amministrare. La topologia di replica tende a diventare più complessa man mano che il cluster di database si espande e potrebbero esserci molti ruoli in un cluster come master intermedio, server binlog, master di backup con replica semi-sincronizzazione, slave di sola lettura e anche server di verifica del backup.
Sarebbe molto meglio se potessimo ottenere un riepilogo dello stato del database ogni volta che ci troviamo in quel particolare server, solo per darci un'idea su cosa ci occuperemo. Possiamo utilizzare il messaggio del giorno (MOTD) di Linux per automatizzare questo comportamento ogni volta che accediamo al server. L'uso dell'impostazione predefinita /etc/motd va bene solo per il contenuto statico, che non è ciò che vogliamo veramente se vogliamo segnalare lo stato corrente di un server MySQL.
Per ottenere risultati simili, possiamo utilizzare un semplice script Bash per produrre un output MOTD significativo per riassumere il nostro server MySQL/MariaDB, ad esempio:
$ 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
fiScegli uno dei ruoli MySQL, master o slave sulla riga 8 o 9 e salva lo script. Questo script richiede il file delle opzioni MySQL per memorizzare le credenziali dell'utente del database, quindi dobbiamo prima crearlo:
$ vim ~/.my.cnfE aggiungi le seguenti righe:
[client]
user=root
password='YourRootP4ssw0rd'Sostituisci la parte relativa alla password con l'effettiva password di root di MySQL. Quindi, applica l'autorizzazione eseguibile allo script:
$ chmod 755 ~/.motd.shVerifica lo script eseguibile se produce o meno l'output corretto:
$ ~/.motd.shSe l'output sembra buono (nessun errore o avviso), aggiungi lo script in ~/.bash_profile in modo che venga caricato automaticamente quando un utente effettua l'accesso:
$ whoami
root
$ echo '~/.motd.sh' >> ~/.bash_profileAccedi nuovamente al terminale e dovresti vedere qualcosa del genere sul master:
Mentre sei sullo slave, dovresti vedere qualcosa del genere:
Nota che questo script è scritto specificamente per un semplice MySQL/MariaDB one- replica master-slave di livello. Probabilmente devi modificare lo script se hai una configurazione più complessa o se desideri utilizzare altre tecnologie di clustering MySQL come Galera Cluster, Group Replication o NDB Cluster. L'idea è di recuperare lo stato del nodo del database e le informazioni subito dopo aver effettuato l'accesso in modo da essere a conoscenza dello stato corrente del server del database su cui stiamo lavorando.
Sensori e temperatura
Questa parte viene comunemente ignorata da molti SysAdmin. Il monitoraggio delle temperature è fondamentale in quanto non vogliamo avere una grande sorpresa se il server si comporta in modo imprevisto in caso di surriscaldamento. Un server fisico è comunemente costituito da centinaia di parti elettroniche incollate insieme in una scatola e sono sensibili alle variazioni di temperatura. Una ventola di raffreddamento guasta potrebbe aumentare la temperatura della CPU fino a raggiungere il suo limite rigido, il che alla fine provoca un rallentamento del clock della CPU e influisce sulle prestazioni di elaborazione dei dati nel loro insieme.
Possiamo usare il pacchetto lm-sensors per questo scopo. Per installarlo, fai semplicemente:
$ yum install lm-sensors # apt-get install lm-sensors for APTQuindi esegui il programma sensors-detect per determinare automaticamente quali moduli del kernel devi caricare per usare lm_sensors nel modo più efficace:
$ sensors-detectRisponde a tutte le domande (di solito accetta tutte le risposte suggerite). Alcuni host come macchine virtuali o container non supportano questo modulo. I sensori devono davvero essere a livello di host (bare-metal). Dai un'occhiata a questo elenco per ulteriori informazioni.
Quindi, esegui il comando sensori:
$ 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)Il risultato sopra mostra la temperatura complessiva della CPU, insieme a ogni suo core della CPU. Un altro strumento che possiamo utilizzare per vedere lo stato generale dei componenti del server è ipmitool. Per installare, fai semplicemente:
$ yum -y install ipmitoolEseguendo il seguente comando, possiamo dire lo stato generale dei componenti fisici nel server:
$ 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 | okL'elenco è lungo ma è autoesplicativo e dovresti essere in grado di controllare lo stato generale dei componenti del server. Potrebbero esserci casi in cui alcune ventole non funzionano alla massima velocità, il che aumenta la temperatura della CPU. Potrebbe essere necessaria la sostituzione dell'hardware per risolvere il problema.
Si noti che il modulo del kernel IPMI (Intelligent Platform Management Interface) richiede l'abilitazione di Baseboard Management Controller (BMC) sulla scheda madre. Usa dmesg per verificare se è disponibile:
$ dmesg | grep -i bmc
[ 8.063470] ipmi_si IPI0001:00: Found new BMC (man_id: 0x000000, prod_id: 0x02f3, dev_id: 0x20)Altrimenti, controlla l'impostazione del BIOS del server se questo controller è disabilitato.
Per ora è tutto. La seconda parte di questa serie di blog tratterà i restanti 5 argomenti come la configurazione dello strumento di backup, gli stress test e il blocco del server.
