sql >> Databasteknik >  >> RDS >> MariaDB

Förbereda en MySQL- eller MariaDB-server för produktion - del ett

Det är oerhört viktigt att installera och konfigurera en MySQL-produktionsserver med nödvändiga paket och verktyg för att jämna ut verksamheten på lång sikt. Vi har sett många fall där felsökning eller justering av en produktionsserver (särskilt en utan offentlig internetåtkomst) ofta är svårt på grund av bristen på nödvändiga verktyg installerade på servern för att identifiera och lösa problemet.

I denna tvådelade bloggserie kommer vi att visa dig 9 tips och tricks om hur du förbereder en MySQL-server för produktionsanvändning ur ett systemadministratörsperspektiv. Alla exempel i det här blogginlägget är baserade på vår tvånods, master-slave MySQL-replikeringsinstallation som körs på CentOS 7.

Installera Essential Packages

Efter installationen av MySQL- eller MariaDB-klient- och serverpaket måste vi förbereda MySQL/MariaDB-servern med alla nödvändiga verktyg för att klara av all administration, hantering och övervakning som kommer att ske på servern. Om du planerar att låsa MySQL-servern i produktion, blir det lite svårare att installera dem alla manuellt utan internetuppkoppling.

Några av de viktiga paketen som bör installeras på MySQL/MariaDB-servern för Linux:

  • Percona Xtrabackup/MariaDB Backup - Icke-blockerande fysisk säkerhetskopiering av databasservern.
  • ntp/ntpdate - synkroniseringsserverns tid.
  • pv - Övervaka data genom en pipeline, kan även användas för strypning.
  • socat eller netcat- Dataströmningsverktyg, bra för streaming backup.
  • net-tools – En samling nätverksfelsökningsverktyg för Linux.
  • bind-utils – En samling DNS-felsökningsverktyg för Linux.
  • sysstat - En samling prestandaövervakningsverktyg för Linux.
  • telnet - Telnet-klient för att kontrollera tjänstens tillgänglighet.
  • mailx/mailutils - MTA-klient.
  • openssl - Toolkit för protokollen Transport Layer Security (TLS) och Secure Sockets Layer (SSL).
  • packa upp - Packa upp verktyget.
  • htop - Värdövervakningsverktyg.
  • innotop - MySQL-övervakningsverktyg.
  • vim - Textredigerare med syntaxmarkering (eller någon föredragen textredigerare).
  • python-setuptools - Python-pakethanterare.
  • lm_sensors/ipmitool - För att kontrollera serverkomponentens temperatur. Bara metallserver.

Observera att några av de föreslagna paketen endast är tillgängliga i icke-standardpaketförråd som EPEL för CentOS. Därför, för YUM-baserad 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

Medan för APT-baserad installation:

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

För MySQL kommandoradsgränssnitt kan vi använda ett annat verktyg än standard "mysql" kommandoradsklient som mycli, med autokomplettering och syntaxmarkering. För att installera paketet kan vi använda pip (Python package manager):

$ pip install mycli

Med mycli kan man reducera vektorn för mänskliga fel med en bättre visualisering när man arbetar med produktionsservern, som visas i följande skärmdump:

Meningsfull skalprompt

Den här delen ser onödig ut i första hand, men den kommer förmodligen att rädda dig från att göra dumma misstag i produktionen. Som människa är vi benägna att göra fel, särskilt när vi kör destruktiva kommandon under ett intensivt ögonblick, till exempel när produktionsservern är nere.

Ta en titt på följande skärmdump. Som standard ser bash PS1-prompten (primär prompt) ganska tråkig ut:

En bra PS1-prompt bör ge distinkt information för att göra SysAdmins mer medvetna om miljö, server och aktuell sökväg som de för närvarande hanterar. Som ett resultat skulle man vara mer försiktig och alltid veta om det är på rätt väg/server/användare för att utföra kommandot.

För att uppnå detta, hitta raden som beskriver PS1-konfigurationen (primär prompt), vanligen i /etc/bashrc rad 41:

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

Och ersätt den med denna rad:

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

Logga ut från terminalen och logga in igen. Du bör se något liknande i terminalen nu:

Som visas på skärmdumpen ovan är den nuvarande användaren (blå), serverns värdnamn (grön), produktionsnivå (fet i röd färg med vit bakgrund), tillsammans med hela sökvägen till den aktuella katalogen (gul) ger en bättre sammanfattning av den aktuella sessionen där den viktiga informationen lätt kan urskiljas med olika färger.

Du kan använda detta kostnadsfria onlineverktyg för att anpassa din bash-prompt efter din smak.

MOTD

Om du hanterar ett databaskluster med flera roller som MySQL eller MariaDB-replikering, är det vanligt att alltid ha denna oroliga känsla när du direkt administrerar en av värdarna eftersom vi behöver utföra extra kontroller för att verifiera att noden som vi är i är den som vi verkligen vill administrera. Replikeringstopologin tenderar att bli mer komplex när ditt databaskluster skalas ut och det kan finnas många roller i ett kluster som mellanliggande master, binlog-server, backup-master med semi-sync replikering, skrivskyddade slavar och även backup-verifieringsserver.

Det kommer att vara mycket bättre om vi kan få en sammanfattning av databastillståndet när vi är på den specifika servern, bara för att ge oss en upplysning om vad vi ska ta itu med. Vi kan använda Linux's Message of the Day (MOTD) för att automatisera detta beteende när vi loggar in på servern. Att använda standarden /etc/motd är bara bra för statiskt innehåll, vilket inte är vad vi egentligen vill ha om vi vill rapportera det aktuella tillståndet för en MySQL-server.

För att uppnå liknande resultat kan vi använda ett enkelt Bash-skript för att producera en meningsfull MOTD-utdata för att sammanfatta vår MySQL/MariaDB-server, till exempel:

$ 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älj en av MySQL-rollerna, antingen en master eller en slav på rad 8 eller 9 och spara skriptet. Det här skriptet kräver MySQL-alternativfil för att lagra användaruppgifterna för databasen, så vi måste skapa den först:

$ vim ~/.my.cnf

Och lägg till följande rader:

[client]
user=root
password='YourRootP4ssw0rd'

Ersätt lösenordsdelen med det faktiska MySQL root-lösenordet. Tillämpa sedan körbar behörighet på skriptet:

$ chmod 755 ~/.motd.sh

Testa det körbara skriptet om det ger rätt utdata eller inte:

$ ~/.motd.sh

Om resultatet ser bra ut (inga fel eller varningar), lägg till skriptet i ~/.bash_profile så att det automatiskt laddas när en användare loggar in:

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

Logga in på terminalen igen och du bör se något sånt här på mastern:

Medan du är på slaven bör du se något sånt här:

Observera att detta skript är specifikt skrivet för en enkel MySQL/MariaDB one- nivå master-slav replikering. Du måste förmodligen modifiera skriptet om du har en mer komplex installation, eller om du vill använda annan MySQL-klustringsteknik som Galera Cluster, Group Replication eller NDB Cluster. Tanken är att hämta databasnodens status och information direkt när vi loggade in så att vi är medvetna om det aktuella tillståndet för databasservern som vi arbetar med.

Sensorer och temperatur

Denna del ignoreras ofta av många systemadministratörer. Övervakning av temperaturerna är avgörande eftersom vi inte vill få en stor överraskning om servern beter sig oväntat vid överhettning. En fysisk server består vanligtvis av hundratals elektroniska delar limmade ihop i en låda och är känsliga för temperaturförändringar. En misslyckad kylfläkt kan spika en CPU-temperatur för att nå sin hårda gräns, vilket så småningom gör att CPU-klockan stryps ner och påverkar databehandlingsprestanda som helhet.

Vi kan använda lm-sensors-paketet för detta ändamål. För att installera det, gör helt enkelt:

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

Kör sedan programmet sensors-detect för att automatiskt avgöra vilka kärnmoduler du behöver ladda för att använda lm_sensors mest effektivt:

$ sensors-detect

Besvarar alla frågor (vanligtvis accepterar du bara alla föreslagna svar). Vissa värdar som virtuella maskiner eller behållare stöder inte denna modul. Sensorer måste verkligen vara på värdnivån (barmetall). Kolla in den här listan för mer information.

Kör sedan sensorkommandot:

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

Resultatet ovan visar den totala CPU-temperaturen, tillsammans med dess varje CPU-kärna. Ett annat verktyg som vi kan använda för att se det övergripande tillståndet för serverkomponenterna är ipmitool. För att installera, gör helt enkelt:

$ yum -y install ipmitool

Genom att köra följande kommando kan vi se det övergripande tillståndet för de fysiska komponenterna i servern:

$ 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

Listan är lång men är självförklarande och du bör kunna övervaka serverkomponenternas övergripande tillstånd. Det kan finnas fall där några av fläktarna inte går på full hastighet vilket då ökar CPU-temperaturen. Maskinvarubyte kan behövas för att åtgärda problemet.

Observera att kärnmodulen Intelligent Platform Management Interface (IPMI) kräver att Baseboard Management Controller (BMC) är aktiverad på moderkortet. Använd dmesg för att verifiera om den är tillgänglig:

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

I annat fall kontrollerar du serverns BIOS-inställning om denna styrenhet är inaktiverad.

Det var allt för nu. Del två av den här bloggserien kommer att täcka de återstående fem ämnena som konfiguration av säkerhetskopieringsverktyg, stresstester och serverlåsning.


  1. Fel syntax nära "GO"

  2. Hur man använder egenskapen IDENTITY() i SQL Server

  3. 4 tips för att ställa in dina SQL Server-varningar

  4. Java-typ för datum/tid när du använder Oracle Date med Hibernate