Operational Wins in MySQL 5.5
•
1 like•677 views
MySQL Release 5.5 offers many improvements—such as making InnoDB the default storage engine and giving more visibility into server performance—in areas that have been consistent pain points for operational DBAs. They are the beneficiaries of some great new features and lots of cleanup in this release of the MySQL server. Replication and partitioning both benefited from attention, and it's clear that Oracle has been hearing about headaches operational DBAs are kept up with late at night. This presentation highlights which changes have enabled the speaker's staff to sleep more and why everyone should consider upgrading to Release 5.5.
Recommended
More Related Content
Viewers also liked
Viewers also liked (20)
More from sarahnovotny
More from sarahnovotny (17)
Recently uploaded
Recently uploaded (20)
Operational Wins in MySQL 5.5
- 1. operational wins in MySQL 5.5 (why we love the new version) sarah novotny – sarah@bluegecko.net MySQL and LAMP services www .BlueGecko . net
- 2. www .BlueGecko . net
- 3. www .BlueGecko . net
- 5. www .BlueGecko . net plug in
- 9. www .BlueGecko . net fast index creation
- 10. www .BlueGecko . net transaction threads
- 11. www .BlueGecko . net InnoDB thread concurrency changes from MySQL documentation
- 12. www .BlueGecko . net barracuda
- 15. faster processors + larger datasets + data-driven applications – minimal cost effective disk innovation => i/o wait the problem
- 16. www .BlueGecko . net a short digression - Artur Bergman on SSDs $$/GB/IOPS
- 17. www .BlueGecko . net compressed rows
- 18. www .BlueGecko . net off page columns
- 19. the problem slow crash recovery
- 20. www .BlueGecko . net crash recovery
- 22. www .BlueGecko . net InnoDB transparency problem
- 39. www .BlueGecko . net InnoDB Information Schema
- 43. tada! www .BlueGecko . net waiting trx id waiting thread waiting query blocking trx id blocking thread blocking query A4 6 SELECT b FROM t FOR UPDATE A3 5 SELECT SLEEP(100) A5 7 SELECT c FROM t FOR UPDATE A3 5 SELECT SLEEP(100) A6 SELECT c FROM t FOR UPDATE A4 6 SELECT b FROM t FOR UPDATE
Editor's Notes
- MySQL 3.23 … managing 100s of DBs
- MySQL 3.23 … managing 100s of DBs
- Baraccuda steve ballmer’s developers developers developers.
- Plugin Starting with MySQL 5.5 and InnoDB 1.1, the built-in InnoDB storage engine within MySQL is upgraded to the full feature set and performance of the former InnoDB Plugin.
- Faster. InnoDB has historically protected the internal state of a read/write lock with an InnoDB mutex. InnoDB implements mutexes and read/write locks with the built-in functions provided by the GNU Compiler Collection (GCC) for atomic memory access instead of using the Pthreads approach previously used. More specifically, an InnoDB that is compiled with GCC version 4.1.2 or later uses the atomic builtins instead of a pthread_mutex_t to implement InnoDB mutexes and read/write locks.
- in earlier versions, InnoDB implemented its own memory allocator in the mem subsystem. This allocator was guarded by a single mutex, which became a bottleneck. InnoDB also implements a wrapper interface around the system allocator (malloc and free) that was likewise guarded by a single mutex. now use -- system memory allocator – better scaled for multi-core boxes
- Atomic operations can often be used to synchronize the actions of multiple threads more efficiently than Pthreads. Each operation to acquire or release a lock can be done in fewer CPU instructions, and thus result in less wasted time when threads are contending for access to shared data structures. This in turn means greater scalability on multi-core platforms.
- With MySQL 5.5 and higher, or MySQL 5.1 with the InnoDB Plugin, creating and dropping secondary indexes for InnoDB tables is much faster than before. Historically, adding or dropping an index on a table with existing data could be very slow. The CREATE INDEX and DROP INDEX statements worked by creating a new, empty table defined with the requested set of indexes, then copying the existing rows to the new table one-by-one, updating the indexes as the rows are inserted. After all rows from the original table were copied, the old table was dropped and the copy was renamed with the name of the original table.
- user transaction threads -- Before limiting the number of concurrently executing threads, review configuration options that may improve the performance of InnoDB on multi-core and multi-processor computers, such as innodb_use_sys_malloc and innodb_adaptive_hash_index.
- Barracuda default innodb_file_format >5.5.0 -- requires innodb_file_per_table
- InnoDB compression applies both to user data and to indexes . In many cases, indexes can constitute 40-50% or more of the total database size, so this difference is significant smaller database can in turn lead to a reduction in I/O, and an increase in throughput, at a modest cost in terms of increased CPU utilization.
- long column values are stored fully off-page, and the clustered index record contains only a 20-byte pointer to the overflow page.
- The cleanup activities that occur when InnoDB is started again after a crash. Changes that were committed before the crash, but not yet written into the tablespace files, are reconstructed from the doublewrite buffer. When the database is shut down normally, this type of activity is performed during shutdown by the purge operation. During normal operation, committed data can be stored in the insert buffer for a period of time before being written to the tablespace files. There is always a tradeoff between keeping the tablespace files up-to-date, which introduces performance overhead during normal operation, and buffering the data, which can make shutdown and crash recovery take longer.
- In particular, scanning the redo log and applying the redo log are faster than in MySQL 5.1 and earlier, due to improved algorithms for memory management. You do not need to take any actions to take advantage of this performance enhancement. If you kept the size of your redo log files artificially low because recovery took a long time, you can consider increasing the file size. redo logs - A set of files, typically named ib_logfile0 and ib_logfile1, that record statements that attempt to change data in InnoDB tables. These statements are replayed automatically to correct data written by incomplete transactions, on startup following a crash. The passage of data through the redo logs is represented by the ever-increasing LSN value. The 4GB limit on maximum size for the redo log is raised in MySQL 5.6. The disk layout of the redo log is influenced by the configuration options innodb_log_file_size, innodb_log_group_home_dir, and (rarely) innodb_log_files_in_group. The performance of redo log operations is also affected by the log buffer, which is controlled by the innodb_log_buffer_size configuration option.
- opaque. show engine innodb status
- For every blocked transaction, INNODB_LOCKS contains one row that describes each lock the transaction has requested, and for which it is waiting. INNODB_LOCKS also contains one row for each lock that is blocking another transaction, whatever the state of the transaction that holds the lock ('RUNNING', 'LOCK WAIT', 'ROLLING BACK' or 'COMMITTING'). The lock that is blocking a transaction is always held in a mode (read vs. write, shared vs. exclusive) incompatible with the mode of requested lock. Using this table, you can tell which transactions are waiting for a given lock, or for which lock a given transaction is waiting. This table contains one or more rows for each blocked transaction, indicating the lock it has requested and the lock(s) that is (are) blocking that request.
- For every blocked transaction, INNODB_LOCKS contains one row that describes each lock the transaction has requested, and for which it is waiting. INNODB_LOCKS also contains one row for each lock that is blocking another transaction, whatever the state of the transaction that holds the lock ('RUNNING', 'LOCK WAIT', 'ROLLING BACK' or 'COMMITTING'). The lock that is blocking a transaction is always held in a mode (read vs. write, shared vs. exclusive) incompatible with the mode of requested lock. Using this table, you can tell which transactions are waiting for a given lock, or for which lock a given transaction is waiting. This table contains one or more rows for each blocked transaction, indicating the lock it has requested and the lock(s) that is (are) blocking that request.
- •❑ disk•❑memory•❑up/down•❑cachehit -- baseline defiinition•❑replication •❑ mktablesync•❑mkchecksum