É extremamente importante instalar e configurar um servidor MySQL de produção com os pacotes e ferramentas necessários para facilitar as operações a longo prazo. Vimos muitos casos em que a solução de problemas ou o ajuste de um servidor de produção (especialmente um sem acesso público à Internet) geralmente é difícil devido à falta de ferramentas necessárias instaladas no servidor para ajudar a identificar e resolver o problema.
Nesta série de blogs em duas partes, mostraremos 9 dicas e truques sobre como preparar um servidor MySQL para uso em produção da perspectiva do administrador do sistema. Todos os exemplos nesta postagem do blog são baseados em nossa configuração de replicação MySQL de dois nós, mestre-escravo, em execução no CentOS 7.
Instalar Pacotes Essenciais
Após a instalação dos pacotes cliente e servidor MySQL ou MariaDB, precisamos preparar o servidor MySQL/MariaDB com todas as ferramentas necessárias para lidar com todas as operações de administração, gerenciamento e monitoramento que ocorrerão no o servidor. Se você planeja bloquear o servidor MySQL em produção, será um pouco mais difícil instalá-los manualmente sem a conexão com a Internet.
Alguns dos pacotes importantes que devem ser instalados no servidor MySQL/MariaDB para Linux:
- Percona Xtrabackup/MariaDB Backup - Backup físico sem bloqueio do servidor de banco de dados.
- ntp/ntpdate - hora do servidor de sincronização.
- pv - Monitore dados por meio de um pipeline, também pode ser usado para limitação.
- socat ou netcat- Ferramenta de streaming de dados, boa para backup de streaming.
- net-tools - Uma coleção de ferramentas de depuração de rede para Linux.
- bind-utils - Uma coleção de ferramentas de depuração de DNS para Linux.
- sysstat - Uma coleção de ferramentas de monitoramento de desempenho para Linux.
- telnet - cliente Telnet para verificar a acessibilidade do serviço.
- mailx/mailutils - cliente MTA.
- openssl - Kit de ferramentas para os protocolos Transport Layer Security (TLS) e Secure Sockets Layer (SSL).
- descompactar - ferramenta de descompactação.
- htop - Ferramenta de monitoramento de host.
- innotop - ferramenta de monitoramento MySQL.
- vim - Editor de texto com realce de sintaxe (ou qualquer editor de texto preferido).
- python-setuptools - gerenciador de pacotes Python.
- lm_sensors/ipmitool - Para verificar a temperatura do componente do servidor. Apenas servidor bare-metal.
Observe que alguns dos pacotes sugeridos estão disponíveis apenas em repositórios de pacotes não padrão, como EPEL para CentOS. Portanto, para instalação baseada em 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 ipmitoolDurante a instalação baseada em APT:
$ apt-get install ntp pv socat htop innotop vim easy_install mailutils bind-utils sysstat net-tools telnet openssl lm_sensors ipmitoolPara a interface de linha de comando do MySQL, podemos usar outra ferramenta além do cliente de linha de comando padrão "mysql", como mycli, com preenchimento automático e realce de sintaxe. Para instalar o pacote, podemos usar o pip (gerenciador de pacotes Python):
$ pip install mycliCom mycli, pode-se reduzir o vetor de erro humano com uma melhor visualização ao lidar com o servidor de produção, conforme mostrado na captura de tela a seguir:
Prompt de shell significativo
Esta parte parece desnecessária em primeiro lugar, mas provavelmente vai evitar que você cometa erros bobos na produção. Como humanos, estamos propensos a cometer erros, especialmente ao executar comandos destrutivos durante um momento intenso, por exemplo, quando o servidor de produção está inativo.
Dê uma olhada na captura de tela a seguir. Por padrão, o prompt do bash PS1 (prompt primário) parece bem monótono:
Um bom prompt PS1 deve fornecer informações distintas para tornar os SysAdmins mais cientes do ambiente, servidor e caminho atual com os quais eles estão lidando atualmente. Como resultado, seria mais cuidadoso e sempre saberia se está no caminho/servidor/usuário correto para executar o comando.
Para conseguir isso, encontre a linha que descreve a configuração do PS1 (prompt primário), comumente em /etc/bashrc linha 41:
[ "$PS1" = "\\s-\\v\\\$ " ] && PS1="[\[email protected]\h \W]\\$ "E substitua por esta linha:
[ "$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\]]$ "Saia do terminal e faça login novamente. Você deve ver algo assim no terminal agora:
Como mostrado na captura de tela acima, o usuário atual (azul), servidor hostname (verde), nível de produção (negrito na cor vermelha com fundo branco), juntamente com o caminho completo do diretório atual (amarelo) fornece um melhor resumo da sessão atual onde as informações importantes são facilmente distinguíveis com cores diferentes.
Você pode usar esta ferramenta online gratuita para personalizar seu prompt do bash, para se adequar ao seu gosto.
MOD
Se você estiver gerenciando um cluster de banco de dados com várias funções, como replicação MySQL ou MariaDB, é comum sempre ter essa sensação de ansiedade ao administrar diretamente um dos hosts, pois precisamos realizar verificações extras para verificar se o nó em que estamos é aquele que realmente queremos administrar. A topologia de replicação tende a se tornar mais complexa à medida que seu cluster de banco de dados se expande e pode haver muitas funções em um cluster, como mestre intermediário, servidor de log binário, mestre de backup com replicação semi-sincronizada, escravos somente leitura e também servidor de verificação de backup.
Será muito melhor se pudermos obter um resumo do estado do banco de dados sempre que estivermos nesse servidor específico, apenas para nos dar um aviso sobre o que vamos lidar. Podemos utilizar a mensagem do dia (MOTD) do Linux para automatizar esse comportamento sempre que efetuarmos login no servidor. Usar o padrão /etc/motd só é bom para conteúdo estático, que não é o que realmente queremos se quisermos relatar o estado atual de um servidor MySQL.
Para obter resultados semelhantes, podemos usar um script Bash simples para produzir uma saída MOTD significativa para resumir nosso servidor MySQL/MariaDB, por exemplo:
$ 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
fiEscolha uma das funções do MySQL, master ou slave na linha 8 ou 9 e salve o script. Este script requer o arquivo de opções do MySQL para armazenar as credenciais do usuário do banco de dados, então temos que criá-lo primeiro:
$ vim ~/.my.cnfE adicione as seguintes linhas:
[client]
user=root
password='YourRootP4ssw0rd'Substitua a parte da senha pela senha real do MySQL root. Em seguida, aplique a permissão executável ao script:
$ chmod 755 ~/.motd.shTeste o script executável se ele produz a saída correta ou não:
$ ~/.motd.shSe a saída parecer boa (sem erros ou avisos), adicione o script em ~/.bash_profile para que ele seja carregado automaticamente quando um usuário fizer login:
$ whoami
root
$ echo '~/.motd.sh' >> ~/.bash_profileFaça login novamente no terminal e você deverá ver algo assim no mestre:
Enquanto estiver no slave, você deverá ver algo assim:
Observe que este script é escrito especificamente para um simples MySQL/MariaDB one- replicação mestre-escravo de camada. Você provavelmente terá que modificar o script se tiver uma configuração mais complexa ou quiser usar outra tecnologia de cluster do MySQL, como Galera Cluster, Group Replication ou NDB Cluster. A ideia é recuperar o status e as informações do nó do banco de dados assim que fizermos login, para que possamos estar cientes do estado atual do servidor de banco de dados em que estamos trabalhando.
Sensores e temperatura
Esta parte é comumente ignorada por muitos SysAdmins. Monitorar as temperaturas é crucial, pois não queremos ter uma grande surpresa se o servidor se comportar inesperadamente ao superaquecer. Um servidor físico geralmente consiste em centenas de peças eletrônicas coladas em uma caixa e são sensíveis a mudanças de temperatura. Uma ventoinha de resfriamento com falha pode aumentar a temperatura da CPU para atingir seu limite rígido, o que eventualmente faz com que o clock da CPU seja reduzido e afeta o desempenho do processamento de dados como um todo.
Podemos usar o pacote lm-sensors para esta finalidade. Para instalá-lo, basta fazer:
$ yum install lm-sensors # apt-get install lm-sensors for APTEm seguida, execute o programa de detecção de sensores para determinar automaticamente quais módulos do kernel você precisa carregar para usar lm_sensors com mais eficiência:
$ sensors-detectResponde a todas as perguntas (geralmente apenas aceita todas as respostas sugeridas). Alguns hosts, como máquinas virtuais ou contêineres, não suportam este módulo. Os sensores realmente precisam estar no nível dos hosts (bare-metal). Confira esta lista para mais informações.
Em seguida, execute o comando de sensores:
$ 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)O resultado acima mostra a temperatura geral da CPU, juntamente com cada núcleo da CPU. Outra ferramenta que podemos usar para ver o estado geral dos componentes do servidor é o ipmitool. Para instalar, basta fazer:
$ yum -y install ipmitoolAo executar o comando a seguir, podemos informar o estado geral dos componentes físicos no servidor:
$ 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 | okA lista é longa, mas autoexplicativa e você deve ser capaz de supervisionar o estado geral dos componentes do servidor. Pode haver casos em que alguns dos ventiladores não estejam funcionando na velocidade máxima, o que aumenta a temperatura da CPU. A substituição de hardware pode ser necessária para corrigir o problema.
Observe que o módulo de kernel do Intelligent Platform Management Interface (IPMI) requer que o Baseboard Management Controller (BMC) esteja habilitado na placa-mãe. Use dmesg para verificar se está disponível:
$ dmesg | grep -i bmc
[ 8.063470] ipmi_si IPI0001:00: Found new BMC (man_id: 0x000000, prod_id: 0x02f3, dev_id: 0x20)Caso contrário, verifique a configuração do BIOS do servidor se este controlador estiver desabilitado.
Por enquanto é isso. A segunda parte desta série de blogs abordará os 5 tópicos restantes, como configuração da ferramenta de backup, testes de estresse e bloqueio do servidor.
