08 junho 2017

Erro ‘Got an error reading communication packets’ no MySQL

Se uma aplicação cliente se conecta com êxito no MySQL, mas depois desconecta indevidamente ou a conexão é encerrada de maneira inesperada você receberá uma mensagem de erro ‘Got an error reading communication packets’. Para solucionar o problema, primeiro tentamos identificar a causa. Porém, uma dificuldade aqui é que se trata de um erro de comunicação entre cliente e servidor e são várias as possíveis causas.

Sintomas


O MySQL Server vai registrar uma mensagem de conexão abortada no log de erros, algo como ‘[Warning] Aborted connection 9999 to db: 'xxxxxx' user: 'yyyyyy' host:'zzzzzz' (Got an error reading communication packets)’. No MySQL 5.6 você deve configurar log_warnings para 2 ou mais para que essas mensagens sejam registradas. No MySQL 5.7 não é necessário alterar a configuração padrão (log_error_verbosity) para ter estes detalhes. Do lado da aplicação, também é comum aparecer erros ‘Lost connection to MySQL server’.

Outra maneira de verificar o problema é monitorar o valor da variável de status do MySQL Aborted_clients. Ela incrementa toda vez que um erro deste tipo ocorre. Outra variável de status relacionada a problemas de comunicação é Aborted_connects, mas ela será incrementada somente no caso da aplicação cliente falhar ao estabelecer a conexão inicial com o MySQL Server. Uma forma de acompanhar os valores destas variáveis é com o comando SHOW GLOBAL STATUS LIKE 'Aborted%';.

Se você estiver usando o MySQL Enterprise Monitor também receberá alertas relacionados a este problema e poderá acompanhar as conexões abortadas no respectivo gráfico.

Causas


Algumas das principais causas do erro são:

  • A aplicação cliente tem algum bug e não fecha adequadamente as conexões ou não encerra transações corretamente com COMMIT.
  • A aplicação está configurada com algum limite máximo do tempo de conexão e o excede. Por exemplo, no caso do PHP há a opção max_execution_time. Outras linguagens e ambientes têm opções similares.
  • A aplicação cliente foi encerrada abruptamente (crash) no meio de uma transferência de dados.
  • O MySQL está com o valor para a configuração max_allowed_packet muito pequeno. Neste caso, a aplicação cliente também deve receber um erro do tipo ‘packet too large’.
  • O MySQL está configurado com limites muito baixos para wait_timeout ou interactive_timeout (em segundos). Neste caso, a conexão que permanecer no estado SLEEP por um tempo superior ao configurado será interrompida. Você poderá verificar o tempo e estado das conexões com o comando SHOW PROCESSLIST;.
  • A rede é ruim e o MySQL está configurado com limites muito baixos para net_write_timeout e net_read_timeout. Neste caso, se o cliente interromper o recebimento ou envio de resultados de queries acima destes limites, o MySQL Server pode pensar que o cliente está morto e fechar a conexão.
  • Algumas de suas queries podem precisar de mais memória do que a configurada no MySQL Server e/ou não puderam ser concluídas em tempo adequado. Tente identificar se o problema ocorre para queries específicas.
  • Firewalls, proxies, TCP/IP mal configurado,MTU auto discovery sem funcionar, DNS, hubs, switches, cabos defeituosos e outros problemas de rede/ethernet.
  • No Linux, alguns drivers apresentam problemas quando as interfaces de rede estão configuradas em Half Duplex em uma ponto e Full Duplex em outra.
  • Algum problema com a biblioteca de threads que causa interrupções nas leituras.

Solução


Se você conseguir identificar e isolar a causa, a solução será trivial. Porém, nem sempre será fácil. Você pode recorrer aos seguintes procedimentos:

  • Revise as seguintes configurações do MySQL: skip_name_resolve, max_allowed_packet, wait_timeout, interactive_timeout, net_write_timeout e net_read_timeout. Monitore o log de erros e as variáveis de status Aborted% para certificar-se de que o problema diminuiu ou desapareceu. Modifique uma configuração de cada vez e gradualmente.
  • Esse erro usualmente está relacionado às condições da sua rede. Comece certificando-se que não há erros reportados pelas interfaces de rede (ifconfig -a) e depois com ferramentas como tcpdump e netstat. Gere um pacote maior que 1GB com ping enquanto procura por anomalias com tcpdump e netstat.
  • Relacione as mensagens de erro tanto do lado da aplicação cliente quanto do lado do MySQL Server. Prefira usar os Id’s das conexões com o MySQL para fazer esta correlação ao invés do timestamp dos logs. Se puder, faça com que sua aplicação coloque esta informação (CONNECTION_ID()) no log de debug. No MySQL Server veja os Id’s das conexões problemáticas no log de erros. Se estiver trabalhando com versão mais antiga que 5.7, configure log_warnings para maior ou igual a 2.
  • Se for necessário, colete e analise os detalhes das conexões problemáticas. Se você estiver usando o MySQL Enterprise Edition, habilite o Audit Log. Se estiver usando o MySQL Community, use o General Log, mas esteja ciente de que isto pode gerar impacto indesejado na performance, portanto use com cuidado. Com a lista dos Id’s de conexões problemáticas verifique se queries específicas estão relacionadas ao problema. Se for possível isolar tais queries será mais fácil reproduzir e corrigir o problema.
  • Se você tiver acesso ao Suporte da Oracle para MySQL, poderá abrir um chamado e solicitar ajuda para identificar a causa-raíz.


Referências:
https://www.percona.com/blog/2016/05/16/mysql-got-an-error-reading-communication-packet-errors

25 maio 2017

MySQL Performance Tuning: sempre configure o InnoDB Buffer Pool

Se você for um usuário iniciante de MySQL, provavelmente vai esbarrar com a necessidade de fazer algum tuning no servidor para melhorar a performance e vai ficar na dúvida de onde iniciar. Alguns ajustes básicos podem ser antecipados, já no momento da instalação do servidor, sendo o principal innodb_buffer_pool_size.
O InnoDB Buffer Pool é a principal área da memória usada pelo InnoDB, que é o storage engine default do MySQL. O ideal é que haja neste buffer espaço suficiente para os dados "mais quentes". A quantidade de memória que o MySQL vai reservar para o Buffer Pool é controlada pela variável de sistema innodb_buffer_pool_size.

Após a instalação do MySQL, o valor padrão da variável de sistema innodb_buffer_pool_size é de 128 MB (versão 5.7), o que é bem baixo para os hardwares atuais. Você pode verificar qual atual configurado no seu MySQL com o comando:
mysql> SHOW GLOBAL VARIABLES LIKE 'innodb_buffer_pool_size';
+-------------------------+-----------+
| Variable_name           | Value     |
+-------------------------+-----------+
| innodb_buffer_pool_size | 134217728 |
+-------------------------+-----------+
1 row in set (0.00 sec)
Uma boa prática é, logo após a instalação, editar seu arquivo my.cnf (ou my.ini no Windows) e atribuir um valor adequado para a variável de configuração innodb_buffer_pool_size. Muitas pessoas vão recomendar como valor “70% da memória RAM disponível no seu servidor”. Isto é um bom começo caso o servidor seja dedicado. A melhor prática é monitorar o uso do Buffer Pool e ajustar seu tamanho conforme a carga de trabalho específica que você submete ao MySQL. Uma boa ferramenta para fazer isso é o MySQL Enterprise Monitor.
Ajudei recentemente um cliente que tinha um servidor compartilhado entre banco de dados e aplicação. O cliente chegou a configurar innodb_buffer_pool_size, porém o manteve baixo demais. O resultado é que a performance não estava agradando. Foi fácil identificar olhando para o gráfico “InnoDB Buffer Pool” do MySQL Enterprise Monitor:
Veja que a quantidade de memória usada pelo buffer (linha vermelha) era maior que a quantidade de memória alocada (linha verde). Como analogia, pense numa máquina fazendo Swap. Depois que fiz o ajuste para um valor maior que ‘used’, as linhas se inverteram e o banco de dados começou muito mais queries por segundo:
Como o cliente usava o MySQL 5.7, fiz a alteração online (sem reiniciar o servidor) com os comandos:
mysql> SELECT ROUND(1.8*1024*1024*1024);
+---------------------------+
| ROUND(1.8*1024*1024*1024) |
+---------------------------+
|                1932735283 |
+---------------------------+
1 row in set (0.00 sec)
mysql> SET GLOBAL innodb_buffer_pool_size=1932735283;
Query OK, 0 rows affected, 1 warning (0.00 sec)
mysql> SHOW GLOBAL VARIABLES LIKE 'innodb_buffer_pool_size';
+-------------------------+------------+
| Variable_name           | Value      |
+-------------------------+------------+
| innodb_buffer_pool_size | 2013265920 |
+-------------------------+------------+
1 row in set (0.00 sec)
Depois de verificado que a configuração teve o efeito desejado, editei o arquivo my.cnf com o valor ideal.
Interessante notar que houve um pico maior de Queries Por Segundo logo após o ajuste (mais de 300 QPS). O valor ‘used’ do Buffer Pool também chegou em certo momento a superar novamente o valor ‘free’ (em torno de 1.2GB). Contudo, depois de um tempo o sistema estabilizou. A explicação é que havia um contenção no sistema e depois que eliminamos o gargalo o sistema levou um tempo para estabilizar, porém, uma vez estabilizado (em torno de 200 QPS), manteve uma boa quantidade de Buffer Pool livre.
Portanto, algumas lições:
  1. Sempre que instalar o MySQL, ajuste o valor de innodb_buffer_pool_size;
  2. Monitore o comportamento do Buffer Pool e faça o tuning de acordo com sua carga de trabalho;
  3. Logo depois do tuning, espere o sistema estabilizar;
  4. Mantenha uma folga no buffer pool, permitindo que o sistema estabilize-se de eventuais momentos de pico de demanda;
  5. Não se esqueça de salvar a configuração no my.cnf ou my.ini.

30 setembro 2016

Migrando Legados para MySQL 5.7 com Query Rewrite Plugin - Parte 2

Moodle 2.3 e MySQL 5.7
No post anterior, vimos o que são os Query Rewrite Plugins, tanto preparse, quanto postparse. Agora é o momento de ver como este recurso pode viabilizar a migração de uma aplicação legada real. Para exemplificar, usaremos uma versão antiga do Moodle que é incompatível com MySQL 5.7. Veremos como implementar um preparse QR plugin.

O legado: Moodle 2.3

Moodle é uma plataforma de aprendizado extremamente popular criada com o LAMP Stack. A versão 2.3 já é bastante antiga e não recebe mais atualizações desde janeiro de 2014.
Ao tentar instalar o Moodle 2.3 com MySQL 5.7, ocorre o erro:
PHP Warning:  mysqli::mysqli(): Headers and client library minor version mismatch. Headers:50550 Library:50631 in /var/www/html/moodle/lib/dml/mysqli_native_moodle_database.php on line 377

Installation
System

Error reading from database

More information about this error

It is usually not possible to recover from errors triggered during installation, you may need to create a new database or use a different database prefix if you want to retry the installation.

Debug info: Unknown system variable 'storage_engine'
SELECT @@storage_engine
[NULL]
Error code: dmlreadexception
Stack trace:
line 407 of /lib/dml/moodle_database.php: dml_read_exception thrown
line 184 of /lib/dml/mysqli_native_moodle_database.php: call to moodle_database->query_end()
line 121 of /lib/ddl/mysql_sql_generator.php: call to mysqli_native_moodle_database->get_dbengine()
line 248 of /lib/ddl/sql_generator.php: call to mysql_sql_generator->getCreateTableSQL()
line 401 of /lib/ddl/database_manager.php: call to sql_generator->getCreateStructureSQL()
line 356 of /lib/ddl/database_manager.php: call to database_manager->install_from_xmldb_structure()
line 1422 of /lib/upgradelib.php: call to database_manager->install_from_xmldb_file()
line 184 of /admin/index.php: call to install_core()
Na base de bugs do Moodle é possível encontrar um bug com a análise do motivo do problema (MDL-50633). Resumidamente o problema ocorre porque o Moodle tenta ler qual o Storage Engine padrão usando a variável de sistema do MySQL @@storage_engine. Esta variável foi renomeada no MySql 5.7 ou superior para @@default_storage_engine.
Uma saída seria atualizar o Moodle, mas isto nem sempre é possível em alguns cenários. Outra seria corrigir esta consulta específica na aplicação. No maravilhoso mundo open source quase sempre podemos contar com esta opção, porém não é o caso de outros softwares de código fechado. Vamos supor que não seja possível mexer na aplicação.
Resta a opção de interceptar os comandos enviados pela aplicação e modificá-los antes que o banco de dados execute-os. Há algumas formas de fazer isso, como por exemplo o MySQL Proxy, porém na maioria dos casos é indesejável adicionar mais um componente na infra-estrutura, principalmente algo que seja um ponto único de falha entre aplicação e banco de dados. E se fosse possível fazer a modificação de comandos online, diretamente no servidor de banco de dados? É exatamente isto que faz um Query Rewrite Plugin!

Tentativa 1: usar um preparse Query Rewrite Plugin

O caminho mais fácil seria usar o plugin Rewriter, apresentado no post anterior, para interceptar a query SELECT @@storage_engine e reescrevê-la para SELECT @@default_storage_engine.
O passo-a-passo é o seguinte:
Passo 1: Instalar o Rewriter plugin:
cd /usr/share/mysql
mysql -uroot -p < install_rewriter.sql
Passo 2: Criar a regra de reescrita:
mysql> INSERT INTO query_rewrite.rewrite_rules ( pattern, pattern_database, replacement ) VALUES ('SELECT @@storage_engine', 'moodle', 'SELECT @@default_storage_engine');
Query OK, 1 row affected (0.02 sec)
Passo 3: Carregar a regra na memória:
mysql> CALL query_rewrite.flush_rewrite_rules();
ERROR 1644 (45000): Loading of some rule(s) failed.
Houve algo errado! Vamos fazer um debug verificando o que o plugin retornou na coluna message da tabela query_rewrite.rewrite_rules:
mysql> SELECT * FROM query_rewrite.rewrite_rules \G

           pattern: SELECT @@storage_engine
  pattern_database: moodle
       replacement: SELECT @@default_storage_engine
           enabled: YES
           message: Parse error in pattern: >>Unknown system variable 'storage_e
ngine'<<
É possível concluir que as variáveis de ambiente são verificadas pelo Banco de Dados antes da etapa de parsing, pois o Rewriter é um postparse QR plugin. Desta forma, teremos que usar um preparse QR plugin.

Tentativa 2: criar um postparse Query Rewrite Plugin

Podemos criar postparse QR plugins customizados, que funcionarão de forma parecida com o rewrite_example mostrado no post anterior.
Para nossa necessidade específica, precisamos apenas de um novo plugin que intercepte a query SELECT @@storage_engine e a reescreva para SELECT @@default_storage_engine antes que ela chegue ao parser.
O rewrite_example é justamente um exemplo de implementação de preparse QR plugin. O seu código-fonte está disponível junto com o código do MySQL 5.7 no GitHub.
Com pequenas modificações, criei um novo plugin para resolver nosso problema, o Rewrite Status Variable Storage Engine, disponível no GitHub. Se usar Linux 64-bit, você pode baixar o plugin já compilado e não precisa preocupar-se com os detalhes de codificação ou processo de compilação.
Desenvolver um plugin para MySQL requer conhecimento em C++, o que pode não ser trivial para alguns leitores. Não trataremos dos detalhes sobre o código-fonte de um novo plugin neste post, talvez em um artigo futuro. Se quiser aprofundar-se no tema, recomendo o ótimo livro Expert MySQL.
Uma vez que você tenha o plugin compilado em forma de biblioteca (arquivos .so no Linux ou .dll no Windows), basta instalá-lo normalmente no MySQL. Se estiver usando Linux 64-bit pode testar usando o seguinte procedimento:
  1. Baixe o plugin compilado rewrite_status_storage_engine.so
  2. Verifique qual seu diretório de plugins no MySQL com o comando SELECT @@plugin_dir e mova o arquivo rewrite_status_storage_engine.so para lá
  3. Certifique-se que o arquivo possui as permissões corretas com chmod 755 rewrite_status_storage_engine.so
  4. Instale o novo plugin normalmente no MySQL com INSTALL PLUGIN rewrite_status_storage_engine SONAME 'rewrite_status_storage_engine.so';
  5. Verifique se o plugin foi instalado com sucesso e está ativo:
    mysql> SHOW PLUGINS \G
    Name: rewrite_status_storage_engine
    Status: ACTIVE
    Type: AUDIT
    Library: rewrite_status_storage_engine.so
    License: GPL
Agora é só confirmar que o erro não ocorre mais:
mysql>  SELECT @@storage_engine;
+--------------------------+
| @@default_storage_engine |
+--------------------------+
| InnoDB                   |
+--------------------------+
1 row in set, 1 warning (0.00 sec)

mysql> SHOW WARNINGS \G
*************************** 1. row ***************************
  Level: Note
   Code: 1105
Message: Query 'SELECT @@storage_engine' rewritten to 'SELECT @@default_storage_
engine' by a query rewrite plugin
1 row in set (0.00 sec)

Seguindo com a instalação do Moodle 2.3

Agora você deve conseguir instalar o Moodle 2.3 com MySQL 5.7 sem erros. Siga os passos do manual do Moodle mantendo o rewrite_status_storage_engine ativo.
Instação Moodle 2.3 com sucesso

Conclusão

Query Rewrite Plugins são bastante poderosos e podem ajudar em migrações evitando alterações na aplicação. Podem ser desenvolvidos plugins cutomizados em C++ ou usar o plugin Rewriter, dependendo da necessidade específica do projeto.
Envie seus comentários e sugestões.

Referências

Migrando Legados para MySQL 5.7 com Query Rewrite Plugin - Parte 1

Uma funcionalidade que pode fazer a diferença e viabilizar projetos de migração de legado para MySQL é a Query Rewrite Plugin. Com ela é possível interceptar comandos que são enviados ao MySQL e modificá-los online, sem a necessidade de alterar a aplicação.
Neste post, vamos entender como utilizar este recurso, com um exemplo real usando Moodle 2.3 no MySQL 5.7.

O que é o Query Rewrite Plugin

A partir do MySQL 5.7.6 há suporte para os Rewrite Plugins, que podem examinar e seletivamente reescrever comandos recebidos pelo servidor antes que sejam executados.
Quando uma instrução é recebido pelo MySQL Server, por exemplo um SELECT * FROM tabela where id = 1, ele passa por um parser que vai validar sintaxe e semântica, entre outros passos. Depois disso, o Otimizador de Consultas entra em ação, gerando e selecionando o melhor plano de execução para a query. Finalmente, o melhor plano é executado e o resultado retornado para o cliente que enviou a instrução.
Execução de Query no MySQL
Plugins Query Rewrite podem ser de dois subtipos:
- preparse: interceptam instruções antes do parser.
- postparse: agem logo depois do parser realizar seu trabalho.

Query Rewrite Plugins disponíveis

No pacote do MySQL Server 5.7 há dois Query Rewrite Plugins já disponíveis:
- rewrite_example: um exemplo de como funciona e como pode ser implementado um preparse Query Rewrite Plugin
- rewriter: um postparse plugin de uso mais genérico, para reescrever queries com SELECT, como veremos a seguir.

Como usar o plugin Rewriter (postparse)

A maneira mais fácil de enteder o funcionamento do Rewriter plugin é testando-o.
Passo 1 - Instale e configure o Rewriter plugin com:
cd /usr/share/mysql
mysql -uroot -p <install_rewriter.sql
Passo 2 - Como um teste simples, crie uma regra para transformar automaticamente SELECT ? em SELECT ? + 1:
mysql> INSERT INTO query_rewrite.rewrite_rules ( pattern, replacement ) VALUES ('SELECT ?', 'SELECT ? + 1');
Query OK, 1 row affected (0.06 sec)

mysql> SELECT * FROM query_rewrite.rewrite_rules\G
*************************** 1. row ***************************
                id: 1
           pattern: SELECT ?
  pattern_database: NULL
       replacement: SELECT ? + 1
           enabled: YES
           message: NULL
    pattern_digest: NULL
normalized_pattern: NULL
1 row in set (0.00 sec)
Passo 3 - Carregue a regra recém criada na memória:
mysql> CALL query_rewrite.flush_rewrite_rules();
Query OK, 0 rows affected (0.06 sec)
Passo 4 - Execute um SELECT:
mysql> SELECT 1;
+-------+
| 1 + 1 |
+-------+
|     2 |
+-------+
1 row in set, 1 warning (0.01 sec)

mysql> SHOW WARNINGS \G
*************************** 1. row ***************************
  Level: Note
   Code: 1105
Message: Query 'SELECT 1' rewritten to 'SELECT 1 + 1' by a query rewrite plugin
1 row in set (0.00 sec)
Você pode desabilitar apenas regras específicas com:
mysql> UPDATE query_rewrite.rewrite_rules SET enabled = 'NO' WHERE id = 1;
Veja que o Rewriter tem a capacidade de reescrever SELECTs. Ele examina instruções SELECT e pode reescrevê-los, com base nas regras de reescrita definidas na tabela query_rewrite.rewrite_rules. Os DBAs usam o plugin manipulando as regras armazenadas nesta tabela. Para efetivar novas regras (alterações na tabela rewrite_rules), o DBA deve chamar a procedure flush_rewrite_rules(), que carrega as regras na memória. Se houver algum erro durante a operação, o plugin o informará através da coluna message.
O plugin adiciona algumas variáveis ​de sistema para configuração:
SHOW GLOBAL VARIABLES LIKE 'rewriter%';
+------------------+-------+
| Variable_name    | Value |
+------------------+-------+
| rewriter_enabled | ON    |
| rewriter_verbose | 1     |
+------------------+-------+
Também são adicionadas variáveis de status com informações sobre sua operação:
SHOW GLOBAL STATUS LIKE 'rewriter%';
+-----------------------------------+-------+
| Variable_name                     | Value |
+-----------------------------------+-------+
| Rewriter_number_loaded_rules      | 1     |
| Rewriter_number_reloads           | 1     |
| Rewriter_number_rewritten_queries | 1     |
| Rewriter_reload_error             | OFF   |
+-----------------------------------+-------+
O Rewriter plugin atuará em instruções SELECT e em Prepared Statements, mas não fará reescritas para SELECTs dentro de Stored Programs ou UDFs.

Testando outro Query Rewrite Plugin (preparse)

O Rewriter é um QR plugin postparse. Isto significa que vai atuar depois do trabalho do parser. Vejamos agora como funciona um QR plugin preparse, que vai modificar a query antes de passar pelo parser:
mysql> INSTALL PLUGIN rewrite_example SONAME 'rewrite_example.so';
Query OK, 0 rows affected (0.01 sec)

mysql> SELECT @@DEFAULT_STORAGE_ENGINE;
+--------------------------+
| @@default_storage_engine |
+--------------------------+
| InnoDB                   |
+--------------------------+
1 row in set, 1 warning (0.00 sec)

mysql> SHOW WARNINGS \G
*************************** 1. row ***************************
  Level: Note
   Code: 1105
Message: Query 'SELECT @@DEFAULT_STORAGE_ENGINE' rewritten to 'select @@default_storage_engine' by a query rewrite plugin
*************************** 2. row ***************************
  Level: Note
   Code: 1105
Message: Query 'SHOW WARNINGS' rewritten to 'show warnings' by a query rewrite plugin
2 rows in set, 1 warning (0.00 sec)
Note que a query foi reescrita pelo plugin para letras minúsculas. Este segundo plugin é apenas um exemplo, talvez sem muita aplicação prática. Porém, talvez você necessite realmente criar um preparse QR plugin em algumas situações, como no estudo de caso que veremos na parte 2.

Conclusão

Query Rewrite Plugins podem ter vários usos e são aliados poderosos quando não é possível alterar o código da aplicação. O Rewriter é uma implementação mais genérica, que pode ajudar se for necessário interceptar e reescrever SELECTs.

Referências

01 julho 2016

Mais eventos com MySQL em Julho de 2016

Mais alguns eventos com MySQL (e outros bancos) em SP:

05/07/16 (terça-feira) a partir das 9h00
The Developers Conference São Paulo (TDC 2016)
Trilha Banco de Dados - MySQL como Document Store
Local: Rua Casa do Ator, 275, Vila Olímpia, São Paulo
Mais info e inscrições: http://www.thedevelopersconference.com.br/tdc/2016/saopaulo/trilha-banco-de-dados

30/07/16 (sábado) a partir das 8h00
Alta Disponibilidade no MySQL 5.7
Local: Hotel Blue Tree Morumbi - Av. Roque Petroni Júnior, 1000, São Paulo
Inscrições: http://www.guobtechday2016.eventize.com.br

Até lá!

17 junho 2016

MySQL no Oracle Open World Latin America 2016


Será nos dias 28, 29 e 30 de junho de 2016 o evento Oracle Open World 2016. O time MySQL estará presente com vários conteúdos:

Palestra: Participe da transformação digital com o MySQL [SES11981]
Quarta-feira 29/06/2016 16:45-17:30 Sala Mezanino 13

Theater Sessions: MySQL Enterprise Edition
Terça-feira 28/06/2016 17:30-17:50 Theater Infrastructure
Quinta-feira 30/06/2016 17:00-17:20 Theater Infrastructure

Demos (sob demanda):

MySQL Enterprise Monitor
Monitore e otimize o MySQL
Aumente a performance, segurança e disponibilidade do seu MySQL com a ferramenta feita pelos engenheiros desenvolvedores do MySQL para DBAs MySQL.

Oracle Enterprise Manager for MySQL
Integre o MySQL ao Oracle EM
A ferramenta de administração do stack Oracle Enterprise também monitora o MySQL. Entenda as funcionalidades do Oracle EM para MySQL para integrá-lo à sua operação.

MySQL Enterprise - Visão Geral
Surpreenda-se com o MySQL 5.7
O MySQL agora também é NoSQL com suporte à chave-valor e modelo orientado a documentos. Confira estas e outras melhorias em performance, segurança e replicação.

MySQL Transparent Data Encryption
Segurança com criptografia
Cumpra requisitos regulamentares, aumente proteção, privacidade e impeça violações de dados críticos com Criptografia Transparente de Dados (TDE) para MySQL Enterprise.

MySQL Security Features - Audit and Authentication
Auditoria e autenticação
Implemente auditoria e autenticação externa em repositórios LDAP com plugins do MySQL Enterprise Edition.

MySQL High Availability Options
Opções de Alta Disponibilidade
O MySQL conta com diversas opções de Alta Disponibilidade. Entenda vantagens e desvantagens de cada uma de acordo com seu cenário de uso.

MySQL Cluster Carrier Grade Edition
Edição do MySQL NDB Cluster
MySQL Cluster é um banco de dados transacional que combina a flexibilidade do relacional SQL full-ACID, interfaces NoSQL, alta disponibilidade e alto desempenho.

MySQL Enterprise Backup
Backups à quente para MySQL
O MySQL Enterprise Backup é o equivalente ao Oracle RMAN para MySQL, com tempos muito menores de backup e restore quando comparado com o mysqldump.

MySQL with NoSQL
Chave-valor e Documentos MySQL
O MySQL é o banco de dados relacional Open Source mais popular do mundo e agora também é NoSQL, com suporte à chave-valor e modelo orientado a documentos.

Nos vemos lá!

18 maio 2016

Monitorando Amazon RDS com MySQL Enterprise Monitor



Neste post mostrarei como fazer o monitoramento avançado de uma instância MySQL no serviço Amazon RDS usando o MySQL Enterprise Monitor.


A Amazon hoje é o principal fornecedor de cloud pública do mercado. Entre seus diversos serviços está o famoso Amazon RDS (Relational Database Service), que facilita as tarefas de configurar, operar e escalar um banco de dados relacional na nuvem, ou seja, trata-se de um DBaaS ou Database as a Service. O primeiro banco de dados disponibilizado pela Amazon no RDS foi o MySQL, apesar de hoje contar com outras opções.


O MySQL Enterprise Monitor (MEM) é uma ferramenta de administração avançada do MySQL Server, permitindo, além do monitoramento e manutenção do histórico de status dos servidores, notificações de potenciais problemas, dicas sobre como corrigí-los, análise de queries, etc. O MEM permite monitorar instâncias do MySQL localmente ou remotamente, como por exemplo num serviço de nuvem como o RDS. Por ser criado e mantido pelo time de engenharia MySQL da Oracle, o MEM é uma das opções mais avançadas de monitoramento disponíveis para MySQL.


Confira uma breve demonstração do MEM monitorando Amazon RDS aqui:



Nota: Para testar o procedimento abaixo, usei o MEM 3.2.1 numa Virtual Machine com Oracle Linux 7. Criei a VM usando o Vagrant e Virtual Box. Você pode utilizar o MEM em distribuições Enterprise Linux, Windows, Solaris ou OS X.


Criando uma instância Amazon RDS



Se você não possui uma instância MySQL no RDS, você pode gratuitamente criar uma para testes. Atualmente a  Amazon disponibiliza instâncias pequenas, mas gratuitas do RDS por 1 ano. Nos testes abaixo, usei uma instância gratuita db.t2.micro com o MySQL 5.6.27.


Instalação do MySQL Enterprise Monitor



O MEM possui 2 componentes: Service Manager e Agent. O Agent coleta os dados de monitoramento diretamente dos hosts e instâncias MySQL e envia para o Service Manager, que consolida as informações de todos hosts e instâncias monitorados. Tipicamente o Agent é instalado no host que o MySQL Server está presente, porém, neste tutorial usaremos o monitoramento remoto, que dispensa a necessidade de instalar o Agent. Portanto, a seguir instalaremos apenas o Service Manager.


  1. Faça o download do MySQL Enterprise Monitor Service Manager em edelivery.oracle.com (se ainda não tiver, você precisará criar uma conta no oracle.com); para este tutorial, você precisará baixar apenas o MySQL Enterprise Monitor Service Manager 3.2.x;
    edelivery_download_mem.png
  2. Descompacte o ZIP e copie o arquivo mysqlmonitor-3*installer.bin para o host onde será instalado o MySQL Enterprise Monitor Service Manager e execute:
    $ sudo mysqlmonitor-3*installer.bin
  3. Siga o passo a passo para instalação. As opções padrão vão funcionar para a maioria dos casos.


Se quiser automatizar esta tarefa, você pode facilmente instalar o MEM com uma única linha de comando (unattended mode). Veja aqui um exemplo de instalação do Service Manager via shellscript.


Nota: O MEM é um software comercial que faz parte do MySQL Enterprise Edition e sua licença para uso em produção deve ser adquirida junto à Oracle. Porém, você pode utilizá-lo em ambiente não-produtivo por 30 dias.


Adicionando uma instância MySQL RDS no MEM



  1. No RDS Dashboard, anote qual seu Endpoint; no meu caso, ficou algo como mysql-rds-test1.xxxxxxxxxxxx.us-west-2.rds.amazonaws.com;
  2. No RDS, certifique-se de permitir que o host do MEM possa acessar a instância; no meu caso, modifiquei o Security Group para aceitar tráfego inbound/outbound do meu IP (CIDR/IP);
  3. Na linha de comando da máquina do MEM, verifique se consegue conectar-se na instância RDS com:
    $ /opt/mysql/enterprise/monitor/mysql/bin/mysql -uroot -p -h<seu_endpoint> -P3306
  4. Aproveite a conexão do passo anterior e crie um database para o MEM na sua instância RDS:
    mysql> CREATE DATABASE mem;
  5. [opcional] Como boa prática, crie um usuário específico de monitoramento na instância RDS. Aproveite a conexão do passo anterior e faça:
    mysql> CREATE USER 'memadmin'@'%' IDENTIFIED BY '<senha_memadmin>';
    mysql> GRANT ALL PRIVILEGES ON `%`.* TO 'memadmin'@'%';
  6. No MEM, menu Dashboards > Add MySQL Instance, crie a conexão remota com sua instância RDS.
    Importante: Para ‘Auto-Create Less Privileged Users’ selecione ‘No’ e na aba ‘Advanced Settings’, campo ‘Inventory Table Schema’ digite ‘mem’ (ou database criado no passo 4).
    mem_add_rds1.png
    mem_add_rds2.png
  7. Se tudo ocorreu bem, você já deve ver a nova instância RDS adicionada no Dashboard.
    mem_add_rds3.png


Query Analyzer e Reports avançados



Para explorar capacidades de monitoramento mais avançadas no MEM, é necessário que o Sys Schema instalado e Performance Schema esteja habilitado. A partir do MySQL 5.6 esse recurso já é habilitado por padrão, porém este não é o caso se você estiver usando configurações padrão da Amazon. Faça o seguinte:
  1. No RDS Dashboard, crie um Parameter Group e edite o parâmetro performance_schema = 1;
  2. No RDS, modifique a instância selecionando em Database Options o novo DB Parameter Group.
  3. No RDS, faça um Reboot da instância para aplicar a nova configuração.
  4. Na linha de comando da máquina do MEM, verifique se o Performance Schema foi habilitado:
    $ /opt/mysql/enterprise/monitor/mysql/bin/mysql -uroot -p -h<seu_endpoint> -P3306
    mysql> SHOW VARIABLES LIKE 'performance_schema';
    +--------------------+-------+
    | Variable_name      | Value |
    +--------------------+-------+
    | performance_schema | ON    |
    +--------------------+-------+
  5. Habilite a coleta de métricas das Queries:
    mysql> UPDATE performance_schema.setup_consumers SET enabled = 'YES' WHERE name = 'statements_digest';
    ...
    mysql> SELECT * FROM performance_schema.setup_consumers WHERE name = 'statements_digest';
    +-------------------+---------+
    | NAME              | ENABLED |
    +-------------------+---------+
    | statements_digest | YES     |
    +-------------------+---------+
  6. Certifique-se de que o ‘sys’ schema está presente:
    mysql> SHOW DATABASES;
    +--------------------+
    | Database           |
    +--------------------+
    | ...                |
    | performance_schema |
    | sys                |
    +--------------------+
    Caso necessário, instale o sys schema disponível em https://github.com/mysql/mysql-sys.
  7. No MEM, verifique se o menu Query Analyzer está funcional.
    mem_qan_rds.png
  8. Verifique também em Reports & Graphs se Processes e File I/O estão funcionais
    mem_reports_rds1.png
    mem_reports_rds2.png


Conclusão



O MySQL Enterprise Monitor pode ser utilizado para monitoramento avançado de uma instância MySQL no serviço Amazon RDS. Estamos limitados ao monitoramento remoto, porém ainda é possível utilizar esta ferramenta para melhor compreensão de eventuais gargalos e notificações pró-ativas de problemas com as instâncias MySQL na nuvem.


Referências