Introdução ao MySQL 5.6

2,068 views
1,893 views

Published on

Workshop to present MySQL 5.6

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

No Downloads
Views
Total views
2,068
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
77
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Introdução ao MySQL 5.6

  1. 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. 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. 3. Contatos • E-mail: wagner.bianchi@percona.com • Skype: wbianchijr • Twitter: @wagnerbianchijr
  4. 4. MySQL Certification Program
  5. 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. 6. Arquitetura do servidor de bancos de dados MySQL 5.6
  7. 7. Arquitetura MySQL 5.6
  8. 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. 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. 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. 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. 12. Arquitetura MySQL 5.6 • MyISAM key buffer/cache:
  13. 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. 14. Arquitetura MySQL 5.6 • InnoDB buffer pool:
  15. 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. 16. Arquitetura MySQL 5.6
  17. 17. MySQL 5.6 INFORMATION_SCHEMA
  18. 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. 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. 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. 21. MySQL 5.6 Otimizador de Consultas
  22. 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. 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. 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. 25. MySQL 5.6 Storage Engine InnoDB
  26. 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. 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. 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. 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. 30. MySQL 5.6 NoSQL com MEMCACHED API
  31. 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. 32. NoSQL com MEMCACHED API
  33. 33. MySQL 5.6 MySQL 5.6 Partitioning Engine
  34. 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. 35. MySQL 5.6 MySQL 5.6 Replicação de Dados
  36. 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. 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. 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. 39. Destaques: • InnoDB Plugin e o suporte ao FullText Search; • Binlog Group Commit (Replicação de Dados);
  40. 40. Obrigado! • E-mail: wagner.bianchi@percona.com • Skype: wbianchijr • Twitter: @wagnerbianchijr

×