GUOB Tech Day 2017

03 novembro 2014

O que há de novo no MySQL 5.7? (Até agora)



No final de setembro de 2014, foi anunciado o MySQL 5.7.5 Milestone Release. Esta é uma Milestone Release, cujo objetivo é fornecer um build integrado para testes e feedback da comunidade, porém não recomendada para produção. Esse é mais um marco no caminho para a release GA (General Availability) que estará em breve pronta para produção. Também é uma boa demonstração dos investimentos da Oracle no MySQL.


Este post é um resumo do que está disponível até agora nesta release. Durante a leitura, você pode ter uma boa idéia para onde o MySQL está caminhando. Se você se interessar por uma feature específica, consulte mais detalhes nos worklogs públicos (WL # ....) ou bugs registrados, que contém especificações e detalhes de implementação. Ou talvez você prefira apenas olhar para o código-fonte agora disponível no GitHub em github.com/mysql.


A equipe de desenvolvimento do MySQL está mais forte do que nunca. Até setembro de 2014 já implementou 244 worklogs, acrescentou 497 testes e corrigiu 1.263 bugs, contando apenas o trabalho na release 5.7. Há muita informação, por isso este pequeno guia pode ser útil.


Nota: além dos recursos já integrados na release 5.7.5 há outras novidades que podem ser testadas em labs.mysql.com:


Agora vamos às melhorias da release 5.7.5!


Desempenho e Escalabilidade



Desempenho e escalabilidade são áreas prioritárias para a engenharia do MySQL. Com o feedback da comunidade e considerando as tendências em hardware, até agora na 5.7 já temos ótimos resultados na escalabilidade vertical do InnoDB para workloads de leitura e escrita, flushing mais rápido e velocidade na carga de dados em massa (bulk load).


Operações online



Sempre online, esta é a premissa de soluções estado da arte para web. É importante para DBAs ou DevOps a capacidade de tuning e ampliação do sistema de produção, sem paradas para manutenção. Continuando as melhorias da versão 5.6, teremos também online na versão 5.7:
  • Redimensionamento online do InnoDB Buffer Pool (WL # 6117);
  • Truncamento automático de UNDO Logs (WL # 6965) quando tablespaces UNDO separadas foram configuradas - veja também Bug # 1287 relatado por Scott Ellsworth;
  • InnoDB Online Alter Table: RENAME online de índices (WL # 6752, WL # 6555) e redimensionamento de colunas VARCHAR (WL # 6554);
  • Definir filtros de replicação sem reiniciar o servidor (WL # 7057) - contribuição de Davi Arnaut (Bug # 67362) e veja também o artigo de Venkatesh Duggirala "Como Tornar o MySQL Slave Replicação filtros dinâmicos";
  • CHANGE MASTER sem STOP SLAVE (WL # 6120) - veja também o artigo de Shivji Jha "Alterar mestre sem parar completamente escravo".


Melhorias Optimizer e Parser



Muitas coisas interessantes estão acontecendo no componente Otimizador e no Parser, como:
  • novo Otimizador, com modelo de custo para planos de execução, substituindo heurísticas existentes por estimativas que levam em conta novas arquiteturas de hardware (mais memória, SSDs, etc) e melhoram o desempenho geral do MySQL - veja "The MySQL Optimizer Cost Model Project" por Jørgen Loland;;
  • refatoração do Otimizador para separação das fases de análise, otimização e execução, o que permitirá uma evolução muito maior e mais rápida - veja "Refatorando detalhes internos de Prepared Statements no 5.7" por Guilhem Bichot;
  • novo Parser, reescrito para gramáticas mais complexas - veja "Refatoração do Parser SQL no 5.7.4" por Gleb Shchepa;
  • arquitetura em camadas de ambos componentes para facilitar a manutenção e receber melhorias;
  • nova implementação para sistemas geográficos (GIS) baseada no Boost Geometry;
  • EXPLAINS para queries em andamento e saída detalhada em JSON;
  • Melhorias para queries com “UNION ALL”, “IN”, “JOINS” e “GROUP BY”.


InnoDB Full-text Search



O suporte ao Full-text Search para InnoDB foi introduzido na versão 5.6. Agora este recurso ganhou uma maior flexibilidade e otimizações adicionais. Por exemplo, os índices full-text para InnoDB agora suportam um parser externo, assim como MyISAM (WL # 6943). O plugin pode substituir o parser embutido ou pode agir apenas como front-end. Também há hints de otimização que são passados para o InnoDB permitindo descartar parte do processamento de pesquisas full-text. Por exemplo, não para calcular os valores de classificação se não forem necessários (WL # 7123). Saiba mais lendo os posts de Wang Shaohua “InnoDB supports plugin parser in fulltext index” e Matt Lord “Rankings with InnoDB Full-Text Search“.


Mais informações no Performance Schema



O Performance Schema é o componente central da nova estratégia de monitoramento do MySQL. Foi introduzido na versão 5.5, evoluiu muito na 5.6 e continua recebendo melhorias na 5.7. Além de reduzir ainda mais o overhead e footprint (WL # 7802), agora também já temos instrumentados:
  • Locking Metadados (WL # 5879);
  • Operações (WL # 5864);
  • Uso da memória (WL # 3249, WL # 7777);
  • Stored Programs (WL # 5766);
  • Prepared Statements (WL # 5768);
  • SLAVE STATUS (WL # 3656) e;
  • Variáveis ​​de usuário (WL # 6884).
Veja também os posts de Mayank Prasad “Performance Schema implementation Internals: Registering instruments” e “MySQL Performance Schema : Prepared Statements Instrumentation“ sobre estas e outras melhorias.


Suporte ao Fabric



A Oracle anunciou a primeira versão pronta para produção do MySQL Fabric em 27 de maio de 2014, que é um componente externo para gerenciar farms de servidores MySQL e implementar Sharding com InnoDB. Porém, há melhorias no próprio MySQL Server que o time de desenvolvimento está trabalhando para melhorar sharding, failover e gerenciamento de farms de servidores. Alguns exemplos:
  • um novo método no Servidor para limpar o estado da sessão (WL # 6797) - agora é possível para um cliente para fazer um reset da conexão existente, ou seja, limpar o contexto de sessões existentes e liberar recursos;
  • outro novo método no Servidor para modo off line (WL # 3836) - numa atualização de versão, irá desconectar todos os clientes de maneira “suave”, deixando conectados apenas aqueles autorizados a gerenciar o sistema enquanto no modo offline.


Segurança



Há um trabalho contínuo na melhoria da segurança do MySQL, por exemplo:
  • garantir a "segurança por padrão" nas instalações recentes - instalações via pacotes RPM agora cria apenas uma única conta root, 'root' @ 'localhost', gera automaticamente uma senha aleatória para essa conta, e marca a senha como expirada, forçando a sua alteração via comando SET PASSWORD (WL # 6962); este processo de instalação também não cria contas anônimas de usuários, banco de dados de teste, e arquivos de demonstração relacionados (WL # 6977, WL # 6973);
  • uma melhor e mais avançada criptografia de dados (WL # 6781) - veja  “Understand and satisfy your AES encryption needs with 5.6.17“ por Georgi Kodinov;
  • melhor gerenciamento de senha, com rotação e expiração (WL # 7131) - veja “Implementing a password policy in MySQL“ por Todd Farmer;
  • melhor segurança da camada de transporte SSL (WL # 6791), incluindo mysqlbinlog (WL # 7198).


Particionamento



Adicionalmente aos recursos de particionamento na camada SQL, o InnoDB terá particionamento nativo. Este recurso já pode ser testado em labs.mysql.com. Isto irá abrir o caminho para melhores recursos em tabelas particionadas, tais como processamento paralelo de queries, índices full-text, e chaves estrangeiras. Até agora já temos suporte na 5.7 para tabelas particionadas:


Desempenho de tabelas temporárias no InnoDB



No roadmap do 5.7 está a otimização de tabelas temporárias declaradas via SQL e intrínsicas, usando InnoDB. Vários passos nessa direção foram tomados:
  • o primeiro passo foi tornar a criação e remoção de tabelas temporárias uma operação mais leve, evitando a etapa desnecessária de persistir metadados de tabelas temporárias em disco, disparando várias melhorias:
    • criar tabelas temporárias em um tablespace separado (WL # 6560) para que o processo de recuperação de tabelas temporárias seja um único e stateless, sem necessidade de recriá-las na inicialização.
    • foram também removidas persistências desnecessárias para tabelas temporárias (WL # 6469);
    • tabelas temporárias são visíveis apenas na conexã/sessão que foram criadas;
    • DMLs para tabelas temporárias foram otimizados (WL # 6470) removendo operações desnecessárias de logging, change buffering, and locking;
    • um tipo adicional de UNDO log (WL # 6915), não executado no REDO log e residente em um novo e separado tablespace - esses registros UNDO não são necessários durante a recuperação e são utilizados apenas para operações de reversão.
  • o segundo passo foi criar um tipo especial de tabelas temporárias chamadas de "tabelas temporárias intrínsecas" (WL # 7682, WL # 6711):
    • uma tabela temporária intrínseca é como uma tabela temporária normal, mas com propriedades ACID e MVCC relaxadas;
    • o objetivo é apoiar os casos de uso internos de módulos do servidor que devem ser ultra-rápidos, tais como demandas do Otimizador, operações intermediárias, etc.
    • finalmente, o Otimizador agora é capaz de usar "tabelas temporárias intrínsecas" em InnoDB para armazenamento interno (WL # 6711). Historicamente, o Otimizador tem utilizado MyISAM para o armazenamento de tabelas temporárias internas criadas como parte da execução da consulta, porém agora o InnoDB pode ser usado em vez disso, proporcionando melhor desempenho na maioria dos casos de uso e futuramente será o padrão.


Buffer Pool: Dump e Load



O aquecimento do Buffer Pool foi introduzido na versão 5.6 e agora está melhor. Na 5.7 é possível fazer dump apenas das páginas mais quentes do buffer. Também foi diminuído o overhead em operações do usuário durante o load do buffer pool, pois agora acontece em segundo plano (WL # 6504).


Ferramentas



Melhorias diversas foram implementadas nas ferramentas:
  • innochecksum - pode escolher algoritmos de checksum e operar em múltiplos arquivos de tabela ou em vários arquivos da mesma tabela (WL # 6045). Mais detalhes no artigo de Anil Toshniwal "Improving Innochecksum";
  • mysql_upgrade - reescrita total da ferramenta tornando-a mais robusta, mais fácil de manter e mais livre de bugs (WL # 7308); por exemplo, corrige Bug # 65288 relatado por Nicholas Bamber e Bug # 71579 relatado por Florian Weimer.
  • mysqlbinlog - adicionadas opções SSL, permitindo realizar consultas remotas log binário através de conexões seguras(WL # 7198);
  • mysql_secure_installation - reescrito em C/C++ para executar comandos via API C (libmysql) (WL # 6441); eliminou-se a necessidade de armazenar a senha fornecida pelo usuário em um arquivo temporário no sistema de arquivos;
  • mysql_install_db - reescrito em C/C++ para ser utilizável em todas as plataformas, fornecer uma melhor experiência do usuário, adicionar mais funcionalidades e melhorar a segurança.


Contribuições da comunidade



Muitas melhorias são baseadas em contribuições da comunidade, entre elas:
  • Declaração de tempos limite para queries (WL # 6936) - baseia-se numa contribuição apresentada por Davi Arnaut (Bug # 68252) que implementa um limite de tempo do lado do servidor para a execução de SELECTs. Após o período de tempo especificado na query, o comando é descartado sem afetar a sessão/conexão ou os contextos de transação. Mais detalhes no post de Praveen Hulakund “Server-side SELECT statement timeouts“;
  • Locks por usuário (WL # 1159) - permite vários locks no nível de usuário por conexão, não apenas por linha ou tabela. Podem ser utilizados para organizar a exclusão mútua ao acessar algum recurso nos casos em que locks por tabela ou linha não são adequados. Este trabalho O trabalho é baseado em uma contribuição por Konstantin Osipov (Bug # 67806).


Triggers



Adequação dos triggers ao padrão SQL:


IGNORE Clause



A IGNORE clause é uma extensão do padrão SQL no MySQL. Ela foi reimplementada para definir corretamente seu significado para que seja consistente em todos os comandos SQL (WL # 6614). Veja também Bug # 30191, Bug # 49539, Bug # 55421, Bug # 54543, Bug # 54106, Bug # 49534, Bug # 47788, Bug # 46539, e Bug # 46425.


STRICT Mode



O servidor MySQL pode operar em diferentes modos de SQL, dependendo da configuração sql_mode. Tais modos afetam a sintaxe SQL suportada pelo MySQL, além das verificações de validação de dados. Isto torna o MySQL mais flexível e fácil de operar em conjunto com outros bancos de dados. Porém, semelhante ao IGNORE, o STRICT Mode não foi previamente definido com clareza e consistência, e foi fonte de muitos bugs como Bug # 42910, Bug # 5929, Bug # 43880, Bug # 48637, Bug # 5912, e Bug # 5913 . Agora o comportamento do STRICT mode é consistente em todos os comandos SQL suportados (WL # 6891) e é mais seguro utilizá-lo como padrão para todos os mecanismos de armazenamento transacionais (WL # 7764).


MySQL Client e protocolo cliente-servidor



Implementadas melhorias para:
  • enviar comandos do cliente mysql para Syslog (WL # 6788) - opção --syslog para ativar/desativar o registro de informações no Syslog como sudo_user (ou usuário), mysql_user, connection_id, db_server, DB, e consulta entrou em uma sessão interativa. Implementa conformidade de auditoria ao registrar todos os comandos interativos inseridos no prompt mysql para syslog;
  • tracing no cliente mysql (WL # 6226) - permite o rastreamento de eventos de protocolo, como o envio de pacotes para o servidor, receber respostas do servidor e handshakes de autenticação, fornecendo um mecanismo para coletar dados de desempenho sobre as conexões cliente-servidor, a partir da perspectiva do cliente;
  • Estensão do protocolo para enviar informações adicionais ao pacote OK (WL # 4797) - vai evitar situações como, por exemplo, após SET NAMES big5 o servidor assuma que o cliente enviará dados codificados em big5, enquanto o charset do cliente ainda está em latin1;
  • Sinalização para o cliente de notificação sobre mudanças de estado de sessão (WL # 6885) - um possível uso deste recurso é a capacidade de detectar se é possível migrar um contexto de sessão para outra conexão física dentro de um ambiente de load-balancing ou cluster.


Índices Espaciais InnoDB e novas capacidades para GIS



Desde a versão 5.5 o InnoDB é storage engine padrão para MySQL. A base de usuários já fez uma enorme transição para o InnoDB, porém, alguns casos de uso ainda não eram satisfeitos pelo InnoDB, como índexação espacial. Novas aplicações web também acabam demandando mais recursos GIS na medida que dados de localização são obtidos de celulares, sensores, GPS, etc.
O InnoDB agora possui suporte para índices de dados espaciais, sendo que é possível utilizar a sintaxe já existente para MyISAM. Além disso, adiciona propriedades transacionais completas, bem como os níveis de isolamento. Saiba mais no post de Jimmy Yang "InnoDB Spatial Indexes in 5.7.4 LAB release" ou visitando as work logs:
  • GEOMETRY Datatype Support (WL#6455);
  • R-tree Index Support (WL#6968);
  • Support DML Operations for InnoDB R-tree Indexes (WL#6745);
  • Support Predicate Locking for Spatial Indexes (WL#6609);
  • Store the GIS POINT Datatype as a Fixed Length Column Rather Than as a BLOB (WL#6942);
Juntamente com índices espaciais também foram substituídos os algoritmos GIS originais, melhorando consideravelmente o MySQL nesta área. Depois de muitas comparações dos engines de geometria open source disponíveis, foi selecionado o Boost.Geometry. Se esse tópico lhe interessa, veja os posts de Manyi Lu “Why Boost.Geometry in MySQL?“, David Zhao’s “Making Use of Boost Geometry in MySQL GIS“ e Matt Lord “MySQL 5.7 and GIS, an Example“ ou as seguintes work logs:
  • Spatial Relation Check Functions (WL#7220)
  • Geometry Set Operations (WL#7221)
  • Spatial Analysis Functions (WL#7236)
  • WKB Geometry Container (WL#7280)
  • Geohash Encoding and Decoding Functions (WL#7928)
  • GeoJSON Support for GIS (WL#7444)


Replicação Assíncrona e Semi-Síncrona



A replicação do MySQL é talvez o recurso que o tornou sucesso entre os sites mais visitados da web. Nas versões 5.5 e 5.6 foram implementados recursos para facilitar a automação, fornecer a infra-estrutura para novas topologias, aumentar a performance, etc. Na versão 5.7 as melhorias e refinamentos continuam:
  • Non-Blocking SHOW SLAVE STATUS (WL#6402);
  • Add Idempotent Mode to mysqlbinlog (WL#6403);
  • Add a Rewrite-DB Option to mysqlbinlog for ROW Events (WL#6404);
  • Binlog_sender: Do Not Reallocate (WL#7299) - veja também Bug#31932 reportado by Mark Callaghan;
  • Move Status Variables to Replication Performance Schema Tables (WL#7817);
  • Make Master-Slave Syncing Option Independent of the Slave Threads (WL#7796);
  • Optimize GTIDs for Passive Slaves — Store GTIDs in a Table (WL#6559);
  • Waiting for More Transactions to Enter Binlog Group Commit (BGC) Queues (WL#7742).


A replicação semi-síncrona também ganhou melhorias específicas, tais como:
  • Make the Master Wait for More than One Slave to Acknowledge Back (WL#7169);
  • Externalize Transactions Only after ACK is Received (WL#6355);
  • Semi-Sync — Separate ACKs Collector (WL#6630).


A capacidade de ter threads paralelas de replicação por database nos slaves implementadas na 5.6 agora está mais granular (por tabela) (WL # 6314). Veja “MySQL 5.7 Enhanced MTS: configuring slave for Intra-database parallelization“ por Rohit Kalhans. Outras work logs relacionadas são:
  • Ordered Commits (Sequential Consistency) (WL#6813);
  • Support Slave Transaction Retries in Multi-Threaded Slave Mode (WL#6964) e Bug#68465 reportado por Yoshinori Matsunobu.


Outras Melhorias



Ainda há mais melhorias relacionadas ao sistema de logs, diagnósticos e aderência ao padrão SQL:
  • Add Native Support for Syslog on Unixoid Platforms (WL#7793) e Bug#55370 reportado por Kyle Joiner, Simon Mudd e Mark Alff;
  • DTrace Support (WL#7894) - para Oracle Linux 6+;
  • Error Logging — Allow Control of Verbosity (WL#6661, WL#6755) - maior controle de níveis de log (ERROR/WARNING/NOTE) e muda formato para UTC timestamp;
  • Error Reporting — Stacked Diagnostic Areas (WL#6406) - suporte ao GET [STACKED] DIAGNOSTICS definido no padrão SQL;
  • Error Reporting — Most Statements Should Clear the Diagnostic Area (WL#5928) e Bug#35296, Bug#43012, and Bug#49634 - de acordo com padrão SQL;
  • TRUNCATE TABLE Statement Becomes Atomic (WL#6501) - reinicia o id do tablespace e remove fisicamente o arquivo .ibd de maneira atômica;
  • Update_time for InnoDB Tables (WL#6658) e Bug#2681 reportado por Phil Sladen.
  • Proper Connection ID Handling (WL#7293) e Bug#44167 reportado by Jan Kneschke - evita tentativa de reúso de connections IDs já em uso;
  • GB 18030 Chinese Character Set Support (WL#4024).


Conclusão



Como vimos, há muito trabalho em andamento, muitas novidades e melhorias. Esta ainda não é uma release final, portanto ainda teremos mais até o próximo Milestone Release 5.7. Se você está interessado em testar, pode baixar o binário para sua distribuição direto de http://dev.mysql.com/downloads/mysql na aba “Development Releases” ou então dos repositórios oficiais Oracle YUM ou APT. Não deixe de colaborar com a melhoria do MySQL relatando quaisquer erros, inconsistências ou pedidos de melhoria em http://bugs.mysql.com.


Referências:


Um comentário:

Rodrigo Ribeiro disse...

Ótimo post! MySQL só evoluiu desde que a Oracle absorveu o produto!