SlideShare uma empresa Scribd logo
Introdução ao MySQL 5.6
Uma abordagem que lhe possibilitará saber de
todas as novidades e o estado da arte do servidor
de bancos de dados mais popular do mundo!
Wagner Bianchi é especialista em MySQL e outros servidores
de bancos de dados relacionais, como Oracle e SQL Server.
Atualmente é Sales Engineer na empresa norte americana
Percona (www.percona.com) para negócios na América
Latina.
Formado em Gerenciamento de Bancos de Dados, com MBA
em Administração de Empresas pela Fundação Getúlio Vargas
e Pós-Graduando em Bancos de Dados pela Universidade
Gama Filho do Distrito Federal. Possui várias certificações,
entre elas a SCMA, SCMDEV, SCMDBA, SMCDBA e MCDBA.
Autor
Contatos
• E-mail: wagner.bianchi@percona.com
• Skype: wbianchijr
• Twitter: @wagnerbianchijr
MySQL Certification Program
Conteúdo do Workshop
• Arquitetura do servidor de bancos de dados MySQL 5.6;
• MySQL 5.6 INFORMATION_SCHEMA;
• Melhorias no Otimizador de Consultas;
• Melhorias no Storage Engine InnoDB;
• Interface NoSQL com MEMCACHED API;
• Melhorias no particionamento de tabelas (MySQL Partitioning);
• Melhorias em pontos críticos da replicação de dados;
• Melhorias no monitoramento de performance;
Destaques:
• InnoDB Plugin e o suporte ao FullText Search;
• Binlog Group Commit (Replicação de Dados);
Arquitetura do servidor de bancos
de dados MySQL 5.6
Arquitetura MySQL 5.6
Arquitetura MySQL 5.6
• Primeira camada contendo módulos que compõem o
software de gerenciamento dos bancos de dados (parser,
query transformation, query cache, etc);
• Segundo camada contendo os “bocais” para “plugar” os
Storage Engines;
– Possibilidade de lidar com características de armazenamento de
dados;
– Possibilidade de lidar com vários Storage Engines em um mesmo
banco de dados;
– Habilitar e desabilitar Storage Engines;
Arquitetura MySQL 5.6
• Desde a versão anterior, a 5.5, lançada em 2010, o InnoDB
Plugin se tornou o Storage Engine padrão.
– quando você cria uma tabela sem a cláusula ENGINE, cria-
se uma nova tabela InnoDB com suporte à transação,
integridade referencial, FullText Search, logs de transação,
tablespace...
• Para verificar os Storage Engine disponíveis nativos do MySQL,
basta utilizar o comando SHOW ENGINES;
mysql> SHOW ENGINESG
[...]
*************************** 8. row ***************************
Engine: InnoDB
Support: YES
Comment: Supports transactions, row-level locking, and foreign keys
Arquitetura MySQL 5.6
• Controle de logs parte é feito pelo SGBD, parte é feito pelo
Storage Engine – e.g. InnoDB Transaction Logs (ib_logsx);
– Controlados pelo SGBD
• --general-log
• --log-bin (log binário do MySQL - registra atualizações - replicação)
• --slow-query-log (--log-slow-query até versão 5.0);
• --log-error
• --pid-file (caso especial, log para troca de mensagens entre mysqld e SO);
– Controlados pelo Storage Engine (InnoDB)
• ib_logsx, onde x é o número do log, geralmente localizados em /var/lib/mysql
Até a versão 5.5 do MySQL, a soma da capacidade de armazenamento dos arquivos
de log do InnoDB não poderia passar de 4G. Com o MySQL 5.6, esse tamanho foi
ampliado para 12G – quanto maior a capacidade dos arquivos de logs de transação,
mais disponibilidade, maior performance;
Arquitetura MySQL 5.6
• Os Storage Engines mais utilizados do MySQL são o MyISAM e
agora, de longe o mais usado é o InnoDB por suas
características e este utilizam memória da seguinte forma;
– MyISAM
• key_buffer_size para armazenamento de dados de índices (PK);
• read_buffer_size para armazenamento de buffer de dados já recuperados;
• Cache de dados realizado com a ajuda do sistema operacional (very busy!);
– InnoDB
• innodb_buffer_pool_size para armazenamento de índices e dados;
• innodb_buffer_pool_size_awe para armazenamento de metadados;
Arquitetura MySQL 5.6
• MyISAM key buffer/cache:
Arquitetura MySQL 5.6
• MyISAM key buffer/cache status variables:
mysql> show status like 'key%';
+------------------------+--------+
| Variable_name | Value |
+------------------------+--------+
| Key_blocks_not_flushed | 0 |
| Key_blocks_unused | 2 |
| Key_blocks_used | 167893 |
| Key_read_requests | 1560 |
| Key_reads | 178590 |
| Key_write_requests | 1980 |
| Key_writes | 102785 |
+------------------------+--------+
7 rows in set (0.01 sec)
Tuning!
Arquitetura MySQL 5.6
• InnoDB buffer pool:
Arquitetura MySQL 5.6
• InnoDB buffer pool:
– InnoDB mantém logs em memória (buffer) e em disco;
• innodb_log_group_home_dir [ =/var/lib/mysql ]
• Innodb_log_files_in_group = [ 4 ]
• Innodb_log_file_size = [ 768M ]
• innodb_log_buffer_size = 12G # MySQL 5.6 ++
– A quantidade de memória configurada para o parâmetro
acima será alocada logo que o mysqld for iniciado;
– As variáveis acima são parte do conjunto utilizado para
configurar o comportamento dos logs do InnoDB;
Tuning!
Arquitetura MySQL 5.6
MySQL 5.6
INFORMATION_SCHEMA
MySQL 5.6 INFORMATION_SCHEMA
• O INFORMATION_SCHEMA, no MySQL, assim como um
vários outros produtos de bancos de dados, é o dicionário de
dados;
– Dados sobre dados:
• Lista de bancos de dados, Storage Engines, tabelas, colunas, índices;
• Lista de aspectos do “runtime” do servidor de bancos de dados;
– Formado por um conjunto de visões (não podem ser alteradas
diretamente):
• INFORMATION_SCHEMA.SCHEMATA;
• INFORMATION_SCHEMA.TABLES;
• INFORMATION_SCHEMA.TABLE_CONSTRAINTS;
• INFORMATION_SCHEMA.GLOBAL_VARIABLES;
• INFORMATION_SCHEMA.PROFILING;
MySQL 5.6 INFORMATION_SCHEMA
• Com o MySQL 5.6, outras visões próprias para a leitura de
performance do InnoDB foram implementadas;
mysql> show tables like “INNODB_SYS%”;
+--------------------------------------------+
| Tables_in_information_schema (INNODB_SYS%) |
+--------------------------------------------+
| INNODB_SYS_FIELDS |
| INNODB_SYS_INDEXES |
| INNODB_SYS_TABLESTATS |
| INNODB_SYS_COLUMNS |
| INNODB_SYS_FOREIGN_COLS |
| INNODB_SYS_FOREIGN |
| INNODB_SYS_TABLES |
+--------------------------------------------+
7 rows in set (0.00 sec)
MySQL 5.6 INFORMATION_SCHEMA
• Visões para monitoramento de outras features já no MySQL
5.5:
mysql> show tables like 'INNODB%';
+----------------------------------------+
| Tables_in_INFORMATION_SCHEMA (INNODB%) |
+----------------------------------------+
| INNODB_CMP_RESET |
| INNODB_TRX |
| INNODB_CMPMEM_RESET |
| INNODB_LOCK_WAITS |
| INNODB_CMPMEM |
| INNODB_CMP |
| INNODB_LOCKS |
+----------------------------------------+
7 rows in set (0.05 sec)
MySQL 5.6
Otimizador de Consultas
Otimizador de Consultas
• Mudanças consideráveis aconteceram no otimizador de
consultas, que tem suas variáveis que influenciam na hora de
determinar a melhor estratégia de recuperação de dados;
mysql> SELECT @@optimizer_switchG
*************************** 1. row ***************************
@@optimizer_switch: index_merge=on,
index_merge_union=on,
index_merge_sort_union=on,
index_merge_intersection=on,
engine_condition_pushdown=on,
index_condition_pushdown=on,
mrr=on,mrr_cost_based=on
Otimizador de Consultas
• Index Condition Pushdown (ICP):
– Otimizações de recuperação de dados baseadas em índices;
– Operação com suporte à todos os Storage Engines;
– As linhas são recuperadas já com a aplicação do filtro (WHERE);
– Recurso originado em operações com o MySQL Cluster 7.0 ++;
mysql> EXPLAIN SELECT Name FROM City WHERE ID > '2000' AND ID <= 4000G
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: City
type: range
possible_keys: PRIMARY
key: PRIMARY
key_len: 4
ref: NULL
rows: 2160
Extra: Using index condition
1 row in set (0.00 sec)
Otimizador de Consultas
• Multi-Range Read:
– Comportamento padrão do otimizador para o MySQL 5.6;
– InnoDB armazena dados de forma randômica, páginas, blocos and extensões;
– Acesso randômico é ruim para índices secundários (PK+[UNIQUE|KEY]);
– O MRR ou Multi-Range Read possibilita acesso seqüencial aos dados;
• File Sort Optimization:
– Comportamento padrão do otimizador para o MySQL 5.6;
– Recurso interessante para sistemas que precisam “paginar” dados;
– Melhor performance para consultas que utilizam ORDER BY com
coluna não indexada com a cláusula LIMIT;
MySQL 5.6
Storage Engine InnoDB
Storage Engine InnoDB
• Persistent Optimizer Stats:
– O Storage Engine InnoDB, na versão 1.2.2, oferece estatísticas
persistentes para que a recuperação de dados não seja afetada após
um restart do servidor de bancos de dados;
– Este comportamento é controlado pelas seguintes variáveis de
ambiente:
• innodb_analyze_is_persistent [= ON];
• innodb_stats_persistent_sample_pages;
• andinnodb_stats_transient_sample_pages;
– Com o POS ativado, as estatísticas somente serão recomputadas caso
seja rodado explicitamente o comando ANALYZE TABLE;
Storage Engine InnoDB
• Novas tabelas no INFORMATION_SCHEMA:
Utilidade Tabelas
Métricas de utilização INNODB_METRICS
Visão interna de todos
os pontos do InnoDB
INNODB_SYS_TABLES, INNODB_SYS_TABLESTAT,
INNODB_SYS_INDEXES, INNODB_SYS_COLUMNS,
INNODB_SYS_FIELDS,INNODB_SYS_FOREIGN,
e INNODB_SYS_FOREIGN_COLS
Informações sobre o
consumo da área de
memória configurada
para o Buffer Pool
INNODB_BUFFER_PAGE,INNODB_BUFFER_PAGE_LRU
e INNODB_BUFFER_POOL_STATS
Storage Engine InnoDB
• Multi-Threaded Purge:
– Com o MySQL 5.6 o InnoDB passa a ter threads especializadas para o processo
de expurgo de dados, que na verdade é tido como um tipo de garbage
collector, o que evita problemas com performance;
– Tal comportamento é configurado através da variável innodb_purge_threads,
que pode ter valores de 0 (off) até 32, que significa o número de threads que
serão dedicadas ao processo de expurgo;
• Separate Flush Thread:
– Uma novidade no MySQL 5.6, uma thread dedicado à limpeza de páginas
sujas, denominada page_cleaner, trabalhando no mesmo conceito do
Adaptive Flushing;
Storage Engine InnoDB
• Pruning the InnoDB Table Cache:
– Tableas que não são acessadas mais por algum tempo são retiradas da
memória (table_cache_definition) para liberar espaço;
– Um algorítimo de LRU é utilizado para fazer esse controle;
MySQL 5.6
NoSQL com MEMCACHED API
NoSQL com MEMCACHED API
• Com uma crescente utilização de armazenamento NoSQL (Not
Only SQL) e com o surgimento de vários players no mercado:
– MySQL dá acesso NoSQL baseado em MEMCACHED API;
– Acesso a dados diretamente em tabelas controladas pelo InnoDB nativo;
– Persistente, crash-safe, transacional baseado em ACID;
– Oferece aos usuários o melhor dos dois mundos, a utilização de linguagem
SQL para recuperação de dados (tabelas InnoDB) e a performance melhorada
para sistemas que acessam dados diretamente, $key -> $value;
NoSQL com MEMCACHED API
MySQL 5.6
MySQL 5.6 Partitioning Engine
MySQL 5.6 Partitioning Engine
• O particionamento de tabelas:
– Se aplicado com padrões poderá melhorar performance radicalmente;
– Organizar melhorar os dados em partições e em discos diferentes;
– Performance!
• Com o MySQL 5.6:
– Selecionar dados de uma partição diretamente com a função PARTITION();
• SELECT * FROM employees PARTITION (p0, p2);
• DELETE FROM employees PARTITION (p0, p1);
• UPDATE employees PARTITION (p0) SET store_id = 2 WHERE fname = 'Jill';
– Migrar dados entre tabelas com comandos SQL;
• ALTER TABLE e EXCHANGE PARTITION p0 WITH TABLE e2;
MySQL 5.6
MySQL 5.6 Replicação de Dados
Replicação de Dados
• Multi-Threaded Slaves:
– Múltiplas threads no servidor SLAVE podem ser utilizadas para
executar as atualizações que são recuperadas do log binário do
servidor MASTER, aumentando a disponibilidade dos serviços;
– As atualizações replicadas são realizadas em paralelo, e não mais
seqüencial como antes;
• Crash-Safe Slaves:
– Aumento da segurança com base na integridade dos dados em
replicação. Através dos arquivos master.info e relaylog.info, uma
transação poderá ter seu skip automático, evitando uma intervenção
do DBA;
– Maior concentração do DBA e atividades mais estratégicas;
Replicação de Dados
• Replication Checksums:
– Ao replicar dados, um checksum é relaizado para que seja conferido
no seu destino, evitando problemas de corrompimento de pacotes de
dados;
• Time-Delayed Replication:
– A partir do MySQL 5.6, você poderá definir um tempo (em
milissegundos) de quando os dados serão liberados para os servidores
SLAVES.
– Configurado em nível de servidor SLAVE e realizado através da
SQL_THREAD;
• Informational Log Events:
– Melhorias em questões de auditoria através do log binário;
Replicação de Dados
• Remote Binlog Back-up:
– Utilizando a opção --raw, juntamente com a opção --read-from-
remote-server, é possível ler e fazer backup dos logs binários em
outro servidor:
shell> mysqlbinlog --read-from-remote-server --host=host_name --raw /
binlog.000130 binlog.000131 binlog.000132
• Server UUIDs
– Não é mais necessário atribuir um server_id único para cada
servidor dentro da topologia de replicação, uma vez que ao executar o
MySQL 5.6 pela primeira vez, uma arquivo auto.cnf será criado com
um valor único para cada servidor – automaticamente.
– Esta informação estará disponível através do SHOW SLAVE STATUS;
Destaques:
• InnoDB Plugin e o suporte ao FullText Search;
• Binlog Group Commit (Replicação de Dados);
Obrigado!
• E-mail: wagner.bianchi@percona.com
• Skype: wbianchijr
• Twitter: @wagnerbianchijr

Mais conteúdo relacionado

PDF
Sistemas Operacionais - Gnu/Linux Gerenciamento de Arquivos
Luiz Arthur
 
PDF
Guía power bi
Reber Cedano
 
PPTX
Minimax e corte alfa beta
Marcos Thomaz
 
PDF
Sistemas NoSQL, surgimento, características e exemplos
Aricelio Souza
 
PPTX
Data governance
MD Redaan
 
PPTX
Integração Contínua
Jackson Veroneze
 
PPT
01 introducaocaats
Portal_do_Estudante_aud
 
PPT
Aula 04 coneitos de auditoria de sistemas
sorayaNadja
 
Sistemas Operacionais - Gnu/Linux Gerenciamento de Arquivos
Luiz Arthur
 
Guía power bi
Reber Cedano
 
Minimax e corte alfa beta
Marcos Thomaz
 
Sistemas NoSQL, surgimento, características e exemplos
Aricelio Souza
 
Data governance
MD Redaan
 
Integração Contínua
Jackson Veroneze
 
01 introducaocaats
Portal_do_Estudante_aud
 
Aula 04 coneitos de auditoria de sistemas
sorayaNadja
 

Mais procurados (20)

PPTX
Big data aplicado el negocio CRISP-DM
Business Data Scientists
 
PPTX
Banco de Dados - Tipos de Dados
Natanael Simões
 
PDF
Aula 1 - Introdução ao Conteúdo de Banco de Dados
Henrique Nunweiler
 
PPTX
JSP: Introdução Parte 1
Elaine Cecília Gatto
 
PDF
Segurança em banco de dados
Arthur Azevedo
 
PPT
Princípios Fundamentais da Análise de Requisitos
elliando dias
 
PDF
Banco de Dados II Aula 10 - Linguagem de Consulta SQL (SQL Avançada)
Leinylson Fontinele
 
PPTX
Introducción a NoSQL
Cycle-IT
 
PDF
Javascript aula 01 - visão geral
Cristiano Pires Martins
 
PDF
Power BI - Choose your map
Lorenzo Vercellati
 
ODP
Aula01-JavaScript
Jorge Ávila Miranda
 
PDF
Data-Ed: Data Governance Strategies
Data Blueprint
 
PDF
05 DEUS prova o amor de Abraão / 05 god tests abrahams love portuguese
Ping Ponga
 
PDF
Data science
Nauber Gois
 
PDF
Introdução a Gerência de Configuração de Software
Camilo Almendra
 
PDF
Governança de TI - Aula04 - Planejamento Estratégico, Governança de TI e alin...
CEULJI/ULBRA Centro Universitário Luterano de Ji-Paraná
 
ODP
Otimizador de Rotas - PythonBrasil[6]
Luiz Augusto Macêdo Morais
 
PDF
Banco de Dados - MySQL Basico
Rangel Javier
 
PDF
BigQuery best practices and recommendations to reduce costs with BI Engine, S...
Márton Kodok
 
ODP
Aula03 - JavaScript
Jorge Ávila Miranda
 
Big data aplicado el negocio CRISP-DM
Business Data Scientists
 
Banco de Dados - Tipos de Dados
Natanael Simões
 
Aula 1 - Introdução ao Conteúdo de Banco de Dados
Henrique Nunweiler
 
JSP: Introdução Parte 1
Elaine Cecília Gatto
 
Segurança em banco de dados
Arthur Azevedo
 
Princípios Fundamentais da Análise de Requisitos
elliando dias
 
Banco de Dados II Aula 10 - Linguagem de Consulta SQL (SQL Avançada)
Leinylson Fontinele
 
Introducción a NoSQL
Cycle-IT
 
Javascript aula 01 - visão geral
Cristiano Pires Martins
 
Power BI - Choose your map
Lorenzo Vercellati
 
Aula01-JavaScript
Jorge Ávila Miranda
 
Data-Ed: Data Governance Strategies
Data Blueprint
 
05 DEUS prova o amor de Abraão / 05 god tests abrahams love portuguese
Ping Ponga
 
Data science
Nauber Gois
 
Introdução a Gerência de Configuração de Software
Camilo Almendra
 
Governança de TI - Aula04 - Planejamento Estratégico, Governança de TI e alin...
CEULJI/ULBRA Centro Universitário Luterano de Ji-Paraná
 
Otimizador de Rotas - PythonBrasil[6]
Luiz Augusto Macêdo Morais
 
Banco de Dados - MySQL Basico
Rangel Javier
 
BigQuery best practices and recommendations to reduce costs with BI Engine, S...
Márton Kodok
 
Aula03 - JavaScript
Jorge Ávila Miranda
 
Anúncio

Destaque (8)

PDF
Arquitetando sua aplicação de nova geração com MySQL 5.7
Mathias Brem
 
PPT
InnoDB Plugin - II Fórum da Comunidade MySQL
Wagner Bianchi
 
PDF
Introduction to Galera Cluster
Codership Oy - Creators of Galera Cluster
 
PDF
MySQL 5.5 Guide to InnoDB Status
Karwin Software Solutions LLC
 
PDF
Arquitetura e sgbd de um banco de dados
diogocbj
 
PDF
The InnoDB Storage Engine for MySQL
Morgan Tocker
 
PDF
UNIFAL - MySQL Storage Engine - 5.0/5.6
Wagner Bianchi
 
PDF
MySQL partitions tutorial
Giuseppe Maxia
 
Arquitetando sua aplicação de nova geração com MySQL 5.7
Mathias Brem
 
InnoDB Plugin - II Fórum da Comunidade MySQL
Wagner Bianchi
 
Introduction to Galera Cluster
Codership Oy - Creators of Galera Cluster
 
MySQL 5.5 Guide to InnoDB Status
Karwin Software Solutions LLC
 
Arquitetura e sgbd de um banco de dados
diogocbj
 
The InnoDB Storage Engine for MySQL
Morgan Tocker
 
UNIFAL - MySQL Storage Engine - 5.0/5.6
Wagner Bianchi
 
MySQL partitions tutorial
Giuseppe Maxia
 
Anúncio

Semelhante a Introdução ao MySQL 5.6 (20)

PDF
Análise de Performance do MySQL e MariaDB
Saveincloud
 
PDF
WBConsulting, MySQL Performance Tuning Basics
WBConsulting
 
PPTX
MySQL Profiling com Enterprise Monitor
MySQL Brasil
 
PPTX
Otimizando a performance com in-memory no SQL 2016
Luiz Henrique Garetti Rosário
 
PPTX
Novidades do Sql Server 2016
Roberto Fonseca
 
PDF
[Webinar] Performance e otimização de banco de dados MySQL
KingHost - Hospedagem de sites
 
PDF
Novidades do MySQL para desenvolvedores ago15
MySQL Brasil
 
PDF
MySQL - visão geral
Airton Lastori
 
PDF
UNIFAL - MySQL 5.6 - Replicação
Wagner Bianchi
 
PDF
MySQL Alta Performance & Alta Disponibilidade
MySQL Brasil
 
PDF
SGBD - ORACLE - JAVA
ssuser4cf889
 
PDF
Cloud Mysql e MariaDB em alta performance
Saveincloud
 
PDF
MySQL no Windows: implementação eficiente de novas aplicações
MySQL Brasil
 
PDF
MySQL 5.6, o que há de novidade?
MySQL Brasil
 
PDF
MySQL no Windows
MySQL Brasil
 
PDF
Introdução a data warehouse e olap
Flavia Martins Bispo
 
PDF
Introdução a data warehouse e olap
Fernando Palma
 
PDF
UNIFAL - MySQL Logs - 5.0/5.6
Wagner Bianchi
 
PDF
Zabbix FLISOL Campinas 28-04-2012
André Déo
 
PPTX
Sql Server
Sabrina Mariana
 
Análise de Performance do MySQL e MariaDB
Saveincloud
 
WBConsulting, MySQL Performance Tuning Basics
WBConsulting
 
MySQL Profiling com Enterprise Monitor
MySQL Brasil
 
Otimizando a performance com in-memory no SQL 2016
Luiz Henrique Garetti Rosário
 
Novidades do Sql Server 2016
Roberto Fonseca
 
[Webinar] Performance e otimização de banco de dados MySQL
KingHost - Hospedagem de sites
 
Novidades do MySQL para desenvolvedores ago15
MySQL Brasil
 
MySQL - visão geral
Airton Lastori
 
UNIFAL - MySQL 5.6 - Replicação
Wagner Bianchi
 
MySQL Alta Performance & Alta Disponibilidade
MySQL Brasil
 
SGBD - ORACLE - JAVA
ssuser4cf889
 
Cloud Mysql e MariaDB em alta performance
Saveincloud
 
MySQL no Windows: implementação eficiente de novas aplicações
MySQL Brasil
 
MySQL 5.6, o que há de novidade?
MySQL Brasil
 
MySQL no Windows
MySQL Brasil
 
Introdução a data warehouse e olap
Flavia Martins Bispo
 
Introdução a data warehouse e olap
Fernando Palma
 
UNIFAL - MySQL Logs - 5.0/5.6
Wagner Bianchi
 
Zabbix FLISOL Campinas 28-04-2012
André Déo
 
Sql Server
Sabrina Mariana
 

Mais de Wagner Bianchi (18)

PDF
Migrations from PLSQL and Transact-SQL - m18
Wagner Bianchi
 
PDF
Maxscale switchover, failover, and auto rejoin
Wagner Bianchi
 
PDF
Meetup São Paulo, Maxscale Implementação e Casos de Uso
Wagner Bianchi
 
PDF
Escalando o ambiente com MariaDB Cluster (Portuguese Edition)
Wagner Bianchi
 
PDF
NY Meetup: Scaling MariaDB with Maxscale
Wagner Bianchi
 
PDF
Webinar: MariaDB Provides the Solution to Ease Multi-Source Replication
Wagner Bianchi
 
PDF
MySQL Multi-Source Replication for PL2016
Wagner Bianchi
 
PDF
MySQL 5.7 Multi-Source Replication
Wagner Bianchi
 
PDF
UNIFAL - MySQL Transações - 5.0/5.6
Wagner Bianchi
 
PDF
UNIFAL - MySQL Views - 5.0/5.6
Wagner Bianchi
 
PDF
UNIFAL - MySQL Triggers - 5.0/5.6
Wagner Bianchi
 
PDF
UNIFAL - MySQL Stored Routines - 5.0/5.6
Wagner Bianchi
 
PDF
UNIFAL - MySQL Linguagem SQL Básico - 5.0/5.6
Wagner Bianchi
 
PDF
UNIFAL - MySQL & Vagrant (iniciando os trabalhos)
Wagner Bianchi
 
PDF
Wagner Bianchi, GUOB 2014 MySQL Cluster 7.3
Wagner Bianchi
 
PPT
Mysql for IBMers
Wagner Bianchi
 
PPTX
MySQL Cluster Product Overview
Wagner Bianchi
 
PPT
MySQL Cluster Basics
Wagner Bianchi
 
Migrations from PLSQL and Transact-SQL - m18
Wagner Bianchi
 
Maxscale switchover, failover, and auto rejoin
Wagner Bianchi
 
Meetup São Paulo, Maxscale Implementação e Casos de Uso
Wagner Bianchi
 
Escalando o ambiente com MariaDB Cluster (Portuguese Edition)
Wagner Bianchi
 
NY Meetup: Scaling MariaDB with Maxscale
Wagner Bianchi
 
Webinar: MariaDB Provides the Solution to Ease Multi-Source Replication
Wagner Bianchi
 
MySQL Multi-Source Replication for PL2016
Wagner Bianchi
 
MySQL 5.7 Multi-Source Replication
Wagner Bianchi
 
UNIFAL - MySQL Transações - 5.0/5.6
Wagner Bianchi
 
UNIFAL - MySQL Views - 5.0/5.6
Wagner Bianchi
 
UNIFAL - MySQL Triggers - 5.0/5.6
Wagner Bianchi
 
UNIFAL - MySQL Stored Routines - 5.0/5.6
Wagner Bianchi
 
UNIFAL - MySQL Linguagem SQL Básico - 5.0/5.6
Wagner Bianchi
 
UNIFAL - MySQL & Vagrant (iniciando os trabalhos)
Wagner Bianchi
 
Wagner Bianchi, GUOB 2014 MySQL Cluster 7.3
Wagner Bianchi
 
Mysql for IBMers
Wagner Bianchi
 
MySQL Cluster Product Overview
Wagner Bianchi
 
MySQL Cluster Basics
Wagner Bianchi
 

Introdução ao MySQL 5.6

  • 1. Introdução ao MySQL 5.6 Uma abordagem que lhe possibilitará saber de todas as novidades e o estado da arte do servidor de bancos de dados mais popular do mundo!
  • 2. Wagner Bianchi é especialista em MySQL e outros servidores de bancos de dados relacionais, como Oracle e SQL Server. Atualmente é Sales Engineer na empresa norte americana Percona (www.percona.com) para negócios na América Latina. Formado em Gerenciamento de Bancos de Dados, com MBA em Administração de Empresas pela Fundação Getúlio Vargas e Pós-Graduando em Bancos de Dados pela Universidade Gama Filho do Distrito Federal. Possui várias certificações, entre elas a SCMA, SCMDEV, SCMDBA, SMCDBA e MCDBA. Autor
  • 3. Contatos • E-mail: [email protected] Skype: wbianchijr • Twitter: @wagnerbianchijr
  • 5. Conteúdo do Workshop • Arquitetura do servidor de bancos de dados MySQL 5.6; • MySQL 5.6 INFORMATION_SCHEMA; • Melhorias no Otimizador de Consultas; • Melhorias no Storage Engine InnoDB; • Interface NoSQL com MEMCACHED API; • Melhorias no particionamento de tabelas (MySQL Partitioning); • Melhorias em pontos críticos da replicação de dados; • Melhorias no monitoramento de performance; Destaques: • InnoDB Plugin e o suporte ao FullText Search; • Binlog Group Commit (Replicação de Dados);
  • 6. Arquitetura do servidor de bancos de dados MySQL 5.6
  • 8. Arquitetura MySQL 5.6 • Primeira camada contendo módulos que compõem o software de gerenciamento dos bancos de dados (parser, query transformation, query cache, etc); • Segundo camada contendo os “bocais” para “plugar” os Storage Engines; – Possibilidade de lidar com características de armazenamento de dados; – Possibilidade de lidar com vários Storage Engines em um mesmo banco de dados; – Habilitar e desabilitar Storage Engines;
  • 9. Arquitetura MySQL 5.6 • Desde a versão anterior, a 5.5, lançada em 2010, o InnoDB Plugin se tornou o Storage Engine padrão. – quando você cria uma tabela sem a cláusula ENGINE, cria- se uma nova tabela InnoDB com suporte à transação, integridade referencial, FullText Search, logs de transação, tablespace... • Para verificar os Storage Engine disponíveis nativos do MySQL, basta utilizar o comando SHOW ENGINES; mysql> SHOW ENGINESG [...] *************************** 8. row *************************** Engine: InnoDB Support: YES Comment: Supports transactions, row-level locking, and foreign keys
  • 10. Arquitetura MySQL 5.6 • Controle de logs parte é feito pelo SGBD, parte é feito pelo Storage Engine – e.g. InnoDB Transaction Logs (ib_logsx); – Controlados pelo SGBD • --general-log • --log-bin (log binário do MySQL - registra atualizações - replicação) • --slow-query-log (--log-slow-query até versão 5.0); • --log-error • --pid-file (caso especial, log para troca de mensagens entre mysqld e SO); – Controlados pelo Storage Engine (InnoDB) • ib_logsx, onde x é o número do log, geralmente localizados em /var/lib/mysql Até a versão 5.5 do MySQL, a soma da capacidade de armazenamento dos arquivos de log do InnoDB não poderia passar de 4G. Com o MySQL 5.6, esse tamanho foi ampliado para 12G – quanto maior a capacidade dos arquivos de logs de transação, mais disponibilidade, maior performance;
  • 11. Arquitetura MySQL 5.6 • Os Storage Engines mais utilizados do MySQL são o MyISAM e agora, de longe o mais usado é o InnoDB por suas características e este utilizam memória da seguinte forma; – MyISAM • key_buffer_size para armazenamento de dados de índices (PK); • read_buffer_size para armazenamento de buffer de dados já recuperados; • Cache de dados realizado com a ajuda do sistema operacional (very busy!); – InnoDB • innodb_buffer_pool_size para armazenamento de índices e dados; • innodb_buffer_pool_size_awe para armazenamento de metadados;
  • 12. Arquitetura MySQL 5.6 • MyISAM key buffer/cache:
  • 13. Arquitetura MySQL 5.6 • MyISAM key buffer/cache status variables: mysql> show status like 'key%'; +------------------------+--------+ | Variable_name | Value | +------------------------+--------+ | Key_blocks_not_flushed | 0 | | Key_blocks_unused | 2 | | Key_blocks_used | 167893 | | Key_read_requests | 1560 | | Key_reads | 178590 | | Key_write_requests | 1980 | | Key_writes | 102785 | +------------------------+--------+ 7 rows in set (0.01 sec) Tuning!
  • 14. Arquitetura MySQL 5.6 • InnoDB buffer pool:
  • 15. Arquitetura MySQL 5.6 • InnoDB buffer pool: – InnoDB mantém logs em memória (buffer) e em disco; • innodb_log_group_home_dir [ =/var/lib/mysql ] • Innodb_log_files_in_group = [ 4 ] • Innodb_log_file_size = [ 768M ] • innodb_log_buffer_size = 12G # MySQL 5.6 ++ – A quantidade de memória configurada para o parâmetro acima será alocada logo que o mysqld for iniciado; – As variáveis acima são parte do conjunto utilizado para configurar o comportamento dos logs do InnoDB; Tuning!
  • 18. MySQL 5.6 INFORMATION_SCHEMA • O INFORMATION_SCHEMA, no MySQL, assim como um vários outros produtos de bancos de dados, é o dicionário de dados; – Dados sobre dados: • Lista de bancos de dados, Storage Engines, tabelas, colunas, índices; • Lista de aspectos do “runtime” do servidor de bancos de dados; – Formado por um conjunto de visões (não podem ser alteradas diretamente): • INFORMATION_SCHEMA.SCHEMATA; • INFORMATION_SCHEMA.TABLES; • INFORMATION_SCHEMA.TABLE_CONSTRAINTS; • INFORMATION_SCHEMA.GLOBAL_VARIABLES; • INFORMATION_SCHEMA.PROFILING;
  • 19. MySQL 5.6 INFORMATION_SCHEMA • Com o MySQL 5.6, outras visões próprias para a leitura de performance do InnoDB foram implementadas; mysql> show tables like “INNODB_SYS%”; +--------------------------------------------+ | Tables_in_information_schema (INNODB_SYS%) | +--------------------------------------------+ | INNODB_SYS_FIELDS | | INNODB_SYS_INDEXES | | INNODB_SYS_TABLESTATS | | INNODB_SYS_COLUMNS | | INNODB_SYS_FOREIGN_COLS | | INNODB_SYS_FOREIGN | | INNODB_SYS_TABLES | +--------------------------------------------+ 7 rows in set (0.00 sec)
  • 20. MySQL 5.6 INFORMATION_SCHEMA • Visões para monitoramento de outras features já no MySQL 5.5: mysql> show tables like 'INNODB%'; +----------------------------------------+ | Tables_in_INFORMATION_SCHEMA (INNODB%) | +----------------------------------------+ | INNODB_CMP_RESET | | INNODB_TRX | | INNODB_CMPMEM_RESET | | INNODB_LOCK_WAITS | | INNODB_CMPMEM | | INNODB_CMP | | INNODB_LOCKS | +----------------------------------------+ 7 rows in set (0.05 sec)
  • 22. Otimizador de Consultas • Mudanças consideráveis aconteceram no otimizador de consultas, que tem suas variáveis que influenciam na hora de determinar a melhor estratégia de recuperação de dados; mysql> SELECT @@optimizer_switchG *************************** 1. row *************************** @@optimizer_switch: index_merge=on, index_merge_union=on, index_merge_sort_union=on, index_merge_intersection=on, engine_condition_pushdown=on, index_condition_pushdown=on, mrr=on,mrr_cost_based=on
  • 23. Otimizador de Consultas • Index Condition Pushdown (ICP): – Otimizações de recuperação de dados baseadas em índices; – Operação com suporte à todos os Storage Engines; – As linhas são recuperadas já com a aplicação do filtro (WHERE); – Recurso originado em operações com o MySQL Cluster 7.0 ++; mysql> EXPLAIN SELECT Name FROM City WHERE ID > '2000' AND ID <= 4000G *************************** 1. row *************************** id: 1 select_type: SIMPLE table: City type: range possible_keys: PRIMARY key: PRIMARY key_len: 4 ref: NULL rows: 2160 Extra: Using index condition 1 row in set (0.00 sec)
  • 24. Otimizador de Consultas • Multi-Range Read: – Comportamento padrão do otimizador para o MySQL 5.6; – InnoDB armazena dados de forma randômica, páginas, blocos and extensões; – Acesso randômico é ruim para índices secundários (PK+[UNIQUE|KEY]); – O MRR ou Multi-Range Read possibilita acesso seqüencial aos dados; • File Sort Optimization: – Comportamento padrão do otimizador para o MySQL 5.6; – Recurso interessante para sistemas que precisam “paginar” dados; – Melhor performance para consultas que utilizam ORDER BY com coluna não indexada com a cláusula LIMIT;
  • 26. Storage Engine InnoDB • Persistent Optimizer Stats: – O Storage Engine InnoDB, na versão 1.2.2, oferece estatísticas persistentes para que a recuperação de dados não seja afetada após um restart do servidor de bancos de dados; – Este comportamento é controlado pelas seguintes variáveis de ambiente: • innodb_analyze_is_persistent [= ON]; • innodb_stats_persistent_sample_pages; • andinnodb_stats_transient_sample_pages; – Com o POS ativado, as estatísticas somente serão recomputadas caso seja rodado explicitamente o comando ANALYZE TABLE;
  • 27. Storage Engine InnoDB • Novas tabelas no INFORMATION_SCHEMA: Utilidade Tabelas Métricas de utilização INNODB_METRICS Visão interna de todos os pontos do InnoDB INNODB_SYS_TABLES, INNODB_SYS_TABLESTAT, INNODB_SYS_INDEXES, INNODB_SYS_COLUMNS, INNODB_SYS_FIELDS,INNODB_SYS_FOREIGN, e INNODB_SYS_FOREIGN_COLS Informações sobre o consumo da área de memória configurada para o Buffer Pool INNODB_BUFFER_PAGE,INNODB_BUFFER_PAGE_LRU e INNODB_BUFFER_POOL_STATS
  • 28. Storage Engine InnoDB • Multi-Threaded Purge: – Com o MySQL 5.6 o InnoDB passa a ter threads especializadas para o processo de expurgo de dados, que na verdade é tido como um tipo de garbage collector, o que evita problemas com performance; – Tal comportamento é configurado através da variável innodb_purge_threads, que pode ter valores de 0 (off) até 32, que significa o número de threads que serão dedicadas ao processo de expurgo; • Separate Flush Thread: – Uma novidade no MySQL 5.6, uma thread dedicado à limpeza de páginas sujas, denominada page_cleaner, trabalhando no mesmo conceito do Adaptive Flushing;
  • 29. Storage Engine InnoDB • Pruning the InnoDB Table Cache: – Tableas que não são acessadas mais por algum tempo são retiradas da memória (table_cache_definition) para liberar espaço; – Um algorítimo de LRU é utilizado para fazer esse controle;
  • 30. MySQL 5.6 NoSQL com MEMCACHED API
  • 31. NoSQL com MEMCACHED API • Com uma crescente utilização de armazenamento NoSQL (Not Only SQL) e com o surgimento de vários players no mercado: – MySQL dá acesso NoSQL baseado em MEMCACHED API; – Acesso a dados diretamente em tabelas controladas pelo InnoDB nativo; – Persistente, crash-safe, transacional baseado em ACID; – Oferece aos usuários o melhor dos dois mundos, a utilização de linguagem SQL para recuperação de dados (tabelas InnoDB) e a performance melhorada para sistemas que acessam dados diretamente, $key -> $value;
  • 33. MySQL 5.6 MySQL 5.6 Partitioning Engine
  • 34. MySQL 5.6 Partitioning Engine • O particionamento de tabelas: – Se aplicado com padrões poderá melhorar performance radicalmente; – Organizar melhorar os dados em partições e em discos diferentes; – Performance! • Com o MySQL 5.6: – Selecionar dados de uma partição diretamente com a função PARTITION(); • SELECT * FROM employees PARTITION (p0, p2); • DELETE FROM employees PARTITION (p0, p1); • UPDATE employees PARTITION (p0) SET store_id = 2 WHERE fname = 'Jill'; – Migrar dados entre tabelas com comandos SQL; • ALTER TABLE e EXCHANGE PARTITION p0 WITH TABLE e2;
  • 35. MySQL 5.6 MySQL 5.6 Replicação de Dados
  • 36. Replicação de Dados • Multi-Threaded Slaves: – Múltiplas threads no servidor SLAVE podem ser utilizadas para executar as atualizações que são recuperadas do log binário do servidor MASTER, aumentando a disponibilidade dos serviços; – As atualizações replicadas são realizadas em paralelo, e não mais seqüencial como antes; • Crash-Safe Slaves: – Aumento da segurança com base na integridade dos dados em replicação. Através dos arquivos master.info e relaylog.info, uma transação poderá ter seu skip automático, evitando uma intervenção do DBA; – Maior concentração do DBA e atividades mais estratégicas;
  • 37. Replicação de Dados • Replication Checksums: – Ao replicar dados, um checksum é relaizado para que seja conferido no seu destino, evitando problemas de corrompimento de pacotes de dados; • Time-Delayed Replication: – A partir do MySQL 5.6, você poderá definir um tempo (em milissegundos) de quando os dados serão liberados para os servidores SLAVES. – Configurado em nível de servidor SLAVE e realizado através da SQL_THREAD; • Informational Log Events: – Melhorias em questões de auditoria através do log binário;
  • 38. Replicação de Dados • Remote Binlog Back-up: – Utilizando a opção --raw, juntamente com a opção --read-from- remote-server, é possível ler e fazer backup dos logs binários em outro servidor: shell> mysqlbinlog --read-from-remote-server --host=host_name --raw / binlog.000130 binlog.000131 binlog.000132 • Server UUIDs – Não é mais necessário atribuir um server_id único para cada servidor dentro da topologia de replicação, uma vez que ao executar o MySQL 5.6 pela primeira vez, uma arquivo auto.cnf será criado com um valor único para cada servidor – automaticamente. – Esta informação estará disponível através do SHOW SLAVE STATUS;
  • 39. Destaques: • InnoDB Plugin e o suporte ao FullText Search; • Binlog Group Commit (Replicação de Dados);
  • 40. Obrigado! • E-mail: [email protected] Skype: wbianchijr • Twitter: @wagnerbianchijr