Your SlideShare is downloading. ×
0
Introdução ao MySQL 5.6
Introdução ao MySQL 5.6
Introdução ao MySQL 5.6
Introdução ao MySQL 5.6
Introdução ao MySQL 5.6
Introdução ao MySQL 5.6
Introdução ao MySQL 5.6
Introdução ao MySQL 5.6
Introdução ao MySQL 5.6
Introdução ao MySQL 5.6
Introdução ao MySQL 5.6
Introdução ao MySQL 5.6
Introdução ao MySQL 5.6
Introdução ao MySQL 5.6
Introdução ao MySQL 5.6
Introdução ao MySQL 5.6
Introdução ao MySQL 5.6
Introdução ao MySQL 5.6
Introdução ao MySQL 5.6
Introdução ao MySQL 5.6
Introdução ao MySQL 5.6
Introdução ao MySQL 5.6
Introdução ao MySQL 5.6
Introdução ao MySQL 5.6
Introdução ao MySQL 5.6
Introdução ao MySQL 5.6
Introdução ao MySQL 5.6
Introdução ao MySQL 5.6
Introdução ao MySQL 5.6
Introdução ao MySQL 5.6
Introdução ao MySQL 5.6
Introdução ao MySQL 5.6
Introdução ao MySQL 5.6
Introdução ao MySQL 5.6
Introdução ao MySQL 5.6
Introdução ao MySQL 5.6
Introdução ao MySQL 5.6
Introdução ao MySQL 5.6
Introdução ao MySQL 5.6
Introdução ao MySQL 5.6
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Introdução ao MySQL 5.6

1,484

Published on

Workshop to present MySQL 5.6

Workshop to present MySQL 5.6

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,484
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
63
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 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: wagner.bianchi@percona.com • Skype: wbianchijr • Twitter: @wagnerbianchijr
  • 4. MySQL Certification Program
  • 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
  • 7. Arquitetura 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!
  • 16. Arquitetura MySQL 5.6
  • 17. MySQL 5.6 INFORMATION_SCHEMA
  • 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)
  • 21. MySQL 5.6 Otimizador de Consultas
  • 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;
  • 25. MySQL 5.6 Storage Engine InnoDB
  • 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;
  • 32. NoSQL com MEMCACHED API
  • 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: wagner.bianchi@percona.com • Skype: wbianchijr • Twitter: @wagnerbianchijr

×