MariaDB
 sql >> Base de Dados >  >> RDS >> MariaDB

Preparando um servidor MySQL ou MariaDB para produção - Parte dois

No blog anterior, abordamos algumas dicas e truques para preparar um servidor MySQL para uso em produção da perspectiva do administrador do sistema. Este blog é a continuação...

Usar uma ferramenta de backup de banco de dados

Cada ferramenta de backup tem suas próprias vantagens e desvantagens. Por exemplo, o Percona Xtrabackup (ou MariaDB Backup para MariaDB) pode realizar um hot-backup físico sem bloquear os bancos de dados, mas só pode ser restaurado para a mesma versão em outra instância. Enquanto para o mysqldump, é compatível com outras versões principais do MySQL e muito mais simples para backup parcial, embora seja relativamente mais lento durante a restauração se comparado ao Percona Xtrabackup em grandes bancos de dados. O MySQL 5.7 também apresenta o mysqlpump, semelhante ao mysqldump com recursos de processamento paralelo para acelerar o processo de dump.

Não deixe de configurar todas essas ferramentas de backup em seu servidor MySQL, pois elas estão disponíveis gratuitamente e são muito críticas para a recuperação de dados. Como o mysqldump e o mysqlpump já estão incluídos no MySQL 5.7 e posterior, basta instalar o Percona Xtrabackup (ou MariaDB Backup for MariaDB), mas requer alguns preparativos, conforme mostrado nas etapas a seguir:

Primeiro passo

Certifique-se de que a ferramenta de backup e suas dependências estejam instaladas:

$ yum install -y epel-release
$ yum install -y socat pv percona-xtrabackup

Para servidores MariaDB, use o MariaDB Backup:

$ yum install -y socat pv MariaDB-Backup

Passo Dois

Crie o usuário 'xtrabackup' no mestre se ele não existir:

mysql> CREATE USER 'xtrabackup'@'localhost' IDENTIFIED BY 'Km4z9^sT2X';
mysql> GRANT RELOAD, LOCK TABLES, PROCESS, REPLICATION CLIENT ON *.* TO 'xtrabackup'@'localhost';

Etapa Três

Crie outro usuário chamado 'mysqldump' no master se ele não existir. Este usuário será usado para 'mysqldump' e 'mysqlpump':

mysql> CREATE USER 'mysqldump'@'localhost' IDENTIFIED BY 'Km4z9^sT2X';
mysql> GRANT SELECT, SHOW VIEW, EVENT, TRIGGER, LOCK TABLES, RELOAD, REPLICATION CLIENT ON *.* TO 'mysqldump'@'localhost';

Passo Quatro

Adicione as credenciais dos usuários de backup dentro do arquivo de configuração do MySQL sob a diretiva [xtrabackup], [mysqldump] e [mysqlpump]:

$ cat /etc/my.cnf

...

[xtrabackup]
user=xtrabackup
password='Km4z9^sT2X'

[mysqldump]
user=mysqldump
password='Km4z9^sT2X'

[mysqlpump]
user=mysqldump
password='Km4z9^sT2X'

Ao especificar as linhas acima, não precisamos especificar nome de usuário e senha no comando backup, pois a ferramenta de backup carregará automaticamente essas opções de configuração do arquivo de configuração principal.

Certifique-se de que as ferramentas de backup sejam testadas adequadamente antes. Para o Xtrabackup que suporta streaming de backup via rede, isso deve ser testado primeiro para garantir que o link de comunicação possa ser estabelecido corretamente entre o servidor de origem e de destino. No servidor de destino, execute o seguinte comando para que o socat escute a porta 9999 e esteja pronto para aceitar o streaming de entrada:

$ socat -u tcp-listen:9999,reuseaddr stdout 2>/tmp/netcat.log | xbstream -x -C /var/lib/mysql

Em seguida, crie um backup no servidor de origem e transmita-o para a porta 9999 no servidor de destino:

$ innobackupex --socket=/var/lib/mysql/mysql.sock --stream=xbstream /var/lib/mysql/ | socat - TCP4:192.168.0.202:9999

Você deve obter um fluxo contínuo de saída após executar o comando backup. Aguarde até ver a linha 'Completed OK' indicando um backup bem-sucedido.

Com pv, podemos limitar o uso da largura de banda ou ver o progresso como um processo sendo canalizado por ele. Comumente, o processo de streaming saturará a rede se nenhuma limitação estiver habilitada e isso pode causar problemas com outros servidores para interagir com outro no mesmo segmento. Usando pv, podemos acelerar o processo de streaming antes de passá-lo para a ferramenta de streaming como socat ou netcat. O exemplo a seguir mostra que o streaming de backup será limitado em torno de 80 MB/s para conexões de entrada e saída:

$ innobackupex --slave-info --socket=/var/lib/mysql/mysql.sock --stream=xbstream /var/lib/mysql/ | pv -q -L 80m | socat - TCP4:192.168.0.202:9999

O streaming de um backup é comumente usado para preparar um escravo ou armazenar o backup remotamente em outro servidor.

Para mysqldump e mysqlpump, podemos testar com os seguintes comandos:

$ mysqldump --set-gtid-purged=OFF --all-databases
$ mysqlpump --set-gtid-purged=OFF --all-databases

Certifique-se de ver linhas sem erro aparecerem na saída.

Teste de estresse no servidor

O teste de estresse do servidor de banco de dados é importante para entender a capacidade máxima que podemos antecipar para o servidor em particular. Isso se tornará útil quando você estiver se aproximando de limites ou gargalos em um estágio posterior. Você pode usar muitas ferramentas de benchmarking disponíveis no mercado como mysqlslap, DBT2 e sysbench.

Neste exemplo, usamos o sysbench para medir o desempenho máximo do servidor, o nível de saturação e também a temperatura dos componentes durante a execução em um ambiente de alta carga de trabalho de banco de dados. Isso lhe dará uma compreensão básica de quão bom é o servidor e antecipará a carga de trabalho que o servidor pode processar para nosso aplicativo em produção.

Para instalar e configurar o sysbench, você pode compilá-lo da fonte ou instalar o pacote do repositório Percona:

$ yum install -y https://repo.percona.com/yum/percona-release-latest.noarch.rpm
$ yum install -y sysbench

Crie o esquema do banco de dados e o usuário no servidor MySQL:

mysql> CREATE DATABASE sbtest;
mysql> CREATE USER 'sbtest'@'localhost' IDENTIFIED BY 'sysbenchP4ss';
mysql> GRANT ALL PRIVILEGES ON sbtest.* TO [email protected]'localhost';

Gere os dados de teste:

$ sysbench \
/usr/share/sysbench/oltp_common.lua \
--db-driver=mysql \
--mysql-host=localhost \
--mysql-user=sbtest \
--mysql-password=sysbenchP4ss \
--tables=50 \
--table-size=100000 \
prepare

Em seguida, execute o benchmark por 1 hora (3600 segundos):

$ sysbench \
/usr/share/sysbench/oltp_read_write.lua \
--report-interval=2 \
--threads=64 \
--max-requests=0 \
--db-driver=mysql \
--time=3600 \
--db-ps-mode=disable \
--mysql-host=localhost \
--mysql-user=sbtest \
--mysql-password=sysbenchP4ss \
--tables=50 \
--table-size=100000 \
run

Enquanto o teste estiver em execução, use o iostat (disponível no pacote sysstat) em outro terminal para monitorar a utilização do disco, largura de banda, IOPS e espera de E/S:

$ yum install -y sysstat
$ iostat -x 60

avg-cpu:  %user %nice %system %iowait  %steal %idle
          40.55    0.00 55.27    4.18 0.00 0.00

Device:         rrqm/s wrqm/s     r/s w/s rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await svctm  %util
sda               0.19 6.18 1236.23  816.92 61283.83 14112.44    73.44 4.00 1.96 2.83    0.65 0.34 69.29

O resultado acima será impresso a cada 60 segundos. Aguarde até que o teste termine e tire a média de r/s (leituras/segundo), w/s (gravações/segundo), %iowait, %util, rkB/s e wkB/s (largura de banda). Se você estiver vendo uma utilização relativamente baixa de disco, CPU, RAM ou rede, provavelmente precisará aumentar o valor "--threads" para um número ainda maior, para que ele use todos os recursos até o limite.

Considere os seguintes aspectos a serem medidos:

  • Consultas por segundo =resumo do Sysbench após a conclusão do teste em estatísticas SQL -> Consultas -> Por segundo.
  • Latência da consulta =resumo do Sysbench assim que o teste for concluído em Latência (ms) -> 95º percentil.
  • IOPS de disco =média de r/s + w/s
  • Utilização do disco =Média de %util
  • Largura de banda do disco R/W =Média de rkB/s / Média de wkB/s
  • Espera de E/S de disco =Média de %iowait
  • Carga média do servidor =Média de carga média conforme relatado pelo comando top.
  • Uso da CPU do MySQL =Utilização média da CPU conforme relatado pelo comando top.

Com o ClusterControl, você pode facilmente observar e obter as informações acima por meio do painel Nodes Overview, conforme mostrado na captura de tela a seguir:

Além disso, as informações coletadas durante o teste de estresse podem ser usadas para ajustar o MySQL e variáveis ​​InnoDB como innodb_buffer_pool_size, innodb_io_capacity, innodb_io_capacity_max, innodb_write_io_threads, innodb_read_io_threads e também max_connections.

Para saber mais sobre o benchmark de desempenho do MySQL usando o sysbench, confira esta postagem do blog, How to Benchmark Performance of MySQL &MariaDB Using SysBench.

Use uma ferramenta de alteração de esquema on-line

A mudança de esquema é algo inevitável em bancos de dados relacionais. À medida que a aplicação cresce e se torna mais exigente ao longo do tempo, certamente requer alguma alteração na estrutura do banco de dados. Existem algumas operações DDL que reconstruirão a tabela, bloqueando a execução de outras instruções DML e isso pode afetar a disponibilidade do banco de dados se você estiver realizando alterações estruturais em uma tabela enorme. Para ver a lista de bloqueio de operações DDL, confira esta página de documentação do MySQL e procure por operações que tenham "Permits Concurrent DML" =No.

Se você não puder arcar com o tempo de inatividade dos servidores de produção ao realizar a alteração de esquema, provavelmente é uma boa ideia configurar a ferramenta de alteração de esquema online no estágio inicial. Neste exemplo, instalamos e configuramos o gh-ost, uma alteração de esquema online criada pelo Github. O Gh-ost usa o fluxo de log binário para capturar as alterações da tabela e as aplica de forma assíncrona na tabela fantasma.

Para instalar o gh-ost em uma caixa CentOS, basta seguir os seguintes passos:

Primeiro passo

 Baixe o gh-ost mais recente aqui:

$ wget https://github.com/github/gh-ost/releases/download/v1.0.48/gh-ost-1.0.48-1.x86_64.rpm

Passo Dois

Instale o pacote:

$ yum localinstall gh-ost-1.0.48-1.x86_64.rpm

Etapa Três

Crie um usuário de banco de dados para gh-ost se ele não existir e conceda-o com os privilégios apropriados:

mysql> CREATE USER 'gh-ost'@'{host}' IDENTIFIED BY 'ghostP455';
mysql> GRANT ALTER, CREATE, DELETE, DROP, INDEX, INSERT, LOCK TABLES, SELECT, TRIGGER, UPDATE ON {db_name}.* TO 'gh-ost'@'{host}';
mysql> GRANT SUPER, REPLICATION SLAVE ON *.* TO 'gh-ost'@'{host}';

** Substitua {host} e {db_name} por seus valores apropriados. Idealmente, o {host} é um dos hosts escravos que realizarão a alteração do esquema online. Consulte a documentação do gh-ost para obter detalhes.

Passo Quatro

Crie um arquivo de configuração gh-ost para armazenar o nome de usuário e a senha em /root/.gh-ost.cnf:

[client]
user=gh-ost
password=ghostP455

Da mesma forma, você pode ter o Percona Toolkit Online Schema Change (pt-osc) configurado no servidor de banco de dados. A ideia é certificar-se de que você esteja preparado com essa ferramenta primeiro no servidor de banco de dados que provavelmente executará essa operação no futuro.

Utilize o Percona Toolkit

Percona Toolkit é uma coleção de ferramentas avançadas de linha de comando de código aberto, desenvolvidas pela Percona, que são projetadas para executar uma variedade de tarefas de servidor e sistema MySQL, MongoDB e PostgreSQL que são muito difíceis ou complexas para realizar manualmente. Essas ferramentas se tornaram o salvador final, usadas por DBAs em todo o mundo para resolver ou resolver problemas técnicos encontrados em servidores MySQL e MariaDB.

Para instalar o Percona Toolkit, basta executar o seguinte comando:

$ yum install https://repo.percona.com/yum/percona-release-latest.noarch.rpm
$ yum install percona-toolkit

Existem mais de 30 ferramentas disponíveis neste pacote. Alguns deles são projetados especificamente para MongoDB e PostgreSQL. Algumas das ferramentas mais populares para solução de problemas e ajuste de desempenho do MySQL são pt-stalk, pt-mysql-summary, pt-query-digest, pt-table-checksum, pt-table-sync e pt-archiver. Este kit de ferramentas pode ajudar os DBAs a verificar a integridade da replicação do MySQL verificando a consistência dos dados mestre e de réplica, arquivar linhas com eficiência, encontrar índices duplicados, analisar consultas MySQL de logs e tcpdump e muito mais.

O exemplo a seguir mostra a saída de uma das ferramentas (pt-table-checksum) onde ela pode realizar a verificação de consistência de replicação online executando consultas de soma de verificação no mestre, o que produz resultados diferentes em réplicas inconsistentes com o mestre:

$ pt-table-checksum --no-check-binlog-format --replicate-check-only
Checking if all tables can be checksummed ...
Starting checksum ...

Differences on mysql2.local

TABLE CHUNK CNT_DIFF CRC_DIFF CHUNK_INDEX LOWER_BOUNDARY UPPER_BOUNDARY
mysql.proc 1 0 1
mysql.tables_priv 1 0 1
mysql.user 1 1 1

A saída acima mostra que existem 3 tabelas no slave (mysql2.local) que são inconsistentes com o master. Podemos então usar a ferramenta pt-table-sync para corrigir os dados ausentes do mestre ou simplesmente ressincronizar o escravo mais uma vez.

Bloquear o servidor

Finalmente, após a conclusão do estágio de configuração e preparação, podemos isolar o nó do banco de dados da rede pública e restringir o acesso do servidor a hosts e redes conhecidos. Você pode usar firewall (iptables, firewalld, ufw), grupos de segurança, hosts.allow e/ou hosts.deny ou simplesmente desabilitar a interface de rede voltada para a internet se você tiver várias interfaces de rede.

Para iptables, é importante especificar um comentário para cada regra usando o sinalizador '-m comment --comment':

$ iptables -A INPUT -p tcp -s 192.168.0.0/24 --dport 22 -m comment --comment 'Allow local net to SSH port' -j ACCEPT
$ iptables -A INPUT -p tcp -s 192.168.0.0/24 --dport 3306 -m comment --comment 'Allow local net to MySQL port' -j ACCEPT
$ iptables -A INPUT -p tcp -s 192.168.0.0/24 --dport 9999 -m comment --comment 'Allow local net to backup streaming port' -j ACCEPT
$ iptables -A INPUT -p tcp -s 0.0.0.0/0 -m comment --comment 'Drop everything apart from the above' -j DROP

Da mesma forma para o Firewall do Ubuntu (ufw), precisamos definir a regra padrão primeiro e depois podemos criar regras semelhantes para MySQL/MariaDB semelhantes a esta:

$ sudo ufw default deny incoming comment 'Drop everything apart from the above'
$ sudo ufw default allow outgoing comment 'Allow outgoing everything'
$ sudo ufw allow from 192.168.0.0/24 to any port 22 comment 'Allow local net to SSH port'
$ sudo ufw allow from 192.168.0.0/24 to any port 3306 comment 'Allow local net to MySQL port'
$ sudo ufw allow from 192.168.0.0/24 to any port 9999 comment 'Allow local net to backup streaming port'

Ative o firewall:

$ ufw enable

Em seguida, verifique se as regras estão carregadas corretamente:

$ ufw status verbose
Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)

New profiles: skip

To                         Action From
--                         ------ ----
22                         ALLOW IN 192.168.0.0/24             # Allow local net to SSH port
3306                       ALLOW IN 192.168.0.0/24             # Allow local net to MySQL port
9999                       ALLOW IN 192.168.0.0/24             # Allow local net to backup streaming port

Novamente, é muito importante especificar comentários em cada regra para nos ajudar a entender melhor a regra.

Para restrição de acesso remoto ao banco de dados, também podemos usar o servidor VPN, conforme mostrado nesta postagem do blog, Usando OpenVPN para proteger o acesso ao seu cluster de banco de dados na nuvem.

Conclusão

Preparar um servidor de produção obviamente não é uma tarefa fácil, como mostramos nesta série de blogs. Se você está preocupado em estragar tudo, por que não usa o ClusterControl para implantar seu cluster de banco de dados? ClusterControl tem um histórico muito bom na implantação de banco de dados e permitiu mais de 70.000 implantações MySQL e MariaDB para todos os ambientes até o momento.