Data

6 abr, 2015

MySQL Utilities – Tarefas administrativas

Publicidade

No último artigo, mostrei ao amigo leitor como configurar de forma muito fácil a replicação GTID entre servidores de bancos de dados MySQL com alguns dos scripts do pacote MySQL Utilities, disponível para download via YUM ou pelo site do MySQL. A parte II sobre Replicação GTID ainda está no forno, mas tive uma oportunidade de executar várias tarefas administrativas em um servidor de produção com alguns outros scripts do MySQL Utilities. Então, resolvi passar este na frente e focar em ajudar o DBA naquelas tarefas executadas no seu dia a dia.

São muitas as possibilidades, vários os scripts, que se encaixam em diversas situações. Lembro que a versão do MySQL Utilities que utilizo na escrita deste artigo é a 1.6.1, que ainda está em desenvolvimento. Neste momento, instalando direto via repositório, a versão disponível é a 1.5.4 que ainda não conta com o mysqlbinlogmove, script que é parte deste artigo.

Nas tarefas administrativas do dia a dia do DBA, várias são aquelas que, para sua execução, é necessário gastar um tempo grande na escrita de certos scripts que considerem diversas necessidades complexas para que nada seja colocado em risco. Mesmo nesses momentos, um ambiente de testes se faz necessário para que tais pedaços de software sejam testados e, assim, validados. A grande vantagem de se utilizar ferramentas que fazem parte do MySQL Utilities é que alguém já escreveu os scripts considerando o maior número de detalhes possível, que são representados por opções passadas como parâmetros e, agora, o que fica por nossa conta é somente rodar os scripts e acertar os ponteiros de diretórios e outros detalhes. Alguns scripts como o mysqldiskusage, que mostro mais abaixo, só precisam se autenticar no mysqld e as informações são exibidas de acordo com algumas opções adicionais que passaremos ao programa.

mysqlbinlogmove

Já trabalhei com muito ambientes em que o administrador de bancos de dados muito atarefado não configurou a variável expire_logs_days para controlar o expurgo automático dos logs binários, ou somente habilitou a geração dos logs por conta da replicação e não se atentou para a quantidade de arquivos de logs que se acumulam no sistema de arquivos, colocando o funcionamento do MySQL em perigo algum momento por falta de espaço em disco. Mesmo naquele momento em que é interessante colocar os logs binários em uma partição ou disco diferente daquele onde residem os dados, para os dois cenários e vários outros, o utilitário mysqlbinlogmove ajuda o DBA a mover os logs binários, seguindo pela alteração manual da variável de ambiente –log-bin e, pronto, os arquivos de log, assim como o arquivo index (importante para manter o controle de leitura dos logs), são colocados em um novo diretório e o MySQL poderá ser reiniciado.

Como fazer isso?

1. Pare o MySQL;
2. Mova os arquivo de log binário com o mysqlbinlogmove;
3. Altere o valor da variável –log-bin no arquivo de configuração;
4. Crie e altere as permissões e o dono do diretório que abrigará os logs;
4. Reinicie o MySQL.

A sequência acima pode ser vista na seguinte listagem:

#: parando o MySQL
[vagrant@mysql01 mysql]$ sudo service mysqld stop
Stopping mysqld:                         [  OK  ]

#: movendo os arquivo de log binário para /opt/binlogs
[vagrant@mysql01 mysql]$ sudo mysqlbinlogmove --binlog-dir=/var/lib/mysql /opt/binlogs/
#
# Moving bin-log files...
# - mysql01-bin.000001
# - mysql01-bin.000002
# - mysql01-bin.000003
# 
#...done. 

#: criando e alterando a permissão do novo dir 
$ sudo mkdir /opt/binlogs && sudo chown -R mysql:mysql /opt/binlogs 

#: alterando --log-bin para /opt/binlogs - edite o arquivo my.cnf 
[mysqld] 
log-bin=/opt/binlogs/mysql01-bin 

#: inicie o mysql 
[vagrant@mysql01 mysql]$ sudo service mysqld start 
Starting mysqld:                             [ OK ]

Para finalizar as alterações, considerando que podemos encontrar alguns bugs ou mesmo problemas na execução dos scripts, confira os arquivos que fora movidos para /opt/binlogs e também, no mysql, envie o comando SHOW MASTER/BINARY LOGS para forçar a leitura deles para, então, nos certificarmos de que está tudo operacional. Querendo saber mais sobre esse utilitário, acesse este link.

#: verificando os arquivos - index e logs
[vagrant@mysql01 binlogs]$ ls -lh
total 16K
-rw-rw---- 1 mysql mysql 1.8K Mar 26 19:25 mysql01-bin.000001
-rw-rw---- 1 mysql mysql  174 Mar 26 19:28 mysql01-bin.000002
-rw-rw---- 1 mysql mysql  151 Mar 26 19:28 mysql01-bin.000003
-rw-rw---- 1 mysql mysql   64 Mar 26 19:28 mysql01-bin.index

#: forçando a leitura dos logs pelo MySQL
mysql> show binary logs;
+--------------------+-----------+
| Log_name           | File_size |
+--------------------+-----------+
| mysql01-bin.000001 |       151 |
| mysql01-bin.000002 |       174 |
| mysql01-bin.000003 |       151 |
+--------------------+-----------+
3 rows in set (0.00 sec)

Se o ambiente contar com replicação, faça os testes inserindo dados novos no MASTER e verificando a entrega dos mesmos ao SLAVE. O log binário é um ponto muito crítico, e tomar cuidado com alterações desse tipo é bastante interessante para não perder dados, nem deixar o MySQL sem direções ao não encontrar os logs que ele procura lendo o arquivo index – nesse caso, mysql01-bin.index.

mysqldiskusage

Este utilitário é bem interessante, já que o administrador de bancos de dados poderá monitorar exatamente o tamanho que cada banco de dados consome, além de ter ciência do espaço consumido por cada arquivo como redo logs, logs binários e outros. Várias opções podem ser utilizadas desde a formatação dos dados na tela do terminal até a geração de dados no formato CSV, tab delimited e vertical. O padrão é grid que exibe as informação no formato com o qual estamos acostumados a utilizar. Abaixo executo o mysqldiskusage em um servidor pequeno, com poucos bancos de dados somente para ilustrar sua utilização. Mais informações sobre esse utilitário estão disponíveis aqui.

[vagrant@mysql01 binlogs]$ sudo mysqldiskusage --server=root:123456@localhost:3306:/var/lib/mysql/mysql.sock --all
WARNING: Using a password on the command line interface can be insecure.
# Source on localhost: ... connected.
# Database totals:
+---------------------+------------+
| db_name             |     total  |
+---------------------+------------+
| mysql               | 1,577,981  |
| performance_schema  | 489,543    |
| wb                  | 127,403    |
+---------------------+------------+

Total database disk usage = 2,194,927 bytes or 2.09 MB

# Log information.
# The general_log is turned off on the server.
# The slow_query_log is turned off on the server.
+-------------+---------+
| log_name    |   size  |
+-------------+---------+
| mysqld.log  | 30,088  |
+-------------+---------+

Total size of logs = 30,088 bytes or 29.38 KB

# Binary log information:
Current binary log file = mysql01-bin.000040
+---------------------+-------+
| log_file            | size  |
+---------------------+-------+
| mysql01-bin.000001  | 1825  |
| mysql01-bin.000002  | 570   |
| mysql01-bin.000003  | 240   |
| mysql01-bin.000004  | 240   |
| mysql01-bin.000005  | 240   |
| mysql01-bin.000006  | 240   |
| mysql01-bin.000007  | 240   |
| mysql01-bin.000008  | 240   |
| mysql01-bin.000009  | 240   |
| mysql01-bin.000010  | 240   |
| mysql01-bin.000011  | 240   |
| mysql01-bin.000012  | 240   |
| mysql01-bin.000013  | 240   |
| mysql01-bin.000014  | 240   |
| mysql01-bin.000015  | 240   |
| mysql01-bin.000016  | 240   |
| mysql01-bin.000017  | 240   |
| mysql01-bin.000018  | 240   |
| mysql01-bin.000019  | 240   |
| mysql01-bin.000020  | 240   |
| mysql01-bin.000021  | 240   |
| mysql01-bin.000022  | 240   |
| mysql01-bin.000023  | 240   |
| mysql01-bin.000024  | 240   |
| mysql01-bin.000025  | 240   |
| mysql01-bin.000026  | 240   |
| mysql01-bin.000027  | 240   |
| mysql01-bin.000028  | 240   |
| mysql01-bin.000029  | 240   |
| mysql01-bin.000030  | 240   |
| mysql01-bin.000031  | 240   |
| mysql01-bin.000032  | 240   |
| mysql01-bin.000033  | 240   |
| mysql01-bin.000034  | 240   |
| mysql01-bin.000035  | 240   |
| mysql01-bin.000036  | 240   |
| mysql01-bin.000037  | 240   |
| mysql01-bin.000038  | 240   |
| mysql01-bin.000039  | 240   |
| mysql01-bin.000040  | 191   |
| mysql01-bin.index   | 1248  |
+---------------------+-------+

Total size of binary logs = 12,714 bytes or 12.42 KB

# Relay log information:
Current relay log file = mysqld-relay-bin.000003
+--------------------------+-------+
| log_file                 | size  |
+--------------------------+-------+
| mysqld-relay-bin.000003  | 143   |
| mysqld-relay-bin.000004  | 120   |
| mysqld-relay-bin.index   | 52    |
+--------------------------+-------+

Total size of relay logs = 315 bytes

# InnoDB tablespace information:
+--------------+-------------+
| innodb_file  |       size  |
+--------------+-------------+
| ib_logfile0  | 50,331,648  |
| ib_logfile1  | 50,331,648  |
| ibdata1      | 12,582,912  |
+--------------+-------------+

Total size of InnoDB files = 113,246,208 bytes or 108.00 MB

#...done.

Muito interessante entender cada parte do log e como o script chega ao final sumarizando todos os valores e números existentes no relatório final. O tamanho total dos logs binários, assim como o tamanho total das estruturas do InnoDB, é exibido aqui e pode ser facilmente assimilado e monitorado pelo DBA. Em um próximo artigo, vou mostrar como se importa, exporta e clona servidores de bancos de dados MySQL, além de entregar também o meu artigo sobre Replicação GTID.