MySQL 5.6
Upcoming SlideShare
Loading in...5
×
 

MySQL 5.6

on

  • 829 views

October 15th presentation for Austin MySQL Users Group on MySQL 5.6

October 15th presentation for Austin MySQL Users Group on MySQL 5.6

Statistics

Views

Total Views
829
Views on SlideShare
829
Embed Views
0

Actions

Likes
0
Downloads
21
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

MySQL 5.6 MySQL 5.6 Presentation Transcript

  • MySQL 5.6 Features and Enhancements David Stokes MySQL Community Manager David.Stokes@Oracle.com @stoker Opensourcedba.wordpress.com NorthTexasMySQL.org Slideshare.net/davestokes1 Copyright © 2011, Oracle and/or its affiliates. All rights reserved.
  • Safe Harbor Agreement The following is intended to outline our general product direction. It is intended for information purposes only, and may not be incorporated into any contract. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. The development, release, and timing of any features or functionality described for Oracle’s products remains at the sole discretion of Oracle.2 Copyright © 2011, Oracle and/or its affiliates. All rights reserved.
  • MySQl 5.6 Release Candidate Announced 10/2 See video at http://medianetwork.oracle.com/video/player/1873154739001 to see official announcements during keynotes at MySQL Connect Conference3 Copyright © 2011, Oracle and/or its affiliates. All rights reserved.
  • Python Connector • Written in Python • GA • Heavily used with MySQL Utilities4 Copyright © 2011, Oracle and/or its affiliates. All rights reserved.
  • MySQL 5.6 – four areas to note • Optimizer • Replication • Performance Schema • NoSQL access to InnoDB and NDB5 Copyright © 2011, Oracle and/or its affiliates. All rights reserved.
  • 5.6 Index Condition Pushdown Moves more of the processing for WHERE clauses to the storage engine. Instead of fetching entire rows to evaluate against a set of WHERE clauses, ICP sends those clauses to the storage engine, which can prune the result set by examining index tuples. The result is less I/O overhead for the base table, and less internal communication overhead for the server and the storage engine. This feature works with InnoDB, MyISAM, and NDBCLUSTER tables6 Copyright © 2011, Oracle and/or its affiliates. All rights reserved.
  • Multi-Range Read Until the day when you have all the SSDs you want, its faster to read data sequentially from disk than to do random accesses. For secondary indexes, the order for the index entries on disk is different than the order of disk blocks for the full rows. Instead of retrieving the full rows using a sequence of small out-of-order reads, MRR scans one or more index ranges used in a query, sorts the associated disk blocks for the row data, then reads those disk blocks using larger sequential I/O requests. The speedup benefits operations such as range index scans and equi-joins on indexed columns. (Think InnoDB foreign keys.) Works all storage engines.7 Copyright © 2011, Oracle and/or its affiliates. All rights reserved.
  • InnoDB Persistent Optimizer Stats Provides improved accuracy of InnoDB index statistics, and consistency across MySQL restarts. InnoDB precomputes statistics that help the optimizer decide which indexes to use in a query, by sampling a portion of the index. You can adjust the amount of sampling that InnoDB does for each index. The resulting statistics can now persist across server restarts, rather than being recomputed (and possibly changing) due to restarts and some runtime events. The more accurate statistics can improve query performance, and the persistence aspect can keep query performance stable. This feature is controlled by the configuration options innodb_analyze_is_persistent, innodb_stats_persistent_sample_pages, and innodb_stats_transient_sample_pages. When the persistent stats feature is enabled, the statistics are only recomputed when you explicitly run ANALYZE TABLE for the table8 Copyright © 2011, Oracle and/or its affiliates. All rights reserved.
  • File Sort Optimizations For queries that combine ORDER BY non_indexed_column and a LIMIT x clause, this feature speeds up the sort when the contents of X rows can fit into the sort buffer. Works with all storage engines9 Copyright © 2011, Oracle and/or its affiliates. All rights reserved.
  • Information Schema Once InnoDB information was made available for queries through the INFORMATION_SCHEMA in MySQL 5.5, people clamored for more kinds of status and monitoring information. The SQL interface is more standardized and predictable than parsing the text output from SHOW STATUS commands. Metrics table: Provides a generic and comprehensive resource and performance monitoring framework for InnoDB. The new I_S table is INNODB_METRICS. System Tables: Makes the InnoDB internal data dictionary available for SQL queries, for convenience of monitoring. The new I_S tables are INNODB_SYS_TABLES, INNODB_SYS_TABLESTATS, INNODB_SYS_INDEXES, INNODB_SYS_COLUMNS, INNODB_SYS_FIELDS, INNODB_SYS_FOREIGN, and INNODB_SYS_FOREIGN_COLS. Buffer Pool Information table: Displays buffer pool page information for tuning on large-memory or highly loaded systems. (Highly requested by customers and community users.) The new I_S tables are INNODB_BUFFER_PAGE, INNODB_BUFFER_PAGE_LRU, and INNODB_BUFFER_POOL_STATS10 Copyright © 2011, Oracle and/or its affiliates. All rights reserved.
  • Stuff under the hood • Split Kernel Mutex • Multi-threaded purge • Separate flush thread • LRU pruning on the InnoDB Table Cache11 Copyright © 2011, Oracle and/or its affiliates. All rights reserved.
  • NoSQL Access to InnoDB/NDB The ever-increasing performance demands of web-based services has generated significant interest in providing NoSQL access methods to MySQL – maintaining all of the advantages of your existing relational database infrastructure, while providing blazing fast performance for simple queries, using an API to complement regular SQL access to your data. • Using the memcached API, web services can now directly access the InnoDB storage engine without transformations to SQL, ensuring low latency and high throughput for read/write queries. Operations such as SQL parsing are eliminated and more of the servers hardware resources (CPU, memory and I/O) are dedicated to servicing the query within the storage engine itself. • By using memcached, developers and DBAs are able to: • Preserve investments in memcached infrastructure by reusing existing memcached clients and eliminating the need for application changes. • Access the full range of memcached client libraries and platforms, providing maximum deployment flexibility and consistently high performance across all supported environments. • Extend memcached functionality by integrating a persistent, crash-safe, transactional database back-end offering ACID compliance12 Copyright © 2011, Oracle and/or its affiliates. All rights reserved.
  • Explicit Partition Selection With partitioned tables, MySQL can restrict processing to only the relevant portions of a big data set. Now you can directly define which partitions are used in a query, DML, or data load operation, rather than repeating all the partitioning criteria in each statement. • SELECT * FROM employees PARTITION (p0, p2); • DELETE FROM employees PARTITION (p0, p1); • UPDATE employees PARTITION (p0) SET store_id = 2 WHERE fname = Jill; • SELECT e.id, s.city FROM employees AS e JOIN stores PARTITION (p1) AS s .13 Copyright © 2011, Oracle and/or its affiliates. All rights reserved.
  • Partition import/export To quickly bring a new data set into a partitioned table, or to export a partition or subpartition to manage it as a regular table, you can use the syntax ALTER TABLE ... EXCHANGE PARTITION. You specify a partition or subpartition of a partitioned table, and a non-partitioned table with a compatible structure, and this operation swaps their places without any expensive copy operation. • ALTER TABLE e EXCHANGE PARTITION p0 WITH TABLE e2; • This operation works with any storage engine that supports partitioned tables.14 Copyright © 2011, Oracle and/or its affiliates. All rights reserved.
  • Replication – weve been busy Optimized Row-Based Replication • By only replicating partial "before" and "after" images for INSERT, UPDATE and DELETE events where primary keys or explicit columns were set in the SQL statement, performance can be increased while binary log disk space, network resources and server memory footprint are reduced. Multi-Threaded Slaves • Replication performance is improved by using multiple execution threads to apply replication events to slave servers. The multi-threaded slave splits work between worker threads based on the database name, allowing updates to be applied in parallel rather than sequentially. • As a result, replication throughput is increased and latency is reduced which minimizes the risk of replication lag, enabling slaves to serve the freshest updates to the application.15 Copyright © 2011, Oracle and/or its affiliates. All rights reserved.
  • Replication enhancements Crash-Safe Slaves • Extends the robustness and ease-of-use of MySQL replication by making the slaves crash-safe when using transactional storage engines such as InnoDB. • The slave can automatically recover from a failure and resume replicating DML updates, without the DBA having to access the master.info and relaylog.info files to manually roll back replication to the last successfully committed transaction, or to skip transactions. • As a result, data integrity is enhanced and DBAs can be free to concentrate on more strategic data management activities. Replication Checksums • Ensures the integrity of data being replicated to a slave by detecting data corruption and returning an error, preventing the slave itself from becoming corrupt. • Checksums are implemented in the binary and relay logs as well as to individual replication events, allowing errors to be detected whether they are caused by memory, disk or network failures, or by the database itself. Checksum checking can be implemented on a per-slave basis, giving maximum flexibility in how and where it is deployed.16 Copyright © 2011, Oracle and/or its affiliates. All rights reserved.
  • Time Delayed Replication You can define a time delay for events to be replicated from a master to each slave, defined in millisecond increments up to a maximum of 68 years! • Time-Delayed Replication affords protection against operational errors made on the master, for example accidently dropping tables, in which event the slave can be promoted to the new master in order to restore the database to its previous state. Time- Delayed Replication can also be useful in testing application behavior by emulating any instances of replication lag. • Time-Delayed Replication is implemented at the per-slave level (via holding execution of the SQL_THREAD), so you could configure multiple slaves to apply replication events immediately, and another slave to apply only after a delay of 5 minutes, therefore providing deployment flexibility.17 Copyright © 2011, Oracle and/or its affiliates. All rights reserved.
  • Replication usability enhancements Informational Log Events • Enhances auditing and debugging when using Row-Based Replication by writing the original query to the binary log, which is then replicated with its associated row-based event to the slave. Remote Binlog Back-up • Enhances operational efficiency by using the replication channel to create real-time back-ups from the binary log. • By adding a "raw" flag, the binlog is written out to remote back-up servers, without having a MySQL database instance translating it into SQL statements, and without the DBA needing SSH access to each master server. Server UUIDs • Automatically generates a Universally Unique Identifier (UUID) for each server, allowing MySQL Enterprise Monitor or any other monitoring tool to retrieve information about master and slave servers in a replication configuration. The UUID is available through a SQL query and in the output of the SHOW SLAVE STATUS command. This technique requires fewer database connections and works better with servers that are monitored remotely or that use virtual IP addresses. This feature is especially useful in large and highly dynamic replication environments, making auto- discovery more reliable and simplifying systems management.18 Copyright © 2011, Oracle and/or its affiliates. All rights reserved.
  • Instrumentation and Diagnostic Improvements via PERFORMANCE_SCHEMA MySQL 5.6 greatly enhances the PERFORMANCE_SCHEMA features for performance monitoring and tuning. The information in the performance_schema tables lets you see how various low-level items factor into overall database performance, which ones are the "hottest" under various workloads and system configurations, and trace issues back to the relevant file and line in the source code so you can really see whats happening behind the scenes. Read more about Performance Schema.19 Copyright © 2011, Oracle and/or its affiliates. All rights reserved.
  • Questions and Answers David.Stokes@oracle.com @stoker Slideshare.net/davestokes20 Copyright © 2011, Oracle and/or its affiliates. All rights reserved.