Percona Server 5.5.34-32.0

Percona Server Documentation
Release 5.5.34-32.0
Percona LLC and/or its afliates 2009-2013
October 28, 2013
CONTENTS
Introduction 1.1 Percona Server Feature Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 The Percona XtraDB Storage Engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Installation 2.1 Installing Percona Server 5.5 from Binaries . . . . . . . . 2.2 Installing Percona Server from a Source Tarball . . . . . 2.3 Installing Percona Server from the Bazaar Source Tree . . 2.4 Percona Sever In-Place Upgrading Guide: From 5.1 to 5.5 Scalability Improvements 3.1 Improved Buffer Pool Scalability . . . . 3.2 Congurable Insert Buffer . . . . . . . . 3.3 Improved InnoDB I/O Scalability . . . . 3.4 Multiple Adaptive Hash Search Partitions 3.5 Multiple Rollback Segments . . . . . . .
3 3 5 7 7 12 12 13 23 23 24 25 31 31 33 33 34 35 37 38 38 39 39 39 41 43 46 49 49 49 50 51 52 52 56
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
Performance Improvements 4.1 Atomic write support for Fusion-io devices . 4.2 Drop table performance . . . . . . . . . . . 4.3 Conguration of the Doublewrite Buffer . . 4.4 Query Cache Enhancements . . . . . . . . . 4.5 Fast InnoDB Checksum . . . . . . . . . . . 4.6 Remove Excessive Function Calls (fcntl) . 4.7 Reduced Buffer Pool Mutex Contention . . . 4.8 InnoDB timer-based Concurrency Throttling 4.9 Improved NUMA support . . . . . . . . . . . 4.10 HandlerSocket . . . . . . . . . . . . . . . . 4.11 Thread Pool . . . . . . . . . . . . . . . . . 4.12 Binary Log Group Commit . . . . . . . . . Flexibility Improvements 5.1 Support of Multiple Page Sizes . . . . 5.2 Suppress Warning Messages . . . . . . 5.3 Handle BLOB End of Line . . . . . . . 5.4 Fixed Size for the Read Ahead Area . . 5.5 Fast Shutdown . . . . . . . . . . . . . 5.6 Improved MEMORY Storage Engine . 5.7 Restricting the number of binlog les .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
5.8 5.9 6
Ignoring missing tables in mysqldump . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Extended SELECT INTO OUTFILE/DUMPFILE . . . . . . . . . . . . . . . . . . . . . . . . . .
57 57 59 59 61 61 62 63 65 65 66 68 71 75 76 78 79 80 81 82 83 85 86 88 90 93 93 98 104 111 122 123 124 129 129 130 131 135
Reliability Improvements 6.1 Crash-Resistant Replication . . . . . 6.2 Too Many Connections Warning . . . 6.3 Error Code Compatibility . . . . . . 6.4 Handle Corrupted Tables . . . . . . . 6.5 Lock-Free SHOW SLAVE STATUS .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
Management Improvements 7.1 InnoDB Recovery Stats . . . . . . . . . . . . . . . 7.2 InnoDB Data Dictionary Size Limit . . . . . . . . . 7.3 Expand Table Import . . . . . . . . . . . . . . . . . 7.4 Dump/Restore of the Buffer Pool . . . . . . . . . . 7.5 Fast Index Creation . . . . . . . . . . . . . . . . . . 7.6 Expanded Fast Index Creation . . . . . . . . . . . . 7.7 Prevent Caching to FlashCache . . . . . . . . . . . 7.8 Percona Toolkit UDFs . . . . . . . . . . . . . . . . 7.9 Support for Fake Changes . . . . . . . . . . . . . . 7.10 Kill Idle Transactions . . . . . . . . . . . . . . . . 7.11 Enforcing Storage Engine . . . . . . . . . . . . . . 7.12 Utility user . . . . . . . . . . . . . . . . . . . . . . 7.13 Extending the secure-file-priv server option 7.14 Expanded Program Option Modiers . . . . . . . . 7.15 XtraDB changed page tracking . . . . . . . . . . . 7.16 PAM Authentication Plugin . . . . . . . . . . . . . Diagnostics Improvements 8.1 InnoDB Statistics . . . . . . . . . . . . . . 8.2 User Statistics . . . . . . . . . . . . . . . 8.3 Slow Query Log . . . . . . . . . . . . . . 8.4 Extended Show Engine InnoDB Status . . 8.5 Count InnoDB Deadlocks . . . . . . . . . 8.6 Log All Client Commands (syslog) . . . 8.7 Response Time Distribution . . . . . . . . 8.8 Show Storage Engines . . . . . . . . . . . 8.9 Show Lock Names . . . . . . . . . . . . . 8.10 Process List . . . . . . . . . . . . . . . . . 8.11 Misc. INFORMATION_SCHEMA Tables 8.12 Thread Based Proling . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
Obsolete and Removed Features 137 9.1 Shared Memory Buffer Pool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 139 139 143 144 152 155 156 157 157 158
10 Reference 10.1 Development of Percona Server . . . . . . . . . . . . . . . . . . . 10.2 Trademark Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.3 List of upstream MySQL bugs xed in Percona Server 5.5 . . . . . 10.4 List of variables introduced in Percona Server 5.5 . . . . . . . . . . 10.5 Index of INFORMATION_SCHEMA Tables . . . . . . . . . . . . . 10.6 Frequently Asked Questions . . . . . . . . . . . . . . . . . . . . . 10.7 Copyright and Licensing Information . . . . . . . . . . . . . . . . 10.8 Options that make XtraDB tablespaces not compatible with MySQL 10.9 Percona Server 5.5 Release notes . . . . . . . . . . . . . . . . . . ii
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
10.10 Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184 Index 187
iii
iv
Percona Server Documentation, Release 5.5.34-32.0
Percona Server is an enhanced drop-in replacement for MySQL. With Percona Server, Your queries will run faster and more consistently. You will consolidate servers on powerful hardware. You will delay sharding, or avoid it entirely. You will save money on hosting fees and power. You will spend less time tuning and administering. You will achieve higher uptime. You will troubleshoot without guesswork. Does this sound too good to be true? Its not. Percona Server offers breakthrough performance, scalability, features, and instrumentation. Its self-tuning algorithms and support for extremely high-performance hardware make it the clear choice for companies who demand the utmost performance and reliability from their database server.
CONTENTS
CONTENTS
CHAPTER
ONE
INTRODUCTION
1.1 Percona Server Feature Comparison
Percona Server is an enhanced drop-in replacement for MySQL. With Percona Server, Your queries will run faster and more consistently. You will consolidate servers on powerful hardware. You will delay sharding, or avoid it entirely. You will save money on hosting fees and power. You will spend less time tuning and administering. You will achieve higher uptime. You will troubleshoot without guesswork. We provide these benets by signicantly enhancing Percona Server as compared to the standard MySQL database server: Features Open source ACID Compliance Multi-Version Concurrency Control Row-Level Locking Automatic Crash Recovery Table Partitioning Views Subqueries Triggers Stored Procedures Foreign Keys Extra Features for Developers NoSQL Socket-Level Interface Extra Hash/Digest Functions Percona Server 5.5.27 Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Percona Server 5.5.27 Yes Yes MySQL 5.5.27 Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes MySQL 5.5.27
Extra Diagnostic Features INFORMATION_SCHEMA Tables Global Performance and Status Counters Per-Table Performance Counters Per-Index Performance Counters Per-User Performance Counters Per-Client Performance Counters Per-Thread Performance Counters High-Resolution Process List Timing Detailed Query Execution and Plan Log Global Query Response Time Statistics InnoDB Data Dictionary as I_S Tables Access to InnoDB Data Statistics Enhanced SHOW ENGINE INNODB STATUS Enhanced Mutex Diagnostics Undo Segment Information Durability and Reliability Enhancements Transactional Replication State Handles Corrupted Tables Gracefully Performance & Scalability Enhancements Support for Multiple I/O Threads Dedicated Purge Thread Self-Tuning Checkpoint Algorithm Fine-Grained Mutex Locking Lock-Free Algorithms Improved MEMORY Storage Engine Partitioned Adaptive Hash Search Separate Doublewrite File Fast Checksum Algorithm Buffer Pool Pre-Load Fast Shut-Down Background Table Drop Support for FlashCache Read-Ahead Improvements Extra Features for DBA/Operations Staff Congurable Page Sizes Import Tables From Different Servers Congurable Data Dictionary Size Congurable Insert Buffer Size Active Change Buffer Purging Error/Warning Logging Enhancements Congurable Fast Index Creation Support for Fake Changes Changed Page Tracking Running Database as a Service Special Utility User Expanded Program Option Modiers Extended secure-file-priv option Enforcing the Specic Storage Engine
Percona Server 5.5.27 60 370 Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Percona Server 5.5.27 Yes Yes Percona Server 5.5.27 Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Percona Server 5.5.27 Yes Yes Yes Yes Yes Yes Yes Yes Yes
MySQL 5.5.27 37 310
MySQL 5.5.27
MySQL 5.5.27 Yes Yes
MySQL 5.5.27
Percona Server 5.5.27 Yes Yes Yes Yes
MySQL 5.5.27
Chapter 1. Introduction
1.2 The Percona XtraDB Storage Engine
Percona XtraDB is an enhanced version of the InnoDB storage engine, designed to better scale on modern hardware, and including a variety of other features useful in high performance environments. It is fully backwards compatible, and so can be used as a drop-in replacement for standard InnoDB. Percona XtraDB includes all of InnoDB s robust, reliable ACID-compliant design and advanced MVCC architecture, and builds on that solid foundation with more features, more tunability, more metrics, and more scalability. In particular, it is designed to scale better on many cores, to use memory more efciently, and to be more convenient and useful. The new features are especially designed to alleviate some of InnoDB s limitations. We choose features and xes based on customer requests and on our best judgment of real-world needs as a high-performance consulting company. Percona XtraDB engine will not have further binary releases, it is distributed as part of Percona Server and MariaDB.
1.2. The Percona XtraDB Storage Engine
Chapter 1. Introduction
CHAPTER
TWO
INSTALLATION
2.1 Installing Percona Server 5.5 from Binaries
Before installing, you might want to read the Percona Server 5.5 Release notes. Ready-to-use binaries are available from the Percona Server download page, including: RPM packages for RHEL 5 and RHEL 6 Debian packages for Debian and Ubuntu
2.1.1 Using Percona Software Repositories

Percona apt Repository Debian and Ubuntu packages from Percona are signed with a key. Before using the repository, you should add the key to apt. To do that, run the following commands:
$ apt-key adv --keyserver keys.gnupg.net --recv-keys 1C4CBDCDCD2EFD2A
Add this to /etc/apt/sources.list, replacing VERSION with the name of your distribution:
deb http://repo.percona.com/apt VERSION main deb-src http://repo.percona.com/apt VERSION main
Remember to update the local cache:

$ apt-get update
After that you can install the server and client packages
# apt-get install percona-server-server-5.5 percona-server-client-5.5
Supported Platforms
x86 x86_64 (also known as amd64)
Supported Releases
Debian 6.0 (squeeze) 7.0 (wheezy) Ubuntu 10.04LTS (lucid) 12.04LTS (precise) 12.10 (quantal) 13.04 (raring)
Percona apt Experimental repository
Percona offers fresh beta builds from the experimental repository. To enable it add the following lines to your /etc/apt/sources.list , replacing VERSION with the name of your distribution:
deb http://repo.percona.com/apt VERSION main experimental deb-src http://repo.percona.com/apt VERSION main experimental
Apt-Pinning the packages
In some cases you might need to pin the selected packages to avoid the upgrades from the distribution repositories. Youll need to make a new le /etc/apt/preferences.d/00percona.pref and add the following lines in it:
Package: * Pin: release o=Percona Development Team Pin-Priority: 1001
For more information about the pinning you can check the ofcial debian wiki. Percona yum Repository The Percona yum repository supports popular RPM -based operating systems, including the Amazon Linux AMI. The easiest way to install the Percona Yum repository is to install an RPM that congures yum and installs the Percona GPG key. You can also do the installation manually.
Automatic Installation
Execute the following command as a root user, replacing x86_64 with i386 if you are not running a 64-bit operating system:
$ rpm -Uhv http://www.percona.com/downloads/percona-release/percona-release-0.0-1.x86_64.rpm
You should see some output such as the following:
Chapter 2. Installation
Retrieving http://www.percona.com/downloads/percona-release/percona-release-0.0-1.x86_64.rpm Preparing... ########################################### [100%] 1:percona-release ########################################### [100%]
The RPMs for the automatic installation are available at http://www.percona.com/downloads/percona-release/ and include source code.
Manual Installation
To install the repository manually, /etc/yum.repos.d/Percona.repo:
place
the
following
into
new
le
named
[percona] name = CentOS $releasever - Percona baseurl=http://repo.percona.com/centos/$releasever/os/$basearch/ enabled = 1 gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-percona gpgcheck = 1
Also, copy the Percona GPG key into a le named /etc/pki/rpm-gpg/RPM-GPG-KEY-percona.

Testing The Repository
Make sure packages are downloaded from the repository, by executing the following command as root:
yum list | grep percona
You should see output similar to the following:

percona-release.x86_64 ... Percona-Server-client-51.x86_64 Percona-Server-devel-51.x86_64 Percona-Server-server-51.x86_64 Percona-Server-shared-51.x86_64 Percona-Server-test-51.x86_64 ... xtrabackup.x86_64 0.0-1 5.1.47-rel11.1.51.rhel5 5.1.47-rel11.1.51.rhel5 5.1.47-rel11.1.51.rhel5 5.1.47-rel11.1.51.rhel5 5.1.47-rel11.1.51.rhel5 1.2-22.rhel5 installed percona percona percona percona percona percona
Supported Platforms
x86_64 i386
Supported Releases
The CentOS repositories should work well with Red Hat Enterprise Linux too, provided that yum is installed on the server. CentOS 5 and RHEL 5 CentOS 6 and RHEL 6 Amazon Linux AMI (works the same as CentOS 5) 2.1. Installing Percona Server 5.5 from Binaries 9
Percona yum Experimental repository
Percona offers fresh beta builds from the experimental repository. To subscribe to the experimental repository, install the experimental RPM :
rpm -Uhv http://repo.percona.com/testing/centos/6/os/noarch/percona-testing-0.0-1.noarch.rpm
Note: This repository works for both RHEL/CentOS 5 and RHEL/CentOS 6 Percona provides repositories for yum (RPM packages for Red Hat, CentOS and Amazon Linux AMI ) and apt (.deb packages for Ubuntu and Debian) for software such as Percona Server, XtraDB, XtraBackup, and Percona Toolkit. This makes it easy to install and update your software and its dependencies through your operating systems package manager. This is the recommend way of installing where possible. YUM-Based Systems Once the repository is set up, use the following commands:
$ yum install Percona-Server-client-55 Percona-Server-server-55
DEB-Based Systems Once the repository is set up, use the following commands:
$ sudo apt-get install percona-server-server-5.5
2.1.2 Using Standalone Packages

RPM-Based Systems Download the packages of the desired series for your architecture from here. For example, at the moment of writing, a way of doing this is:
$ wget -r -l 1 -nd -A rpm -R "*devel*,*debuginfo*" \ http://www.percona.com/redir/downloads/Percona-Server-5.5/Percona-Server-5.5.14-20.5/RPM/rhel5/i686/
Install them in one command:

$ rpm -ivh Percona-Server-server-55-5.5.14-rel20.5.149.rhel5.i686.rpm \ Percona-Server-client-55-5.5.14-rel20.5.149.rhel5.i686.rpm \ Percona-Server-shared-55-5.5.14-rel20.5.149.rhel5.i686.rpm
If you dont install all at the same time, you will need to do it in a specic order - shared, client, server:
$ rpm -ivh Percona-Server-shared-55-5.5.14-rel20.5.149.rhel5.i686.rpm $ rpm -ivh Percona-Server-client-55-5.5.14-rel20.5.149.rhel5.i686.rpm $ rpm -ivh Percona-Server-server-55-5.5.14-rel20.5.149.rhel5.i686.rpm
Otherwise, the dependencies wont be met and the installation will fail.
10
Whats in each RPM?
Each of the Percona Server RPM packages have a particular purpose. The Percona-Server-server package contains the server itself (the mysqld binary). The Percona-Server-55-debuginfo package contains debug symbols for use debugging the database server. The Percona-Server-client package contains the command line client. The Percona-Server-devel package contains the header les needed to compile software using the client library. The Percona-Server-shared package includes the client shared library. The Percona-Server-shared-compat package includes shared libraries for software compiled against old versions of the client library. The Percona-Server-test package includes the test suite for Percona Server. DEB-Based Systems Download the packages of the desired series for your architecture from here. For example, at the moment of writing, for Ubuntu Maverick on i686, a way of doing this is:
$ wget -r -l 1 -nd -A deb -R "*dev*" \ http://www.percona.com/redir/downloads/Percona-Server-5.5/Percona-Server-5.5.14-20.5/deb/maverick/x86

$ sudo dpkg -i *.deb
The installation wont succeed as there will be missing dependencies. To handle this, use:
$ apt-get -f install
and all dependencies will be installed and the Percona Server installation will be nished by apt.
Whats in each DEB package?
The percona-server-server package contains the database server itself, the mysqld binary and associated les. The percona-server-common package contains les common to the server and client. The percona-server-client package contains the command line client. The percona-server-dfsg package contains.... The libmysqlclient-dev package contains header les needed to compile software to use the client library. The libmysqlclient18 package contains the client shared library. The 18 is a reference to the version of the shared library. The version is incremented when there is a ABI change that requires software using the client library to be recompiled or their source code modied.
2.1. Installing Percona Server 5.5 from Binaries
11
2.2 Installing Percona Server from a Source Tarball

Fetch and extract the source tarball. For example:
$ wget http://www.percona.com/redir/downloads/Percona-Server-5.5/Percona-Server-5.5.15-21.0/source/Pe $ tar xfz Percona-Server-5.5.15-rel21.0.tar.gz
Next, run cmake to congure the build. Here you can specify all the normal build options as you do for a normal MySQL build. Depending on what options you wish to compile Percona Server with, you may need other libraries installed on your system. Here is an example using a congure line similar to the options that Percona uses to produce binaries:
$ cmake . -DCMAKE_BUILD_TYPE=RelWithDebInfo -DBUILD_CONFIG=mysql_release -DFEATURE_SET=community -DWI
Now, compile using make

$ make
Install:
$ make install
2.3 Installing Percona Server from the Bazaar Source Tree

Percona uses the Bazaar revision control system for development. To build the latest Percona Server from the source tree you will need Bazaar installed on your system. Good practice is to use a shared repository, create one like this:
$ bzr init-repo ~/percona-server
You can now fetch the latest Percona Server 5.5 sources. In the future, we will provide instructions for fetching each specic Percona Server version and building it, but currently we will just talk about building the latest Percona Server 5.5 development tree.
$ cd ~/percona-server $ bzr branch lp:percona-server/5.5
You can now change into the 5.5 directory and build Percona Server 5.5:
$ make
This will fetch the upstream MySQL source tarball and apply the Percona Server patches to it. If you have the quilt utility installed, it will use it to apply the patches, otherwise it will just use the standard patch utility. You will then have a directory named Percona-Server that is ready to run the congure script and build.
$ cmake . -DCMAKE_BUILD_TYPE=RelWithDebInfo -DBUILD_CONFIG=mysql_release -DFEATURE_SET=community -DWI $ make $ make install
Note: PAM Authentication Plugin has been merged into Percona Server in 5.5.24-26.0 but it is not built with the server by default. In order to build the Percona Server with PAM plugin, additional option -DWITH_PAM=ON should be used.
12
2.4 Percona Sever In-Place Upgrading Guide: From 5.1 to 5.5

In-place upgrades are those which are done using the existing data in the server. Generally speaking, this is stopping the server, installing the new server and starting it with the same data les. While they may not be suitable for high-complexity environments, they may be adequate for many scenarios. Having this in mind, the changes in the in the 5.5 series can be grouped into 3 areas: Server conguration Server behavior and functioning SQL changes The following is a summary of the more relevant changes in the 5.5 series. For more details, see Percona Server documentation http://dev.mysql.com/doc/refman/5.5/en/upgrading-from-previous-series.html Warning: Upgrade 5.1 to 5.5 on a crashed instance is not recommended. If the server instance has crashed, crash recovery should be run before proceeding with the upgrade.
2.4.1 Changes in Server Conguration

Features and Variables The conguration options and table columns for the following features have been modied in Percona Server 5.5: Feature Improved InnoDB I/O Scalability Suppress Warning Messages Handle Corrupted Tables Expand Table Import Dump/Restore of the Buffer Pool at Startup Slow Query Log 5.1 Series innodb_adaptive_checkpoint 5.5 Series innodb_adaptive_ushing_method suppress_log_warning_1592 log_warnings_suppress innodb_pass_corrupt_table innodb_corrupt_table_action innodb_expand_import innodb_import_table_from_xtrabackup innodb_auto_lru_dump innodb_buffer_pool_restore_at_startup log_slow_timestamp_every slow_query_log_timestamp_always slow_query_log_microseconds_timestamp slow_query_log_timestamp_precision use_global_log_slow_control slow_query_log_use_global_control enable_query_response_time_stats query_response_time_stats innodb_extra_rsegments (removed) innodb_use_purge_thread using upstream version
Response Time Distribution Multiple Rollback Segments Dedicated Purge Thread

Shared Memory Buffer Pool
The SHM buffer pool patch has been replaced with the safer LRU Dump/Restore patch, which provides similar improvements in restart performance and has the advantage of persisting across machine restarts. The conguration variables for my.cnf have been kept for compatibility and warnings will be printed for the deprecated options (innodb_buffer_pool_shm_key and innodb_buffer_pool_shm_checksum) if used. Instructions for disabling the SHM buffer pool can be found here and for setting up LRU dump/restore here.
2.4. Percona Sever In-Place Upgrading Guide: From 5.1 to 5.5
13
Multiple Rollback Segments
Percona Server 5.1 offered a feature that enabled InnoDB to use multiple rollback segments, relieving a major cause of resource contention in write-intensive workloads. In MySQL 5.5, Oracle implemented a similar feature, and so in Percona Server 5.5, the innodb_extra_rsegments option has been replaced by the MySQL 5.5 innodb_rollback_segment option.
InnoDB Statistics
Three elds in table INNODB_INDEX_STATS were renamed: 5.1 Series row_per_keys index_size leaf_pages 5.5 Series rows_per_key index_total_pages index_leaf_pages
For more information, see its documentation documentation.

Process List
The columns ROWS_EXAMINED, ROWS_SENT, and ROWS_READ have been added to the SHOW PROCESSLIST command and the table PROCESSLIST. For more information, see its documentation documentation. Grepping Old Variables You can check if old variables are being used in your conguration le by issuing the following line in a shell:
egrep -ni innodb_adaptive_checkpoint|suppress_log_warning_1592|innodb_pass_corrupt_table|innodb_expa
New Features You may also want to check the new features available in Percona Server 5.5: Multiple Adaptive Hash Search Partitions Crash-Resistant Replication Show Engine InnoDB Status Plugins All plugins not included with Percona Server will have to be recompiled for Percona Server 5.5. There is a new plugin interface that complements the plugin API, plugins must be recompiled and linked to libmysqlservices. The plugins bundled with the server are already linked, you can list the installed plugins with the SHOW PLUGINS statement:
mysql> SHOW PLUGINS; +-----------------------+--------+--------------------+---------+---------+ | Name | Status | Type | Library | License | +-----------------------+--------+--------------------+---------+---------+ | binlog | ACTIVE | STORAGE ENGINE | NULL | GPL | ... +-----------------------+--------+--------------------+---------+---------+
For more information, see: 14 Chapter 2. Installation
http://dev.mysql.com/doc/refman/5.5/en/plugin-services.html http://dev.mysql.com/doc/refman/5.5/en/plugin-installing-uninstalling.html Upgrading from MySQL 5.1 If you are upgrading from MySQL 5.1 instead of Percona Server 5.1, you should take into account that the InnoDB Plugin has been included in the standard MySQL 5.5 distribution as default for the InnoDB storage engine. This change does not affect Percona Server as it has the XtraDB storage engine - an enhanced version of InnoDB built-in since the 5.1 series. If you are migrating from MySQL 5.1.X, and you were using the InnoDB plugin, make sure to remove it from the conguration le by deleting the following two lines from the [mysqld] section:
[mysqld] ignore-builtin-innodb # <- DELETE plugin-load=innodb=ha_innodb_plugin.so # <- DELETE
otherwise, the server wont start. Strictly speaking, the ignore-builtin-innodb option will disable XtraDB in Percona Server 5.5 if set, and the server will not start if no other default storage engine is specied (i.e. default-storage-engine=MyISAM). Also, the variable innodb_le_io_threads has been replaced by innodb_read_io_threads and innodb_write_io_threads (these variables were already introduced in Percona Server 5.1). All of them defaults to 4, you should replace the old variable with the two new ones with the proper value (or delete it if the default - 4 - is acceptable).
2.4.2 Changes in Server Behavior and Functioning

Privileges The schema of the grants tables in MySQL 5.5 has changed and a new table has been introduced, proxy_priv. The conversion to the new schema will be handled by mysql_upgrade (see below). Logs The server will not rename the current log le with the sufx -old when issuing a FLUSH LOGS statement. The renaming must be done by the user before ushing. It is important to note this as if it is not renamed before, the past log will be lost. Numeric calculations On the numeric side, the server includes a new a library for conversions between strings and numbers, dtoa. This library provides the basis for an improved conversion between string or DECIMAL values and approximate-value (FLOAT or DOUBLE) numbers. Also, all numeric operators and functions on integer, oating-point and DECIMAL values throw an out of range error (ER_DATA_OUT_OF_RANGE) rather than returning an incorrect value or NULL. If an application rely on previous numeric results, it may have to be adjusted to the new precision or behavior.
15
Replication When upgrading in a replication environment, a change in handling of IF NOT EXISTS results in an incompatibility for statement-based replication from a MySQL 5.1 master prior to 5.1.51 to a MySQL 5.5 slave. If you use CREATE TABLE IF NOT EXISTS ... higher. SELECT statements, upgrade the master rst to 5.1.51 or
Note that this differs from the usual replication upgrade advice of upgrading the slave rst. Indexes The stopword le is loaded and searched using latin1 if character_set_server is ucs2, utf16, or utf32. If any table was created with FULLTEXT indexes while the server character set was ucs2, utf16, or utf32, it should be repaired using this statement REPAIR TABLE tbl_name QUICK;. Error Messages The --language option has been deprecated and is an alias for --lc-messages-dir and --lc-messages. Also, error messages are now constructed in UTF-8 and returned with character_set_results encoding. Unicode Support The Unicode implementation has been extended to provide support for supplementary characters that lie outside the Basic Multilingual Plane (BMP), introducing the utf16, utf32 and utf8mb4 charsets. If you are considering upgrading from utf8 to utf8mb4 to take advantage of the supplementary characters, you may have to adjust the size of the elds and indexes in the future. See http://dev.mysql.com/doc/refman/5.5/en/charsetunicode-upgrading.html. Upgrading to utf8mb4 will not take place unless you explicitly change the charset, i.e. with a ALTER TABLE. . . statement. Changes in SQL The following changes require modications in the SQL statements in the client side: INTO clauses are no longer accepted in nested SELECT statements. Modify the SQL statements to not contain the clause. Alias declarations outside table_reference are not allowed for multiple-table DELETE statements. Modify those statements to use aliases only inside table_reference part. Alias resolution does not require qualication and alias reference should not be qualied with the database name. New reserved words: GENERAL IGNORE_SERVER_IDS MASTER_HEARTBEAT_PERIOD MAXVALUE RESIGNAL
16
SIGNAL SLOW TRUNCATE TABLE fails for a XtraDB table if there are any FOREIGN KEY constraints from other tables that reference the table. As XtraDB always use the fast truncation technique in 5.5 - equivalent to DROP TABLE and CREATE TABLE - you should modify the SQL statements to issue DELETE FROM table_name for such tables instead of TRUNCATE TABLE or an error will be returned in that cases.
2.4.3 BEFORE STARTING: FULL BACKUP

Before starting the upgrade, a full backup of the data must be done. Doing a full backup will guarantee us the safety of going back without consequences if something goes wrong. After all, its only one line:
$ innobackupex --user=DBUSER --password=SECRET /path/where/to/store/backup/
This will backup all the data in your server to a time stamped subdirectory of the path provided. innobackupex is a Perl script distributed with XtraBackup, a hot-backup utility for MySQL -based servers that doesnt block your database during the backup. If you dont have XtraBackup installed already, instructions can be found here. You should backup your entire conguration le - my.cnf - also. The le is usually located in /etc/mysql/ or /etc/ or as .my.cnf in users home directory,
$ cp /etc/mysql/my.cnf /path/where/to/store/backup/
While this is not an in-place upgrade technically, where possible, doing a full dump of the servers data for restoring it later is recommended. By this way, the indexes from all tables will be rebuilt explicitly, and any binary compatibility issue will be avoided:
$ mysqldump --user=root -p --all-databases --routines > mydata.sql
This is not possible in some cases because of available space or downtime requirements, but if it is feasible, it is highly recommended.
2.4.4 Upgrading using the Percona repositories

The easiest and recommended way of installing - where possible - is by using the Percona repositories. Instructions for enabling the repositories in a system can be found in: Percona APT Repository Percona YUM Repository DEB-based distributions Having done the full backup (or dump if possible), stop the server:
$ sudo /etc/init.d/mysqld stop
and proceed to do the modications needed in your conguration le, as explained at the beginning of this guide. Note: For extra safety doing the slow InnoDB shutdown before the upgrade is recommended. Then install the new server with:
17
$ sudo apt-get install percona-server-server-5.5
The installation script will run automatically mysql_upgrade to migrate to the new grant tables, rebuild the indexes where needed and then start the server. Note that this procedure is the same for upgrading from MySQL 5.1 or 5.5 to Percona Server 5.5. RPM-based distributions Having done the full backup (and dump if possible), stop the server:
$ /sbin/service mysql stop
and check your installed packages with:

$ rpm -qa | grep Percona-Server Percona-Server-client-51-5.1.57-rel12.8.232.rhel5.i686.rpm Percona-Server-server-51-5.1.57-rel12.8.232.rhel5.i686.rpm Percona-Server-shared-51-5.1.57-rel12.8.232.rhel5.i686.rpm
You may have a forth, shared-compat, which is for compatibility purposes. After checking, proceed to remove them without dependencies:
$ rpm -qa | grep Percona-Server | xargs rpm -e --nodeps
It is important that you remove it without dependencies as many packages may depend on these (as they replace mysql) and will be removed if omitted. Note that this procedure is the same for upgrading from MySQL 5.1 or 5.5 to Percona Server 5.5: just grep ^mysql- instead of Percona-Server and remove them. You will have to install the following packages: Percona-Server-server-55 Percona-Server-client-55
$ yum install Percona-Server-server-55 Percona-Server-client-55
Once installed, proceed to modify your conguration le - my.cnf - and recompile the plugins if necessary, as explained at the beginning of this guide. As the schema of the grant table has changed, the server must be started without reading them:
$ /usr/sbin/mysqld --skip-grant-tables --user=mysql &
and use mysql_upgrade to migrate to the new grant tables, it will rebuild the indexes needed and do the modications needed:
$ mysql_upgrade ... OK
Once this is done, just restart the server as usual:

$ /sbin/service mysql restart
If it cant nd the PID le, kill the server and start it normally:
18
$ killall /usr/sbin/mysqld $ /sbin/service mysql start
2.4.5 Upgrading using Standalone Packages

DEB-based distributions Having done the full backup (and dump if possible), stop the server:
$ sudo /etc/init.d/mysqld stop
and remove the installed packages with their dependencies:

$ sudo apt-get autoremove percona-server-server-51 percona-server-client-51
Once removed, proceed to do the modications needed in your conguration le, as explained at the beginning of this guide. Then, download the following packages for your architecture: percona-server-server-5.5 percona-server-client-5.5 percona-server-common-5.5 libmysqlclient16 At the moment of writing this guide, for Ubuntu Maverick on i686, a way of doing this is:
$ wget -r -l 1 -nd -A deb -R "*dev*" http://www.percona.com/redir/downloads/Percona-Server-5.5/Percon

$ sudo dpkg -i *.deb
The installation wont succeed as there will be missing dependencies. To handle this, use: $ apt-get -f install and all dependencies will be handled by apt. The installation script will run automatically mysql_upgrade to migrate to the new grant tables and rebuild the indexes where needed. RPM-based distributions Having done the full backup (and dump if possible), stop the server:
$ /sbin/service mysql stop
and check your installed packages:

$ rpm -qa | grep Percona-Server Percona-Server-client-51-5.1.57-rel12.8.232.rhel5.i686.rpm Percona-Server-server-51-5.1.57-rel12.8.232.rhel5.i686.rpm Percona-Server-shared-51-5.1.57-rel12.8.232.rhel5.i686.rpm
19
You may have a forth, shared-compat, which is for compatibility purposes. After checked that, proceed to remove them without dependencies:
$ rpm -qa | grep Percona-Server | xargs rpm -e --nodeps
It is important that you remove it without dependencies as many packages may depend on these (as they replace mysql) and will be removed if ommited. Note that this procedure is the same for upgrading from MySQL 5.1 to Percona Server 5.5, just grep ^mysql- instead of Percona-Server and remove them. Download the following packages for your architecture: Percona-Server-server-55 Percona-Server-client-55 Percona-Server-shared-55 At the moment of writing this guide, a way of doing this is:
$ wget -r -l 1 -nd -A rpm -R "*devel*,*debuginfo*" http://www.percona.com/redir/downloads/Percona-Ser

$ rpm -ivh Percona-Server-server-55-5.5.12-rel20.3.118.rhel5.i686.rpm \ Percona-Server-client-55-5.5.12-rel20.3.118.rhel5.i686.rpm \ Percona-Server-shared-55-5.5.12-rel20.3.118.rhel5.i686.rpm
If you dont install all at the same time, you will need to do it in a specic order - shared, client, server:
$ rpm -ivh Percona-Server-shared-55-5.5.12-rel20.3.118.rhel5.i686.rpm $ rpm -ivh Percona-Server-client-55-5.5.12-rel20.3.118.rhel5.i686.rpm $ rpm -ivh Percona-Server-server-55-5.5.12-rel20.3.118.rhel5.i686.rpm
Otherwise, the dependencies wont be met and the installation will fail. Once installed, proceed to modify your conguration le - my.cnf - and recompile the plugins if necessary, as explained at the beginning of this guide. As the schema of the grant table has changed, the server must be started without reading them:
$ /usr/sbin/mysqld --skip-grant-tables --user=mysql &
and use mysql_upgrade to migrate to the new grant tables, it will rebuild the indexes needed and do the modications needed:
$ mysql_upgrade
After this is done, just restart the server as usual:

$ /sbin/service mysql restart
If it cant nd the pid le, kill the server and start it normally:
$ killall /usr/sbin/mysqld $ /sbin/service mysql start
2.4.6 Other Reading

Upgrading MySQL: Best Practices webinar, 20 Chapter 2. Installation
Upgrading MySQL webinar questiones
21
22
CHAPTER
THREE
SCALABILITY IMPROVEMENTS
3.1 Improved Buffer Pool Scalability
The InnoDB buffer pool is a well known point of contention when many queries are executed concurrently. In XtraDB, the global mutex protecting the buffer pool has been split into several mutexes to decrease contention. This feature splits the single global InnoDB buffer pool mutex into several mutexes: Name buf_pool_mutex LRU_list_mutex ush_list_mutex page_hash_latch free_list_mutex zip_free_mutex zip_hash_mutex Protects ags about IO LRU list of blocks in buffer pool ush list of dirty blocks to ush hash table to search blocks in buffer pool list of free blocks in buffer pool lists of free area to treat compressed pages hash table to search compressed pages
The goal of this change is to reduce mutex contention, which can be very impacting when the working set does not t in memory.
3.1.1 Other Information

Detecting Mutex Contention You can detect when you suffer from mutex contention in the buffer pool by reading the information provided in the SEMAPHORES section of the output of SHOW ENGINE INNODB STATUS: Under normal circumstances this section should look like this:
SEMAPHORES ---------OS WAIT ARRAY INFO: reservation count 50238, signal count 17465 Mutex spin waits 0, rounds 628280, OS waits 31338 RW-shared spins 38074, OS waits 18900; RW-excl spins 0, OS waits 0
If you have a high-concurrency workload this section may look like this:
1 2 3 4 5 ---------SEMAPHORES ---------OS WAIT ARRAY INFO: reservation count 36255, signal count 12675 --Thread 10607472 has waited at buf/buf0rea.c line 420 for 0.00 seconds the semaphore:
23
6 Mutex at 0x358068 created file buf/buf0buf.c line 597, lock var 0 7 waiters flag 0 8 --Thread 3488624 has waited at buf/buf0buf.c line 1177 for 0.00 seconds the semaphore: 9 Mutex at 0x358068 created file buf/buf0buf.c line 597, lock var 0 10 waiters flag 0 11 --Thread 6896496 has waited at btr/btr0cur.c line 442 for 0.00 seconds the semaphore: 12 S-lock on RW-latch at 0x8800244 created in file buf/buf0buf.c line 547 13 a writer (thread id 14879600) has reserved it in mode exclusive 14 number of readers 0, waiters flag 1 15 Last time read locked in file btr/btr0cur.c line 442 16 Last time write locked in file buf/buf0buf.c line 1797 [...] 17 Mutex spin waits 0, rounds 452650, OS waits 22573 18 RW-shared spins 27550, OS waits 13682; RW-excl spins 0, OS waits 0
Note that in the second case you will see indications that threads are waiting for a mutex created in the le buf/buf0buf.c (lines 5 to 7 or 8 to 10). Such an indication is a sign of buffer pool contention.
3.2 Congurable Insert Buffer

Percona has implemented several changes related to MySQLs InnoDB Insert Buffer. These features enable adjusting the insert buffer to the different workloads and hardware congurations.
3.2.1 System variables:

variable innodb_ibuf_active_contract Version Info 5.5.8-20.0 Introduced Command Line Yes Cong File Yes Scope Global Dynamic Yes Variable Type Numeric Default Value 1 Range 0 - 1 This variable species whether the insert buffer can be processed before it reaches its maximum size. The following values are allowed: 0: the insert buffer is not processed until it is full. This is the standard InnoDB behavior. 1: the insert buffer can be processed even it is not full. variable innodb_ibuf_accel_rate Version Info 5.5.8-20.0 Introduced Command Line Yes Cong File Yes 24 Chapter 3. Scalability Improvements
Scope Global Dynamic Yes Default Value 100 Range 100 - 999999999 This variable allows better control of the background thread processing the insert buffer. Each time the thread is called, its activity is altered by the value of both innodb_io_capacity and innodb_ibuf_accel_rate this way:
[real activity] = [default activity] * (innodb_io_capacity/100) * (innodb_ibuf_accel_rate/100)
By increasing the value of innodb_ibuf_accel_rate, you will increase the insert buffer activity. variable innodb_ibuf_max_size Command Line Yes Cong File Yes Scope Global Dynamic No Variable Type Numeric Default Value Half the size of the InnoDB buffer pool Range 0 - Half the size of the InnoDB buffer pool Units Bytes This variable species the maximum size of the insert buffer. By default the insert buffer is half the size of the buffer pool so if you have a very large buffer pool, the insert buffer will be very large too and you may want to restrict its size with this variable. Setting this variable to 0 is equivalent to disabling the insert buffer. But then all changes to secondary indexes will be performed synchronously which will probably cause performance degradation. Likewise a too small value can hurt performance. If you have very fast storage (ie storage with RAM-level speed, not just a RAID with fast disks), a value of a few MB may be the best choice for maximum performance.
3.2.2 Other Reading

Some little known facts about InnoDB Insert Buffer 5.0.75-build12 Percona binaries
3.3 Improved InnoDB I/O Scalability

InnoDB is a complex storage engine. It must be congured properly in order to perform at its best. Some points are not congurable in standard InnoDB, however. The goal of this feature is to provide a more exhaustive set of options for XtraDB. Note that some of these parameters are already available in the InnoDB plugin. These new variables are divided into several categories: Conguration of the capacity of the I/O subsystem (number of read and write threads, number of available I/O operations per second) Additional options to control the ushing and checkpointing activities
3.3. Improved InnoDB I/O Scalability
25
Conguration of the insert buffer (maximum size, activity) Various other options
3.3.1 Version Specic Information

5.5.19-24.0 Added option value cont for variable innodb_flush_neighbor_pages. 5.5.8-20.0 Added variable innodb_adaptive_flushing_method. Added variable innodb_ibuf_active_merge. Added variable innodb_ibuf_merge_rate. Added variable innodb_use_global_flush_log_at_trx_commit. 5.5.20-beta The reex value was removed from innodb_adaptive_flushing_method in 5.5.20-beta as a x for bug #689450.
3.3.2 System Variables

variable innodb_adaptive_flushing Command Line NOT AVAILABLE Variable Type BOOLEAN Default Value TRUE This is an existing InnoDB variable used to attempt ushing dirty pages in a way that avoids I/O bursts at checkpoints. In XtraDB, the default value of the variable is changed from that in InnoDB. variable innodb_adaptive_flushing_method Version Info 5.5.8-20.0 Introduced Command Line YES Cong File YES Scope GLOBAL Dynamic YES Type STRING Default Value estimate Allowed Values native, estimate, keep_average (or 0/1/2, respectively, for compatibility) This variable controls the way adaptive checkpointing is performed. InnoDB constantly ushes dirty blocks from the buffer pool. Normally, the checkpoint is done passively at the current oldest page modication (this is called fuzzy checkpointing). When the checkpoint age nears the maximum checkpoint age (determined by the total length of all transaction log les), InnoDB tries to keep the checkpoint age away from the maximum by ushing many dirty blocks. But, if there are many updates per second and many blocks have almost the same modication age, the huge number of ushes can cause stalls.
26
Chapter 3. Scalability Improvements
Adaptive checkpointing forces a constant ushing activity at a rate of approximately [modied age / maximum checkpoint age]. This can avoid or soften the impact of stalls casued by aggressive ushing. The following values are allowed: native [0]: This setting causes checkpointing to operate exactly as it does in native InnoDB. estimate [1]: If the oldest modied age exceeds 1/4 of the maximum age capacity, InnoDB starts ushing blocks every second. The number of blocks ushed is determined by [number of modied blocks], [LSN progress speed] and [average age of all modied blocks]. So, this behavior is independent of the innodb_io_capacity variable for the 1-second loop, but the variable still has an effect for the 10-second loop. keep_average [2]: This method attempts to keep the I/O rate constant by using a much shorter loop cycle (0.1 second) than that of the other methods (1.0 second). It is designed for use with SSD cards. reflex: This behavior is similar to innodb_max_dirty_pages_pct ushing. The difference is that this method starts ushing blocks constantly and contiguously based on the oldest modied age. If the age exceeds 1/2 of the maximum age capacity, InnoDB starts weak contiguous ushing. If the age exceeds 3/4, InnoDB starts strong ushing. The strength can be adjusted by the MySQL variable innodb_io_capacity. In other words, we must tune innodb_io_capacity for the reflex method to work the best. This method was removed in 5.5.20-beta as a x for bug #689450. variable innodb_checkpoint_age_target Command Line Yes Cong File Yes Scope GLOBAL Dynamic Yes Variable Type Numeric Default Value 0 Range 0+ This variable controls the maximum value of the checkpoint age if its value is different from 0. If the value is equal to 0, it has no effect. It is not needed to shrink innodb_log_file_size to tune recovery time. variable innodb_flush_method Command Line Yes Cong File Yes Scope Global Dyn No Variable Type Enumeration Default Value fdatasync Allowed Values fdatasync, O_DSYNC, O_DIRECT, ALL_O_DIRECT This is an existing MySQL 5.5 system variable. It determines the method InnoDB uses to ush its data and log les. (See innodb_flush_method in the MySQL 5.5 Reference Manual). The following values are allowed: fdatasync: use fsync() to ush both the data and log les.
27
O_SYNC: use O_SYNC to open and ush the log les; use fsync() to ush the data les. O_DIRECT: use O_DIRECT to open the data les and fsync() system call to ush both the data and log les. ALL_O_DIRECT: use O_DIRECT to open both data and log les, and use fsync() to ush the data les but it is skipped for all log les writes. This option is recommended when InnoDB log les are big (more than 8GB), otherwise there might be even a performance degradation. Note: When using this option on ext4 lesystem variable innodb_log_block_size should be set to 4096 (default log-block-size in ext4) in order to avoid the unaligned AIO/DIO warnings. variable innodb_flush_neighbor_pages Version Info 5.5.19-24.0 Introduced option value cont Command Line Yes Cong File Yes Scope Global Dynamic Yes Variable Type Enumeration Default Value area Range none, area, cont This variable species whether, when the dirty pages are ushed to the data le, the neighbor pages in the data le are also ushed at the same time or not. The following values (and their numeric counterparts 0, 1 and 2 for older patch compatibility) are available: none: disables the feature. area (default): enables ushing of non-contiguous neighbor pages. For each page that is about to be ushed, look into its vicinity for other dirty pages and ush them too. This value implements the standard InnoDB behavior. If you use a storage which has no head seek delay (e.g. SSD or enough memory for write buffering), none or cont may show better performance. cont: enable ushing of contiguous neighbor pages. For each page that is about to be ushed, look if there is a contiguous block of dirty pages surrounding it. If such block is found it is ushed in a sequential I/O operation as opposed to several random I/Os if area is used. variable innodb_read_ahead Command Line Yes Cong File Yes Scope Global Dynamic Yes Variable Type String Default Value linear Allowed Values none, random (*), linear, both This variable controls the read-ahead algorithm of InnoDB. The following values are available: none: disables read-ahead random: if enough pages within the same extent are in the buffer pool, InnoDB will automatically fetch the remaining pages (an extent consists of 64 consecutive pages)
28
linear (default): if enough pages within the same extent are accessed sequentially, InnoDB will automatically fetch the remaining pages both: enable both random and linear algorithms. You can also control the threshold from which InnoDB will perform a read ahead request with the innodb_read_ahead_threshold variable (*) random is removed from InnoDB Plugin 1.0.5, XtraDB ignores it after 1.0.5. variable innodb_use_global_flush_log_at_trx_commit Version Info 5.5.8-20.0 Introduced Command Line Yes Cong File Yes Scope Global Dynamic Yes Type Boolean Default Value True Range True/False This variable is used to control the ability of the user to set the value of the global MySQL variable innodb_flush_log_at_trx_commit. If innodb_use_global_flush_log_at_trx_commit=0 (False), the client can set the global MySQL variable, using:
SET innodb_use_global_flush_log_at_trx_commit=N
If innodb_use_global_flush_log_at_trx_commit=1 (True), the user session will use the current value of innodb_flush_log_at_trx_commit, and the user cannot reset the value of the global variable using a SET command. variable innodb_log_block_size Command Line Yes Cong File Yes Scope Global Dynamic No Variable Type Numeric Default Value 512 Units Bytes This variable changes the size of transaction log records. The default size of 512 bytes is good in most situations. However, setting it to 4096 may be a good optimization with SSD cards. While settings other than 512 and 4096 are possible, as a practical matter these are really the only two that it makes sense to use. Clean restart and removal of the old logs is needed for the variable innodb_log_block_size to be changed. variable innodb_log_file_size Version Info 5.5.8-20.0 Introduced
29
Command Line Yes Cong File Yes Scope Global Dynamic No Type Numeric Default Value 5242880 Range 1048576 .. 4294967295 In upstream MySQL the limit for the combined size of log les must be less than 4GB. But in Percona Server it is: on 32-bit systems: individual log le limit is 4 GB and total log le size limit is 4 GB, i.e. the same as in the upstream server. on 64-bit systems: both individual log les and total log le size are practically unlimited (the limit is 2^63 - 1 bytes which is 8+ million TB). variable innodb_purge_threads Command Line Yes Cong File Yes Scope Global Dynamic No Type Numeric Default Value 1 This variable is the same as the one in the upstream version. The only difference is the default value, in Percona Server it is 1 while in the upstream version is 0. Status Variables The following information has been added to SHOW ENGINE INNODB STATUS to conrm the checkpointing activity:
The max checkpoint age The current checkpoint age target The current age of the oldest page modification which has not been flushed to disk yet. The current age of the last checkpoint ... --LOG --Log sequence number 0 1059494372 Log flushed up to 0 1059494372 Last checkpoint at 0 1055251010 Max checkpoint age 162361775 Checkpoint age target 104630090 Modified age 4092465 Checkpoint age 4243362 0 pending log writes, 0 pending chkp writes ...
30
3.3.3 Other Reading

For Fusion-IO devices-specic tuning, see Atomic write support for Fusion-io devices documentation.
3.4 Multiple Adaptive Hash Search Partitions

The InnoDB adaptive hash index can have contention issues on multi-core systems when you run a mix of read and write queries that need to scan secondary indexes. This feature splits the adaptive hash index across several partitions to avoid such problems. The number of adaptive hash partitions specied by the variable innodb_adaptive_hash_index_partitions are created, and hash indexes are assigned to each one based on index_id. This should help to solve contention problems in the adaptive hash search process when they occur. Version Specic Information Percona Server Version Comments 5.5.8-20.0 Initially released.

variable innodb_adaptive_hash_index_partitions Version Info 5.5.8-20.0 Introduced Command Line Yes Cong File Yes Scope Global Dynamic No Variable Type Numeric Def 1 Range 1-64, (on 32-bit platform 1-32) Species the number of partitions to use in the adaptive hash search process. When set to one, no extra partitions are created and the normal process is in effect. When greater than one, the specied number of partitions are created across which to perform the adaptive search.
3.4.2 Other reading

Index lock and adaptive search
3.5 Multiple Rollback Segments

In Percona Server 5.1, an improvement was provided for write-intensive workloads that allowed multiple rollback segments to be used. It has been removed from Percona Server 5.5.11-20.2 because an equivalent variable, innodb_rollback_segment, has been implemented in MySQL 5.5, and so the MySQL 5.5 implementation is available in Percona Server 5.5.
3.4. Multiple Adaptive Hash Search Partitions
31
Percona Server, in addition to the upstream multiple rollback segment implementation, provides the additonal Information Schema table: INFORMATION_SCHEMA.INNODB_RSEG.
3.5.1 INFORMATION_SCHEMA Tables

This feature provides the following table: table INFORMATION_SCHEMA.INNODB_RSEG Columns rseg_id rollback segment id space_id space where the segment placed zip_size compressed page size in bytes if compressed otherwise 0 page_no page number of the segment header max_size max size in pages curr_size current size in pages This table shows information about all the rollback segments (the default segment and the extra segments). Here is an example of output with innodb_extra_rsegments = 8
mysql> select * from information_schema.innodb_rseg; +---------+----------+----------+---------+------------+-----------+ | rseg_id | space_id | zip_size | page_no | max_size | curr_size | +---------+----------+----------+---------+------------+-----------+ | 0 | 0 | 0 | 6 | 4294967294 | 1 | | 1 | 0 | 0 | 13 | 4294967294 | 2 | | 2 | 0 | 0 | 14 | 4294967294 | 1 | | 3 | 0 | 0 | 15 | 4294967294 | 1 | | 4 | 0 | 0 | 16 | 4294967294 | 1 | | 5 | 0 | 0 | 17 | 4294967294 | 1 | | 6 | 0 | 0 | 18 | 4294967294 | 1 | | 7 | 0 | 0 | 19 | 4294967294 | 1 | | 8 | 0 | 0 | 20 | 4294967294 | 1 | +---------+----------+----------+---------+------------+-----------+ 9 rows in set (0.00 sec)
32
CHAPTER
FOUR
PERFORMANCE IMPROVEMENTS
4.1 Atomic write support for Fusion-io devices
Note: This feature implementation is considered BETA quality. DirectFS lesystem on Fusion-io devices supports atomic writes. Atomic writes can be used instead of InnoDB doublewrite buffer to guarantee that the InnoDB data pages will be written to disk entirely or not at all. When atomic writes are enabled the device will take care of protecting the data against partial writes. In case the doublewrite buffer is enabled it will be disabled automatically. This will improve the write performance, because data doesnt need to be written twice anymore, and make the recovery simpler.

5.5.31-30.3 Atomic write support for Fusion-io feature implemented. This feature was ported from MariaDB.

variable innodb_use_atomic_writes Command Line Yes Cong File Yes Scope Global Dynamic No Variable Type Boolean Default Value 0 (OFF) This variable can be used to enable or disable atomic writes instead of the doublewrite buffer. When this option is enabled (set to 1), doublewrite buffer will be disabled on InnoDB initialization and the le ush method will be set to O_DIRECT if its not O_DIRECT or ALL_O_DIRECT already. Warning: innodb_use_atomic_writes should only be enabled on supporting devices, otherwise InnoDB will fail to start.
33
4.1.3 Other Reading

For general InnoDB tuning Improved InnoDB I/O Scalability documentation is available. FusionIO DirectFS atomic write support in *MariaDB* Atomic Writes Accelerate MySQL Performance
4.2 Drop table performance

Warning: This feature has been removed and its controlling variable innodb_lazy_drop_table has been deprecated from Percona Server 5.5.30-30.2. Feature has been removed because the upstream DROP TABLE implementation has been improved. When innodb_le_per_table is set to 1, doing a DROP TABLE can take a long time on servers with a large buffer pool, even on an empty InnoDB table. This is because InnoDB has to scan through the buffer pool to purge pages that belong to the corresponding tablespace. Furthermore, no other queries can start while that scan is in progress. This feature allows you to do background table drop.

5.5.10-20.1 Feature added. 5.5.30-30.2 Feature deprecated.

variable innodb_lazy_drop_table Command Line Yes Cong File Yes Scope Global Dynamic Yes Variable Type BOOL Default Value FALSE Range TRUE/FALSE When this option is ON, XtraDB optimizes that process by only marking the pages corresponding to the tablespace being deleted. It defers the actual work of evicting those pages until it needs to nd some free pages in the buffer pool. When this option is OFF, the usual behavior for dropping tables is in effect.
4.2.3 Related Reading

Drop table performance blog post.
34
Chapter 4. Performance Improvements
4.3 Conguration of the Doublewrite Buffer

InnoDB and XtraDB use a special feature called the doublewrite buffer to provide a strong guarantee against data corruption. The idea is to write the data to a sequential log in the main tablespace before writing to the data les. If a partial page write happens (in other words, a corrupted write), InnoDB and XtraDB will use the buffer to recover the data. Even if the data is written twice the performance impact is usually small, but in some heavy workloads the doublewrite buffer becomes a bottleneck. Now we have an option to put the buffer on a dedicated disk in order to parallelize I/O activity on the buffer and on the tablespace. This feature allows you to move the doublewrite buffer from the main tablespace to a separate location. This option is for advanced users only. See the discussion below to fully understand whether you really need to use it.
4.3.1 Detailed Information

The following discussion will clarify the improvements made possible by this feature. Goal of the Doublewrite Buffer InnoDB and XtraDB use many structures, some on disk and others in memory, to manage data as efciently as possible. To have an overview of the different components see this post. Lets now focus on the doublewrite buffer. InnoDB / XtraDB uses a reserved area in its main tablespace, called the doublewrite buffer, to prevent data corruption that could occur with partial page writes. When the data in the buffer pool is ushed to disk, InnoDB / XtraDB will ush whole pages at a time (by default 16KB pages) and not just the records that have changed within a page. It means that, if anything unexpected happens during the write, the page can be partially written leading to corrupt data. With the doublewrite buffer feature, InnoDB / XtraDB rst writes the page in the doublewrite buffer and then to the data les. If a partial page write occurs in the data les, InnoDB / XtraDB will check on recovery if the checksum of the page in the data le is different from the checksum of the page in the doublewrite buffer and thus will know if the page is corrupt or not. If it is corrupt, the recovery process will use the page stored in the doublewrite buffer to restore the correct data. If a partial write occurs in the doublewrite buffer, the original page is untouched and can be used with the redo logs to recover the data. Performance Impact of the Doublewrite Buffer In usual workloads the performance impact is low-5% or so. As a consequence, you should always enable the doublewrite buffer because the strong guarantee against data corruption is worth the small performance drop. But if you experience a heavy workload, especially if your data does not t in the buffer pool, the writes in the doublewrite buffer will compete against the random reads to access the disk. In this case, you can see a sharp performance drop compared to the same workload without the doublewrite buffer-a 30% performance degradation is not uncommon. Another case when you can see a big performance impact is when the doublewrite buffer is full. Then new writes must wait until entries in the doublewrite buffer are freed.
4.3. Conguration of the Doublewrite Buffer
35
Whats New with This Feature In a standard InnoDB / XtraDB installation, the doublewrite buffer is located in the main tablespace (whether you activate the innodb_file_per_table or not) and you have no option to control anything about it. The feature adds an option (innodb_doublewrite_file) to have a dedicated location for the doublewrite buffer. How to Choose a Good Location for the Doublewrite Buffer Basically if you want to improve the I/O activity, you will put the doublewrite buffer on a different disk. But is it better on an SSD or a more traditional HDD? First you should note that pages are written in a circular fashion in the doublewrite buffer and only read on recovery. So the doublewrite buffer performs mostly sequential writes and a few sequential reads. Second HDDs are very good at sequential write if a write cache is enabled, which is not the case of SSDs. Therefore you should choose a fast HDD if you want to see performance benets from this option. For instance, you could place the redo logs (also written in a sequential way) and the doublewrite buffer on the same disk.

5.5.8-20.0 Full functionality available.

The following system variable was introduced. variable innodb_doublewrite_file Command Line Yes Cong File Yes Scope Global Dynamic No Variable Type STR Def NULL Use this option to create a dedicated tablespace for the doublewrite buffer. This option expects a lename which can be specied either with an absolute or a relative path. A relative path is relative to the data directory.

XtraDB / InnoDB internals in drawing InnoDB Double Write SSD and HDD for InnoDB
36
4.4 Query Cache Enhancements

This page describes the enhancements for the query cache. At the moment three features are available: Disabling the cache completely Diagnosing contention more easily Ignoring comments
4.4.1 Diagnosing contention more easily

This features provides a new thread state - Waiting on query cache mutex. It has always been difcult to spot query cache bottlenecks because these bottlenecks usually happen intermittently and are not directly reported by the server. This new thread state appear in the output of SHOW PROCESSLIST, easing diagnostics. Imagine that we run three queries simultaneously (each one in a separate thread): > SELECT number from t where id > 0; > SELECT number from t where id > 0; > SELECT number from t where id > 0; If we experience query cache contention, the output of SHOW PROCESSLIT will look like this:
> SHOW PROCESSLIST; Id User Host 2 root localhost 3 root localhost 4 root localhost 5 root localhost db test test test test Command Sleep Query Query Query Time 2 2 1 0 State NULL Waiting on query cache mutex Waiting on query cache mutex NULL Info
SELECT number f SELECT number
4.4.2 Ignoring comments

This feature adds an option to make the server ignore comments when checking for a query cache hit. For example, consider these two queries:
/* first query */ select name from users where users.name like Bob%; /* retry search */ select name from users where users.name like Bob%;
By default (option off), the queries are considered different, so the server will execute them both and cache them both. If the option is enabled, the queries are considered identical, so the server will execute and cache the rst one and will serve the second one directly from the query cache.

variable query_cache_strip_comments Command Line Yes Cong File Yes Scope Global Dynamic Yes Variable Type Boolean Default Value Off
4.4. Query Cache Enhancements
37
Makes the server ignore comments when checking for a query cache hit. Other Reading MySQL general thread states Query cache freezes
4.5 Fast InnoDB Checksum

Warning: This feature has been deprecated after Percona Server 5.5.28-29.2 and it will not be available in Percona Server 5.6, because the innodb_checksum_algorithm feature in MySQL 5.6 makes it redundant. InnoDB writes a checksum at the end of each data page in order to detect data les corruption. However computing this checksum requires CPU cycles and in some circumstances this extra overhead can become signicant. XtraDB can use a more CPU-efcient algorithm, based on 4-byte words, which can be benecial for some workloads (for instance write-heavy workloads on servers that can perform lots of IO). The original algorithm is checked after the new one, so you can have data pages with old checksums and data pages with new checksums. However in this case, you may experience slow reads from pages having old checksums. If you want to have the entire benet of this change, you will need to recreate all your InnoDB tables, for instance by dumping and reloading all InnoDB tables. Once enabled, turning it off will require table(s) to be dump/imported, since it will fail to start on data les created when innodb_fast_checksums was enabled. In this case ALTER TABLE wont work due to its implementation.

variable innodb_fast_checksum Command Line Yes Cong File Yes Scope Global Dynamic No Variable Type BOOL Default Value 0
4.6 Remove Excessive Function Calls (fcntl)

This change removes a bottleneck at the client/server protocol level for high concurrency workloads. When reading a packet from a socket, the read can be performed either in non-blocking mode or in blocking mode. The non-blocking mode was originally chosen because it avoids the cost of setting up an alarm in case of a timeout: thus the rst attempt to read is done in non-blocking mode, and only if it fails, the next attempts are done in blocking mode. However, this behavior can hurt performance as the switch from non-blocking mode to blocking mode is expensive, requiring calls to the fcntl function and calls into the kernel.
38
The solution is to use socket timeouts, with the SO_RCVTIMEO and SO_SNDTIMEO options. This way, the timeouts are automatically handled by the operating system, which means that all reads can be done in blocking mode.
4.6.1 Other Reading

fcntl Bottleneck Use of non-blocking mode for sockets limits performance
4.7 Reduced Buffer Pool Mutex Contention

We removed buffer_pool mutex operations on counting blocks on LRU list where it is safe to delete. As drawback we may have some inaccurate information of LRU list, but it does not affect storage engine operations. As result we have decreased contention on buffer_pool mutex.
4.8 InnoDB timer-based Concurrency Throttling

If the variable innodb_thread_concurrency_timer_based has been set to TRUE, lock-free timer-based InnoDB method of handling thread concurrency will be used instead of original mutex-based method.

variable innodb_thread_concurrency_timer_based Command Line Yes Cong File Yes Scope Global Dynamic No Variable Type BOOL Default Value FALSE Range TRUE/FALSE Note: This feature depends on atomic op builtins being available.
4.9 Improved NUMA support

In cases where the buffer pool memory allocation was bigger than size of the node, system would start swapping already allocated memory even if there is available memory on other node. This is would happen if the default NUMA memory allocation policy was selected. In that case system would favor one node more than other which caused the node to run out of memory. Changing the allocation policy to interleaving, memory will be allocated in round-robing fashion over the available node. This can be done by using the mysqld_safe numa_interleave option. Another improvement implemented is preallocating the pages in the buffer pool on startup with innodb_buffer_pool_populate variable. This forces NUMA allocation decisions to be made immediately while the buffer cache is clean. 4.7. Reduced Buffer Pool Mutex Contention 39
It is generally recommended to enable all of the options together to maximize the performance effects on the NUMA architecture.

5.5.28-29.1 Improved NUMA support implemented. This feature was ported from Twitters MySQL patches.

variable innodb_buffer_pool_populate Command Line Yes Cong File No Location mysqld Scope Global Dynamic No Variable Type Boolean Default Value 0 Range 0/1 When this variable is enabled, InnoDB preallocates pages in the buffer pool on startup to force NUMA allocation decisions to be made immediately while the buffer cache is clean.
4.9.3 Command-line Options

variable flush_caches Command Line No Cong File Yes Location mysqld_safe Dynamic No Variable Type Boolean Default Value 0 Range 0/1 When enabled this will ush and purge buffers/caches before starting the server to help ensure NUMA allocation fairness across nodes. This option is useful for establishing a consistent and predictable behavior for normal usage and/or benchmarking. variable numa_interleave Command Line No Cong File Yes Location mysqld_safe Dynamic No Variable Type Boolean 40 Chapter 4. Performance Improvements
Default Value 0 Range 0/1 When this option is enabled, mysqld will run with its memory interleaved on all NUMA nodes by starting it with numactl --interleave=all. In case there is just 1 CPU/node, allocations will be interleaved between that node.
4.9.4 Other Reading

The MySQL swap insanity problem and the effects of the NUMA architecture A brief update on NUMA and MySQL
4.10 HandlerSocket
4.10.1 Description
HandlerSocket is a MySQL plugin that implements a NoSQL protocol for MySQL. This allows applications to communicate more directly with MySQL storage engines, without the overhead associated with using SQL. This includes operations such as parsing and optimizing queries, as well as table handling operations (opening, locking, unlocking, closing). As a result, using HandlerSocket can provide much better performance for certain applications that using normal SQL application protocols. Complete documentation on the HandlerSocket plugin, including installation and conguration options, is located here. The plugin is disabled by default. To enable it in Percona Server with XtraDB, see below.

5.5.11-20.2 Full functionality available. Other Information Author/Origin Akira Higuchi, DeNA Co., Ltd.
4.10.3 Enabling the Plugin

Once HandlerSocket has been downloaded and installed on your system, there are two steps required to enable it. First, add the following lines to the [mysqld] section of your my.cnf le:
loose_handlersocket_port = 9998 # the port number to bind to for read requests loose_handlersocket_port_wr = 9999 # the port number to bind to for write requests loose_handlersocket_threads = 16 # the number of worker threads for read requests loose_handlersocket_threads_wr = 1 # the number of worker threads for write requests open_files_limit = 65535 # to allow handlersocket to accept many concurrent # connections, make open_files_limit as large as # possible.
4.10. HandlerSocket
41
Second, log in to mysql as root, and execute the following query:

mysql> install plugin handlersocket soname handlersocket.so;
4.10.4 Testing the Plugin installation

If handlersocket.so was successfully installed, it will begin accepting connections on ports 9998 and 9999. Executing a SHOW PROCESSLIST command should show HandlerSocket worker threads:
mysql> SHOW PROCESSLIST; +----+-------------+-----------------+---------------+---------+------+-----------------------------| Id | User | Host | db | Command | Time | State +----+-------------+-----------------+---------------+---------+------+-----------------------------| 1 | system user | connecting host | NULL | Connect | NULL | handlersocket: mode=rd, 0 con | 2 | system user | connecting host | NULL | Connect | NULL | handlersocket: mode=rd, 0 con ... | 16 | system user | connecting host | NULL | Connect | NULL | handlersocket: mode=rd, 0 con | 17 | system user | connecting host | handlersocket | Connect | NULL | handlersocket: mode=wr, 0 con
To ensure HandlerSocket is working as expected, you can follow these steps: Create a new table:
mysql> CREATE TABLE t ( id int(11) NOT NULL, col varchar(20) NOT NULL, PRIMARY KEY (id) ) ENGINE=InnoDB;
Insert a row with HandlerSocket (elds are separated by comma):

$ telnet 127.0.0.1 9999 Trying 127.0.0.1... Connected to 127.0.0.1. Escape character is ^]. P 1 test t 0 1 1 + 2 1 0 1
PRIMARY id,col test value
And check in SQL that the row has been written:

mysql> SELECT * FROM t; +----+------------+ | id | col | +----+------------+ | 1 | test value | +----+------------+
Conguration options HandlerSocket has many conguration options that are detailed here.
4.10.5 Other Reading

Yoshinori Matsunobus blog post describing HandlerSocket
42
Percona Server now both SQL and NOSQL
4.11 Thread Pool

Note: This feature implementation is considered BETA quality. MySQL executes statements using one thread per client connection. Once the number of connections increases past a certain point performance will degrade. This feature enables the server to keep the top performance even with large number of client connections by introducing a dynamic thread pool. By using the thread pool server would decrease the number of threads, which will then reduce the context switching and hot locks contentions. Using the thread pool will have the most effect with OLTP workloads (relatively short CPU-bound queries). In order to enable the thread pool variable thread_handling should be set up to pool-of-threads value. This can be done by adding:
thread_handling=pool-of-threads
to the MySQL conguration le my.cnf. Although the default values for the thread pool should provide good performance, additional tuning can be performed with the dynamic system variables described below. Note: Current implementation of the thread pool is built in the server, unlike the upstream version which is implemented as a plugin. Another signicant implementation difference is that this implementation doesnt try to minimize the number of concurrent transactions like the MySQL Enterprise Threadpool. Because of these things this implementation isnt compatible with the upstream one.
4.11.1 Priority connection scheduling

In Percona Server 5.5.30-30.2 priority connection scheduling for thread pool has been implemented. Even though thread pool puts a limit on the number of concurrently running queries, the number of open transactions may remain high, because connections with already started transactions are put to the end of the queue. Higher number of open transactions has a number of implications on the currently running queries. To improve the performance new thread_pool_high_prio_tickets variable has been introduced. This variable controls the high priority queue policy. Each new connection is assigned this many tickets to enter the high priority queue. Whenever a query has to be queued to be executed later because no threads are available, the thread pool puts the connection into the high priority queue if the following conditions apply: 1. The connection has an open transaction in the server. 2. The number of high priority tickets of this connection is non-zero. If both the above conditions hold, the connection is put into the high priority queue and its tickets value is decremented. Otherwise the connection is put into the common queue with the initial tickets value specied with this option. Each time the thread pool looks for a new connection to process, rst it checks the high priority queue, and picks connections from the common queue only when the high priority one is empty. The goal is to minimize the number of open transactions in the server. In many cases it is benecial to give shortrunning transactions a chance to commit faster and thus deallocate server resources and locks without waiting in the
4.11. Thread Pool
43
same queue with other connections that are about to start a new transaction, or those that have run out of their high priority tickets. With the default value of 0, all connections are always put into the common queue, i.e. no priority scheduling is used as in the original implementation in MariaDB. The higher is the value, the more chances each transaction gets to enter the high priority queue and commit before it is put in the common queue.

5.5.29-30.0 Thread Pool feature implemented. This feature was ported from MariaDB. 5.5.30-30.2 Implemented priority connection scheduling and introduced new variable thread_pool_high_prio_tickets to the original implementation introduced in MariaDB.

variable thread_pool_idle_timeout Command Line Yes Cong File Yes Scope Global Dynamic Yes Variable Type Numeric Default Value 60 (seconds) This variable can be used to limit the time an idle thread should wait before exiting. variable thread_pool_high_prio_tickets Command Line Yes Cong File Yes Scope Global Dynamic Yes Variable Type Numeric Default Value 0 This variable controls the high priority queue policy. Each new connection is assigned this many tickets to enter the high priority queue. variable thread_pool_max_threads Command Line Yes Cong File Yes Scope Global Dynamic Yes Variable Type Numeric Default Value 500 This variable can be used to limit the maximum number of threads in the pool. Once this number is reached no new threads will be created. 44 Chapter 4. Performance Improvements
variable thread_pool_oversubscribe Command Line Yes Cong File Yes Scope Global Dynamic Yes Variable Type Numeric Default Value 3 The higher the value of this parameter the more threads can be run at the same time, if the values is lower than 3 it could lead to more sleeps and wake-ups. variable thread_pool_size Command Line Yes Cong File Yes Scope Global Dynamic Yes Variable Type Numeric Default Value Number of processors This variable can be used to dene the number of threads that can use the CPU at the same time. variable thread_pool_stall_limit Command Line Yes Cong File Yes Scope Global Dynamic No Variable Type Numeric Default Value 500 (ms) The number of milliseconds before a running thread is considered stalled. When this limit is reached thread pool will wake up or create another thread. This is being used to prevent a long-running query from monopolizing the pool. variable extra_port Command Line Yes Cong File Yes Scope Global Dynamic No Variable Type Numeric Default Value 0 This variable can be used to specify additional port Percona Server will listen on. This can be used in case no new connections can be established due to all worker threads being busy or being locked when pool-of-threads feature is enabled. To connect to the extra port following command can be used:
4.11. Thread Pool
45
mysql --port=extra-port-number --protocol=tcp
variable extra_max_connections Command Line Yes Cong File Yes Scope Global Dynamic Yes Variable Type Numeric Default Value 1 This variable can be used to specify the maximum allowed number of connections on the extra port. This can be used with the extra_port variable to access the server in case no new connections can be established due to all worker threads being busy or being locked when pool-of-threads feature is enabled.
4.11.4 Status Variables

variable Threadpool_idle_threads Command Line Yes Variable Type Numeric This status variable shows the number of idle threads in the pool. variable Threadpool_threads Command Line Yes Variable Type Numeric This status variable shows the number of threads in the pool.

Thread pool in MariaDB 5.5 Thread pool implementation in Oracle MySQL
4.12 Binary Log Group Commit

In cases when strict durability and recoverability is required and the storage that provides fast syncs is unavailable, setting up the variables innodb_flush_log_at_trx_commit =1 and sync_binlog =1 can result in big performance drop. Note: Variable innodb_flush_log_at_trx_commit makes sure that every transaction is written to the disk and that it can survive the server crash. In case the binary log is used for replication sync_binlog makes sure that every transaction written to the binary log matches the one executed in the storage engine. More information about these variables can be found in the MySQL documentation. Performance drop happening when these variables are enabled is caused by additional fsync() system calls on both binary and XtraDB REDO log when committing a transaction, that are needed to store the additional information on
46
the disk. Binary Log Group Commit feature can use a single fsync() call to force data to the storage for multiple concurrently committing transactions, which provides throughput improvements in a write-concurrent workload. Because there are no negative effects of this feature, it has been enabled by default and cant be disabled. Effects of this feature can be measured by the binlog_commits and binlog_group_commits status variables. The bigger the difference between these two variables the bigger is the performance gained with this feature.

5.5.18-23.0 Ported MariaDB Group commit for the binary log patch

variable binlog_commits Command Line Yes Scope Session Variable Type Numeric This variable shows the total number of transactions committed to the binary log. variable binlog_group_commits Command Line Yes Scope Session Variable Type Numeric This variable shows the total number of group commits done to the binary log.

Testing the Group Commit Fix Fixing MySQL group commit
4.12. Binary Log Group Commit
47
48
CHAPTER
FIVE
FLEXIBILITY IMPROVEMENTS
5.1 Support of Multiple Page Sizes
Warning: This feature has been deprecated in the Percona Server 5.5.30-30.2. It has been replaced by the upstream version released in MySQL 5.6.4. Percona Server has implemented support for multiple InnoDB page sizes. This can be used to increase the IO performance by setting this value close to storage device block size. InnoDB page size can be set up with the innodb_page_size variable.

variable innodb_page_size Command Line Yes Cong File Yes Scope Global Dynamic No Variable Type ULONG Default Value 16384 Range 4096, 8192, 16384 EXPERIMENTAL: The universal page size of the database. Changing for an existing database is not supported. Use at your own risk!
5.2 Suppress Warning Messages

This feature is intended to provide a general mechanism (using log_warnings_silence) to disable certain warning messages to the log le. Currently, it is only implemented for disabling message #1592 warnings. This feature does not inuence warnings delivered to a client.
49

5.5.8-20.0: System variable log_warnings_silence introduced. 5.5.10-20.1: Renamed variable log_warnings_silence to log_warnings_suppress.

variable log_warnings_suppress Version Info 5.5.8-20.0 Introduced. 5.5.10-20.1 Renamed. Command Line Yes Cong File Yes Scope Global Dynamic Yes Variable Type SET Default Value (empty string) Range (empty string), 1592 This variable was added in beta release 5.5.8-20.0 as log_warnings_silence and renamed in release 5.5.1020.1. It is intended to provide a more general mechanism for disabling warnings than existed previously with variable suppress_log_warning_1592. When set to the empty string, no warnings are disabled. When set to 1592, warning #1592 messages (unsafe statement for binary logging) are suppressed. In the future, the ability to optionally disable additional warnings may also be added.

MySQL bug 42851 MySQL InnoDB replication InnoDB Startup Options and System Variables InnoDB Error Handling
5.3 Handle BLOB End of Line

At some point in the past, the MySQL command line client was modied to remove \r before \n in its input. This caused problems in some workloads, specically when loading BLOB elds containing \r characters. Percona Server solves this by implementing a new command line client option, no-remove-eol-carret. When the no-remove-eol-carret option is specied, \r before \n is not removed.
50
Chapter 5. Flexibility Improvements

5.5.8-20.0: Full functionality.
5.3.2 Client Command Line Parameter

variable no-remove-eol-carret Command Line Yes Cong File Yes Scope Local Dynamic No Variable Type Boolean Default Value Off Range On/Off
5.4 Fixed Size for the Read Ahead Area

InnoDB dynamically calculates the size of the read-ahead area in case it has to trigger its read-ahead algorithm. When the workload involves heavy I/O operations, this size is computed so frequently that it has a non-negligeable impact on the CPU usage. This variable only depends on the size of the buffer pool set by the innodb_buffer_pool_size variable, and as soon as the buffer pool has a size properly greater than 1024 pages (or 16 MB), it is always 64. With this change, its value is xed to 64, thus removing a bottleneck experienced by some users. Please note that the minimum allowed value for the InnoDB buffer pool is de facto set to 32 MB. This change is a port of the feature from Facebook: http://bazaar.launchpad.net/~mysqlatfacebook/mysqlatfacebook/5.1/revision/3538

5.5.8-20.0 : Full functionality available.

Author/Origin: Facebook Bugs xed: #606811
5.4.3 Other Reading

BUF_READ_AHEAD_AREA Bottleneck
5.4. Fixed Size for the Read Ahead Area
51
5.5 Fast Shutdown

Some InnoDB / XtraDB threads which perform various background activities are in the sleep state most of the time. They only wake up every few seconds to perform their tasks. They also check whether the server is in the shutdown phase, and if not, they go to the sleep state again. That means there could be a noticeable delay (up to 10 seconds) after a shutdown command and before all InnoDB / XtraDB threads actually notice this and terminate. This is not a big problem for most production servers, because a shutdown of a heavily loaded server normally takes much longer than 10 seconds. The problem, however, had a signicant impact on running the regression test suite, because it performs a lot of server restarts during its execution and also because there is not so much to do when shutting a test server. So it makes even less sense to wait up to 10 seconds. This change modies that behavior to make the sleep waiting interruptible, so that when the server is told to shutdown, threads no longer wait until the end of their sleep interval. This results in a measurably faster test suite execution (~40% in some cases). The change was contributed by Kristian Nielsen.


Author / Origin: Kristian Nielsen Bugs xed: #643463
5.5.3 Other reading

How to decrease InnoDB shutdown times How long InnoDB shutdown may take
5.6 Improved MEMORY Storage Engine

As of MySQL 5.5.15, a Fixed Row Format (FRF) is still being used in the MEMORY storage engine. The xed row format imposes restrictions on the type of columns as it assigns on advance a limited amount of memory per row. This renders a VARCHAR eld in a CHAR eld in practice and makes impossible to have a TEXT or BLOB eld with that engine implementation. To overcome this limitation, the Improved MEMORY Storage Engine is introduced in this release for supporting true VARCHAR, VARBINARY, TEXT and BLOB elds in MEMORY tables. This implementation is based on the Dynamic Row Format (DFR) introduced by the mysql-heap-dynamic-rows patch. DFR is used to store column values in a variable-length form, thus helping to decrease memory footprint of those columns and making possible BLOB and TEXT elds and real VARCHAR and VARBINARY. Unlike the xed implementation, each column value in DRF only uses as much space as required. This is, for variablelength values, up to 4 bytes is used to store the actual value length, and then only the necessary number of blocks is used to store the value.
52
Rows in DFR are represented internally by multiple memory blocks, which means that a single row can consist of multiple blocks organized into one set. Each row occupies at least one block, there can not be multiple rows within a single block. Block size can be congured when creating a table (see below). This DFR implementation has two caveats regarding to ordering and indexes.
5.6.1 Caveats
Ordering of Rows In the absence of ORDER BY, records may be returned in a different order than the previous MEMORY implementation. This is not a bug. Any application relying on a specic order without an ORDER BY clause may deliver unexpected results. A specic order without ORDER BY is a side effect of a storage engine and query optimizer implementation which may and will change between minor MySQL releases. Indexing It is currently impossible to use indexes on BLOB columns due to some limitations of the Dynamic Row Format. Trying to create such an index will fail with the following error:
BLOB column <name> cant be used in key specification with the used table type.
5.6.2 Restrictions
For performance reasons, a mixed solution is implemented: the xed format is used at the beginning of the row, while the dynamic one is used for the rest of it. The size of the xed-format portion of the record is chosen automatically on CREATE TABLE and cannot be changed later. This, in particular, means that no indexes can be created later with CREATE INDEX or ALTER TABLE when the dynamic row format is used. All values for columns used in indexes are stored in xed format at the rst block of the row, then the following columns are handled with DRF. This sets two restrictions to tables: the order of the elds and therefore, the minimum size of the block used in the table. Ordering of Columns The columns used in xed format must be dened before the dynamic ones in the CREATE TABLE statement. If this requirement is not met, the engine will not be able to add blocks to the set for these elds and they will be treated as xed. Minimum Block Size The block size has to be big enough to store all xed-length information in the rst block. If not, the CREATE TABLE or ALTER TABLE statements will fail (see below).
5.6. Improved MEMORY Storage Engine
53
5.6.3 Setting Row Format

Taking the restrictions into account, the Improved MEMORY Storage Engine will choose DRF over FRF at the moment of creating the table according to following criteria: There is an implicit request of the user in the column types OR There is an explicit request of the user AND the overhead incurred by DFR is benecial. Implicit Request The implicit request by the user is taken when there is at least one BLOB or TEXT column in the table denition. If there are none of these columns and no relevant option is given, the engine will choose FRF. For example, this will yield the use of the dynamic format:
mysql> CREATE TABLE t1 (f1 VARCHAR(32), f2 TEXT, PRIMARY KEY (f1)) ENGINE=HEAP;
While this will not:

mysql> CREATE TABLE t1 (f1 VARCHAR(16), f2 VARCHAR(16), PRIMARY KEY (f1)) ENGINE=HEAP;
Explicit Request The explicit request is set with one of the following options in the CREATE TABLE statement: KEY_BLOCK_SIZE = <value> Requests the DFR with the specied block size (in bytes) ROW_FORMAT = DYNAMIC Requests the dynamic format with the default block size (256 bytes) Despite its name, the KEY_BLOCK_SIZE option refers to a block size used to store data rather then indexes. The reason for this is that an existing CREATE TABLE option is reused to avoid introducing new ones. The Improved MEMORY Engine checks whether the specied block size is large enough to keep all key column values. If it is too small, table creation will abort with an error. After DRF is requested explicitly and there are no BLOB or TEXT columns in the table denition, the Improved MEMORY Engine will check if using the dynamic format provides any space saving benets as compared to the xed one: if the xed row length is less than the dynamic block size (plus the dynamic row overhead - platform dependent) OR there isnt any variable-length columns in the table or VARCHAR elds are declared with length 31 or less, the engine will revert to the xed format as it is more space efcient in such case. The row format being used by the engine can be checked using SHOW TABLE STATUS.
5.6.4 Examples
On a 32-bit platform:
54
mysql> CREATE TABLE t1 (f1 VARCHAR(32), f2 VARCHAR(32), f3 VARCHAR(32), f4 VARCHAR(32), PRIMARY KEY (f1)) KEY_BLOCK_SIZE=124 ENGINE=HEAP ROW_FORMAT=DYNAMIC; mysql> SHOW TABLE STATUS LIKE t1; Name Engine Version Row_format t1 MEMORY 10 Dynamic 0
Rows X
Avg_row_length 0 X
Data_length 0 0
Max_data_length Index_l NULL NULL NULL
On a 64-bit platform:
mysql> CREATE TABLE t1 (f1 VARCHAR(32), f2 VARCHAR(32), f3 VARCHAR(32), f4 VARCHAR(32), PRIMARY KEY (f1)) KEY_BLOCK_SIZE=124 ENGINE=HEAP ROW_FORMAT=DYNAMIC; mysql> SHOW TABLE STATUS LIKE t1; Name Engine Version Row_format t1 MEMORY 10 Fixed 0
Rows X
Avg_row_length 0 X
Data_length 0 0
Max_data_length Index_l NULL NULL NULL
5.6.5 Implementation Details

MySQL MEMORY tables keep data in arrays of xed-size chunks. These chunks are organized into two groups of HP_BLOCK structures: group1 contains indexes, with one HP_BLOCK per key (part of HP_KEYDEF), group2 contains record data, with a single HP_BLOCK for all records. While columns used in indexes are usually small, other columns in the table may need to accommodate larger data. Typically, larger data is placed into VARCHAR or BLOB columns. The Improved MEMORY Engine implements the concept of dataspace, HP_DATASPACE, which incorporates the HP_BLOCK structures for the record data, adding more information for managing variable-sized records. Variable-size records are stored in multiple chunks, which means that a single record of data (a database row) can consist of multiple chunks organized into one set, contained in HP_BLOCK structures. In variable-size format, one record is represented as one or many chunks depending on the actual data, while in xedsize mode, one record is always represented as one chunk. The index structures would always point to the rst chunk in the chunkset. Variable-size records are necessary only in the presence of variable-size columns. The Improved Memory Engine will be looking for BLOB or VARCHAR columns with a declared length of 32 or more. If no such columns are found, the table will be switched to the xed-size format. You should always put such columns at the end of the table denition in order to use the variable-size format. Whenever data is being inserted or updated in the table, the Improved Memory Engine will calculate how many chunks are necessary. For INSERT operations, the engine only allocates new chunksets in the recordspace. For UPDATE operations it will modify the length of the existing chunkset if necessary, unlinking unnecessary chunks at the end, or allocating and adding more if a larger length is needed. When writing data to chunks or copying data back to a record, xed-size columns are copied in their full format, while VARCHAR and BLOB columns are copied based on their actual length, skipping any NULL values. When allocating a new chunkset of N chunks, the engine will try to allocate chunks one-by-one, linking them as they become allocated. For allocating a single chunk, it will attempt to reuse a deleted (freed) chunk. If no free chunks are available, it will try to allocate a new area inside a HP_BLOCK. When freeing chunks, the engine will place them at the front of a free list in the dataspace, each one containing a reference to the previously freed chunk.
5.6. Improved MEMORY Storage Engine
55
The allocation and contents of the actual chunks varies between xed and variable-size modes: Format of a xed-size chunk: uchar[] * With sizeof=chunk_dataspace_length, but at least sizeof(uchar*) bytes. It keeps actual data or pointer to the next deleted chunk, where chunk_dataspace_length equals to full record length uchar * Status eld (1 means in use, 0 means deleted) Format of a variable-size chunk: uchar[] * With sizeof=chunk_dataspace_length, but at least sizeof(uchar*) bytes. It keeps actual data or pointer to the next deleted chunk, where chunk_dataspace_length is set according to tables key_block_size uchar* * Pointer to the next chunk in this chunkset, or NULL for the last chunk uchar * Status eld (1 means rst, 0 means deleted, 2 means linked) Total chunk length is always aligned to the next sizeof(uchar*).
5.6.6 See Also

Dynamic row format for MEMORY tables
5.7 Restricting the number of binlog les

Maximum number of binlog les can now be restricted in Percona Server with max_binlog_files. When variable max_binlog_files is set to non-zero value, the server will remove the oldest binlog le(s) whenever their number exceeds the value of the variable. This variable can be used with the existing max_binlog_size variable to limit the disk usage of the binlog les. If max_binlog_size is set to 1G and max_binlog_files to 20 this will limit the maximum size of the binlogs on disk to 20G. The actual size limit is not necessarily max_binlog_size * max_binlog_files. Server restart or FLUSH LOGS will make the server start a new log le and thus resulting in log les that are not fully written in these cases limit will be lower.

5.5.27-29.0: Variable max_binlog_files introduced.

variable max_binlog_files Version Info
56
5.5.27-29.0 Introduced. Command Line Yes Cong File Yes Scope Global Dynamic Yes Variable Type ULONG Default Value 0 (unlimited) Range 0-102400
5.7.3 Example
Number of the binlog les before setting this variable
$ ls -l mysql-bin.0* | wc -l 26
Variable max_binlog_files is set to 20:

max_binlog_files = 20
In order for new value to take effect FLUSH LOGS needs to be run. After that the number of binlog les is 20
$ ls -l mysql-bin.0* | wc -l 20
5.8 Ignoring missing tables in mysqldump

In case table name was changed during the mysqldump process taking place, mysqldump would stop with error:
Couldnt execute show create table testtable Table testdb.tabletest doesnt exist (1146)\n")
This could happen if mysqldump was taking a backup of a working slave and during that process table name would get changed. This error happens because mysqldump takes the list of the tables at the beginning of the dump process but the SHOW CREATE TABLE happens just before the table is being dumped. With this option mysqldump will still show error to stderr, but it will continue to work and dump the rest of the tables.

5.5.8-20.0 mysqldump option --ignore-create-error introduced
5.9 Extended SELECT INTO OUTFILE/DUMPFILE

Percona Server has extended the SELECT INTO ... OUTFILE and SELECT INTO DUMPFILE commands to add the support for UNIX sockets and named pipes. Before this was implemented the database would return an error for such les.
5.8. Ignoring missing tables in mysqldump
57
This feature allows using LOAD DATA LOCAL INFILE in combination with SELECT INTO OUTFILE to quickly load multiple partitions across the network or in other setups, without having to use an intermediate le which wastes space and I/O.

5.5.34-32.0 - Feature Implemented
5.9.2 Other Reading

MySQL bug: #44835
58
CHAPTER
SIX
RELIABILITY IMPROVEMENTS
6.1 Crash-Resistant Replication
This feature makes replication much more reliable after a crash by making the replicas position relative to the master transactional. MySQL replication normally stores its position in a le that is neither durable nor consistent. Thus, if the replica crashes, it can re-execute committed transactions. This usually causes replication to fail, potentially forcing the replicas data to be re-initialized from the master or from a recent backup. The improvement in Percona Server makes InnoDB store the replication position transactionally, and overwrite the usual relay_log.info le upon recovery, so replication restarts from the correct position and does not try to re-execute committed transactions. This change greatly improves the durability of MySQL replication. It can be set to activate automatically, so replication just works and no intervention is necessary after a crash.
6.1.1 Restrictions
When innodb_overwrite_relay_log_info is enabled, you should only update InnoDB / XtraDB tables, not MyISAM tables or other storage engines. You should not use relay or binary log lenames longer than 480 characters (normal: up to 512). If longer, the replication position information is not recorded in InnoDB.
6.1.2 Example Server Error Log Output

Upon crash recovery, the error log on a replica will show information similar to the following:
InnoDB: .... InnoDB: InnoDB: InnoDB: InnoDB: InnoDB: Starting crash recovery. Apply batch completed In a MySQL replication slave the last master binlog file position 0 468, file name gauntlet3-bin.000015 and relay log file position 0 617, file name ./gauntlet3-relay-bin.000111
If this feature is enabled, the output will look like the following, with additional lines prexed with a + symbol:
.... + InnoDB: + InnoDB: + InnoDB: + InnoDB: .... InnoDB:
Warning: innodb_overwrite_relay_log_info is enabled. Updates of other storage engines may h relay-log.info is detected. relay log: position 429, file name ./gauntlet3-relay-bin.000111 master log: position 280, file name gauntlet3-bin.000015 Starting crash recovery.
59
.... InnoDB: Apply batch completed + InnoDB: In a MySQL replication slave the last master binlog file + InnoDB: position 0 468, file name gauntlet3-bin.000015 + InnoDB: and relay log file + InnoDB: position 0 617, file name ./gauntlet3-relay-bin.000111 090205 17:41:31 InnoDB Plugin 1.0.2-3 started; log sequence number 57933 + InnoDB: relay-log.info have been overwritten. .... 090205 17:41:31 [Note] Slave SQL thread initialized, starting replication in log gauntlet3-bin.00
In this case, the master log position was overwritten to 468 from 280, so replication will start at position 468 and not repeat the transaction beginning at 280.

5.5.10-20.1: Renamed variable innodb_recovery_update_relay_log. innodb_overwrite_relay_log_info to

One new system variable was introduced by this feature. variable innodb_overwrite_relay_log_info Version Info 5.5.10-20.1 Renamed. Command Line Yes Cong File Yes Scope Global Dynamic No Variable Type BOOLEAN Default Value FALSE Range TRUE/FALSE If set to true, InnoDB overwrites relay-log.info at crash recovery when the information is different from the record in InnoDB. This variable was renamed to innodb_recovery_update_relay_log, beginning in release 5.5.10-20.1. It still exists as innodb_overwrite_relay_log_info in versions prior to that. variable innodb_recovery_update_relay_log Version Info 5.5.10-20.1 Introduced. Command Line Yes Cong File Yes Scope Global Dynamic No
60
Chapter 6. Reliability Improvements
Variable Type BOOLEAN Default Value FALSE Range TRUE/FALSE If set to true, InnoDB overwrites relay-log.info at crash recovery when the information is different from the record in InnoDB. This variable was added in release 5.5.10-20.1. Prior to that, innodb_overwrite_relay_log_info, which still exists in earlier versions. it was named
6.1.5 Other Reading

Another solution for MySQL 5.0 is Googles transactional replication feature, but it had some problems and bugs. Related bug (xed and re-implemented in this feature) A blog post explaining how this feature makes replication more reliable
6.2 Too Many Connections Warning

This feature issues the warning Too many connections to the log, if log_warnings is enabled.
6.2.1 Version-Specic Information

5.5.8-20.0: Full functionality available.
6.3 Error Code Compatibility

Percona Server with XtraDB has error code incompatibilities with MySQL 5.5. It is important to maintain compatibility in the error codes used by the servers. For example, scripts that may be run on both servers could contain references to error codes. The reasons for the current incompatibilities are: Percona Server with XtraDB contains features that have been backported from MyQL 5.5. Some of the MySQL 5.5 features added new error codes. Some Percona Server with XtraDB features have added new error codes. The solution to the rst problem is to preserve MySQL 5.5 error codes in the Percona Server. An example of where this has been done is Percona Server feature Query Cache Enhancements. This feature adds error ER_QUERY_CACHE_DISABLED to the Percona Server, which is dened as error code 1651 in MySQL 5.5. After migrating Percona Server / XtraDB to MySQL 5.5, users might experience troubles because of this. The solution to the second problem is to insure that unique error codes are chosen, when adding new ones to Percona Server, that will never be duplicated during MySQL development. For example, MySQL has a tool comp_err that generates: errmsg.sys les header le include/mysqld_error.h
6.2. Too Many Connections Warning
61
header le include/mysqld_ername.h from the le errmsg.txt. To keep error numbers consistent, we should add some ctive errors to errmsg.txt, because comp_err assigns error code numbers sequentially, without gaps. I propose patch to comp_err. This patch allows usage of a new syntax, with prex PADD, for example:
PADD_QUERY_CACHE_DISABLED 1651 eng "ER_QUERY_CACHE_DISABLED padding to 1651 error" ER_QUERY_CACHE_DISABLED eng "Query cache is disabled; restart the server with query_cache_type=1 to enable it"
comp_err with my patch padds empty intervals (from last error code number to 1651) by error message ER_QUERY_CACHE_DISABLED padding to 1651 error, i.e. and ER_QUERY_CACHE_DISABLED now has error code 1651 (as desired). I propose to use this patch for Percona errors, for example:
PADD_PERCONA_NEW_ERROR_CODE 4000 end "Padd empty space to error code number 4000 (Percona error codes)" ...some percona error codes...
Patch only adds prex PADD_ and padds error in sys les. All other MySQL code (load*.sys les, my_error, etc) works as old one.

6.4 Handle Corrupted Tables

Instead of crashing the server as they used to do, corrupted InnoDB tables are simply disabled, so that the database remains available while the corruption is being xed. This feature adds a new system variable.

5.5.10-20.1: Renamed innodb_corrupt_table_action. variable innodb_pass_corrupt_table to

variable innodb_pass_corrupt_table Version Info 5.5.10-20.1 Renamed. Command Line Yes Cong File Yes Scope Global
62
Dynamic Yes Variable Type ULONG Default Value 0 Range 0 - 1 Return error 1194 (ER_CRASHED_ON_USAGE) instead of crashing with an assertion failure, when used with innodb_file_per_table. Once corruption is detected, access to the corrupted tablespace is disabled. The only allowed operation on a corrupted tablespace is DROP TABLE. The only exception to this rule is when the option value is salvage (see below). This variable was renamed to innodb_corrupt_table_action, beginning in release 5.5.10-20.1. The option name was innodb_pass_corrupt_table in versions prior to that. variable innodb_corrupt_table_action Version Info 5.5.10-20.1 Introduced. Command Line Yes Cong File Yes Scope Global Dynamic Yes Variable Type ENUM Default Value assert Range assert, warn, salvage With the default value XtraDB will intentionally crash the server with an assertion failure as it would normally do when detecting corrupted data in a single-table tablespace. If the warn value is used it will pass corruption of the table as corrupt table instead of crashing itself. For this to work innodb_file_per_table should be enabled. All le I/O for the datale after detected as corrupt is disabled, except for the deletion. When the option value is salvage, XtraDB allows read access to a corrupted tablespace, but ignores corrupted pages. This variable was added in release 5.5.10-20.1. Prior to that, it was named innodb_pass_corrupt_table, which still exists in earlier versions.
6.5 Lock-Free SHOW SLAVE STATUS

The STOP SLAVE and SHOW SLAVE STATUS commands can conict due to a global lock in the situation where one thread on a slave attempts to execute a STOP SLAVE command, while a second thread on the slave is already running a command that takes a long time to execute. If a STOP SLAVE command is given in this situation, it will wait and not complete execution until the long-executing thread has completed its task. If another thread now executes a SHOW SLAVE STATUS command while the STOP SLAVE command is waiting to complete, the SHOW SLAVE STATUS command will not be able to execute while the STOP SLAVE command is waiting. This features modies the SHOW SLAVE STATUS syntax to allow:
SHOW SLAVE STATUS NOLOCK
6.5. Lock-Free SHOW SLAVE STATUS
63
This will display the slaves status as if there were no lock, allowing the user to detect and understand the situation that is occurring. NOTE: The information given when NOLOCK is used may be slightly inconsistent with the actual situation while the lock is being held.

5.5.8-20.0: Introduced
64
CHAPTER
SEVEN
MANAGEMENT IMPROVEMENTS
7.1 InnoDB Recovery Stats
When the variable innodb_recovery_stats is enabled and XtraDB has to do recovery on startup, server will write detailed recovery statistics information to the error log. This info will be written after the recovery process is nished. Example of output statistics for recovery process:
------------------RECOVERY STATISTICS ------------------Recovery time: 18 sec. (1 turns) Data page IO statistics Requested pages: 9126 Read pages: 9126 Written pages: 7957 (Dirty blocks): 1156 Grouping IO [times]: number of pages, read request neighbors (in 32 pages chunk), combined read IO, combined write IO 1, 32, 335, 548 2, 0, 121, 97 3, 7, 49, 44 4, 4, 43, 26 .... 64, 0, 2, 25 Recovery process statistics Checked pages by doublewrite buffer: Overwritten pages from doublewrite: Recovered pages by io_thread: Recovered pages by main thread: Parsed log records to apply: Sum of the length: Applied log records: Sum of the length: Pages which are already new enough: Oldest pages LSN: Newest pages LSN:
128 0 9145 0 2572491 71274689 2376356 68098300 93 926917970 1526578232
65

variable innodb_recovery_stats Command Line No Cong File Yes Dynamic No Variable Type BOOL Default Value FALSE Range TRUE/FALSE
7.1.2 Other reading

How to estimate time it takes InnoDB to recover? InnoDB recovery - is large buffer pool always better? What is the longest part of InnoDB recovery process? Improving InnoDB recovery time How long is recovery from 8G innodb_log_le
7.2 InnoDB Data Dictionary Size Limit

This feature lets users limit the amount of memory used for InnoDB s data dictionary. It was introduced in release 5.0.77-b13 of Percona Server with XtraDB. The data dictionary is InnoDB s internal catalog of tables. InnoDB stores the data dictionary on disk, and loads entries into memory while the server is running. This is somewhat analogous to MySQL s table cache, but instead of operating at the server level, it is internal to the InnoDB storage engine. This feature permits you to control how InnoDB manages the data dictionary in memory, but does not modify on-disk storage. In standard InnoDB, the size of the data dictionary depends on the number and size of tables opened in the server. Once a table is opened, it is never removed from the data dictionary unless you drop the table or you restart the server. In some cases, the data dictionary grows extremely large. If this consumes enough memory, the server will begin to use virtual memory. Use of virtual memory can cause swapping, and swapping can cause severe performance degradation. By providing a way to set an upper limit to the amount of memory the data dictionary can occupy, this feature provides users a way to create a more predictable and controllable situation. If your data dictionary is taking up more than a gigabyte or so of memory, you may benet from this feature. A data dictionary of this size normally occurs when you have many tens of thousands of tables. For servers on which tables are accessed little by little over a signicant portion of time, memory usage will grow steadily over time, as if there is a memory leak. For servers that access every table fairly soon after being started, memory usage will increase quickly and then stabilize. If you;re using Percona Server, you can determine the actual size of the data dictionary. (See Show Hashed Memory.) However, if youre not using Percona Server, you can still make an estimate of the data dictionarys size. (See Estimating the Data Dictionary Size below.) Please note that this variable only sets a soft limit on the memory consumed by the data dictionary. In some cases, memory usage will exceed the limit (see Implementation Details below for more).
66
Chapter 7. Management Improvements

The following system variable was introduced by this feature. variable innodb_dict_size_limit Command Line Yes Cong File Yes Scope Global Dynamic Yes Variable Type ULONG Default Value 0 Range 0-LONG_MAX Units Bytes This variable places a soft upper bound on the amount of memory used by tables in the data dictionary. When the allocated memory exceeds this amount, InnoDB tries to remove some unused entries, if possible. The default value of 0 indicates an unlimited amount of memory and results in the same behavior as standard InnoDB.

The following status variable was introduced by this feature: variable Innodb_dict_tables Variable Type LONG Scope Global This status variable shows the number of entries in the InnoDB data dictionary cache.
7.2.3 Choosing a Good Value

As a rough guide, a server that is likely to run into problems with an oversized data dictionary is probably a powerful machine with a lot of memory, perhaps 48GB or more. A gigabyte seems like a comfortable upper limit on the data dictionary for such a server, but this is a matter of opinion and you should choose a value that makes sense to you. You might nd it helpful to understand how much memory each table requires in the dictionary. Quick tests on a 32-bit server show that the data dictionary requires a minimum of about 1712 bytes per table, plus 288 bytes per column, and about 570 bytes for each index. The number might be higher on a 64-bit server due to the increased size of pointers. Please do not rely on these rules of thumb as absolute truth. We do not know an exact formula for the memory consumption, and would appreciate your input if you investigate it more deeply.

This feature tries to remove the least recently used InnoDB tables from the data dictionary. To achieve this, we need to sort entries in the dictionary in a LRU fashion and to know whether the table is used by the server. The rst part is provided by an existing LRU algorithm in InnoDB. To determine whether the server is using a table, we check the servers table cache for the second part. If a table is in the table cache, it is considered to be in use by the server, and is kept in the dictionary. If it is not in the table cache, it can be removed from the dictionary.
7.2. InnoDB Data Dictionary Size Limit
67
Unfortunately, the table cache is not always an accurate way to know whether the table is used by MySQL or not. Tables that are in the table cache might not really be in use, so if you have a big table cache, the algorithm will only be able to remove some of the items in the dictionary, which means that the memory consumed by the dictionary may exceed the value of innodb_dict_size_limit. This is why we said this variable sets a soft limit on the size of the dictionary, not an absolute limit. Estimating the Data Dictionary Size Percona Server provides instrumentation to show the data dictionary size directly, but if youre not using Percona Server, you can estimate the size of the data dictionary. By calculating how much memory InnoDB has allocated that is not attributable to the buffer pool, etc., you will have an idea of how much allocated memory is not accounted for. This will not be the exact size of the data dictionary, but it will be a reasonable estimate. To make this estimate, rst locate the following lines in the output of SHOW ENGINE INNODB STATUS:
---------------------BUFFER POOL AND MEMORY ---------------------Total memory allocated 13563931762; in additional pool allocated 1048576 Buffer pool size 524288
The line beginning Total memory allocated shows the total memory InnoDB has allocated. The next line shows the buffer pool size in pages; you can either multiply that by the page size to get a value in bytes, or determine the size of the InnoDB buffer pool by executing the command SHOW VARIABLES LIKE innodb_buffer_pool_size . The latter is easier, if you use MySQL 5.0 or later, so for the purpose of this example, assume we use that and it gives the value 8589934592. Finally, subtract the InnoDB buffer pool size from the total memory allocated:
13563931762 - 8589934592 = 4973997170
So, there is a little over 4.6 GB of memory that InnoDB has allocated and which is unaccounted for. This is a pretty large amount of extra memory usage; quite a bit more than the gigabyte or so suggested as a maximum. So, you may benet from using this feature.
7.2.5 Other reading

Limiting InnoDB data dictionary How much memory InnoDB dictionary can take
7.3 Expand Table Import

Unlike MyISAM, InnoDB does not allow users to copy datales for a single table between servers. If exported with XtraBackup, a table can now be imported on another server running XtraDB. This feature implements the abililty to import arbitrary .ibd les exported using the XtraBackup --export option. The innodb_expand_import variable makes to convert .ibd le during import process. The normal version can import only the backed-up .ibd le at the same place. Note: This feature is unsupported with InnoDB data les created with MySQL 5.0 and MySQL 5.1 prior to version 5.1.7 due to InnoDB le format limitation. It may work in some cases, but may result in crashes on import as well, see bug #1000221 and bug #727704 for examples and details.
68
Percona Server 5.5.28-29.2 extended the innochecksum with an option -f to read the le format information from a given InnoDB data le. As only the rst page needs to be read to detect the format/version information, it can also be used on a running server. Example of the output should look like this:
$ innochecksum -f ibdata1 Detected file format: Antelope (5.1.7 or newer).
7.3.1 Example
Assuming that: innodb_expand_import is set to 1. the les (.ibd and .exp) are prepared by the xtrabackup --prepare --export command. First create exactly same structured tables to the target database. Then discard the tables as preparation of import, for example,
mysql> set FOREIGN_KEY_CHECKS=0; Query OK, 0 rows affected (0.00 sec) mysql> alter table customer discard tablespace; Query OK, 0 rows affected (0.01 sec) mysql> alter table district discard tablespace; Query OK, 0 rows affected (0.01 sec) mysql> alter table history discard tablespace; Query OK, 0 rows affected (0.00 sec) ... put the .ibd and .exp files at the same place to .frm file. import the tables (command example) mysql> set FOREIGN_KEY_CHECKS=0; Query OK, 0 rows affected (0.00 sec) mysql> set global innodb_expand_import=1; Query OK, 0 rows affected (0.00 sec) mysql> alter table customer import tablespace; Query OK, 0 rows affected (0.17 sec) mysql> alter table district import tablespace; Query OK, 0 rows affected (0.00 sec) mysql> alter table history import tablespace; Query OK, 0 rows affected (0.04 sec) ... (.err file example) InnoDB: import: extended import of tpcc2/customer is started. InnoDB: import: 2 indexes are detected. InnoDB: Progress in %: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 InnoDB: import: extended import of tpcc2/district is started. InnoDB: import: 1 indexes are detected. InnoDB: Progress in %: 16 33 50 66 83 100 done. InnoDB: import: extended import of tpcc2/history is started.
7.3. Expand Table Import
69
InnoDB: import: 3 indexes are detected. InnoDB: Progress in %: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 ...

5.5.10-20.1: Renamed variable innodb_expand_import to innodb_import_table_from_xtrabackup.

variable innodb_expand_import Version Info 5.5.10-20.1 Renamed. Command Line Yes Cong File Yes Scope Global Dynamic Yes Variable Type ULONG Default Value 0 Range 0-1 If set to 1, .ibd le is converted (space id, index id, etc.) with index information in .exp le during the import process (ALTER TABLE ... IMPORT TABLESPACE command). This variable was renamed to innodb_import_table_from_xtrabackup, beginning in release 5.5.10-20.1. It still exists as innodb_expand_import in versions prior to that. variable innodb_import_table_from_xtrabackup Version Info 5.5.10-20.1 Introduced. Command Line Yes Cong File Yes Scope Global Dynamic Yes Variable Type ULONG Default Value 0 Range 0-1 If set to 1, .ibd le is converted (space id, index id, etc.) with index information in .exp le during the import process (ALTER TABLE ... IMPORT TABLESPACE command). This variable was added in release 5.5.10-20.1. Prior to that, it was named innodb_expand_import, which still exists in earlier versions.
70
7.3.4 Other reading

Moving InnoDB tables between servers Copying InnoDB tables between servers
7.4 Dump/Restore of the Buffer Pool

Percona Server can speed up restarts by saving and restoring the contents of the buffer pool, the largest memory buffer the MySQL server typically uses. Servers with large amounts of memory typically need a long time to warm up the buffer pool after a restart, so a server cannot be placed under production load for hours or even days. This special feature of Percona Server enables the buffer pool to be restored to its pre-shutdown state in a matter of minutes. The feature works as follows. The buffer pool is a list of pages, usually 16kb in size, which are identied by an 8-byte number. The list is kept in least-recently-used order, which is why the buffer pool is sometimes referred to as an LRU list. The mechanism is to save the list of 8-byte page numbers just before shutdown, and after restart, to read the pages from disk and insert them back into the LRU at the correct position. The pages are sorted by ID to avoid random I/O, which is slower than sequential I/O on most disks. The LRU list is saved to the le ib_lru_dump in the directory specied by the datadir conguration setting, so you can back it up and restore it with the rest of your data easily. Note that this feature does not store the contents of the buffer pool (i.e. it does not write 1GB of data to disk if you have a 1GB buffer pool). It stores only the identiers of the pages in the buffer pool, which is a very small amount of data even for large buffer pools. This feature can be used both manually and automatically. It is safe to enable automatically, and we have not found any performance regressions in it.
7.4.1 Automatic Operation

To perform dump/restore of the buffer pool automatically, set the innodb_auto_lru_dump conguration variable. A non-zero value for this variable causes the server to create a new thread at startup. This threads rst task is to read and sort the saved le, and then restore the LRU accordingly. After nishing the restore operation, the thread switches into dump mode, to periodically dump the LRU. The period is specied by the conguration variables value in seconds. For example, if you set the variable to 60, then the thread saves the LRU list once per minute.
7.4.2 Manual Operation

Manual dump/restore is done through the INFORMATION_SCHEMA using the following two administrative commands: XTRA_LRU_DUMP: Dumps the contents of the buffer pool (a list of space_id and page_no) to the le ib_lru_dump in the directory specied by the datadir conguration setting. XTRA_LRU_RESTORE: Restores pages based on the le ib_lru_dump. Here is an example of how to manually save and restore the buffer pool. On a running server, examine the number of pages in the buffer pool, as in the following example:
mysql> show status like innodb_buffer_pool_pages_data; +-------------------------------+-------+ | Variable_name | Value | +-------------------------------+-------+
7.4. Dump/Restore of the Buffer Pool
71
| innodb_buffer_pool_pages_data | 6231 | +-------------------------------+-------+
Save the contents of the LRU list to a le:

mysql> select * from information_schema.XTRADB_ADMIN_COMMAND /*!XTRA_LRU_DUMP*/; +------------------------------+ | result_message | +------------------------------+ | XTRA_LRU_DUMP was succeeded. | +------------------------------+ 1 row in set (0.02 sec)
This is a fast operation, and the resulting le is very small compared to the buffer pool. The le is in binary format, not text format. Now restart MySQL, and examine the number of pages in the buffer pool, for example,
mysql> show status like innodb_buffer_pool_pages_data; +-------------------------------+-------+ | Variable_name | Value | +-------------------------------+-------+ | innodb_buffer_pool_pages_data | 22 | +-------------------------------+-------+
The following command instructs XtraDB to restore the LRU from the le:
mysql> select * from information_schema.XTRADB_ADMIN_COMMAND /*!XTRA_LRU_RESTORE*/; +---------------------------------+ | result_message | +---------------------------------+ | XTRA_LRU_RESTORE was succeeded. | +---------------------------------+ 1 row in set (0.62 sec)
This command executes quickly, because it doesnt use direct_io. Afterwards, inspect the status of the buffer pool again:
mysql> show status like innodb_buffer_pool_pages_data; +-------------------------------+-------+ | Variable_name | Value | +-------------------------------+-------+ | innodb_buffer_pool_pages_data | 6231 | +-------------------------------+-------+
7.4.3 Status Information

Status information about the dump and restore is written to the servers error le:
.... 091217 11:49:16 InnoDB: administration command XTRA_LRU_DUMP was detected. .... 091217 11:51:44 InnoDB: administration command XTRA_LRU_RESTORE was detected. 091217 11:51:45 InnoDB: reading pages based on the dumped LRU list was done. (requested: 6231, read:
The requested number of pages is the number of pages that were in the LRU dump le. A page might not be read if it is already in the buffer pool, or for some other miscellaneous reasons, so the number of pages read can be less than the number requested.
72

The mechanism used to read pages into the LRU is the normal InnoDB calls for reading a page into the buffer pool. This means that it still performs all of the usual checks for data integrity. It also means that if you decrease the size of the buffer pool, InnoDB uses the usual page replacement and ushing algorithm to free pages when it becomes full. The pages are sorted by tablespace, and then by ID within the tablespace. The dump le is not deleted after loading, so you should delete it if you wish to disable the feature. For example, suppose you dump the LRU, and then some time later you decide to enable automatic dumping and reloading. You set the conguration variable and restart MySQL. Upon restart, the server will load the LRU to its state in the previously saved le, which might be very stale and not what you want to happen.
7.4.5 Block Startup until LRU dump is loaded

Percona Server provides a boolean option to block the start of XtraDB until LRU is preloaded from dump. When the variable innodb_blocking_buffer_pool_restore is set to ON, XtraDB waits until the restore of the dump is completed before reporting successful startup to the server. This variable is OFF by default.

5.5.8-20.0: Automatic dump/restore implemented. 5.5.10-20.1: Renamed variable innodb_auto_lru_dump to innodb_buffer_pool_restore_at_startup.

variable innodb_auto_lru_dump Version Info 5.5.10-20.1 Renamed. Command Line Yes Cong File Yes Scope Global Dynamic Yes Variable Type Numeric Default Value 0 Range 0-UINT_MAX32 Units Seconds This variable species the time in seconds between automatic buffer pool dumps. When set to zero, automatic dumps are disabled and must be done manually. When set to a non-zero value, an automatic restore of the buffer pool is also performed at startup, as described above. This variable was renamed to innodb_buffer_pool_restore_at_startup, beginning in release 5.5.10-20.1. It still exists as innodb_auto_lru_dump in versions prior to that. variable innodb_blocking_buffer_pool_restore Version Info
7.4. Dump/Restore of the Buffer Pool
73
5.5.16-22.0 Added Command Line Yes Cong File Yes Scope Global Dynamic No Variable Type Boolean Default Value OFF Range ON/OFF When this variable is set to ON XtraDB waits until the restore of the dump is completed before reporting successful startup to the server. variable innodb_buffer_pool_restore_at_startup Version Info 5.5.10-20.1 Added. Command Line Yes Cong File Yes Scope Global Dynamic Yes Variable Type Numeric Default Value 0 Range 0-UINT_MAX32 Units Seconds This variable species the time in seconds between automatic buffer pool dumps. When set to zero, automatic dumps are disabled and must be done manually. The variable innodb_buffer_pool_restore_at_startup controls both automatic buffer pool dumps and automatic restore on startup. When set to a non-zero value, an automatic restore of the buffer pool is also performed at startup, as described above. This variable was added in release 5.5.10-20.1. Prior to that, it was named innodb_auto_lru_dump, which still exists in earlier versions.

This feature provides the following table: table INFORMATION_SCHEMA.XTRADB_ADMIN_COMMAND Columns result_message result message of the XTRADB_ADMIN_COMMAND
7.4.9 Other reading

Save / restore buffer pool
74
7.5 Fast Index Creation

Percona has implemented several changes related to MySQLs fast index creation feature. Extended features, besides disabling fast_index_creation, can be enabled with expand_fast_index_creation.
7.5.1 Disabling Fast Index Creation

Fast index creation was implemented in MySQL as a way to speed up the process of adding or dropping indexes on tables with many rows. However, cases have been found in which fast index creation creates an inconsistency between MySQL and InnoDB data dictionaries. This feature implements a session variable that disables fast index creation. This causes indexes to be created in the way they were created before fast index creation was implemented. While this is slower, it avoids the problem of data dictionary inconsistency between MySQL and InnoDB.
7.5.2 Tunable buffer size for fast index creation

Percona Server supports tunable buffer size for fast index creation in InnoDB. This value was calculated based on the merge block size (which was hardcoded to 1 MB) and the minimum index record size. By adding the session variable innodb_merge_sort_block_size block size that is used in the merge sort can now be adjusted for better performance.

5.5.8-20.0: Variable fast_index_creation implemented. 5.5.11-20.2: Expanded the applicability of fast index creation to mysqldump, ALTER TABLE, and OPTIMIZE TABLE. 5.5.27-28.0 Variable innodb_merge_sort_block_size implemented.

variable fast_index_creation Command Line Yes Cong File No Scope Local Dynamic Yes Variable Type Boolean Default Value ON Range ON/OFF variable innodb_merge_sort_block_size Command Line Yes Cong File Yes Scope Global
7.5. Fast Index Creation
75
Dynamic Yes Variable Type ULONG Default Value 1048576 (1M) Range 1048576 - 1073741824 (1G)
7.5.5 Other Reading

Thinking about running OPTIMIZE on your InnoDB Table? Stop! Building Indexes by Sorting In Innodb
7.6 Expanded Fast Index Creation

Percona has implemented several changes related to MySQLs fast index creation feature. This feature expands the ALTER TABLE command by adding a new clause that provides online index renaming capability, that is renaming indexes without rebuilding the whole table.
7.6.1 Enabling Expanded Fast Index Creation

Fast index creation was implemented in MySQL as a way to speed up the process of adding or dropping indexes on tables with many rows. However, cases have been found in which fast index creation creates an inconsistency between MySQL and InnoDB data dictionaries. This feature implements a session variable that enables extended fast index creation. Besides optimizing DDL directly, expand_fast_index_creation may also optimize index access for subsequent DML statements because using it results in much less fragmented indexes. mysqldump A new option, --innodb-optimize-keys, was implemented in mysqldump. It changes the way InnoDB tables are dumped, so that secondary keys are created after loading the data, thus taking advantage of fast index creation. More specically: KEY, UNIQUE KEY, and CONSTRAINT clauses are omitted from CREATE TABLE statements corresponding to InnoDB tables. An additional ALTER TABLE is issued after dumping the data, in order to create the previously omitted keys. ALTER TABLE When ALTER TABLE requires a table copy, secondary keys are now dropped and recreated later, after copying the data. The following restrictions apply: Only non-unique keys can be involved in this optimization. If the table contains foreign keys, or a foreign key is being added as a part of the current ALTER TABLE statement, the optimization is disabled for all keys. This optimization wont work in case the index is dropped and added in the same ALTER TABLE statement because in that case MySQL copies the table.
76
OPTIMIZE TABLE Internally, OPTIMIZE TABLE is mapped to ALTER TABLE ... ENGINE=innodb for InnoDB tables. As a consequence, it now also benets from fast index creation, with the same restrictions as for ALTER TABLE. Caveats InnoDB fast index creation uses temporary les in tmpdir for all indexes being created. So make sure you have enough tmpdir space when using expand_fast_index_creation. It is a session variable, so you can temporarily switch it off if you are short on tmpdir space and/or dont want this optimization to be used for a specic table. Theres also a number of cases when this optimization is not applicable: UNIQUE indexes in ALTER TABLE are ignored to enforce uniqueness where necessary when copying the data to a temporary table; ALTER TABLE and OPTIMIZE TABLE always process tables containing foreign keys as if expand_fast_index_creation is OFF to avoid dropping keys that are part of a FOREIGN KEY constraint; mysqldump innodb-optimize-keys ignores foreign keys because InnoDB requires a full table rebuild on foreign key changes. So adding them back with a separate ALTER TABLE after restoring the data from a dump would actually make the restore slower; mysqldump innodb-optimize-keys ignores indexes on AUTO_INCREMENT columns, because they must be indexed, so it is impossible to temporarily drop the corresponding index; mysqldump innodb-optimize-keys ignores the rst UNIQUE index on non-nullable columns when the table has no PRIMARY KEY dened, because in this case InnoDB picks such an index as the clustered one.

5.5.16-22.0 Variable expand_fast_index_creation implemented. This variable controls whether fast index creation optimizations made by Percona are used.

variable expand_fast_index_creation Command Line Yes Cong File No Scope Local/Global Dynamic Yes Variable Type Boolean Default Value OFF Range ON/OFF
7.6. Expanded Fast Index Creation
77
7.6.4 Other Reading

Improved InnoDB fast index creation Thinking about running OPTIMIZE on your InnoDB Table? Stop!
7.7 Prevent Caching to FlashCache

FlashCache increases performance by caching data on SSDs. It works even better when only hot data is cached. This feature prevents the caching of the unwanted blocks of data. Better utilization of FlashCache partitions is achieved when caching of rarely used data is avoided. Use of this feature prevents blocks of data from being cached to FlashCache during a query. Usage of the feature is as follows:
SELECT /* sql_no_fcache */ ...
The mysqldump binary was changed to use this option.

5.5.8-20.0: Full functionality available. 5.5.27-29.0: Variable have_flashcache introduced.

variable have_flashcache Version Info 5.5.27-29.0 Variable introduced Command Line Yes Cong File Yes Scope Global Dynamic No Variable Type Boolean Range Yes/No This variable shows if the server was compiled with Flashcache support.

variable Flashcache_enabled Scope Global Variable Type Boolean Range OFF/ON This status variable shows if the Flashcache support has been enabled. 78 Chapter 7. Management Improvements

The feature is a port of the original Facebook change.
7.7.5 Other reading

Releasing Flashcache Level 2 Flash cache is there
7.8 Percona Toolkit UDFs

Three Percona Toolkit UDFs that provide faster checksums are provided: libfnv1a_udf libfnv_udf libmurmur_udf

5.5.8-20.0: Began distributing libfnv1a_udf, libfnv_udf, and libmurmur_udf.

Author / Origin: Baron Schwartz
7.8.3 Installation
These UDFs are part of the Percona Server packages. To install one of the UDFs into the server, execute one of the following commands, depending on which UDF you want to install:
$ mysql -e "CREATE FUNCTION fnv1a_64 RETURNS INTEGER SONAME libfnv1a_udf.so" $ mysql -e "CREATE FUNCTION fnv_64 RETURNS INTEGER SONAME libfnv_udf.so" $ mysql -e "CREATE FUNCTION murmur_hash RETURNS INTEGER SONAME libmurmur_udf.so"
Executing each of these commands will install its respective UDF into the server.
7.8.4 Troubleshooting
If you get the error:
ERROR 1126 (HY000): Cant open shared library fnv_udf.so (errno: 22 fnv_udf.so: cannot open shared
Then you may need to copy the .so le to another location in your system. Try both /lib and /usr/lib. Look at your environments $LD_LIBRARY_PATH variable for clues. If none is set, and neither /lib nor /usr/lib works, you may need to set LD_LIBRARY_PATH to /lib or /usr/lib.
7.8. Percona Toolkit UDFs
79
7.8.5 Other Reading

Percona Toolkit documentation
7.9 Support for Fake Changes

Restarting a slave server in a replication environment or setting up new slave server can cause a replication reads slower. This is happening because replication in MySQL is single-threaded and because it needs to read the data before it can execute the queries. The process can be speeded up by having prefetch threads to warm the server: replay statements and then rollback at commit. That makes prefetch simple but has high overhead from locking rows only to undo changes at rollback. Using this approach, support for Fake Changes have been implemented in order to remove the overhead and make it faster. By reading the rows for INSERT, UPDATE and DELETE statements but not updating them (Fake Changes), the rollback is very fast as in most cases there is nothing to do.
7.9.1 Caveats
DML operations are supported Currently only DML operations are supported, i.e. UPDATE, INSERT, REPLACE and DELETE (set deleted ag). DDL operations are not supported DDL operations are not supported, i.e. ALTER TABLE and TRUNCATE TABLE. Fake Changes should be disabled temporally if DDL statements are going to be executed. Otherwise, data may be lost. Explicit COMMIT will lead to an error From the viewpoint of transactional RDBMS, COMMIT should not be fake anytime. ROLLBACK must be used to terminate the fake transaction.

variable innodb_fake_changes Version Info 5.5.16-22.0 Introduced Scope GLOBAL Type BOOLEAN Dynamic YES Default Value FALSE This variable enables the Fake Changes feature. variable innodb_locking_fake_changes
80
Version Info 5.5.28-29.2 Introduced Scope GLOBAL Type BOOLEAN Dynamic YES Default Value TRUE When this variable is set to FALSE, it makes fake transactions not to take any row locks. This feature was implemented because, although fake change transactions downgrade the requested exclusive (X) row locks to shared (S) locks, these S locks prevent X locks from being taken and block the real changes. However, this option is not safe to set to FALSE by default, because the fake changes implementation is not ready for lock-less operation for all workloads. Namely, if a real transaction will remove a row that a fake transaction is doing a secondary index maintenance for, the latter will fail. This option is considered experimental and might be removed in the future if lockless operation mode xes are implemented.

The fake session is used as a prefetch of the replication, it should not affect to later replication SQL execution. The effective unit is each transaction. The behavior is decided at the start of the each one and never changed during the transaction INSERT operations doesnt use the INSERT BUFFER, it always causes the reading of the page actually for the option. DELETE also doesnt use the INSERT BUFFER. It never acquires X_LOCK from tables or records, only S_LOCK. The auto increment values behaves as usual. It reserves free pages as usual. Existed only root ~ leaf pages, which are accessed in the DML operation. It will not prefetch allocate/free, split/merge, INODE, XDES or other management pages. The same is for extern pages, i.e. large BLOB s). Foreign key constraints are checked (for causing IO), but passed always.

on MySQL replication prefetching
7.10 Kill Idle Transactions

This feature limits the age of idle XtraDB transactions. If a transaction is idle for more seconds than the threshold specied, it will be killed. This prevents users from blocking purge by mistake.

variable innodb_kill_idle_transaction Version Info
7.10. Kill Idle Transactions
81
5.5.16-22.0 Introduced Scope GLOBAL Cong YES Dynamic YES Variable Type INTEGER Default Value 0 (disabled) Units Seconds To enable this feature, set this variable to the desired seconds wait until the transaction is killed.
7.11 Enforcing Storage Engine

Percona Server has implemented variable which can be used for enforcing the use of a specic storage engine. When this variable is specied and a user tries to create a table using an explicit storage engine that is not the specied enforced engine, he will get either an error if the NO_ENGINE_SUBSTITUTION SQL mode is enabled or a warning if NO_ENGINE_SUBSTITUTION is disabled and the table will be created anyway using the enforced engine (this is consistent with the default MySQL way of creating the default storage engine if other engines arent available unless NO_ENGINE_SUBSTITUTION is set). In case user tries to enable enforce_storage_engine with engine that isnt available, system will not start.

5.5.24-26.0 Variable enforce_storage_engine implemented.

variable enforce_storage_engine Command Line No Cong File Yes Scope Global Dynamic No Variable Type String Default Value NULL
7.11.3 Example
Adding following option to my.cnf will start the server with InnoDB as enforced storage engine.
enforce_storage_engine=InnoDB
82
7.12 Utility user

Percona Server has implemented ability to have a MySQL user who has system access to do administrative tasks but limited access to user schema. This feature is especially useful to those operating MySQL As A Service. This user has a mixed and special scope of abilities and protection: Utility user will not appear in the mysql.user table and can not be modied by any other user, including root. Utility user will not appear in USER_STATISTICS, CLIENT_STATISTICS or THREAD_STATISTICS tables. Utility users queries may appear in the general and slow logs. Utility user doesnt have the ability create, modify, delete or see any schemas or data not specied (except for information_schema). Utility user may modify all visible, non read-only system variables (see Expanded Program Option Modiers functionality). Utility user may see, create, modify and delete other system users only if given access to the mysql schema. Regular users may be granted proxy rights to the utility user but any attempt to impersonate the utility user will fail. The utility user may not be granted proxy rights on any regular user. For example running: GRANT PROXY ON utility_user TO regular_user; will not fail, but any actual attempt to impersonate as the utility user will fail. Running: GRANT PROXY ON regular_user TO utility_user; will fail when utility_user is an exact match or is more specic than than the utility user specied. When the server starts, it will note in the log output that the utility user exists and the schemas that it has access to. In order to have the ability for a special type of MySQL user, which will have a very limited and special amount of control over the system and can not be see or modied by any other user including the root user, three new options have been added. Option utility_user species the user which the system will create and recognize as the utility user. The host in the utility user specication follows conventions described in the MySQL manual, i.e. it allows wildcards and IP masks. Anonymous user names are not permitted to be used for the utility user name. This user must not be an exact match to any other user that exists in the mysql.user table. If the server detects that the user specied with this option exactly matches any user within the mysql.user table on start up, the server will report an error and shut down gracefully. If host name wildcards are used and a more specic user specication is identied on start up, the server will report a warning and continue. Example: --utility_user =frank@% and frank@localhost exists within the mysql.user table. If a client attempts to create a MySQL user that matches this user specication exactly or if host name wildcards are used for the utility user and the user being created has the same name and a more specic host, the creation attempt will fail with an error. Example: --utility_user =frank@% and CREATE USER frank@localhost; As a result of these requirements, it is strongly recommended that a very unique user name and reasonably specic host be used and that any script or tools test that they are running within the correct user by executing SELECT CURRENT_USER() and comparing the result against the known utility user. Option utility_user_password species the password for the utility user and MUST be specied or the server will shut down gracefully with an error. Example: --utility_user_password =Passw0rD; Option utility_user_schema_access species the name(s) of the schema(s) that the utility user will have access to read write and modify. If a particular schema named here does not exist on start up it will be ignored. If a
7.12. Utility user
83
schema by the name of any of those listed in this option is created after the server is started, the utility user will have full access to it. Example: --utility_user_schema_access =schema1,schema2,schema3 ; Option utility_user_privileges allows a comma-separated list of extra access privileges to grant to the utility user. Example: --utility-user-privileges =CREATE, DROP, LOCK TABLES

variable utility_user Version Info 5.5.27-28.0 Implemented Command Line Yes Cong File utility_user=<user@host> Scope Global Dynamic No Variable Type String Default Value NULL Species a MySQL user that will be added to the internal list of users and recognized as the utility user. variable utility_user_password Version Info 5.5.27-28.0 Implemented Command Line Yes Cong File utility_user_password=<password> Scope Global Dynamic No Variable Type String Default Value NULL Species the password required for the utility user. variable utility_user_schema_access Version Info 5.5.27-28.0 Implemented Command Line Yes Cong File utility_user_schema_access=<schema>,<schema>,<schema> Scope Global Dynamic No Variable Type String Default Value NULL 84 Chapter 7. Management Improvements
Species the schemas that the utility user has access to in a comma delimited list. variable utility_user_privileges Version Info 5.5.34-32.0 Implemented Command Line Yes Cong File utility_user_privileges=<privilege1>,<privilege2>,<privilege3> Scope Global Dynamic No Variable Type String Default Value NULL This variable can be used to specify a comma-separated list of extra access privileges to grant to the utility user. Supported values for the privileges list are: SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, RELOAD, SHUTDOWN, PROCESS,FILE, GRANT, REFERENCES, INDEX, ALTER, SHOW DATABASES, SUPER, CREATE TEMPORARY TABLES, LOCK TABLES,EXECUTE, REPLICATION SLAVE, REPLICATION CLIENT, CREATE VIEW, SHOW VIEW, CREATE ROUTINE, ALTER ROUTINE, CREATE USER, EVENT, TRIGGER, CREATE TABLESPACE
7.13 Extending the secure-file-priv server option

Percona Server has extended secure-file-priv server option. When used with no argument, the LOAD_FILE() function will always return NULL. The LOAD DATA INFILE and SELECT INTO OUTFILE statements will fail with the following error: The MySQL server is running with the secure-le-priv option so it cannot execute this statement. LOAD DATA LOCAL INFILE is not affected by the secure-le-priv option and will still work when its used without an argument.

5.5.25a-27.1 Variable secure-file-priv extended behavior implemented.

variable secure-file-priv Command Line No Cong File Yes Scope Global Dynamic No Variable Type String Default Value NULL
7.13. Extending the secure-file-priv server option
85
7.14 Expanded Program Option Modiers

MySQL has the concept of options modiers which is a simple way to modify either the way that MySQL interprets an option or the way the option behaves. Option modiers are used by simply prepending the name of the modier and a dash - before the actual conguration option name. For example specifying maximum-query_cache_size=4M on the mysqld commad line or specifying maximum-query_cache_size=4M in the my.cnf will prevent any client from setting the query_cache_size value larger than 4MB. Currently MySQL supports ve existing option modiers: disable [disable-<option_name>] disables or ignores option_name. enable [enable-<option_name>] enables option_name. loose [loose-<option_name>] - mysqld will not exit with an error if it does not recognize option_name, but instead it will issue only a warning. maximum [maximum-<option_name>=<value>] indicates that a client can not set the value of option_name greater than the limit specied. If the client does attempt to set the value of option_name greater than the limit, the option_name will simply be set to the dened limit. skip [skip-<option_name>] skips or ignores option_name.
In order to offer more control over option visibility, access and range limits, the following new option modiers have been added minimum [minimum-<option_name>=<value>] indicates that clients can not set the value of option_name to less than the limit specied. If the client does attempt to set the value of option_name lesser than the limit, the option_name will simply be set to the dened limit. hidden [hidden-<option_name>=<TRUE/FALSE>] indicates that clients can not see or modify the value of option_name. readonly [readonly-<option_name>=<TRUE/FALSE>] indicates that clients can see the value of option_name but can not modify the value.
7.14.1 Combining the options

Some of the option modiers may be used together in the same option specication, example:
--skip-loose-<option_name> --loose-readonly-<option_name>=<T/F> --readonly-<option_name>=<T/F> --hidden-<option_name>=<T/F>

5.5.27-28.0 Expanded program option modiers implemented
7.14.3 Examples
Adding the following option to the my.cnf will set the minimum limit on query_cache_size
minimum-query_cache_size = 4M
86
Trying to set up bigger value will work correctly, but if we try to set it up with smaller than the limit, dened minimum limit will be used and warning (1292) will be issued: Initial query_cache_size size:
mysql> show variables like query_cache_size; +------------------+---------+ | Variable_name | Value | +------------------+---------+ | query_cache_size | 8388608 | +------------------+---------+ 1 row in set (0.00 sec)
Setting up bigger value:

mysql> set global query_cache_size=16777216; Query OK, 0 rows affected (0.00 sec) mysql> show variables like query_cache_size; +------------------+----------+ | Variable_name | Value | +------------------+----------+ | query_cache_size | 16777216 | +------------------+----------+ 1 row in set (0.00 sec)
Setting up smaller value:

mysql> set global query_cache_size=1048576; Query OK, 0 rows affected, 1 warning (0.00 sec) mysql> show warnings; +---------+------+-------------------------------------------------------+ | Level | Code | Message | +---------+------+-------------------------------------------------------+ | Warning | 1292 | Truncated incorrect query_cache_size value: 1048576 | +---------+------+-------------------------------------------------------+ 1 row in set (0.00 sec) mysql> show variables like query_cache_size; +------------------+---------+ | Variable_name | Value | +------------------+---------+ | query_cache_size | 4194304 | +------------------+---------+ 1 row in set (0.00 sec)
Adding following option to my.cnf will make query_cache_size hidden.

hidden-query_cache_size=1 mysql> show variables like query_cache%; +------------------------------+---------+ | Variable_name | Value | +------------------------------+---------+ | query_cache_limit | 1048576 | | query_cache_min_res_unit | 4096 | | query_cache_strip_comments | OFF | | query_cache_type | ON | | query_cache_wlock_invalidate | OFF |
7.14. Expanded Program Option Modiers
87
+------------------------------+---------+ 5 rows in set (0.00 sec)
Adding following option to my.cnf will make query_cache_size read-only

readonly-query_cache_size=1
Trying to change the variable value will result in error:

mysql> show variables like query_cache%; +------------------------------+---------+ | Variable_name | Value | +------------------------------+---------+ | query_cache_limit | 1048576 | | query_cache_min_res_unit | 4096 | | query_cache_size | 8388608 | | query_cache_strip_comments | OFF | | query_cache_type | ON | | query_cache_wlock_invalidate | OFF | +------------------------------+---------+ 6 rows in set (0.00 sec) mysql> set global query_cache_size=16777216; ERROR 1238 (HY000): Variable query_cache_size is a read only variable
7.15 XtraDB changed page tracking

XtraDB now tracks the pages that have changes written to them according to the redo log. This information is written out in special changed page bitmap les. This information can be used to speed up incremental backups using Percona XtraBackup by removing the need to scan whole data les to nd the changed pages. Changed page tracking is done by a new XtraDB worker thread that reads and parses log records between checkpoints. The tracking is controlled by a new read-only server variable innodb_track_changed_pages. Bitmap lename format used for changed page tracking is ib_modified_log_<seq>_<startlsn>.xdb. The rst number is the sequence number of the bitmap log le and the startlsn number is the starting LSN number of data tracked in that le. Example of the bitmap log les should look like this:
ib_modified_log_1_0.xdb ib_modified_log_2_1603391.xdb
Sequence number can be used to easily check if all the required bitmap les are present. Start LSN number will be used in XtraBackup and INFORMATION_SCHEMA queries to determine which les have to be opened and read for the required LSN interval data. The bitmap le is rotated on each server restart and whenever the current le size reaches the predened maximum. This maximum is controlled by a new innodb_max_bitmap_file_size variable. This feature will be used for implementing faster incremental backups that use this information to avoid full data scans in Percona XtraBackup.
7.15.1 User statements for handling the XtraDB changed page bitmaps
In Percona Server 5.5.29-30.0 new statements have been introduced for handling the changed page bitmap tracking. All of these statements require SUPER privilege. FLUSH CHANGED_PAGE_BITMAPS - this statement can be used for synchronous bitmap write for immediate catch-up with the log checkpoint. This is used by innobackupex to make sure that XtraBackup indeed has all the required data it needs. 88 Chapter 7. Management Improvements
RESET CHANGED_PAGE_BITMAPS - this statement will delete all the bitmap log les and restart the bitmap log le sequence. PURGE CHANGED_PAGE_BITMAPS BEFORE <lsn> - this statement will delete all the change page bitmap les up to the specied log sequence number.
7.15.2 Additional information in SHOW ENGINE INNODB STATUS

When log tracking is enabled, the following additional elds are displayed in the LOG section of the SHOW ENGINE INNODB STATUS output: Log tracked up to: displays the LSN up to which all the changes have been parsed and stored as a bitmap on disk by the log tracking thread Max tracked LSN age: displays the maximum limit on how far behind the log tracking thread may be.

This table contains a list of modied pages from the bitmap le data. As these les are generated by the log tracking thread parsing the log whenever the checkpoint is made, it is not real-time data. table INFORMATION_SCHEMA.INNODB_CHANGED_PAGES Columns space_id (INT(11)) space id of modied page page_id (INT(11)) id of modied page start_lsn (BIGINT(21)) start of the interval end_lsn (BIGINT(21)) end of the interval The start_lsn and the end_lsn columns denote between which two checkpoints this page was changed at least once. They are also equal to checkpoint LSNs. Number of records in this table can be limited by using the variable innodb_changed_pages_limit.

variable innodb_max_changed_pages Version Info 5.5.27-29.0 Variable innodb_changed_pages_limit introduced 5.5.29-30.0 Variable renamed to innodb_max_changed_pages Command Line Yes Cong File Yes Scope Global Dynamic Yes Variable Type Numeric Default Value 1000000 Range 1 - 0 (unlimited)
7.15. XtraDB changed page tracking
89
variable innodb_track_changed_pages Version Info 5.5.27-29.0 Variable introduced Command Line Yes Cong File Yes Scope Global Dynamic No Variable Type Boolean Default Value 0 - False Range 0-1 variable innodb_max_bitmap_file_size Version Info 5.5.28-29.2 Variable introduced Command Line Yes Cong File Yes Scope Global Dynamic Yes Variable Type Numeric Default Value 104857600 (100 MB) Range 4096 (4KB) - 18446744073709551615 (16EB)
7.16 PAM Authentication Plugin

Percona PAM Authentication Plugin is a free and Open Source implementation of the MySQLs authentication plugin. This plugin acts as a mediator between the MySQL server, the MySQL client, and the PAM stack. The server plugin requests authentication from the PAM stack, forwards any requests and messages from the PAM stack over the wire to the client (in cleartext) and reads back any replies for the PAM stack. PAM plugin uses dialog as its client side plugin. Dialog plugin can be loaded to any client application that uses libmysqlclient library. Here are some of the benets that Percona dialog plugin offers over the default one: It correctly recognizes whether PAM wants input to be echoed or not, while the default one always echoes the input on the users console. It can use the password which is passed to MySQL client via -p parameter. Dialog client installation bug has been xed. This plugin works on MySQL and Percona Server. Percona offers two versions of this plugin: Full PAM plugin called auth_pam. This plugin uses dialog.so. It fully supports the PAM protocol with arbitrary communication between client and server.
90
Oracle-compatible PAM called auth_pam_compat. This plugin uses mysql_clear_password which is a part of Oracle MySQL client. It also has some limitations, such as, it supports only one password input. You must use -p option in order to pass the password to auth_pam_compat. These two versions of plugins are physically different. To choose which one you want used, you must use IDENTIFIED WITH auth_pam for auth_pam, and IDENTIFIED WITH auth_pam_compat for auth_pam_compat.
7.16.1 Installation
This plugin requires manual installation because it isnt installed by default.
mysql> INSTALL PLUGIN auth_pam SONAME auth_pam.so;
After the plugin has been installed it should be present in the plugins list. To check if the plugin has been correctly installed and active
mysql> SHOW PLUGINS; ... ... | auth_pam
| ACTIVE
| AUTHENTICATION
| auth_pam.so | GPL
7.16.2 Conguration
In order to use the plugin, authentication method should be congured. Simple setup can be to use the standard UNIX authentication method (pam_unix). Note: To use pam_unix, mysql will need to be added to the shadow group in order to have enough privileges to read the /etc/shadow. A sample /etc/pam.d/mysqld le:
auth account required required pam_unix.so pam_unix.so
For added information in the system log, you can expand it to be:
auth auth account required required required pam_warn.so pam_unix.so audit pam_unix.so audit
7.16.3 Creating a user

After the PAM plugin has been congured, users can be created with the PAM plugin as authentication method
mysql> CREATE USER newuser@localhost IDENTIFIED WITH auth_pam;
This will create a user newuser that can connect from localhost who will be authenticated using the PAM plugin. If the pam_unix method is being used user will need to exist on the system.
7.16.4 Supplementary groups support

Percona Server has implemented PAM plugin support for supplementary groups. Supplementary or secondary groups are extra groups a specic user is member of. For example user joe might be a member of groups: joe (his primary 7.16. PAM Authentication Plugin 91
group) and secondary groups developers and dba. A complete list of groups and users belonging to them can be checked with cat /etc/group command. This feature enables using secondary groups in the mapping part of the authentication string, like mysql, developers=joe, dba=mark. Previously only primary groups could have been specied there. If user is a member of both developers and dba, PAM plugin will map it to the joe because developers matches rst.

5.5.24-26.0 PAM authentication plugin has been integrated with Percona Server. 5.5.32-31.0 Implemented PAM support for supplementary groups.
92
CHAPTER
EIGHT
DIAGNOSTICS IMPROVEMENTS
8.1 InnoDB Statistics
This feature provides new startup options (control method and collection of index statistics estimation) and information schema views to conrm the statistics.

5.5.8-20.0: Renamed three elds in INNODB_INDEX_STATS table.

Four new system variables were introduced by this feature. variable innodb_stats_method Command Line YES Cong File YES Scope GLOBAL Dynamic YES Type STRING Default Value nulls_equal Allowed Values nulls_equal, nulls_unequal, nulls_ignored The values and meanings are almost same to myisam_stats_method option of native MySQL (nulls_equal, nulls_unequal, nulls_ignored). But InnoDB doesnt have several patterns of statistics currently. Even though this option can be changed dynamically, statistics needs to be re-calculated to change the method for the table. (reference: MyISAM Index Statistics Collection) variable innodb_stats_auto_update Type BOOLEAN Default Value 1 InnoDB updates the each index statistics automatically (many updates were done, some information_schema is accessed, table monitor, etc.). Setting this option 0 can stop these automatic recalculation of the statistics except for rst open and ANALYZE TABLE command.
93
variable innodb_stats_update_need_lock Type BOOLEAN Default Value 1 If you meet contention of &dict_operation_lock, setting 0 reduces the contention. But 0 disables to update Data_free: of SHOW TABLE STATUS. variable innodb_use_sys_stats_table Type BOOLEAN Default Value 0 If this option is enabled, XtraDB uses the SYS_STATS system table to store statistics of table indexes. Also, when InnoDB opens a table for the rst time, it loads the statistics from SYS_STATS instead of sampling index pages. If you use a high stats_sample_pages value, the rst open of a table is expensive. In such a case, this option will help. Intended behavior is to never update statistics unless an explicit ANALYZE TABLE is issued.

table INFORMATION_SCHEMA.INNODB_SYS_STATS Shows statistics of table indexes. Columns INDEX_ID Index ID KEY_COLS Number of key columns DIFF_VALS Number of Different Values NON_NULL_VALS Number of Non NULL Values table INFORMATION_SCHEMA.INNODB_SYS_TABLES Shows the information about InnoDB tables Columns TABLE_ID Table ID SCHEMA Database (schema) name NAME Table name FLAG Contains 0 if it is a InnoDB system table or 1 it is a user table N_COLS Number of columns in the table SPACE Tablespace ID table INFORMATION_SCHEMA.INNODB_SYS_TABLESTATS Shows the information about the performance statistics of InnoDB tables. Columns TABLE_ID Table ID SCHEMA Database (schema) Name NAME Table Name STATS_INITIALIZED Contains Initialized value if the statistics are collected or Uninitialized if they are not collected. NUM_ROWS Estimated number of rows in the table. 94 Chapter 8. Diagnostics Improvements
CLUST_INDEX_SIZE Number of pages on disk that store the clustered index. OTHER_INDEX_SIZE Number of pages on disk that store all secondary indexes. MODIFIED_COUNTER Number of rows modied by DML operations. AUTOINC MYSQL_HANDLES_OPENED table INFORMATION_SCHEMA.INNODB_SYS_INDEXES Shows the information about InnoDB indexes Columns INDEX_ID Index ID NAME Index Name TABLE_ID Table ID TYPE Numeric identier signifying the index type N_FIELDS Number of columns in the index PAGE_NO Page offset within its tablespace SPACE Tablespace ID table INFORMATION_SCHEMA.INNODB_SYS_COLUMNS Shows the information about the InnoDB table columns Columns TABLE_ID Table ID NAME Column Name POS Position of the column inside the table. MTYPE Numeric identier for the column type. PRTYPE Binary value with bits representing data type, character set code and nullability. LEN Column length. table INFORMATION_SCHEMA.INNODB_SYS_FIELDS Shows the information about the InnoDB index key elds. Columns INDEX_ID Index ID NAME Index Name POS Position of the eld inside the index. table INFORMATION_SCHEMA.INNODB_SYS_FOREIGN Shows the information about the InnoDB foreign keys. Columns ID Foreign Key ID FOR_NAME Database/Table which contains the Foreign Key FOR_REF Database/Table being referenced by the Foreign Key N_COLS Number of columns in the foreign key.
8.1. InnoDB Statistics
95
TYPE Type of foreign key, represented by the bit ags. table INFORMATION_SCHEMA.INNODB_SYS_FOREIGN_COLS Shows the information about the columns of the InnoDB foreign keys. Columns ID Foreign Key ID FOR_COL_NAME Foreign Key Column Name FOR_REF Referenced Column Name POS Position of the eld inside the index. table INFORMATION_SCHEMA.INNODB_TABLE_STATS Shows table statistics information of dictionary cached. Columns table_schema Database name of the table. table_name Table name. rows estimated number of all rows. clust_size cluster index (table/primary key) size in number of pages. other_size Other index (non primary key) size in number of pages. modied Internal counter to judge whether statistics recalculation should be done. If the value of modied column exceeds rows / 16 or 2000000000, the statistics recalculation is done when innodb_stats_auto_update == 1. We can estimate the oldness of the statistics by this value. table INFORMATION_SCHEMA.INNODB_INDEX_STATS Shows index statistics information of dictionary cached. Columns table_schema Database name of the table. table_name Table name. index_name Index name. elds How many elds the index key has. (it is internal structure of InnoDB, it may be larger than the CREATE TABLE). rows_per_key Estimate rows per 1 key value. ([1 column value], [2 columns value], [3 columns value], ...). index_total_pages Number of index pages. index_leaf_pages Number of leaf pages. In releases before 5.5.8-20.0, these elds had different names: rows_per_key was row_per_keys index_total_pages was index_size index_leaf_pages was leaf_pages
96
Chapter 8. Diagnostics Improvements
8.1.4 Example
[innodb_stats_method = nulls_equal (default behavior of InnoDB)]
mysql> explain SELECT COUNT(*), 0 FROM orgs2 orgs LEFT JOIN sa_opportunities2 sa_opportunities ON org +----+-------------+------------------+-------+-----------------+-----------------+---------+-------| id | select_type | table | type | possible_keys | key | key_len | ref +----+-------------+------------------+-------+-----------------+-----------------+---------+-------| 1 | SIMPLE | orgs | index | NULL | orgs$org_id | 4 | NULL | 1 | SIMPLE | sa_opportunities | ref | sa_opp$org_id | sa_opp$org_id | 5 | test2.o | 1 | SIMPLE | contacts | ref | contacts$org_id | contacts$org_id | 5 | test2.o +----+-------------+------------------+-------+-----------------+-----------------+---------+-------3 rows in set (0.00 sec)
[innodb_stats_method = nulls_unequal or nulls_ignored]
mysql> explain SELECT COUNT(*), 0 FROM orgs2 orgs LEFT JOIN sa_opportunities2 sa_opportunities ON org +----+-------------+------------------+-------+-----------------+-----------------+---------+-------| id | select_type | table | type | possible_keys | key | key_len | ref +----+-------------+------------------+-------+-----------------+-----------------+---------+-------| 1 | SIMPLE | orgs | index | NULL | orgs$org_id | 4 | NULL | 1 | SIMPLE | sa_opportunities | ref | sa_opp$org_id | sa_opp$org_id | 5 | test2.o | 1 | SIMPLE | contacts | ref | contacts$org_id | contacts$org_id | 5 | test2.o +----+-------------+------------------+-------+-----------------+-----------------+---------+-------3 rows in set (0.00 sec) <example of information_schema> mysql> select * from information_schema.innodb_table_stats; +------------------------+-------+------------+------------+----------+ | table_name | rows | clust_size | other_size | modified | +------------------------+-------+------------+------------+----------+ | test/sa_opportunities2 | 11175 | 21 | 11 | 0 | | test/orgs2 | 128 | 1 | 0 | 0 | | test/contacts2 | 47021 | 97 | 97 | 0 | +------------------------+-------+------------+------------+----------+ 3 rows in set (0.00 sec) mysql> select * from information_schema.innodb_index_stats; +------------------------+-----------------+--------+--------------+------------+------------+ | table_name | index_name | fields | row_per_keys | index_size | leaf_pages | +------------------------+-----------------+--------+--------------+------------+------------+ | test/sa_opportunities2 | GEN_CLUST_INDEX | 1 | 1 | 21 | 20 | | test/sa_opportunities2 | sa_opp$org_id | 2 | 338, 1 | 11| 10 | | test/orgs2 | orgs$org_id | 1 | 1 | 1 | 1 | | test/contacts2 | GEN_CLUST_INDEX | 1 | 1 | 97 | 80 | | test/contacts2 | contacts$org_id | 2 | 516, 0 | 97 | 37 | +------------------------+-----------------+--------+--------------+------------+------------+ 5 rows in set (0.00 sec)
8.1.5 Other reading

InnoDB Table/Index stats
8.1. InnoDB Statistics
97
8.2 User Statistics

This feature adds several INFORMATION_SCHEMA tables, several commands, and the userstat variable. The tables and commands can be used to understand the server activity better and identify the source of the load. The functionality is disabled by default, and must be enabled by setting userstat to ON. It works by keeping several hash tables in memory. To avoid contention over global mutexes, each connection has its own local statistics, which are occasionally merged into the global statistics, and the local statistics are then reset to 0.

5.5.10-20.1: Renamed variable userstat_running to userstat. 5.5.24-26.0: TOTAL_SSL_CONNECTIONS column has been added to CLIENT_STATISTICS, THREAD_STATISTICS and USER_STATISTICS tables

Author/Origin: Google; Percona added the INFORMATION_SCHEMA tables and the userstat_running variable.

variable userstat Version Info 5.5.10-20.1 Renamed from userstat_running Command Line Yes Cong File Yes Scope Global Dynamic Yes Variable Type BOOLEAN Default Value OFF Range ON/OFF Enables or disables collection of statistics. The default is OFF, meaning no statistics are gathered. This is to ensure that the statistics collection doesnt cause any extra load on the server unless desired. variable thread_statistics Version Info 5.5.8-20.0 Feature ported from Percona Server 5.1 Command Line Yes Cong File Yes Scope Global Dynamic Yes Variable Type BOOLEAN 98 Chapter 8. Diagnostics Improvements
Default Value OFF Range ON/OFF Enables or disables collection of thread statistics. The default is OFF, meaning no thread statistics are gathered. This is to ensure that the statistics collection doesnt cause any extra load on the server unless desired. Variable userstat needs to be enabled as well in order for thread statistics to be collected. Note: In Percona Server 5.5 thread_statistics is a reserved word. Which means you have to quote it when using the system variable with the same name: mysql> set global thread_statistics=1;

table INFORMATION_SCHEMA.CLIENT_STATISTICS Columns CLIENT The IP address or hostname from which the connection originated. TOTAL_CONNECTIONS The number of connections created for this client. CONCURRENT_CONNECTIONS The number of concurrent connections for this client. CONNECTED_TIME The cumulative number of seconds elapsed while there were connections from this client. BUSY_TIME The cumulative number of seconds there was activity on connections from this client. CPU_TIME The cumulative CPU time elapsed, in seconds, while servicing this clients connections. BYTES_RECEIVED The number of bytes received from this clients connections. BYTES_SENT The number of bytes sent to this clients connections. BINLOG_BYTES_WRITTEN The number of bytes written to the binary log from this clients connections. ROWS_FETCHED The number of rows fetched by this clients connections. ROWS_UPDATED The number of rows updated by this clients connections. TABLE_ROWS_READ The number of rows read from tables by this clients connections. (It may be different from ROWS_FETCHED.) SELECT_COMMANDS The number of SELECT commands executed from this clients connections. UPDATE_COMMANDS The number of UPDATE commands executed from this clients connections. OTHER_COMMANDS The number of other commands executed from this clients connections. COMMIT_TRANSACTIONS The number of COMMIT commands issued by this clients connections. ROLLBACK_TRANSACTIONS The number of ROLLBACK commands issued by this clients connections.
8.2. User Statistics
99
DENIED_CONNECTIONS The number of connections denied to this client. LOST_CONNECTIONS The number of this clients connections that were terminated uncleanly. ACCESS_DENIED The number of times this clients connections issued commands that were denied. EMPTY_QUERIES The number of times this clients connections sent empty queries to the server. TOTAL_SSL_CONNECTIONS The number of times this clients connections connected using SSL to the server. This table holds statistics about client connections. The Percona version of the feature restricts this tables visibility to users who have the SUPER or PROCESS privilege. Example:
mysql> SELECT * FROM INFORMATION_SCHEMA.CLIENT_STATISTICS\G *************************** 1. row *************************** CLIENT: 10.1.12.30 TOTAL_CONNECTIONS: 20 CONCURRENT_CONNECTIONS: 0 CONNECTED_TIME: 0 BUSY_TIME: 93 CPU_TIME: 48 BYTES_RECEIVED: 5031 BYTES_SENT: 276926 BINLOG_BYTES_WRITTEN: 217 ROWS_FETCHED: 81 ROWS_UPDATED: 0 TABLE_ROWS_READ: 52836023 SELECT_COMMANDS: 26 UPDATE_COMMANDS: 1 OTHER_COMMANDS: 145 COMMIT_TRANSACTIONS: 1 ROLLBACK_TRANSACTIONS: 0 DENIED_CONNECTIONS: 0 LOST_CONNECTIONS: 0 ACCESS_DENIED: 0 EMPTY_QUERIES: 0 TOTAL_SSL_CONNECTIONS: 0
table INFORMATION_SCHEMA.INDEX_STATISTICS Columns TABLE_SCHEMA The schema (database) name. TABLE_NAME The table name. INDEX_NAME The index name (as visible in SHOW CREATE TABLE). ROWS_READ The number of rows read from this index. This table shows statistics on index usage. An older version of the feature contained a single column that had the TABLE_SCHEMA, TABLE_NAME and INDEX_NAME columns concatenated together. The Percona version of the feature separates these into three columns. Users can see entries only for tables to which they have SELECT access. This table makes it possible to do many things that were difcult or impossible previously. For example, you can use it to nd unused indexes and generate DROP commands to remove them. If the index has not been used it wont be in this table.
100
Example:
mysql> SELECT * FROM INFORMATION_SCHEMA.INDEX_STATISTICS WHERE TABLE_NAME=tables_priv; +--------------+-----------------------+--------------------+-----------+ | TABLE_SCHEMA | TABLE_NAME | INDEX_NAME | ROWS_READ | +--------------+-----------------------+--------------------+-----------+ | mysql | tables_priv | PRIMARY | 2 | +--------------+-----------------------+--------------------+-----------+
Note: Current implementation of index statistics doesnt support partitioned tables. table INFORMATION_SCHEMA.TABLE_STATISTICS Columns TABLE_SCHEMA The schema (database) name. TABLE_NAME The table name. ROWS_READ The number of rows read from the table. ROWS_CHANGED The number of rows changed in the table. ROWS_CHANGED_X_INDEXES The number of rows changed in the table, multiplied by the number of indexes changed. This table is similar in function to the INDEX_STATISTICS table. Example:
mysql> SELECT * FROM INFORMATION_SCHEMA.TABLE_STATISTICS WHERE TABLE_NAME=tables_priv; +--------------+-------------------------------+-----------+--------------+------------------------+ | TABLE_SCHEMA | TABLE_NAME | ROWS_READ | ROWS_CHANGED | ROWS_CHANGED_X_INDEXES | +--------------+-------------------------------+-----------+--------------+------------------------+ | mysql | tables_priv | 2 | 0 | 0 | +--------------+-------------------------------+-----------+--------------+------------------------+
Note: Current implementation of table statistics doesnt support partitioned tables. table INFORMATION_SCHEMA.THREAD_STATISTICS Columns THREAD_ID Thread ID TOTAL_CONNECTIONS The number of connections created from this thread. CONCURRENT_CONNECTIONS The number of concurrent connections from this thread. CONNECTED_TIME The cumulative number of seconds elapsed while there were connections from this thread. BUSY_TIME The cumulative number of seconds there was activity from this thread. CPU_TIME The cumulative CPU time elapsed while servicing this thread. BYTES_RECEIVED The number of bytes received from this thread. BYTES_SENT The number of bytes sent to this thread.
101
BINLOG_BYTES_WRITTEN The number of bytes written to the binary log from this thread. ROWS_FETCHED The number of rows fetched by this thread. ROWS_UPDATED The number of rows updated by this thread. TABLE_ROWS_READ The number of rows read from tables by this tread. SELECT_COMMANDS The number of SELECT commands executed from this thread. UPDATE_COMMANDS The number of UPDATE commands executed from this thread. OTHER_COMMANDS The number of other commands executed from this thread. COMMIT_TRANSACTIONS The number of COMMIT commands issued by this thread. ROLLBACK_TRANSACTIONS The number of ROLLBACK commands issued by this thread. DENIED_CONNECTIONS The number of connections denied to this thread. LOST_CONNECTIONS The number of thread connections that were terminated uncleanly. ACCESS_DENIED The number of times this thread issued commands that were denied. EMPTY_QUERIES The number of times this thread sent empty queries to the server. TOTAL_SSL_CONNECTIONS The number of thread connections that used SSL. In order for this table to be populated with statistics, additional variable thread_statistics should be set to ON. table INFORMATION_SCHEMA.USER_STATISTICS Columns USER The username. The value #mysql_system_user# appears when there is no username (such as for the slave SQL thread). TOTAL_CONNECTIONS The number of connections created for this user. CONCURRENT_CONNECTIONS The number of concurrent connections for this user. CONNECTED_TIME The cumulative number of seconds elapsed while there were connections from this user. BUSY_TIME The cumulative number of seconds there was activity on connections from this user. CPU_TIME The cumulative CPU time elapsed, in seconds, while servicing this users connections. BYTES_RECEIVED The number of bytes received from this users connections. BYTES_SENT The number of bytes sent to this users connections. BINLOG_BYTES_WRITTEN The number of bytes written to the binary log from this users connections. ROWS_FETCHED The number of rows fetched by this users connections. ROWS_UPDATED The number of rows updated by this users connections. TABLE_ROWS_READ The number of rows read from tables by this users connections. (It may be different from ROWS_FETCHED.)
102
SELECT_COMMANDS The number of SELECT commands executed from this users connections. UPDATE_COMMANDS The number of UPDATE commands executed from this users connections. OTHER_COMMANDS The number of other commands executed from this users connections. COMMIT_TRANSACTIONS The number of COMMIT commands issued by this users connections. ROLLBACK_TRANSACTIONS The number of ROLLBACK commands issued by this users connections. DENIED_CONNECTIONS The number of connections denied to this user. LOST_CONNECTIONS The number of this users connections that were terminated uncleanly. ACCESS_DENIED The number of times this users connections issued commands that were denied. EMPTY_QUERIES The number of times this users connections sent empty queries to the server. TOTAL_SSL_CONNECTIONS The number of times this users connections connected using SSL to the server. This table contains information about user activity. The Percona version of the patch restricts this tables visibility to users who have the SUPER or PROCESS privilege. The table gives answers to questions such as which users cause the most load, and whether any users are being abusive. It also lets you measure how close to capacity the server may be. For example, you can use it to nd out whether replication is likely to start falling behind. Example:
mysql> SELECT * FROM INFORMATION_SCHEMA.USER_STATISTICS\G *************************** 1. row *************************** USER: root TOTAL_CONNECTIONS: 5592 CONCURRENT_CONNECTIONS: 0 CONNECTED_TIME: 6844 BUSY_TIME: 179 CPU_TIME: 72 BYTES_RECEIVED: 603344 BYTES_SENT: 15663832 BINLOG_BYTES_WRITTEN: 217 ROWS_FETCHED: 9793 ROWS_UPDATED: 0 TABLE_ROWS_READ: 52836023 SELECT_COMMANDS: 9701 UPDATE_COMMANDS: 1 OTHER_COMMANDS: 2614 COMMIT_TRANSACTIONS: 1 ROLLBACK_TRANSACTIONS: 0 DENIED_CONNECTIONS: 0 LOST_CONNECTIONS: 0 ACCESS_DENIED: 0 EMPTY_QUERIES: 0 TOTAL_SSL_CONNECTIONS: 0
103
8.2.5 Commands Provided

FLUSH CLIENT_STATISTICS FLUSH INDEX_STATISTICS FLUSH TABLE_STATISTICS FLUSH THREAD_STATISTICS FLUSH USER_STATISTICS These commands discard the specied type of stored statistical information. SHOW CLIENT_STATISTICS SHOW INDEX_STATISTICS SHOW TABLE_STATISTICS SHOW THREAD_STATISTICS SHOW USER_STATISTICS These commands are another way to display the information you can get from the INFORMATION_SCHEMA tables. The commands accept WHERE clauses. They also accept but ignore LIKE clauses.
8.3 Slow Query Log

This feature adds microsecond time resolution and additional statistics to the slow query log output. It lets you enable or disable the slow query log at runtime, adds logging for the slave SQL thread, and adds ne-grained control over what and how much to log into the slow query log. The ability to log queries with microsecond precision is essential for measuring the work the MySQL server performs. The standard slow query log in MySQL 5.0 has only 1-second granularity, which is too coarse for all but the slowest queries. MySQL 5.1 has microsecond resolution, but does not have the extra information about query execution that is included in the Percona Server. You can use Percona-Toolkits pt-query-digest tool to aggregate similar queries together and report on those that consume the most execution time.

5.5.8-20.0: Added log_slow_verbosity. 5.5.10-20.1: Renamed variable slow_query_log_timestamp_always slow_query_log_timestamp_always. Renamed variable slow_query_log_microseconds_timestamp slow_query_log_timestamp_precision. to to values profiling and profiling_use_getrusage to variable
Renamed variable use_global_log_slow_control to slow_query_log_use_global_control. 5.5.34-32.0: New slow_query_log_always_write_time variable introduced.
104

Author / Origin: Maciej Dobrzanski, Percona

variable log_slow_admin_statements Command Line Yes Cong File Yes Scope Global Dynamic yes When this variable is enabled, administrative statements will be logged to the slow query log. Upstream version of the MySQL server has implemented command line option with same name. Signicant difference is that this feature is implemented as variable in Percona Server, that means it can be enabled/disabled dynamically without restarting the server. variable log_slow_filter Command Line Yes Cong File Yes Scope Global, Session Dynamic Yes Filters the slow log by the querys execution plan. The value is a comma-delimited string, and can contain any combination of the following values: qc_miss: The query was not found in the query cache. full_scan: The query performed a full table scan. full_join: The query performed a full join (a join without indexes). tmp_table: The query created an implicit internal temporary table. tmp_table_on_disk: The querys temporary table was stored on disk. filesort: The query used a lesort. filesort_on_disk: The lesort was performed on disk. Values are ORed together. If the string is empty, then the lter is disabled. If it is not empty, then queries will only be logged to the slow log if their execution plan matches one of the types of plans present in the lter. For example, to log only queries that perform a full table scan, set the value to full_scan. To log only queries that use on-disk temporary storage for intermediate results, set the value to tmp_table_on_disk,filesort_on_disk. variable log_slow_rate_type Command Line Yes Cong File Yes Scope Global Dynamic Yes Variable Type Enumerated
8.3. Slow Query Log
105
Default Value session Range session, query Species semantic of log_slow_rate_limit - session or query. variable log_slow_rate_limit Command Line Yes Cong File Yes Scope Global, session Dynamic Yes Behavior of this variable depends from log_slow_rate_type. Species that only a fraction of session/query should be logged. Logging is enabled for every nth session/query. By default, n is 1, so logging is enabled for every session/query. Please note: when log_slow_rate_type is session rate limiting is disabled for the replication thread. Logging all queries might consume I/O bandwidth and cause the log le to grow large. When log_slow_rate_type is session, this option lets you log full sessions, so you have complete records of sessions for later analysis; but you can rate-limit the number of sessions that are logged. Note that this feature will not work well if your application uses any type of connection pooling or persistent connections. Note that you change log_slow_rate_limit in session mode, you should reconnect for get effect. When log_slow_rate_type is query, this option lets you log just some queries for later analysis. For example, if you set the value to 100, then one percent of queries will be logged. Note that every query has global unique query_id and every connection can has it own (session) log_slow_rate_limit. Decision log or no calculated in following manner: if log_slow_rate_limit is 0 - log every query If log_slow_rate_limit > 0 - log query when (query_id % log_slow_rate_limit) is zero. This allows exible setup logging behavior. For example, if you set the value to 100, then one percent of sessions/queries will be logged. In Percona Server 5.5.34-32.0 information about the log_slow_rate_limit has been added to the slow query log. This means that if the log_slow_rate_limit is effective it will be reected in the slow query log for each written query. Example of the output looks like this:
Log_slow_rate_type: query Log_slow_rate_limit: 10
variable log_slow_slave_statements Command Line Yes Cong File Yes Scope Global, session Dynamic Yes Species that slow queries replayed by the slave SQL thread on a MySQL slave will be logged. Upstream version of the MySQL server has implemented command line option with same name. Signicant difference is that this feature is implemented as variable in Percona Server, that means it can be enabled/disabled dynamically without restarting the server.
106
To start the logging from the slave thread, you should change the global value: set global log_slow_slave_statements =ON; and then execute: STOP SLAVE; START SLAVE;. This will destroy and recreate the slave SQL thread, so it will see the newly set global value. To stop the logging from the slave thread, you should just change the global value: log_slow_slave_statements =OFF; the logging stops immediately. variable log_slow_sp_statements Command Line Yes Cong File Yes Scope Global Dynamic Yes Variable Type Boolean Default Value TRUE Range TRUE/FALSE If TRUE, statements executed by stored procedures are logged to the slow if it is open. Note: Support for logging stored procedures doesnt involve triggers, so they wont be logged even if this feature is enabled. variable log_slow_verbosity Version Info 5.5.8-20.0 Added profiling and profiling_use_getrusage Command Line Yes Cong File Yes Scope Global, session Dynamic Yes Species how much information to include in your slow log. The value is a comma-delimited string, and can contain any combination of the following values: microtime: Log queries with microsecond precision. query_plan: Log information about the querys execution plan. innodb: Log InnoDB statistics. minimal: Equivalent to enabling just microtime. standard: Equivalent to enabling microtime,innodb. full: Equivalent to all other values ORed together. profiling: Enables proling of all queries in all connections. profiling_use_getrusage: Enables usage of the getrusage function. Values are ORed together. For example, to enable microsecond query timing and InnoDB statistics, set this option to microtime,innodb or standard. To turn all options on, set the option to full. variable slow_query_log_timestamp_always set global
8.3. Slow Query Log
107
Version Info 5.5.10-20.1 Introduced (renamed from use_global_log_slow_control) Command Line Yes Cong File Yes Scope Global Dynamic Yes Variable Type Boolean Default Value FALSE Range TRUE/FALSE If TRUE, a timestamp is printed on every slow log record. Multiple records may have the same time. variable slow_query_log_timestamp_precision Version Info 5.5.10-20.1 Introduced (renamed from slow_query_log_microseconds_timestamp) Command Line Yes Cong File Yes Scope Global Dynamic Yes Variable Type Enumerated Default Value second Range second, microsecond Normally, entries to the slow query log are in seconds precision, in this format:
# Time: 090402 9:23:36 # User@Host: XXX @ XXX [10.X.X.X]
If slow_query_log_timestamp_precision =microsecond, entries to the slow query log are in microsecond precision, in this format:
# Time: 090402 9:23:36.123456 # User@Host: XXX @ XXX [10.X.X.X]
variable slow_query_log_use_global_control Command Line Yes Cong File Yes Scope Global Dynamic Yes Default Value None Version Info 5.5.10-20.1 Introduced (renamed from log_slow_timestamp_every) Species which variables have global scope instead of local. Value is a ag variable - you can specify multiple values separated by commas none: All variables use local scope
108
log_slow_filter: Global variable log_slow_filter has effect (instead of local) log_slow_rate_limit: Global variable log_slow_rate_limit has effect (instead of local) log_slow_verbosity: Global variable log_slow_verbosity has effect (instead of local) long_query_time: Global variable long_query_time has effect (instead of local) min_examined_row_limit: Global variable min_examined_row_limit has effect (instead of local) all Global variables has effect (instead of local) NOTE: This variable has been renamed from log_slow_timestamp_every since 5.5.10-20.1. variable slow_query_log_always_write_time Command Line Yes Cong File Yes Scope Global Dynamic Yes Default Value 10 (seconds) This variable can be used to specify the query execution time after which the query will be written to the slow query log. It can be used to specify an additional execution time threshold for the slow query log, that, when exceeded, will cause a query to be logged unconditionally, that is, log_slow_rate_limit will not apply to it.

Changes to the Log Format The feature adds more information to the slow log output. Here is a sample log entry:
# User@Host: mailboxer[mailboxer] @ [192.168.10.165] # Thread_id: 11167745 Schema: board # Query_time: 1.009400 Lock_time: 0.000190 Rows_sent: 4 Rows_examined: 1543719 Rows_affected: 0 # Bytes_sent: 278 Tmp_tables: 0 Tmp_disk_tables: 0 Tmp_table_sizes: 0 # InnoDB_trx_id: 1500 # QC_Hit: No Full_scan: Yes Full_join: No Tmp_table: No Tmp_table_on_disk: No # Filesort: No Filesort_on_disk: No Merge_passes: 0 # InnoDB_IO_r_ops: 6415 InnoDB_IO_r_bytes: 105103360 InnoDB_IO_r_wait: 0.001279 # InnoDB_rec_lock_wait: 0.000000 InnoDB_queue_wait: 0.000000 # InnoDB_pages_distinct: 6430 SET timestamp=1346844943; SELECT id,title,production_year FROM title WHERE title = Bambi;
Another example (log_slow_verbosity =profiling):
# Query_time: 0.962742 Lock_time: 0.000202 Rows_sent: 4 Rows_examined: 1543719 Rows_affected: 0 # Bytes_sent: 278 Tmp_tables: 0 Tmp_disk_tables: 0 Tmp_table_sizes: 0 # Profile_starting: 0.000030 Profile_starting_cpu: 0.000028 Profile_Waiting_for_query_cache_lock: 0.0 Profile_Waiting_for_query_cache_lock_cpu: 0.000003 Profile_Waiting_on_query_cache_mutex: 0.000003 Profile_Waiting_on_query_cache_mutex_cpu: 0.000003 Profile_checking_query_cache_for_query: 0.000076 Profile_checking_query_cache_for_query_cpu: 0.000076 Profile_checking_permissions: 0.000011 Profile_checking_permissions_cpu: 0.000011 Profile_Opening_tables: 0.000078 Profile_Opening_tables_ Profile_System_lock: 0.000022 Profile_System_lock_cpu: 0.000022 Profile_Waiting_for_query_cache_loc Profile_Waiting_for_query_cache_lock_cpu: 0.000002 Profile_Waiting_on_query_cache_mutex: 0.000054 Profile_Waiting_on_query_cache_mutex_cpu: 0.000054 Profile_init: 0.000039 Profile_init_cpu: 0.00004 Profile_optimizing: 0.000015 Profile_optimizing_cpu: 0.000014 Profile_statistics: 0.000021 Profile_
8.3. Slow Query Log
109
Profile_preparing: 0.000020 Profile_preparing_cpu: 0.000020 Profile_executing: 0.000003 Profile_exe Profile_Sending_data: 0.962324 Profile_Sending_data_cpu: 0.961526 Profile_end: 0.000006 Profile_end Profile_query_end: 0.000004 Profile_query_end_cpu: 0.000004 Profile_closing_tables: 0.000008 Profil Profile_freeing_items: 0.000007 Profile_freeing_items_cpu: 0.000007 Profile_Waiting_for_query_cache Profile_Waiting_for_query_cache_lock_cpu: 0.000001 Profile_Waiting_on_query_cache_mutex: 0.000001 Profile_Waiting_on_query_cache_mutex_cpu: 0.000001 Profile_freeing_items: 0.000017 Profile_freeing_ Profile_Waiting_for_query_cache_lock: 0.000001 Profile_Waiting_for_query_cache_lock_cpu: 0.000001 Profile_Waiting_on_query_cache_mutex: 0.000000 Profile_Waiting_on_query_cache_mutex_cpu: 0.000001 Profile_freeing_items: 0.000001 Profile_freeing_items_cpu: 0.000001 Profile_storing_result_in_query Profile_storing_result_in_query_cache_cpu: 0.000002 Profile_logging_slow_query: 0.000001 Profile_lo # Profile_total: 0.962751 Profile_total_cpu: 0.961950 # InnoDB_trx_id: 1700
Connection and Schema Identier Each slow log entry now contains a connection identier, so you can trace all the queries coming from a single connection. This is the same value that is shown in the Id column in SHOW FULL PROCESSLIST or returned from the CONNECTION_ID() function. Each entry also contains a schema name, so you can trace all the queries whose default database was set to a particular schema.
# Thread_id: 11167745 Schema: board
Microsecond Time Resolution and Extra Row Information This is the original functionality offered by the microslow feature. Query_time and Lock_time are logged with microsecond resolution. The feature also adds information about how many rows were examined for SELECT queries, and how many were analyzed and affected for UPDATE, DELETE, and INSERT queries,
# Query_time: 0.962742 Lock_time: 0.000202 Rows_sent: 4 Rows_examined: 1543719 Rows_affected: 0
Values and context: Rows_examined: Number of rows scanned - SELECT Rows_affected: Number of rows changed - UPDATE, DELETE, INSERT Rows_read: Number of rows read - UPDATE, DELETE, INSERT Memory Footprint The feature provides information about the amount of bytes sent for the result of the query and the number of temporary tables created for its execution - differentiated by whether they were created on memory or on disk - with the total number of bytes used by them.
# Bytes_sent: 8053 Tmp_tables: 1 Tmp_disk_tables: 0 Tmp_table_sizes: 950528
Values and context: Bytes_sent: The amount of bytes sent for the result of the query Tmp_tables: Number of temporary tables created on memory for the query Tmp_disk_tables: Number of temporary tables created on disk for the query
110
Tmp_table_sizes: Total Size in bytes for all temporary tables used in the query Query Plan Information Each query can be executed in various ways. For example, it may use indexes or do a full table scan, or a temporary table may be needed. These are the things that you can usually see by running EXPLAIN on the query. The feature will now allow you to see the most important facts about the execution in the log le.
# QC_Hit: No Full_scan: Yes Full_join: No Tmp_table: No # Filesort: No Filesort_on_disk: No Merge_passes: 0 Tmp_table_on_disk: No
The values and their meanings are documented with the log_slow_filter option. InnoDB Usage Information The nal part of the output is the InnoDB usage statistics. MySQL currently shows many per-session statistics for operations with SHOW SESSION STATUS, but that does not include those of InnoDB, which are always global and shared by all threads. This feature lets you see those values for a given query.
# # # InnoDB_IO_r_ops: 6415 InnoDB_IO_r_bytes: 105103360 InnoDB_IO_r_wait: 0.001279 InnoDB_rec_lock_wait: 0.000000 InnoDB_queue_wait: 0.000000 InnoDB_pages_distinct: 6430
Values: innodb_IO_r_ops: Counts the number of page read operations scheduled. The actual number of read operations may be different, but since this can be done asynchronously, there is no good way to measure it. innodb_IO_r_bytes: Similar to innodb_IO_r_ops, but the unit is bytes. innodb_IO_r_wait: Shows how long (in seconds) it took InnoDB to actually read the data from storage. innodb_rec_lock_wait: Shows how long (in seconds) the query waited for row locks. innodb_queue_wait: Shows how long (in seconds) the query spent either waiting to enter the InnoDB queue or inside that queue waiting for execution. innodb_pages_distinct: Counts approximately the number of unique pages the query accessed. The approximation is based on a small hash array representing the entire buffer pool, because it could take a lot of memory to map all the pages. The inaccuracy grows with the number of pages accessed by a query, because there is a higher probability of hash collisions. If the query did not use InnoDB tables, that information is written into the log instead of the above statistics.

Impact of logging on MySQLs performance log_slow_lter Usage Blueprint in Launchpad
8.4 Extended Show Engine InnoDB Status

This feature reorganizes the output of SHOW ENGINE INNODB STATUS for a better readability and prints the amount of memory used by the internal hash tables. In addition, new variables are available to control the output. 8.4. Extended Show Engine InnoDB Status 111
This feature modied the SHOW ENGINE INNODB STATUS command as follows: TRANSACTION section was moved to the end of the output, so that important information is not overlooked when the there is a large amount of it. Added two variables to control SHOW ENGINE INNODB STATUS information presented (bugx for #29123): innodb_show_verbose_locks - Whether to show records locked innodb_show_locks_held - Number of locks held to print for each InnoDB transaction Added extended information about InnoDB internal hash table sizes (in bytes) in the BUFFER POOL AND MEMORY section; also added buffer pool size in bytes. Added additional LOG section information (beginning in release 5.5.8-20.0).

5.5.8-20.0 Added status variables showing information from SHOW ENGINE INNODB STATUS. 5.5.8-20.0 Added additional information in the LOG section. 5.5.10-20.1: Renamed innodb_current_row_locks. status variable innodb_row_lock_numbers to
5.5.31-30.3: Added innodb_read_views_memory and innodb_descriptors_memory to improve InnoDB memory diagnostics.

Author / Origin: Baron Schwartz, http://lists.mysql.com/internals/35174

variable innodb_show_verbose_locks Command Line Yes Cong File Yes Scope Global Dynamic Yes Variable Type ULONG Default Value 0 Range 0 - 1 Species to show records locked in SHOW ENGINE INNODB STATUS. The default is 0, which means only the higher-level information about the lock (which table and index is locked, etc.) is printed. If set to 1, then traditional InnoDB behavior is enabled: the records that are locked are dumped to the output. variable innodb_show_locks_held Command Line Yes Cong File Yes Scope Global
112
Dynamic Yes Variable Type ULONG Default Value 10 Range 0 - 1000 Species the number of locks held to print for each InnoDB transaction in SHOW ENGINE INNODB STATUS.

The status variables here contain information available in the output of SHOW ENGINE INNODB STATUS, organized by the sections SHOW ENGINE INNODB STATUS displays. If you are familiar with the output of SHOW ENGINE INNODB STATUS, you will probably already recognize the information these variables contain. BACKGROUND THREAD The following variables contain information in the BACKGROUND THREAD section of the output from SHOW ENGINE INNODB STATUS. An example of that output is: Insert an example of BACKGROUND THREAD section output here. variable Innodb_master_thread_1_second_loops Version Info 5.5.8-20.0 Introduced. Variable Type Numeric Scope Global variable Innodb_master_thread_10_second_loops Version Info 5.5.8-20.0 Introduced. Variable Type Numeric Scope Global variable Innodb_master_thread_background_loops Version Info 5.5.8-20.0 Introduced. Variable Type Numeric Scope Global variable Innodb_master_thread_main_flush_loops Version Info 5.5.8-20.0 Introduced. Variable Type Numeric Scope Global variable Innodb_master_thread_sleeps Version Info 8.4. Extended Show Engine InnoDB Status 113
5.5.8-20.0 Introduced. Variable Type Numeric Scope Global variable Innodb_background_log_sync Version Info 5.5.8-20.0 Introduced. Variable Type Numeric Scope Global SEMAPHORES The following variables contain information in the SEMAPHORES section of the output from SHOW ENGINE INNODB STATUS. An example of that output is:
---------SEMAPHORES ---------OS WAIT ARRAY INFO: reservation count 9664, signal count 11182 Mutex spin waits 20599, rounds 223821, OS waits 4479 RW-shared spins 5155, OS waits 1678; RW-excl spins 5632, OS waits 2592 Spin rounds per wait: 10.87 mutex, 15.01 RW-shared, 27.19 RW-excl
variable Innodb_mutex_os_waits Version Info 5.5.8-20.0 Introduced. Variable Type Numeric Scope Global variable Innodb_mutex_spin_rounds Version Info 5.5.8-20.0 Introduced. Variable Type Numeric Scope Global variable Innodb_mutex_spin_waits Version Info 5.5.8-20.0 Introduced. Variable Type Numeric Scope Global variable Innodb_s_lock_os_waits Version Info 5.5.8-20.0 Introduced. Variable Type Numeric Scope Global 114 Chapter 8. Diagnostics Improvements
variable Innodb_s_lock_spin_rounds Version Info 5.5.8-20.0 Introduced. Variable Type Numeric Scope Global variable Innodb_s_lock_spin_waits Version Info 5.5.8-20.0 Introduced. Variable Type Numeric Scope Global variable Innodb_x_lock_os_waits Version Info 5.5.8-20.0 Introduced. Variable Type Numeric Scope Global variable Innodb_x_lock_spin_rounds Version Info 5.5.8-20.0 Introduced. Variable Type Numeric Scope Global variable Innodb_x_lock_spin_waits Version Info 5.5.8-20.0 Introduced. Variable Type Numeric Scope Global INSERT BUFFER AND ADAPTIVE HASH INDEX The following variables contain information in the INSERT BUFFER AND ADAPTIVE HASH INDEX section of the output from SHOW ENGINE INNODB STATUS. An example of that output is:
------------------------------------INSERT BUFFER AND ADAPTIVE HASH INDEX ------------------------------------Ibuf: size 1, free list len 6089, seg size 6091, 44497 inserts, 44497 merged recs, 8734 merges Hash table size 276707, node heap has 1 buffer(s) 0.00 hash searches/s, 0.00 non-hash searches/s
variable Innodb_ibuf_discarded_delete_marks Version Info 5.5.8-20.0 Introduced. 8.4. Extended Show Engine InnoDB Status 115
Variable Type Numeric Scope Global variable Innodb_ibuf_discarded_deletes Version Info 5.5.8-20.0 Introduced. Variable Type Numeric Scope Global variable Innodb_ibuf_discarded_inserts Version Info 5.5.8-20.0 Introduced. Variable Type Numeric Scope Global variable Innodb_ibuf_free_list Version Info 5.5.8-20.0 Introduced. Variable Type Numeric Scope Global variable Innodb_ibuf_merged_delete_marks Version Info 5.5.8-20.0 Introduced. Variable Type Numeric Scope Global variable Innodb_ibuf_merged_deletes Version Info 5.5.8-20.0 Introduced. Variable Type Numeric Scope Global variable Innodb_ibuf_merged_inserts Version Info 5.5.8-20.0 Introduced. Variable Type Numeric Scope Global variable Innodb_ibuf_merges Version Info 5.5.8-20.0 Introduced. Variable Type Numeric
116
Scope Global variable Innodb_ibuf_segment_size Version Info 5.5.8-20.0 Introduced. Variable Type Numeric Scope Global variable Innodb_ibuf_size Version Info 5.5.8-20.0 Introduced. Variable Type Numeric Scope Global variable Innodb_adaptive_hash_cells Version Info 5.5.8-20.0 Introduced. Variable Type Numeric Scope Global variable Innodb_adaptive_hash_heap_buffers Version Info 5.5.8-20.0 Introduced. Variable Type Numeric Scope Global variable Innodb_adaptive_hash_hash_searches Version Info 5.5.8-20.0 Introduced. Variable Type Numeric Scope Global variable Innodb_adaptive_hash_non_hash_searches Version Info 5.5.8-20.0 Introduced. Variable Type Numeric Scope Global LOG The following variables contain information in the LOG section of the output from SHOW ENGINE INNODB STATUS. An example of that output is:
8.4. Extended Show Engine InnoDB Status
117
--LOG --Log sequence number 28219393219 Log flushed up to 28219393219 Last checkpoint at 28212583337 Max checkpoint age 7782360 Checkpoint age target 7539162 Modified age 6809882 Checkpoint age 6809882 0 pending log writes, 0 pending chkp writes 8570 log i/os done, 2000.00 log i/os/second
variable Innodb_lsn_current Version Info 5.5.8-20.0 Introduced. Variable Type Numeric Scope Global variable Innodb_lsn_flushed Version Info 5.5.8-20.0 Introduced. Variable Type Numeric Scope Global variable Innodb_lsn_last_checkpoint Version Info 5.5.8-20.0 Introduced. Variable Type Numeric Scope Global variable Innodb_checkpoint_age Version Info 5.5.8-20.0 Introduced. Variable Type Numeric Scope Global variable Innodb_checkpoint_max_age Version Info 5.5.8-20.0 Introduced. Variable Type Numeric Scope Global variable Innodb_checkpoint_target_age Version Info 5.5.8-20.0 Introduced.
118
Variable Type Numeric Scope Global BUFFER POOL AND MEMORY The following variables contain information in the BUFFER POOL AND MEMORY section of the output from SHOW ENGINE INNODB STATUS. An example of that output is:
---------------------BUFFER POOL AND MEMORY ---------------------Total memory allocated 137625600; in additional pool allocated 0 Total memory allocated by read views 88 Internal hash tables (constant factor + variable factor) Adaptive hash index 3774352 (2213656 + 1560696) Page hash 139144 Dictionary cache 629811 (554864 + 74947) File system 83536 (82672 + 864) Lock system 380792 (332872 + 47920) Recovery system 0 (0 + 0) Threads 84040 (82696 + 1344) Dictionary memory allocated 74947 Buffer pool size 8192 Buffer pool size, bytes 134217728 Free buffers 0 Database pages 8095 Old database pages 2968 Modified db pages 5914 Pending reads 0 Pending writes: LRU 0, flush list 129, single page 0 Pages made young 372084, not young 0 2546000.00 youngs/s, 0.00 non-youngs/s Pages read 103356, created 154787, written 979572 469000.00 reads/s, 78000.00 creates/s, 138000.00 writes/s Buffer pool hit rate 994 / 1000, young-making rate 34 / 1000 not 0 / 1000 Pages read ahead 0.00/s, evicted without access 15000.00/s
variable Innodb_mem_adaptive_hash Version Info 5.5.8-20.0 Introduced. Variable Type Numeric Scope Global variable Innodb_mem_dictionary Version Info 5.5.8-20.0 Introduced. Variable Type Numeric Scope Global variable Innodb_mem_total Version Info 5.5.8-20.0 Introduced. 8.4. Extended Show Engine InnoDB Status 119
Variable Type Numeric Scope Global variable Innodb_buffer_pool_pages_LRU_flushed Version Info 5.5.8-20.0 Introduced. Variable Type Numeric Scope Global variable Innodb_buffer_pool_pages_made_not_young Version Info 5.5.8-20.0 Introduced. Variable Type Numeric Scope Global variable Innodb_buffer_pool_pages_made_young Version Info 5.5.8-20.0 Introduced. Variable Type Numeric Scope Global variable Innodb_buffer_pool_pages_old Version Info 5.5.8-20.0 Introduced. Variable Type Numeric Scope Global variable Innodb_descriptors_memory Version Info 5.5.31-30.3 Introduced. Variable Type Numeric Scope Global This status variable shows the current size of the descriptors array (in bytes). The descriptor array is an XtraDB data structure that contains the information on currently running transactions. variable Innodb_read_views_memory Version Info 5.5.31-30.3 Introduced. Variable Type Numeric Scope Global This status variable shows the total amount of memory allocated for the InnoDB read view (in bytes).
120
OLDEST VIEW This part contains the information about the oldest active transaction in the system. An example of that output is:
---OLDEST VIEW--Normal read view Read view low limit trx n:o 3300 Read view up limit trx id 3300 Read view low limit trx id 3300 Read view individually stored trx ids:
Read view low limit trx n:o and Read view up limit trx id are the highest transactions IDs at the time the view was created. This means that it should not see newer transactions with IDs bigger than or equal to that value. Read view low limit trx id is the latest committed transaction ID at the time the oldest view was created. This means that it should see all transactions with IDs smaller than or equal to that value. Read view individually stored trx ids contains the list of active transactions at the time the view was created. TRANSACTIONS The following variables contain information in the TRANSACTIONS section of the output from SHOW ENGINE INNODB STATUS. An example of that output is:
-----------TRANSACTIONS -----------Trx id counter F561FD Purge done for trxs n:o < F561EB undo n:o < 0 History list length 19 LIST OF TRANSACTIONS FOR EACH SESSION: ---TRANSACTION 0, not started, process no 993, OS thread id 140213152634640 mysql thread id 15933, query id 32109 localhost root show engine innodb status ---TRANSACTION F561FC, ACTIVE 29 sec, process no 993, OS thread id 140213152769808 updating or deleti mysql tables in use 1, locked 1
variable Innodb_history_list_length Version Info 5.5.8-20.0 Introduced. Variable Type Numeric Scope Global variable Innodb_max_trx_id Version Info 5.5.8-20.0 Introduced. Variable Type Numeric Scope Global variable Innodb_oldest_view_low_limit_trx_id Version Info
8.4. Extended Show Engine InnoDB Status
121
5.5.8-20.0 Introduced. Variable Type Numeric Scope Global variable Innodb_purge_trx_id Version Info 5.5.8-20.0 Introduced. Variable Type Numeric Scope Global variable Innodb_purge_undo_no Version Info 5.5.8-20.0 Introduced. Variable Type Numeric Scope Global variable Innodb_current_row_locks version 5.5.8-20.0 Introduced. version 5.5.10-20.1 Renamed. vartype Numeric scope Global This variable was named innodb_row_lock_numbers in release 5.5.8-20.0.
8.4.5 Other reading

SHOW INNODB STATUS walk through Table locks in SHOW INNODB STATUS
8.5 Count InnoDB Deadlocks

When running a transactional application you have to live with deadlocks. They are not problematic as long as they do not occur too frequently. The standard SHOW ENGINE INNODB STATUS gives information on the latest deadlocks but it is not very useful when you want to know the total number of deadlocks or the number of deadlocks per unit of time. This change adds a status variable that keeps track of the number of deadlocks since the server startup, opening the way to a better knowledge of your deadlocks. This feature was provided by Eric Bergen under BSD license (see InnoDB Deadlock Count Patch). It adds a new global status variable (innodb_deadlocks) showing the number of deadlocks.* You can use it with SHOW GLOBAL STATUS, e.g.:
122
mysql> SHOW GLOBAL STATUS LIKE innodb_deadlocks; +------------------+-------+ | Variable_name | Value | +------------------+-------+ | innodb_deadlocks | 323 | +------------------+-------+
or with INFORMATION_SCHEMA, e.g.:
mysql> SELECT VARIABLE_VALUE FROM INFORMATION_SCHEMA.GLOBAL_STATUS WHERE VARIABLE_NAME = innodb_dead +----------------+ | VARIABLE_VALUE | +----------------+ | 323 | +----------------+
A deadlock will occur when at least two transactions are mutually waiting for the other to nish, thus creating a circular dependency that lasts until something breaks it. InnoDB is quite good at detecting deadlocks and generally returns an error instantly. Most transactional systems have no way to prevent deadlocks from occurring and must be designed to handle them, for instance by retrying the transaction that failed.


One new status variable was introduced by this feature. variable Innodb_deadlocks Variable Type LONG Scope Global

Original post by Eric Bergen
8.6 Log All Client Commands (syslog)

When enabled, this feature causes all commands run by the command line client to be logged to syslog. If you want to enable this option permanently, add it to the [mysql] group in my.cnf.


Author / Origin: Percona 8.6. Log All Client Commands (syslog) 123
8.6.3 Client Variables

variable syslog Command Line Yes Cong File Yes Server No Scope Global Dynamic Yes Variable Type Boolean Default Value OFF Range ON/OFF The variable enables (ON)/disables (OFF) logging to syslog.
8.6.4 Other Reading

http://en.wikipedia.org/wiki/Syslog http://tools.ietf.org/html/rfc5424
8.7 Response Time Distribution

The slow query log provides exact information about queries that take a long time to execute. However, sometimes there are a large number of queries that each take a very short amount of time to execute. This feature provides a tool for analyzing that information by counting and displaying the number of queries according to the the length of time they took to execute. The user can dene time intervals that divide the range 0 to positive innity into smaller intervals and then collect the number of commands whose execution times fall into each of those intervals. Note that in a replication environment, the server will not take into account any queries executed by the slaves SQL thread (whether they are slow or not) for the time distribution unless the log_slow_slave_statements variable is set. The feature isnt implemented in all versions of the server. The variable have_response_time_distribution indicates whether or not it is implemented in the server you are running. Each interval is described as:
(range_base ^ n; range_base ^ (n+1)]
The range_base is some positive number (see Limitations). The interval is dened as the difference between two nearby powers of the range base. For example, if the range base=10, we have the following intervals:
(0; 10 ^ -6], (10 ^ -6; 10 ^ -5], (10 ^ -5; 10 ^ -4], ..., (10 ^ -1; 10 ^1], (10^1; 10^2]...(10^7; po
or
(0; 0.000001], (0.000001; 0.000010], (0.000010; 0.000100], ..., (0.100000; 1.0]; (1.0; 10.0]...(10000
124
For each interval, a count is made of the queries with execution times that fell into that interval. You can select the range of the intervals by changing the range base. For example, for base range=2 we have the following intervals:
(0; 2 ^ -19], (2 ^ -19; 2 ^ -18], (2 ^ -18; 2 ^ -17], ..., (2 ^ -1; 2 ^1], (2 ^ 1; 2 ^ 2]...(2 ^ 25;
or
(0; 0.000001], (0.000001, 0.000003], ..., (0.25; 0.5], (0.5; 2], (2; 4]...(8388608; positive infinity
Small numbers look strange (i.e., dont look like powers of 2), because we lose precision on division when the ranges are calculated at runtime. In the resulting table, you look at the high boundary of the range. For example, you may see:
+----------------+-------+------------+ | time | count | total | +----------------+-------+------------| | 0.000001 | 0 | 0.000000 | | 0.000010 | 17 | 0.000094 | | 0.000100 | 4301 | 0.236555 | | 0.001000 | 1499 | 0.824450 | | 0.010000 | 14851 | 81.680502 | | 0.100000 | 8066 | 443.635693 | | 1.000000 | 0 | 0.000000 | | 10.000000 | 0 | 0.000000 | | 100.000000 | 1 | 55.937094 | | 1000.000000 | 0 | 0.000000 | | 10000.000000 | 0 | 0.000000 | | 100000.000000 | 0 | 0.000000 | | 1000000.000000 | 0 | 0.000000 | | TOO LONG QUERY | 0 | 0.000000 | +----------------+-------+------------+
This means there were:
* 17 queries with 0.000001 < query execution time < = 0.000010 seconds; total execution time of the 1
* 4301 queries with 0.000010 < query execution time < = 0.000100 seconds; total execution time of the
* 14851 queries with 0.001000 < query execution time < = 0.010000 seconds; total execution time of th
* 1 query with 10.000000 < query execution time < = 100.0000 seconds; total execution time of the 1 q
8.7.1 Usage
SELECT You can get the distribution using the query:
> SELECT * from INFORMATION_SCHEMA.QUERY_RESPONSE_TIME time count total 0.000001 0 0.000000 0.000010 0 0.000000
8.7. Response Time Distribution
125
0.000100 0.001000 0.010000 0.100000 1.000000 10.000000 100.000000 1000.000000 10000.000000 100000.000000 1000000.000000 TOO LONG QUERY
1 0 0 0 0 8 0 0 0 0 0 0
0.000072 0.000000 0.000000 0.000000 0.000000 47.268416 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000
You can write a complex query like:
SELECT c.count, c.time, (SELECT SUM(a.count) FROM INFORMATION_SCHEMA.QUERY_RESPONSE_TIME as a WHERE a.count != 0) as query_co (SELECT COUNT(*) FROM INFORMATION_SCHEMA.QUERY_RESPONSE_TIME as b WHERE b.count != 0) as not_zero (SELECT COUNT(*) FROM INFORMATION_SCHEMA.QUERY_RESPONSE_TIME) as region_count FROM INFORMATION_SCHEMA.QUERY_RESPONSE_TIME as c WHERE c.count > 0;
Note: If query_response_time_stats is ON, the execution times for these two SELECT queries will also be collected. SHOW Also, you can use this syntax:
> SHOW QUERY_RESPONSE_TIME; time count 0.000001 0 0.000010 0 0.000100 1 0.001000 0 0.010000 0 0.100000 0 1.000000 0 10.000000 8 100.000000 0 1000.000000 0 10000.000000 0 100000.000000 0 1000000.000000 0 TOO LONG QUERY 0 total 0.000000 0.000000 0.000072 0.000000 0.000000 0.000000 0.000000 47.268416 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000
Note: The execution time for the SHOW query will also be collected. FLUSH Flushing can be done with:
FLUSH QUERY_RESPONSE_TIME;
FLUSH does two things: Clears the collected times from the QUERY_RESPONSE_TIME table Reads the value of query_response_time_range_base and uses it to set the range base for the table 126 Chapter 8. Diagnostics Improvements
Note: The execution time for the FLUSH query will also be collected. Stored procedures Stored procedure calls count as single query. Collect time point Time is collected after query execution completes (before clearing data structures).
8.7.2 Limitations
String width for seconds Value: 7 Compile-time variable: QUERY_RESPONSE_TIME_STRING_POSITIVE_POWER_LENGTH String width for microseconds Value: 6 Compile-time variable: QUERY_RESPONSE_TIME_STRING_NEGATIVE_POWER_LENGTH Minimum range base Value: 2 Compile-time variable: QUERY_RESPONSE_TIME_MINIMUM_BASE Minimum range base Value: 1000 Compile-time variable: QUERY_RESPONSE_TIME_MAXIMUM_BASE Minimum time interval Value: 1 microsecond Maximum time interval Value: 9999999 seconds

5.5.8-20.0: Introduced variable have_response_time_distribution. 5.5.8-20.0: Introduced variable query_response_time_stats.

variable have_response_time_distribution Version Info 5.5.8-20.0 Introduced. Scope Global
8.7. Response Time Distribution
127
Dynamic No Variable Type Boolean Default Value YES Range YES/NO Contains the value YES if the server youre running supports this feature; contains NO if the feature is not supported. It is enabled by default. variable query_response_time_range_base Command Line Yes Cong File Yes Scope Global Dynamic Yes Variable Type Numeric Default Value 10 Range 2-1000 Sets up the logarithm base for the scale. Note: The variable takes effect only after this command has been executed:
FLUSH QUERY_RESPONSE_TIME;
variable query_response_time_stats Version Info 5.5.8-20.0 Introduced. Command Line Yes Cong File Yes Scope Global Dynamic Yes Variable Type Boolean Default Value OFF Range ON/OFF This variable enables and disables collection of query times if the feature is available in the server thats running. If the value of variable have_response_time_distribution is YES, then you can enable collection of query times by setting this variable to ON using SET GLOBAL. Prior to release 5.5.8-20.0, this variable was named enable_query_response_time_stats.

table INFORMATION_SCHEMA.QUERY_RESPONSE_TIME Columns TIME (VARCHAR) Interval range in which the query occurred COUNT (INT(11)) Number of queries with execution times that fell into that interval 128 Chapter 8. Diagnostics Improvements
TOTAL (VARCHAR) Total execution time of the queries
8.8 Show Storage Engines

This feature changes the comment eld displayed when the SHOW STORAGE ENGINES command is executed and XtraDB is the storage engine. Before the Change:
mysql> show storage engines; +------------+---------+----------------------------------------------------------------+-----------| Engine | Support | Comment | Transaction +------------+---------+----------------------------------------------------------------+-----------| InnoDB | YES | Supports transactions, row-level locking, and foreign keys | YES ... +------------+---------+----------------------------------------------------------------+------------
After the Change:
mysql> show storage engines; +------------+---------+----------------------------------------------------------------------------+ | Engine | Support | Comment | +------------+---------+----------------------------------------------------------------------------+ | InnoDB | YES | Percona-XtraDB, Supports transactions, row-level locking, and foreign keys | ... +------------+---------+----------------------------------------------------------------------------+


Author / Origin: Percona
8.9 Show Lock Names

This feature is currently undocumented except for the following example. Example:
mysql> SHOW ENGINE INNODB MUTEX; +--------+---------------------------+---------------+ | Type | Name | Status | +--------+---------------------------+---------------+ | InnoDB | &rseg->mutex | os_waits=210 | | InnoDB | &dict_sys->mutex | os_waits=3 | | InnoDB | &trx_doublewrite->mutex | os_waits=1 | | InnoDB | &log_sys->mutex | os_waits=1197 | | InnoDB | &LRU_list_mutex | os_waits=2 | | InnoDB | &fil_system->mutex | os_waits=5 | | InnoDB | &kernel_mutex | os_waits=242 | | InnoDB | &new_index->lock | os_waits=2 |
8.8. Show Storage Engines
129
| InnoDB | &new_index->lock .....
| os_waits=415
8.10 Process List

This page describes Percona changes to both the standard MySQL SHOW PROCESSLIST command and the standard MySQL INFORMATION_SCHEMA table PROCESSLIST. The changes that have been made as of version 5.5 of the server are: SHOW PROCESSLIST command: added columns ROWS_EXAMINED, ROWS_SENT, and ROWS_READ PROCESSLIST table: added columns TIME_MS, ROWS_EXAMINED, ROWS_SENT, and ROWS_READ

5.5.10-20.1: Added columns ROWS_EXAMINED, ROWS_SENT, and ROWS_READ to SHOW PROCESSLIST command. Added columns ROWS_EXAMINED, ROWS_SENT, and ROWS_READ to PROCESSLIST table.

table INFORMATION_SCHEMA.PROCESSLIST This table implements modications to the standard MySQL INFORMATION_SCHEMA table PROCESSLIST. Columns ID The connection identier. USER The MySQL user who issued the statement. HOST The host name of the client issuing the statement. DB The default database, if one is selected, otherwise NULL. COMMAND The type of command the thread is executing. TIME The time in seconds that the thread has been in its current state. STATE An action, event, or state that indicates what the thread is doing. INFO The statement that the thread is executing, or NULL if it is not executing any statement. TIME_MS The time in milliseconds that the thread has been in its current state. ROWS_EXAMINED The number of rows examined by the statement being executed. ROWS_SENT The number of rows sent by the statement being executed. ROWS_READ The number of rows read by the statement being executed.
130
8.10.3 Example Output

SHOW PROCESSLIST Command:
mysql> show processlist; +------+-----------+-----------+--------+---------+------+------------+-----------------------------| Id | User | Host | db | Command | Time | State | Info +------+-----------+-----------+--------+---------+------+------------+-----------------------------| 2 | root | localhost | test | Query | 0 | NULL | SHOW PROCESSLIST | 14 | root | localhost | test | Query | 0 | User lock | SELECT GET_LOCK(t,1000) +------+-----------+-----------+--------+---------+------+------------+------------------------------
Table PROCESSLIST:
mysql> select * from information_schema.PROCESSLIST; +------+-----------+-----------+--------+---------+------+------------+-----------------------------| ID | USER | HOST | DB | COMMAND | TIME | STATE | INFO +------+-----------+-----------+--------+---------+------+------------+-----------------------------| 14 | root | localhost | test | Query | 0 | User lock | SELECT GET_LOCK(t,1000) | 2 | root | localhost | test | Query | 0 | executing | SELECT * from INFORMATION_SCH +------+-----------+-----------+--------+---------+------+------------+------------------------------
8.11 Misc. INFORMATION_SCHEMA Tables

8.11.1 Temporary tables
Only the temporary tables that were explicitly created with CREATE TEMPORARY TABLE or ALTER TABLE are shown, and not the ones created to process complex queries. table INFORMATION_SCHEMA.GLOBAL_TEMPORARY_TABLES Columns SESSION_ID MySQL connection id TABLE_SCHEMA Schema in which the temporary table is created TABLE_NAME Name of the temporary table ENGINE Engine of the temporary table NAME Internal name of the temporary table TABLE_ROWS Number of rows of the temporary table AVG_ROW_LENGTH Average row length of the temporary table DATA_LENGTH Size of the data (Bytes) INDEX_LENGTH Size of the indexes (Bytes) CREATE_TIME Date and time of creation of the temporary table UPDATE_TIME Date and time of the latest update of the temporary table This table holds information on the temporary tables existing for all connections. You dont need the SUPER privilege to query this table. table INFORMATION_SCHEMA.TEMPORARY_TABLES Columns
8.11. Misc. INFORMATION_SCHEMA Tables
131
SESSION_ID MySQL connection id TABLE_SCHEMA Schema in which the temporary table is created TABLE_NAME Name of the temporary table ENGINE Engine of the temporary table NAME Internal name of the temporary table TABLE_ROWS Number of rows of the temporary table AVG_ROW_LENGTH Average row length of the temporary table DATA_LENGTH Size of the data (Bytes) INDEX_LENGTH Size of the indexes (Bytes) CREATE_TIME Date and time of creation of the temporary table UPDATE_TIME Date and time of the latest update of the temporary table This table holds information on the temporary tables existing for the running connection.
8.11.2 Buffer Pool Data Structure Tables

The following tables provide various information about the contents of the InnoDB buffer pool. table INFORMATION_SCHEMA.INNODB_BUFFER_POOL_PAGES Columns PAGE_TYPE Type of the page. Possible values: index, undo_log, inode, ibuf_free_list, allocated, bitmap, sys, trx_sys, fsp_hdr, xdes, blob, zblob, zblob2, unknown SPACE_ID Tablespace ID PAGE_NO Page offset within its tablespace LRU_POSITION Page position in the LRU list FIX_COUNT reference count of a page. It is incremented every time the page is accessed by InnoDB, and is 0 if and only if the page is not currently being accessed FLUSH_TYPE type of the last ush of the page (0:LRU 2:ush_list) Example:
mysql> select * from information_schema.INNODB_BUFFER_POOL_PAGES LIMIT 20; +-----------+----------+---------+--------------+-----------+------------+ | page_type | space_id | page_no | lru_position | fix_count | flush_type | +-----------+----------+---------+--------------+-----------+------------+ | allocated | 0 | 7 | 3 | 0 | 2 | | allocated | 0 | 1 | 4 | 0 | 0 | | allocated | 0 | 3 | 5 | 0 | 0 | | inode | 0 | 2 | 6 | 0 | 2 | | index | 0 | 4 | 7 | 0 | 2 | | index | 0 | 11 | 8 | 0 | 0 | | index | 0 | 12956 | 9 | 0 | 0 | | allocated | 0 | 5 | 10 | 0 | 2 | | allocated | 0 | 6 | 11 | 0 | 2 | | undo_log | 0 | 51 | 12 | 0 | 2 | | undo_log | 0 | 52 | 13 | 0 | 2 | | index | 0 | 8 | 14 | 0 | 0 | | index | 0 | 288 | 15 | 0 | 0 |
132
| index | 0 | 290 | 16 | 0 | 2 | | index | 0 | 304 | 17 | 0 | 0 | | allocated | 0 | 0 | 18 | 0 | 2 | | index | 0 | 10 | 19 | 0 | 0 | | index | 0 | 12973 | 20 | 0 | 0 | | index | 0 | 9 | 21 | 0 | 2 | | index | 0 | 12 | 22 | 0 | 0 | +-----------+----------+---------+--------------+-----------+------------+ 20 rows in set (0.81 sec)
This table shows the characteristics of the allocated pages in buffer pool and current state of them. table INFORMATION_SCHEMA.INNODB_BUFFER_POOL_PAGES_INDEX Columns index_id index name space_id Tablespace ID page_no Page offset within its tablespace n_recs number of user records on page data_size sum of the sizes of the records in page hashed the block is in adaptive hash index (1) or not (0) access_time time of the last access to that page modied modied since loaded (1) or not (0) dirty modied since last ushed (1) or not (0) old is old blocks in the LRU list (1) or not (0) lru_position page position in the LRU list x_count reference count of a page. It is incremented every time the page is accessed by InnoDB, and is 0 if and only if the page is not currently being accessed ush_type type of the last ush of the page (0:LRU 2:ush_list) Example:
+----------+----------+---------+--------+-----------+--------+-------------+----------+-------+----| index_id | space_id | page_no | n_recs | data_size | hashed | access_time | modified | dirty | old +----------+----------+---------+--------+-----------+--------+-------------+----------+-------+----| 39 | 0 | 5787 | 468 | 14976 | 1 | 2636182517 | 1 | 0 | 1 | 40 | 0 | 5647 | 1300 | 15600 | 1 | 2636182517 | 1 | 0 | 1 | 39 | 0 | 5786 | 468 | 14976 | 1 | 2636182516 | 1 | 0 | 1 | 40 | 0 | 6938 | 1300 | 15600 | 1 | 2636193968 | 1 | 0 | 1 | 39 | 0 | 5785 | 468 | 14976 | 1 | 2636182514 | 1 | 0 | 1 | 39 | 0 | 5784 | 468 | 14976 | 1 | 2636182512 | 1 | 0 | 1 | 40 | 0 | 5646 | 1300 | 15600 | 1 | 2636182511 | 1 | 0 | 1 | 39 | 0 | 7203 | 468 | 14976 | 1 | 2636193967 | 1 | 0 | 1 | 39 | 0 | 5783 | 468 | 14976 | 1 | 2636182507 | 1 | 0 | 1 | 39 | 0 | 5782 | 468 | 14976 | 1 | 2636182506 | 1 | 0 | 1 +----------+----------+---------+--------+-----------+--------+-------------+----------+-------+-----
This table shows information about the index pages located in the buffer pool. table INFORMATION_SCHEMA.INNODB_BUFFER_POOL_PAGES_BLOB Columns
8.11. Misc. INFORMATION_SCHEMA Tables
133
space_id tablespace ID page_no page offset within its tablespace compressed contains compressed data (1) or not (0) part_len data length in the page next_page_no page number of the next data lru_position page position in the LRU list x_count reference count of a page. It is incremented every time the page is accessed by InnoDB, and is 0 if and only if the page is not currently being accessed ush_type type of the last ush of the page (0:LRU 2:ush_list) Example:
mysql> select * from information_schema.INNODB_BUFFER_POOL_PAGES_BLOB LIMIT 20; +----------+---------+------------+----------+--------------+--------------+-----------+------------+ | space_id | page_no | compressed | part_len | next_page_no | lru_position | fix_count | flush_type | +----------+---------+------------+----------+--------------+--------------+-----------+------------+ | 1748 | 111 | 0 | 10137 | 0 | 263 | 0 | 2 | | 1748 | 307 | 0 | 5210 | 0 | 1084 | 0 | 2 | | 1748 | 1329 | 0 | 6146 | 0 | 4244 | 0 | 2 | | 1748 | 1330 | 0 | 11475 | 0 | 4245 | 0 | 2 | | 1748 | 1345 | 0 | 5550 | 0 | 4247 | 0 | 2 | | 1748 | 1346 | 0 | 7597 | 0 | 4248 | 0 | 2 | | 1748 | 3105 | 0 | 6716 | 0 | 8919 | 0 | 2 | | 1748 | 3213 | 0 | 8170 | 0 | 9390 | 0 | 2 | | 1748 | 6142 | 0 | 5648 | 0 | 19638 | 0 | 2 | | 1748 | 7387 | 0 | 10634 | 0 | 24191 | 0 | 2 | | 1748 | 7426 | 0 | 5355 | 0 | 24194 | 0 | 2 | | 1748 | 7489 | 0 | 16330 | 7489 | 24196 | 0 | 2 | | 1748 | 7490 | 0 | 7126 | 0 | 24197 | 0 | 2 | | 1748 | 7657 | 0 | 13571 | 0 | 24681 | 0 | 2 | | 1748 | 7840 | 0 | 11208 | 0 | 25737 | 0 | 2 | | 1748 | 9599 | 0 | 11882 | 0 | 31989 | 0 | 2 | | 1748 | 11719 | 0 | 7367 | 0 | 40466 | 0 | 2 | | 1748 | 12051 | 0 | 11049 | 0 | 41441 | 0 | 2 | | 1748 | 12052 | 0 | 16330 | 12052 | 41442 | 0 | 2 | | 1748 | 12053 | 0 | 2674 | 0 | 41443 | 0 | 2 | +----------+---------+------------+----------+--------------+--------------+-----------+------------+ 20 rows in set (0.05 sec)
This table shows information from blob pages located in buffer pool.
8.11.3 InnoDB Undo Logs

The purpose of this table is to report on the existence and usage of the internal undo log records. These undo records are stored in standard InnoDB pages and are used in a few ways but their main purpose is that currently executing but uncommitted user transactions can be rolled back after either a crash, fast shutdown or other recovery purpose. Each record within the table identies an InnoDB undo segment and will refer to other INFORMATION_SCHEMA tables such as INNODB_TRX and INODB_RSEG. This table can be used to help troubleshoot large system tablespaces and identify run-away or long running transactions. table INFORMATION_SCHEMA.INNODB_UNDO_LOGS Columns
134
trx_id Transaction ID - this is the id of the transaction that has currently allocated the undo segment and will potentially place undo records within it. More information on this transaction can be found by matching the trx_id with that in the INFORMATION_SCHEMA.INNODB_TRX table. rseg_id Rollback segment ID associated with this particular undo segment. More info on this rollback segment can be found by matching the rseg_id with that in the INFORMATION_SCHEMA.INNODB_RSEG. useg_id Undo segment ID type Segment type - identies what type of operation the segments is allocated for. state Segment state size Segment size in pages States of an undo log segment: ACTIVE - contains an undo log of an active transaction CACHED - cached for quick reuse TO_FREE - insert undo segment can be freed TO_PURGE - update undo segment will not be reused; it can be freed in purge when all undo data in it is removed PREPARED - contains an undo log of a prepared transaction
8.12 Thread Based Proling

Percona Server now uses thread based proling by default, instead of process based proling. This was implemented because with process based proling, threads on the server, other than the one being proled, can affect the proling information. Thread based proling is using the information provided by the kernel getrusage function. Since the 2.6.26 kernel version, thread based resource usage is available with the RUSAGE_THREAD. This means that the thread based proling will be used if youre running the 2.6.26 kernel or newer, or if the RUSAGE_THREAD has been ported back. This feature is enabled by default if your system supports it, in other cases it uses process based proling.

5.5.25a-27.1: Thread based proling introduced
8.12. Thread Based Proling
135
136
CHAPTER
NINE
OBSOLETE AND REMOVED FEATURES

9.1 Shared Memory Buffer Pool
The SHM buffer pool patch, which provided the ability to use a shared memory segment for the buffer pool to enable faster server restarts, has been removed. Instead, we recommend using the LRU Dump/Restore patch which provides similar improvements in restart performance. Replacement is due to SHM buffer pool both being very invasive and not widely used. Improved restart times are better provided by the much safer LRU D/R patch which has the advantage of also persisting across machine restarts. The conguration variables for my.cnf have been kept for compatibility and warnings will be printed for the deprecated options (innodb_buffer_pool_shm_key and innodb_buffer_pool_shm_checksum) if used. Instructions for disabling the SHM buffer pool can be found here. Instructions on setting up LRU dump/restore can be found here.

5.5.8-20.0: First Percona Server 5.5 release, also included Shared Memory Buffer Pool. 5.5.13-20.4: Feature removed, as LRU Dump/Restore is less invasive, more reliable and a better solution.

variable innodb_buffer_pool_shm_key Command Line Yes Cong File Yes Scope Global Dynamic No Variable Type Boolean Default Value OFF Range ON/OFF variable innodb_buffer_pool_shm_checksum Command Line Yes Cong File Yes 137
Scope Global Dynamic No Variable Type Boolean Default Value ON Range ON/OFF
138
Chapter 9. Obsolete and Removed Features
CHAPTER
TEN
REFERENCE
10.1 Development of Percona Server
Percona Server is an open source project to produce a distribution of the MySQL server with improved performance, scalability and diagnostics.
10.1.1 Submitting Changes

This process is very much modeled on what is being used by Drizzle. The Drizzle project went through several iterations and renements before settling on this process. It has been found to both keep trunk in a constant state of stability (allowing for a release at any time) and minimizing wasted time by developers due to broken code from somebody else interfering with their day. You should also be familiar with our Jenkins setup. Overview At Percona we use Bazaar for source control and launchpad for both code hosting and release management. Changes to our software projects could be because of a new feature (blueprint) or xing a bug (bug). Projects such as refactoring could be classed as a blueprint or a bug depending on the scope of the work. Blueprints and bugs are targeted to specic milestones (releases). A milestone is part of a series - e.g. 1.6 is a series in Percona XtraBackup and 1.6.1, 1.6.2 and 1.6.3 are milestones in the 1.6 series. Code is proposed for merging in the form of merge requests on launchpad. Some software (such as Percona Xtrabackup) we maintain both a development branch and a stable branch. For example: Xtrabackup 1.6 is the current stable series, and changes that should make it into bugx releases of 1.6 should be proposed for the 1.6 tree. However, most new features or more invasive (or smaller) bug xes should be targeted to the next release, currently 1.7. If submitting something to 1.6, you should also propose a branch that has these changes merged to the development release (1.7). This way somebody else doesnt have to attempt to merge your code and we get to run any extra tests that may be in the tree (and check compatibility with all platforms). For Percona Server, we have two current bzr branches on which development occurs: 5.1 and 5.5. As Percona Server is not a traditional project, instead being a set of patches against an existing product, these two branches are not related. That is, we do not merge from one to the other. To have your changes in both, you must propose two branches: one for 5.1 version of patch and one for 5.5.
139
Making a change to a project In this case were going to use percona-xtrabackup as an example. workow is similar for Percona Server, but patch will need to be modied both in 5.1 and 5.5 branches. bzr branch lp:percona-xtrabackup featureX (where featureX is a sensible name for the task at hand) (developer makes changes in featureX, testing locally) Developer pushes to lp:~username/percona-xtrabackup/featureX When the developer thinks the branch may be ready to be merged, they will run the branch through param build. If there are any build or test failures, developer xes them (in the case of failing tests in trunk... no more tests should fail. Eventually all tests will pass in trunk) Developer can then submit a merge proposal to lp:percona-xtrabackup, referencing URL for the param build showing that build and test passes Code undergoes review Once code is accepted, it can be merged (see other section) If the change also applies to a stable release (e.g. 1.6) then changes should be made on a branch of 1.6 and merged to a branch of trunk. In this case there should be two branches run through param build and two merge proposals (one for 1.6 and one with the changes merged to trunk). This prevents somebody else having to guess how to merge your changes. Merging approved branches Before code hits trunk, it goes through a staging branch, where some extra tests may be run (e.g. valgrind) along with testing that all branches behave well together (build and test) before pushing to trunk. To ensure quality, DO NOT push directly to trunk! everything must go through adequate testing rst. This ensures that at any point trunk is in a releasable state. Please note that ALL changes must go through staging rst This is to ensure that several approved merge requests do not interact badly with each other. Merge captain (for lack of a better term for the person merging approved code into trunk) may collate several approved branches that have individually passed param-build as run by the original developers. Workow would look something like this: * bzr branch lp:percona-xtrabackup staging * bzr merge lp:~user/percona-xtrabackup/featureX * bzr commit -m "merge feature X" * bzr merge lp:~user/percona-xtrabackup/featureY * bzr commit -m "merge feature Y" * bzr push --overwrite lp:percona-xtrabackup/staging * Run lp:percona-xtrabackup/staging through param build (in future, well likely have a Jenkins job specically for this) * If build succeeds, bzr push lp:percona-server (and branches will be automatically marked as merged.. although bug reports will need to be manually changed to Fix Released)
140
Chapter 10. Reference
* If build or test fails, attempt to nd which branch may be the cause, and repeat process but without that branch. Any failing branch will be set to Work in Progress with a Needs xing review with the URL of the build in jenkins where the failure occured. This will allow developers to x their code. Resubmitting a merge request In the event of a merge request being marked as Work In Progress due to build/test failures when merging, the developer should x up the branch, run through param build and then Resubmit the merge proposal. There is a link on launchpad to resubmit the merge proposal, this means it appears in the list of merge requests to review again rather than off in the work in progress section. Percona Server The same process for Percona Server, but we have different branches (and merge requests) for 5.1 and 5.5 series. Upgrading MySQL base version Same process as other modications. create local branch make changes param build merge request We will need some human processes to ensure that we do not merge extra things during the time when base MySQL version is being updated to avoid making life harder for the person doing the update.
10.1.2 Making a release

bzr branch lp:project release-project-VERSION build packages perform any nal tests (as we transition, this will already have been done by jenkins) bzr tag project-version merge request back to lp:project including the tag (TODO: write exact bzr commands for this) This way anybody can easily check out an old release by just using bzr to branch the specic tag.
10.1.3 Jenkins
Our Jenkins instance uses a mixture of VMs on physical hosts that Percona runs and Virtual Machines in Amazon EC2 that are launched on demand.
10.1. Development of Percona Server
141
Basic Concepts We have some jobs that are activated based on source control changes (new commits in a bzr repository). We have some that are param build - that is, a user species parameters for the build (e.g. the bzr tree). A param-build allows developers to ensure their branch compiles and passes tests on all supported platforms before submitting a merge request. This helps us maintain the quality of the main bzr branches and not block other developers work. Jenkins is a Master/Slave system and the jenkins master schedules the builds across available machines (and may launch new VMs in EC2 to meet demand). Most of our jobs are whats known as matrix builds. That is, a job that will be run with several different congurations of the project (e.g. release, debug) across several platforms (e.g. on a host matching the label of centos5-32 and a host matching label of ubuntu-natty-32bit). Matrix builds show a table of lights to indicate their status. Clicking build now on one of these queues up builds for all of the combinations. We have some integration of our regression test suites (currently xtrabackup) with Jenkins ability to parse JUnitXML, presenting a nice user interface to any test failures. Because building some projects is non-trivial, in order to not duplicate the list of compile instructions for each job, we use template builds. Youll see builds such as percona-xtrabackup-template which is a disabled job, but all current xtrabackup jobs point to it for the commands to build and run the test suite. Percona Xtrabackup http://jenkins.percona.com/view/XtraBackup/ We currently build Xtrabackup 1.6, 2.0 and xtrabackup trunk (will become 2.1). There are param-builds for 1.6 and trunk too. These should be run for each merge request (and before any collection of merged branches is pushed to trunk) Percona Server We have separate jobs for Percona Server 5.1 and Percona Server 5.5 due to the different build systems that MySQL 5.1 and 5.5 use. The mysql-test-run.pl test suite is integrated with Jenkins through subunit and subunit2junitxml allowing us to easily see which tests passed/failed on any particular test run.
Percona Server 5.1
http://jenkins.percona.com/view/PS%205.1/ We have trunk and param jobs. We also have a valgrind job that will run after a successful trunk build.
Percona Server 5.5
http://jenkins.percona.com/view/PS%205.5/ Similar to 5.1, but for PS5.5 instead.
142
MySQL Builds http://jenkins.percona.com/view/MySQL/ Ive set up a few jobs in Jenkins that should help us predict the future for Percona Server. Namely, if upstream MySQL may cause us any problems. I wanted to see if some test failures were possibly upstream, so I set up two jobs: http://jenkins.percona.com/view/MySQL/job/mysql-5.1-url-param/ http://jenkins.percona.com/view/MySQL/job/mysql5.5-url-param/ both of which ask for a URL to a MySQL source tarball and then do a full build and test across the platforms we have in jenkins. But my next thought was that we could try and do this before the source tarballs come out - hopefully then being able to have MySQL release source tarballs that do in fact pass build and test everywhere where were wanting to support Percona Server. http://jenkins.percona.com/view/MySQL/job/mysql-5.1-trunk/ http://jenkins.percona.com/view/MySQL/job/mysql5.5-trunk/ are scheduled to just try once per week (we can change the frequency if we want to) to build and test from the MySQL bzr trees. I also have a valgrind build (same conguration as for Percona Server) to help us see if theres any new valgrind warnings (or missed suppressions). Im hoping that these jobs will help us catch any future problems before they become our problem. (e.g. we can easily see that the sporadic test failures we see in Percona Server are actually in upstream MySQL).
10.2 Trademark Policy

This Trademark Policy is to ensure that users of Percona-branded products or services know that what they receive has really been developed, approved, tested and maintained by Percona. Trademarks help to prevent confusion in the marketplace, by distinguishing one companys or persons products and services from anothers. Percona owns a number of marks, including but not limited to Percona, XtraDB, Percona XtraDB, XtraBackup, Percona XtraBackup, Percona Server, and Percona Live, plus the distinctive visual icons and logos associated with these marks. Both the unregistered and registered marks of Percona are protected. Use of any Percona trademark in the name, URL, or other identifying characteristic of any product, service, website, or other use is not permitted without Perconas written permission with the following three limited exceptions. First, you may use the appropriate Percona mark when making a nominative fair use reference to a bona de Percona product. Second, when Percona has released a product under a version of the GNU General Public License (GPL), you may use the appropriate Percona mark when distributing a verbatim copy of that product in accordance with the terms and conditions of the GPL. Third, you may use the appropriate Percona mark to refer to a distribution of GPL-released Percona software that has been modied with minor changes for the sole purpose of allowing the software to operate on an operating system or hardware platform for which Percona has not yet released the software, provided that those third party changes do not affect the behavior, functionality, features, design or performance of the software. Users who acquire this Percona-branded software receive substantially exact implementations of the Percona software. Percona reserves the right to revoke this authorization at any time in its sole discretion. For example, if Percona believes that your modication is beyond the scope of the limited license granted in this Policy or that your use of the Percona mark is detrimental to Percona, Percona will revoke this authorization. Upon revocation, you must 10.2. Trademark Policy 143
immediately cease using the applicable Percona mark. If you do not immediately cease using the Percona mark upon revocation, Percona may take action to protect its rights and interests in the Percona mark. Percona does not grant any license to use any Percona mark for any other modied versions of Percona software; such use will require our prior written permission. Neither trademark law nor any of the exceptions set forth in this Trademark Policy permit you to truncate, modify or otherwise use any Percona mark as part of your own brand. For example, if XYZ creates a modied version of the Percona Server, XYZ may not brand that modication as XYZ Percona Server or Percona XYZ Server, even if that modication otherwise complies with the third exception noted above. In all cases, you must comply with applicable law, the underlying license, and this Trademark Policy, as amended from time to time. For instance, any mention of Percona trademarks should include the full trademarked name, with proper spelling and capitalization, along with attribution of ownership to Percona Inc. For example, the full proper name for XtraBackup is Percona XtraBackup. However, it is acceptable to omit the word Percona for brevity on the second and subsequent uses, where such omission does not cause confusion. In the event of doubt as to any of the conditions or exceptions outlined in this Trademark Policy, please contact trademarks@percona.com for assistance and we will do our very best to be helpful.
10.3 List of upstream MySQL bugs xed in Percona Server 5.5
Upstream bug #69639 - mysql failed to build with dtrace Sun D 1.11 Launchpad bug #1196460 Upstream state Open (checked on 2013-08-26) Fix Released 5.5.33-31.1 Upstream x N/A
Upstream bug #68354 - Server crashes on update/join FEDERATED + local table when only 1 local... Launchpad bug #1182572 Upstream state N/A Fix Released 5.5.32-31.0 Upstream x N/A
Upstream bug #42415 - UPDATE/DELETE with LIMIT clause unsafe for SBL even with ORDER BY PK ... Launchpad bug #1132194 Upstream state Veried (checked on 2013-08-26) Fix Released 5.5.32-31.0 Upstream x N/A
Upstream bug #69179 - accessing information_schema.partitions causes plans to change Launchpad bug #1192354 Upstream state Veried (checked on 2013-08-26) Fix Released 5.5.32-31.0 Upstream x N/A Continued on next page
144
Table 10.1 continued from previous page Upstream bug #68970 - fsp_reserve_free_extents switches from small to big tblspace handling ... Launchpad bug #1169494 Upstream state Veried (checked on 2013-08-26) Fix Released 5.5.32-31.0 Upstream x N/A
Upstream bug #65077 - internal temporary tables are contended on THR_LOCK_myisam Launchpad bug #1179978 Upstream state Closed Fix Released 5.5.31-30.3 Upstream x N/A
Upstream bug #68999 - SSL_OP_NO_COMPRESSION not dened Launchpad bug #1183610 Upstream state Open (checked on 2013-08-26) Fix Released 5.5.31-30.3 Upstream x N/A
Upstream bug #68197 - InnoDB reports that its going to wait for I/O but the I/O is async Launchpad bug #1107539 Upstream state Closed Fix Released 5.5.30-30.2 Upstream x 5.5.31
Upstream bug #68845 Unnecessary mtr_log_reserve_and_write() Launchpad bug #1163439 Upstream state Veried (checked on 2013-08-26) Fix Released 5.5.30-30.2 Upstream x N/A
log_sys->mutex
reacquisition
in
Upstream bug #62578 - mysql client aborts connection on terminal resize Launchpad bug #925343 Upstream state Wont Fix Fix Released 5.5.30-30.2 Upstream x N/A
Upstream bug #49169 - read_view_open_now is inefcient with many concurrent sessions Launchpad bug #1131187 and #1131189 Upstream state Closed Fix Released 5.5.30-30.2 Upstream x N/A Continued on next page
10.3. List of upstream MySQL bugs xed in Percona Server 5.5
145
Table 10.1 continued from previous page Upstream bug #63144 - CREATE TABLE IF NOT EXISTS metadata lock is too restrictive Launchpad bug #1127008 Upstream state Closed Fix Released 5.5.30-30.2 Upstream x N/A
Upstream bug #68477 - Suboptimal code in skip_trailing_space() Launchpad bug #1132351 Upstream state Closed Fix Released 5.5.30-30.1 Upstream x N/A
Upstream bug #68476 - Suboptimal code in my_strnxfrm_simple() Launchpad bug #1132350 Upstream state Veried (checked on 2013-08-26) Fix Released 5.5.30-30.1 Upstream x N/A
Upstream bug #68116 - InnoDB monitor may hit an assertion error in buf_page_get_gen in debug ... Launchpad bug #1100178 Upstream state Analyzing (checked on 2013-08-26) Fix Released 5.5.29-30.0 Upstream x N/A
Upstream bug #67504 - Duplicate error in replication with slave triggers and auto increment Launchpad bug #1068210 Upstream state Closed Fix Released 5.5.29-30.0 Upstream x N/A
Upstream bug #67983 - Memory leak on ltered slave Launchpad bug #1042946 Upstream state Closed Fix Released 5.5.29-30.0 Upstream x 5.5.31
Upstream bug #67974 - Server crashes in add_identier on concurrent ALTER TABLE and SHOW ENGINE Launchpad bug #1017192 Upstream state N/A Fix Released 5.5.29-30.0 Upstream x N/A Continued on next page
146
Table 10.1 continued from previous page Upstream bug #68045 - security vulnerability CVE-2012-4414 Launchpad bug #1049871 Upstream state N/A Fix Released 5.5.29-29.4 Upstream x N/A
Upstream bug #70277 - last argument of LOAD DATA ... SET ... statement repeated twice in binlog Launchpad bug #1223196 Upstream state Veried (checked on 2013-09-30) Fix Released 5.5.28-29.3 Upstream x N/A
Upstream bug #69380 - Incomplete x for security vulnerability CVE-2012-5611 Launchpad bug #1186748 Upstream state N/A Fix Released 5.5.28-29.3 Upstream x N/A
Upstream bug #66550 - security vulnerability CVE-2012-4414 Launchpad bug #1049871 Upstream state N/A Fix Released 5.5.28-29.3 Upstream x N/A
Upstream bug #67685 - security vulnerability CVE-2012-5611 Launchpad bug #1083377 Upstream state N/A Fix Released 5.5.28-29.3 Upstream x N/A
Upstream bug #66237 - Temporary les created by binary log cache are not purged after transa... Launchpad bug #1070856 Upstream state Veried (checked on 2013-08-26) Fix Released 5.5.28-29.3 Upstream x N/A
Upstream bug #69124 - Incorrect truncation of long SET expression in LOAD DATA can cause SQL ... Launchpad bug #1175519 Upstream state N/A Fix Released 5.5.28-29.3 Upstream x N/A Continued on next page
147
Table 10.1 continued from previous page Upstream bug #67606 - MySQL crashes with segmentation fault when disk quota is reached Launchpad bug #1079596 Upstream state Duplicate Fix Released 5.5.28-29.3 Upstream x N/A
Upstream bug #67737 - mysqldump test sometimes fails due to mixing stdout and stderr Launchpad bug #959198 Upstream state Closed Fix Released 5.5.28-29.2 Upstream x 5.5.29
Upstream bug #66890 - Slave server crash after a START SLAVE Launchpad bug #1053342 Upstream state Duplicate Fix Released 5.5.28-29.1 Upstream x 5.5.29
Upstream bug #62856 - Check for stack overrun doesnt work with gcc-4.6, server crashes Launchpad bug #1042517 Upstream state Closed Fix Released 5.5.28-29.1 Upstream x N/A
Upstream bug #61180 - korr/store macros in my_global.h assume the argument to be a char pointer Launchpad bug #1042517 Upstream state Veried (checked on 2013-08-26) Fix Released 5.5.27-29.0 Upstream x N/A
Upstream bug #61178 - Incorrect implementation of intersect(ulonglong) in non-optimized Bitmap.. Launchpad bug #1042517 Upstream state Veried (checked on 2013-08-26) Fix Released 5.5.27-29.0 Upstream x N/A
Upstream bug #54127 - mysqld segfaults when built using with-max-indexes=128 Launchpad bug #1042517 Upstream state Closed Fix Released 5.5.27-29.0 Upstream x N/A Continued on next page
148
Table 10.1 continued from previous page Upstream bug #64800 - mysqldump with include-master-host-port putting quotes around port no. Launchpad bug #1013432 Upstream state Veried (checked on 2013-08-26) Fix Released 5.5.27-28.0 Upstream x N/A
Upstream bug #66301 - INSERT ... odb_autoinc_lock_mode=1 is broken Launchpad bug #1035225 Upstream state Closed Fix Released 5.5.27-28.0 Upstream x N/A
ON
DUPLICATE
KEY
UPDATE
inn-
Upstream bug #60743 - typo in cmake/dtrace.cmake Launchpad bug #1013455 Upstream state Closed Fix Released 5.5.25a-27.1 Upstream x 5.5.33
Upstream bug #64663 - Segfault when adding indexes to InnoDB temporary tables Launchpad bug #999147 Upstream state Veried (checked on 2013-08-26) Fix Released 5.5.24-26.0 Upstream x N/A
Upstream bug #64624 - Mysql is crashing during replication Launchpad bug #915814 Upstream state Closed Fix Released 5.5.24-26.0 Upstream x 5.5.26
Upstream bug #64160 - page size 1024 but the only supported page size in this release is=16384 Launchpad bug #966844 Upstream state Closed Fix Released 5.5.21-25.1 Upstream x 5.5.22
Upstream bug #64432 - Bug #54330 (Broken fast index creation) was never xed in 5.5 Launchpad bug #939485 Upstream state Closed Fix Released 5.5.21-25.0 Upstream x 5.5.30 Continued on next page
149
Table 10.1 continued from previous page Upstream bug #49336 - mysqlbinlog does not accept input from stdin when stdin is a pipe Launchpad bug #933969 Upstream state Closed Fix Released 5.5.21-25.0 Upstream x 5.5.28
Upstream bug #62557 - SHOW SLAVE STATUS gives wrong output with master-master and using SET... Launchpad bug #860910 Upstream state Closed Fix Released 5.5.17-22.1 Upstream x 5.5.28
Upstream bug #45702 - Impossible to specify myisam_sort_buffer > 4GB on 64 bit machines Launchpad bug #878404 Upstream state Closed Fix Released 5.5.17-22.1 Upstream x 5.5.22
Upstream bug #62516 - Fast index creation does not update index statistics Launchpad bug #857590 Upstream state Veried (checked on 2013-08-26) Fix Released 5.5.16-22.0 Upstream x N/A
Upstream bug #25007 - memory tables with dynamic rows format Launchpad bug N/A Upstream state Veried (checked on 2013-08-26) Fix Released 5.5.15-21.0 Upstream x N/A
Upstream bug #51196 - Slave SQL: Got an error writing communication packets, Error_code: 1160 Launchpad bug #813587 Upstream state Closed Fix Released 5.5.14-20.5 Upstream x 5.5.21
Upstream bug #43593 - dump/backup/restore/upgrade tools fails because of utf8_general_ci Launchpad bug N/A Upstream state Closed Fix Released 5.5.14-20.5 Upstream x 5.5.21 Continued on next page
150
Table 10.1 continued from previous page Upstream bug #61595 - mysql-test/include/wait_for_slave_param.inc timeout logic is incorrect Launchpad bug #800035 Upstream state Veried (checked on 2013-08-26) Fix Released 5.5.13-20.4 Upstream x N/A
Upstream bug #54160 - InnoDB should retry on failed read or write, not immediately panic Launchpad bug #764395 Upstream state Closed Fix Released 5.5.11-20.2 Upstream x N/A
Upstream bug #51325 - Dropping an empty innodb table takes a long time with large buffer pool Launchpad bug none Upstream state Closed Fix Released 5.5.10-20.1 Upstream x 5.5.20
Upstream bug #56433 - Auto-extension of InnoDB les Launchpad bug none Upstream state Closed Fix Released 5.5.10-20.1 Upstream x N/A
Upstream bug #20001 - Support for temp-tables in INFORMATION_SCHEMA Launchpad bug none Upstream state Closed Fix Released 5.5.8-20.0 Upstream x N/A
Upstream bug #69146 Optimization srv_buf_pool_instances Launchpad bug #1176496 Upstream state Open (checked on 2013-08-26) Fix Released 5.5.8-20.0 Upstream x N/A
in
buf_pool_get_oldest_modication
if
Upstream bug #54790 - Use of non-blocking mode for sockets limits performance Launchpad bug #606810 Upstream state Closed Fix Released 5.5.8-20.0 Upstream x N/A
151
10.4 List of variables introduced in Percona Server 5.5

enforce_storage_engine expand_fast_index_creation extra_max_connections extra_port fast_index_creation have_flashcache have_response_time_distribution innodb_adaptive_flushing_method innodb_adaptive_hash_index_partitions innodb_blocking_buffer_pool_restore innodb_buffer_pool_populate innodb_buffer_pool_restore_at_startup innodb_buffer_pool_shm_checksum innodb_buffer_pool_shm_key innodb_checkpoint_age_target innodb_corrupt_table_action innodb_dict_size_limit innodb_doublewrite_file innodb_fake_changes innodb_fast_checksum innodb_flush_neighbor_pages innodb_ibuf_accel_rate innodb_ibuf_active_contract innodb_ibuf_max_size innodb_import_table_from_xtrabackup innodb_kill_idle_transaction innodb_lazy_drop_table innodb_locking_fake_changes innodb_log_block_size innodb_max_bitmap_file_size innodb_max_changed_pages innodb_merge_sort_block_size innodb_page_size
152
innodb_read_ahead innodb_recovery_stats innodb_recovery_update_relay_log innodb_show_locks_held innodb_show_verbose_locks innodb_stats_auto_update innodb_stats_update_need_lock innodb_thread_concurrency_timer_based innodb_track_changed_pages innodb_use_atomic_writes innodb_use_global_flush_log_at_trx_commit innodb_use_sys_stats_table log_slow_admin_statements log_slow_filter log_slow_rate_limit log_slow_rate_type log_slow_slave_statements log_slow_sp_statements log_slow_verbosity log_warnings_suppress max_binlog_files optimizer_fix query_cache_strip_comments query_response_time_range_base query_response_time_stats slow_query_log_timestamp_always slow_query_log_timestamp_precision slow_query_log_use_global_control thread_pool_high_prio_tickets thread_pool_idle_timeout thread_pool_max_threads thread_pool_oversubscribe thread_pool_size thread_pool_stall_limit thread_statistics userstat
10.4. List of variables introduced in Percona Server 5.5
153

Com_show_client_statistics Com_show_index_statistics Com_show_slave_status_nolock Com_show_table_statistics Com_show_temporary_tables Com_show_thread_statistics Com_show_user_statistics Flashcache_enabled Innodb_adaptive_hash_cells Innodb_adaptive_hash_heap_buffers Innodb_adaptive_hash_hash_searches Innodb_adaptive_hash_non_hash_searches Innodb_background_log_sync Innodb_buffer_pool_pages_LRU_flushed Innodb_buffer_pool_pages_made_not_young Innodb_buffer_pool_pages_made_young Innodb_buffer_pool_pages_old Innodb_checkpoint_age Innodb_checkpoint_max_age Innodb_checkpoint_target_age Innodb_deadlocks Innodb_dict_tables Innodb_history_list_length Innodb_ibuf_discarded_delete_marks Innodb_ibuf_discarded_deletes Innodb_ibuf_discarded_inserts Innodb_ibuf_free_list Innodb_ibuf_merged_delete_marks Innodb_ibuf_merged_deletes Innodb_ibuf_merged_inserts Innodb_ibuf_merges Innodb_ibuf_segment_size Innodb_ibuf_size Innodb_lsn_current Innodb_lsn_flushed 154 Chapter 10. Reference
Innodb_lsn_last_checkpoint Innodb_master_thread_1_second_loops Innodb_master_thread_10_second_loops Innodb_master_thread_background_loops Innodb_master_thread_main_flush_loops Innodb_master_thread_sleeps Innodb_max_trx_id Innodb_mem_adaptive_hash Innodb_mem_dictionary Innodb_mem_total Innodb_mutex_os_waits Innodb_mutex_spin_rounds Innodb_mutex_spin_waits Innodb_oldest_view_low_limit_trx_id Innodb_purge_trx_id Innodb_purge_undo_no Innodb_current_row_locks Innodb_read_views_memory Innodb_descriptors_memory Innodb_s_lock_os_waits Innodb_s_lock_spin_rounds Innodb_s_lock_spin_waits Innodb_x_lock_os_waits Innodb_x_lock_spin_rounds Innodb_x_lock_spin_waits Threadpool_idle_threads Threadpool_threads binlog_commits binlog_group_commits
10.5 Index of INFORMATION_SCHEMA Tables

This is a list of the INFORMATION_SCHEMA TABLES that exist in Percona Server with XtraDB. The entry for each table points to the page in the documentation where its described. CLIENT_STATISTICS INDEX_STATISTICS GLOBAL_TEMPORARY_TABLES 10.5. Index of INFORMATION_SCHEMA Tables 155
QUERY_RESPONSE_TIME TABLE_STATISTICS TEMPORARY_TABLES THREAD_STATISTICS USER_STATISTICS INNODB_RSEG INNODB_UNDO_LOGS INNODB_SYS_TABLESTATS INNODB_INDEX_STATS INNODB_CHANGED_PAGES INNODB_BUFFER_POOL_PAGES INNODB_BUFFER_POOL_PAGES_BLOB INNODB_BUFFER_POOL_PAGES_INDEX INNODB_SYS_TABLES INNODB_SYS_FIELDS INNODB_SYS_COLUMNS INNODB_SYS_STATS INNODB_SYS_FOREIGN INNODB_SYS_INDEXES XTRADB_ADMIN_COMMAND INNODB_TABLE_STATS INNODB_SYS_FOREIGN_COLS
10.6 Frequently Asked Questions

10.6.1 Q: Will Percona Server with XtraDB invalidate our MySQL support?
A: We dont know the details of your support contract. You should check with your Oracle representative. We have heard anecdotal stories from MySQL Support team members that they have customers who use Percona Server with XtraDB, but you should not base your decision on that.
10.6.2 Q: Will we have to GPL our whole application if we use Percona Server with XtraDB ?
A: This is a common misconception about the GPL. We suggest reading the Free Software Foundation s excellent reference material on the GPL Version 2, which is the license that applies to MySQL and therefore to Percona Server with XtraDB. That document contains links to many other documents which should answer your questions. Percona is unable to give legal advice about the GPL.
156
10.6.3 Q: Do I need to install Percona client libraries?

A: No, you dont need to change anything on the clients. Percona Server is 100% compatible with all existing client libraries and connectors.
10.6.4 Q: When using the Percona XtraBackup to setup a replication slave on Debian based systems Im getting: ERROR 1045 (28000): Access denied for user debian-sys-maint@localhost (using password: YES)
A: In case youre using init script on Debian based system to start mysqld, be sure that the password for debian-sys-maint user has been updated and its the same as that users password from the server that the backup has been taken from. Password can be seen and updated in /etc/mysql/debian.cnf. For more information on how to set up a replication slave using Percona XtraBackup see this how-to.
10.7 Copyright and Licensing Information

10.7.1 Documentation Licensing
This software documentation is (C)2009-2013 Percona LLC and/or its afliates and is distributed under the Creative Commons Attribution-ShareAlike 2.0 Generic license.
10.7.2 Software License

Percona Server is built upon MySQL from Oracle. Along with making our own modications, we merge in changes from other sources such as community contributions and changes from MariaDB. The original SHOW USER/TABLE/INDEX statistics code came from Google. Percona does not require copyright assignment. See the COPYING les accompanying the software distribution.
10.8 Options that make XtraDB tablespaces not compatible with MySQL
10.8.1 Fast checksums
Enabling innodb_fast_checksum will use more CPU-efcient algorithm, based on 4-byte words which can be benecial for some workloads. Once enabled, turning it off will require table to be dump/imported again, since Percona Server will fail to start on data les created when innodb_fast_checksums was enabled. In case youve migrated from Percona Server to MySQL you could get the corrupted checksum error message. In order to recover that table youll need to: 1. Reinstall Percona Server to read your tables that were created with fast checksums. 2. Dump the tables (or temporarily convert them to MyISAM). 3. Install stock MySQL (or at least disable fast checksums). 4. Restore the InnoDB tables (or convert back from MyISAM).
10.7. Copyright and Licensing Information
157
10.8.2 Page sizes other than 16KiB

This is controlled by variable innodb_page_size. Changing the page size for an existing database is not supported. Table will need to be dumped/imported again if compatibility with MySQL is required.
10.8.3 Relocation of the doublewrite buffer

Variable innodb_doublewrite_file provides an option to put the buffer on a dedicated disk in order to parallelize I/O activity on the buffer and on the tablespace. Only in case of crash recovery this variable cannot be changed, in all other cases it can be turned on/off without breaking the compatibility.
10.9 Percona Server 5.5 Release notes

10.9.1 Percona Server 5.5.34-32.0
Percona is glad to announce the release of Percona Server 5.5.34-32.0 on October 28th, 2013. Downloads are available here and from the Percona Software Repositories. Based on MySQL 5.5.34, including all the bug xes in it, Percona Server 5.5.34-32.0 is now the current stable release in the 5.5 series. All of Perconas software is open-source and free, all the details of the release can be found in the 5.5.34-32.0 milestone at Launchpad. New Features Percona Server has extended the SELECT INTO ... to add the support for UNIX sockets and named pipes. Percona Server now provides additional log_slow_rate_limit variable is enabled. OUTFILE and SELECT INTO DUMPFILE in the slow query log when
information
A new variable slow_query_log_always_write_time has been introduced. It can be used to specify an additional execution time threshold for the slow query log, that, when exceeded, will cause a query to be logged unconditionally, that is, log_slow_rate_limit will not apply to it. Utility user feature has been extended by adding a new utility_user_privileges that allows a comma separated value list of extra access privileges that can be granted to the utility user. Bugs Fixed Due to an incompatible upstream change that went in unnoticed, the log tracker thread would attempt to replay any le operations it encountered. In most cases this were a no-op, but there were race conditions for certain DDL operations that would have resulted in server crash. Bug xed #1217002. apt-get upgrade of Percona Server would fail in post-installation step if server failed to start. Bug xed #1002500. Fixed the libssl.so.6 dependency issues in binary tarballs releases. Bug xed #1172916. Error in install_layout.cmake could cause that some library les, during the build, end up in different directories on x86_64 environment. Bug xed #1174300. Percona Server could crash while accessing BLOB or TEXT columns in InnoDB tables if Support for Fake Changes was enabled. Bug xed #1188168.
158
Memory leak was introduced by the x for bug #1132194. Bug xed #1204873. The unnecessary overhead from persistent InnoDB adaptive hash index latching has been removed, potentially improving stability of the Multiple Adaptive Hash Search Partitions feature as well. Upstream bug xed #70216, bug xed #1218347. Fixed the incorrect dependency with 5.5.33-31.1. Bug xed #1237097. libmysqlclient18-dev from Percona Server
A memory leak in Utility user feature has been xed. Bug xed #1166638. Expanded Program Option Modiers did not deallocate memory correctly. Bug xed #1167487. A server could crash due to a race condition between a INNODB_CHANGED_PAGES query and a bitmap le delete by PURGE CHANGED_PAGE_BITMAP or directly on the le system. Bug xed #1191580. Percona Server could not be built with Thread Pool feature and -DWITH_PERFSCHEMA_ENGINE=OFF option. Bug xed #1196383. Building Percona Server with -DHAVE_PURIFY option would result in an error. Fixed by porting the close_socket function from MariaDB. Bug xed #1203567. Adaptive hash index memory size was incorrectly calculated in SHOW ENGINE INNODB STATUS and Innodb_mem_adaptive_hash status variable. Bug xed #1218330. Some Expanded Program Option Modiers didnt have an effect if they were specied in non-normalized way (innodb_io_capacity vs innodb-io-capacity). Bug xed #1233294. Enabling Enforcing Storage Engine feature could lead to error on Percona Server shutdown. Bug xed #1233354. Storage engine enforcement (enforce_storage_engine) is now ignored when the server is started in either bootstrap or skip-grant-tables mode. Bug xed #1236938. Fixed the build warnings caused by User Statistics code on non-Linux platforms. Bug xed #711817. Adaptive hash indexing partitioning code has been simplied, potentially improving performance. Bug xed #1218321. Other bugs xed: bug xed #1239630, bug xed #1191589, bug xed #1200162, bug xed #1214449, and bug xed #1190604.
10.9.2 Percona Server 5.5.33-31.1

Percona is glad to announce the release of Percona Server 5.5.33-31.1 on August 27th, 2013. Downloads are available here and from the Percona Software Repositories. Based on MySQL 5.5.33, including all the bug xes in it, Percona Server 5.5.33-31.1 is now the current stable release in the 5.5 series. All of Perconas software is open-source and free, all the details of the release can be found in the 5.5.33-31.1 milestone at Launchpad. Bugs Fixed The buffer pool mutex split patch implemented in Percona Server could cause a race condition, involving a dirty compressed page block for which there is an uncompressed page image in the buffer pool, that could lead to a server crash. Bug xed #1086680. If binary log was enabled, Fake Changes transactions were binlogged. This could lead to data corruption issues with deeper replication topologies. Bug xed #1190580.
10.9. Percona Server 5.5 Release notes
159
Changes made to the RPM scripts for previous Percona Server version caused installer to fail if there were different datadir options in multiple conguration les. Bug xed #1201036. Percona Server shared-compat package was being built with the 5.1.66 version of the client, which didnt work with OpenSSL. Fixed by building the shared-compat package with a more recent version. Bug xed #1201393. Fixed the upstream bug #69639 which caused compile errors for Percona Server with DTrace version Sun D 1.11 provided by recent SmartOS versions. Bug xed #1196460. Fixed a regression introduced in Percona Server 5.5.32-31.0, where server wouldnt be able to start if Atomic write support for Fusion-io devices was enabled. Bug xed #1214735. Percona Server used to acquire the buffer pool LRU list mutex in the I/O completion routine for the compressed page ush list ushes where it was not necessary. Bug xed #1181269. Other bugs xed: bug xed #1189743, bug xed #1188162 and bug xed #1203308.
10.9.3 Percona Server 5.5.32-31.0

Percona is glad to announce the release of Percona Server 5.5.32-31.0 on July 2nd, 2013. Downloads are available here and from the Percona Software Repositories. Based on MySQL 5.5.32, including all the bug xes in it, Percona Server 5.5.32-31.0 is now the current stable release in the 5.5 series. All of Perconas software is open-source and free, all the details of the release can be found in the 5.5.32-31.0 milestone at Launchpad. New Features Percona Server has implemented support for supplementary groups for PAM Authentication Plugin. Bugs Fixed Prevented a race condition that could lead to a server crash when INFORMATION_SCHEMA.INNODB_BUFFER_PAGE table. Bug xed #1072573. querying the
Percona Server wouldnt start if the XtraDB changed page tracking was enabled and variable innodb_flush_method was set to ALL_O_DIRECT. Bug xed #1131949. Fixed the upstream bug #68970 that, in Percona Server, would cause small tablespaces to expand too fast around 500KB tablespace size. Bug xed #1169494. Query to the INNODB_CHANGED_PAGES table would cause server to stop with an I/O error if a bitmap le in the middle of requested LSN range was missing. Bug xed #1179974. Server would crash if an INNODB_CHANGED_PAGES query is issued that has an empty LSN range and thus does not need to read any bitmap les. Bug xed #1184427. Querying INFORMATION_SCHEMA.PARTITIONS could cause key distribution statistics for partitioned tables to be reset to those corresponding to the last partition. Fixed the upstream bug #69179. Bug xed #1192354. Incorrect schema denition for the User Statistics tables in INFORMATION_SCHEMA (CLIENT_STATISTICS, INDEX_STATISTICS, TABLE_STATISTICS, THREAD_STATISTICS, and USER_STATISTICS) led to the maximum counter values being limited to 32-bit signed integers. Fixed so that these values can be 64-bit unsigned integers now. Bug xed #714925.
160
Fixed the upstream bug #42415 that would cause UPDATE/DELETE statements with the LIMIT clause to be unsafe for Statement Based Replication even when ORDER BY primary key was present. Fixed by implementing an algorithm to do more elaborate analysis on the nature of the query to determine whether the query will cause uncertainty for replication or not. Bug xed #1132194. When an upgrade was performed between major versions (e.g. by uninstalling a 5.1 RPM and then installing a 5.5 one), mysql_install_db was still called on the existing data directory which lead to re-creation of the test database. Bug xed #1169522. XtraDB changed page tracking used to hold the log system mutex for the log reads needlessly, potentially limiting performance on write-intensive workloads. Bug xed #1171699. The RPM installer script had the datadir hardcoded to /var/lib/mysql instead of using my_print_defaults function to get the correct datadir info. Bug xed #1181753. Missing path separator between the directory and le name components in a bitmap le name could stop the server starting if the innodb_data_home_dir variable didnt have the path separator at the end. Bug xed #1181887. Fixed the upstream bug #68354 that could cause server to crash when performing update or join on Federated and MyISAM tables with one row, due to a bug in the Federated storage engine. Bug xed #1182572. A warning is now returned if a bitmap le I/O error occurs after an INNODB_CHANGED_PAGES query started returning data to indicate an incomplete result set. Bug xed #1185040. Under very rare circumstances, deleting a zero-size bitmap le at the right moment would make server stop with an I/O error if changed page tracking is enabled. Bug xed #1184517. Fixed the compiler warnings caused by Atomic write support for Fusion-io devices when building Percona Server on non-Linux platforms. Bug xed #1189429. The INNODB_CHANGED_PAGES table couldnt be queried if the log tracker wasnt running. Bug xed #1185304. Transaction objects are now allocated calling calloc() directly instead of using InnoDB heap allocation. This may improve write performance for high levels of concurrency. Bug xed #1185686. Other bugs xed: bug xed #1099764, bug xed #1132412, bug xed #1191395, bug xed #1079688, bug xed #1132422, bug xed #1153651, bug xed #1160951, bug xed #1183583, bug xed #1133266.
10.9.4 Percona Server 5.5.31-30.3

Percona is glad to announce the release of Percona Server 5.5.31-30.3 on May 24th, 2013. Downloads are available here and from the Percona Software Repositories. Based on MySQL 5.5.31, including all the bug xes in it, Percona Server 5.5.31-30.3 is now the current stable release in the 5.5 series. All of Perconas software is open-source and free, all the details of the release can be found in the 5.5.31-30.3 milestone at Launchpad. New Features Percona Server has ported the Atomic write support for Fusion-io devices patch from MariaDB. This feature adds atomic write support for directFS lesystem on Fusion-io devices. This feature implementation is considered BETA quality. Percona Server has introduced innodb_read_views_memory and innodb_descriptors_memory status variables in the Extended Show Engine InnoDB Status to improve InnoDB memory usage diagnostics. 10.9. Percona Server 5.5 Release notes 161
Bug Fixes Fix for bug #1131187 introduced a regression that could cause a memory leak if query cache was used together with InnoDB. Bug xed #1170103. Fixed RPM packaging regression that was introduced with the x for bug #710799. This regression caused mysql schema to be missing after the clean RPM installation. Bug xed #1174426. Fixed the Percona-Server-shared-55 and Percona-XtraDB-Cluster-shared RPM package dependences. Bug xed #1050654. Fixed the upstream bug #68999 which caused compiling Percona Server to fail on CentOS 5 and Debian squeeze due to older OpenSSL version. Bug xed #1183610. If a slave was running with its binary log enabled and then restarted with the binary log disabled, Crash-Resistant Replication could overwrite the relay log info log with an incorrect position. Bug xed #1092593. Fixed the CVE-2012-5615 vulnerability. This vulnerability would allow remote attacker to detect what user accounts exist on the server. This bug x comes originally from MariaDB (see MDEV-3909). Bug xed #1171941. Fixed the CVE-2012-5627 vulnerability, where an unprivileged MySQL account owner could perform brute-force password guessing attack on other accounts efciently. This bug x comes originally from MariaDB (see MDEV-3915). Bug xed #1172090. mysql_set_permission was failing on Debian due to missing libdbd-mysql-perl package. Fixed by adding the package dependency. Bug xed #1003776. Rebuilding Debian source package would fail because dpatch and automake were missing from builddep. Bug xed #1023575 (Stephan Adig). Backported the x for the upstream bug #65077 from the MySQL 5.6 version, which removed MyISAM internal temporary table mutex contention. Bug xed #1179978.
10.9.5 Percona Server 5.5.30-30.2

Percona is glad to announce the release of Percona Server 5.5.30-30.2 on April 10th, 2013 (Downloads are available here and from the Percona Software Repositories). Based on MySQL 5.5.30, including all the bug xes in it, Percona Server 5.5.30-30.2 is now the current stable release in the 5.5 series. All of Perconas software is open-source and free, all the details of the release can be found in the 5.5.30-30.2 milestone at Launchpad. New Features Percona Server has implemented priority connection scheduling for the Thread Pool. (Alexey Kopytov) Percona Server will now be shipped with the libjemalloc library. Benchmark showing the impact of memory allocators on MySQL performance can be found in this blogpost. (Ignacio Nin) This release of Percona Server has xed a number of performance bugs. (Alexey Kopytov) Drop table performance has been removed and its controlling variable innodb_lazy_drop_table has been deprecated. Feature has been removed because the upstream DROP TABLE implementation has been improved. (Laurynas Biveinis)
162
Known Issues This release contains a regression introduced by the x for bug #1131187. The workaround is to disable the query cache. Regression is reported as bug #1170103. Bug Fixes Due to parse error in the percona-server.spec Percona Server rpm packages couldnt be built on RHEL 5 and CentOS 5. Bug xed #1144777 (Ignacio Nin). When mysqldump was used with --innodb-optimize-keys option it produced invalid SQL for cases when there was an explicitly named foreign key constraint which implied an implicit secondary index with the same name. Fixed by detecting such cases and omitting the corresponding secondary keys from deferred key creation optimization. Bug xed #1081016 (Alexey Kopytov). Percona Server was built with YaSSL which could cause some of the programs that use it to crash. Fixed by building packages with OpenSSL support rather than the bundled YaSSL library. Bug xed #1104977 (Ignacio Nin). Running a DDL statement while innodb_lazy_drop_table was enabled could cause assertion failure. Bugs xed #1086227 and #1128848 (Laurynas Biveinis). Fixed yum dependencies that were causing conicts in CentOS 6.3 during installation. Bugs xed #1031427 and #1051874 (Ignacio Nin). The log tracker thread was unaware of the situation when the oldest untracked log records are overwritten by the new log data. In some corner cases this could lead to assertion errors in the log parser or bad changed page data. Bug xed #1108613 (Laurynas Biveinis). Ported a x from MariaDB for the upstream bug #63144. CREATE TABLE or CREATE TABLE IF NOT EXISTS statements on an existing table could wait on a metadata lock instead of failing or returning immediately if there is a transaction that executed a query which opened that table. Bug xed #1127008 (Sergei Glushchenko). Fix for bug #1070856 introduced a regression in Percona Server 5.5.28-29.3 which could cause a server to hang when binary log is enabled. Bug xed #1162085 (Alexey Kopytov). Fixed upstream bug #49169 by avoiding the malloc call in the read_view_create_low() in most cases. This signicantly improves InnoDB scalability on read-only workloads, especially when the default glibc memory allocator is used. Bug xed #1131187 (Alexey Kopytov). Removed trx_list scan in read_view_open_now() which is another problem originally reported as upstream bug #49169. This also provides much better scalability in InnoDB high-concurrent workloads. Bugs xed #1131189 (Alexey Kopytov). In the event that a slave was disconnected from the master, under certain conditions, upon reconnect, it would report that it received a packet larger than the slave_max_allowed_packet variable. Bug xed #1135097 (George Ormond Lorch III ). Fixed the upstream bug #62578 which caused MySQL client to abort the connections on terminal resize. Bug xed #925343 (Sergei Glushchenko). Percona Server would re-create the test database when using rpm on server upgrade, even if the database was previously removed. Bug xed #710799 (Alexey Bychko). Debian packages included the old version of innotop. Fixed by removing innotop and its InnoDBParser Perl package from source and Debian installation. Bug xed #1032139 (Alexey Bychko). UDF/congure.ac was incompatible with automake 1.12. Bug xed #1099387 (Alexey Bychko).
163
Reduced the overhead from innodb_pass_corrupt_table value checks by optimizing them for better CPU branch prediction. Bug xed #1125248 (Alexey Kopytov). dialog.so used by the PAM Authentication Plugin couldnt be loaded with Perl and Python clients when plugin-dir option was set in the [client] section of the my.cnf. Bug xed #1155859 (Sergei Glushchenko). Fixed the upstream bug #68845 which could unnecessarily increase contention on log_sys->mutex in write-intensive workloads. Bug xed #1163439 (Alexey Kopytov). Ported back from the upstream MySQL 5.6 the x for unnecessary log_flush_order_mutex acquisition. Bug xed #1163262 (Alexey Kopytov). When mysqldump was used with --innodb-optimize-keys and --no-data options, all secondary key denitions would be lost. Bug xed #989253 (Alexey Kopytov). Warning about the Percona Toolkit UDFs was omitted when installing from Perconas Debian repositories. Bug xed #1015506 (Alexey Bychko). Percona Server was missing help texts in the MySQL client because the help tables were missing. Bug xed #1041981 (Alexey Bychko). Fixed the upstream bug #68197 that caused InnoDB to misclassify internal read operations as synchronous when they were actually asynchronous when Thread Pool feature was used. Bug xed #1107539 (Sergei Glushchenko). Suboptimal code for User Statistics feature has been optimized to make sure no additional work is done when userstat is disabled. Bug xed #1128066 (Alexey Kopytov). Other bug xes: bug xed #1103850 (Laurynas Biveinis), bug xed #1146621 (Laurynas Biveinis), bug xed #1050536 (Alexey Bychko), bug xed #1144059 (Roel Van de Paar), bug xed #1154962 (Hrvoje Matijakovic), bug xed #1154959 (Hrvoje Matijakovic), bug xed #1154957 (Hrvoje Matijakovic), bug xed #1154954 (Hrvoje Matijakovic).
10.9.6 Percona Server 5.5.30-30.1

Percona is glad to announce the release of Percona Server 5.5.30-30.1 on March 7th, 2012 (Downloads are available here and from the Percona Software Repositories). Based on MySQL 5.5.30, including all the bug xes in it, Percona Server 5.5.30-30.1 is now the current stable release in the 5.5 series. All of Perconas software is open-source and free, all the details of the release can be found in the 5.5.30-30.1 milestone at Launchpad. Bug Fixes Minor optimization cleanup by removing unnecessary current_thd calls. Bug xed #1121794 (Alexey Kopytov). Fixed the regression introduced with the x for bug #1083058 which caused unnecessary mutex reacquisitions in adaptive ushing. Bug xed #1117067 (Laurynas Biveinis). Percona Server would do unnecessary slow log stats accounting even with the slow log disabled. Bug xed #1123915 (Alexey Kopytov). Optimization cleanup to avoid calls related to extended slow query log stats when this feature is disabled. Bug xed #1123921 (Alexey Kopytov).
164
The static srv_pass_corrupt_table variable could share CPU cache lines with InnoDB row counters, which resulted in high false sharing effect in high-concurrent workloads. Bug xed #1125259 (Alexey Kopytov). Fixed the regression introduced with x for bug #791030 in Percona Server 5.5.13-20.4 by implementing an optimized version of the same function. Bug xed #1130655 (Alexey Kopytov). Potentially improve server performance by implementing an optimized version of the my_strnxfrm_simple function. Bug xed #1132350, upstream bug xed #68476 (Alexey Kopytov). Potentially improve server performance by implementing an optimized version of the skip_trailing_space function. Bug xed #1132351, upstream bug xed #68477 (Alexey Kopytov). Other bug xes: bug xed #1089265 (Laurynas Biveinis).
10.9.7 Percona Server 5.5.29-30.0

Percona is glad to announce the release of Percona Server 5.5.29-30.0 on February 26th, 2012 (Downloads are available here and from the Percona Software Repositories). Based on MySQL 5.5.29, including all the bug xes in it, Percona Server 5.5.29-30.0 is now the current stable release in the 5.5 series. All of Perconas software is open-source and free, all the details of the release can be found in the 5.5.29-30.0 milestone at Launchpad. New Features Ported the Thread Pool patch from MariaDB. This feature enables the server to keep the top performance even with the increased number of client connections. New user statements have been introduced for handling the XtraDB changed page tracking log les. In addition to the --debug build option for build-binary.sh script, new --valgrind option has been introduced, which will build debug builds with the Valgrind instrumentation enabled. Bug Fixes Ported a x from MariaDB for the upstream bug #67974, which caused server crash on concurrent ALTER TABLE and SHOW ENGINE INNODB STATUS. Bug xed #1017192 (Sergei Glushchenko). The server could crash when executing an INSERT or UPDATE statement containing BLOB values for a compressed table. This regression was introduced in Percona Server 5.5.28-29.2. Bug xed #1100159 (Laurynas Biveinis). Upstream bug #67983 was causing a memory leak on a ltered slave. Bug xed #1042946 (Sergei Glushchenko). Percona Server would fail to install on a vanilla Ubuntu 12.04 server. Bug xed #1103655 (Ignacio Nin). The master thread was doing dirty buffer pool ush list reads to make its adaptive ushing decisions. Fixed by acquiring the ush list mutex around the list scans. Bug xed #1083058 (Laurynas Biveinis). Upstream changes made to improve InnoDB DROP TABLE performance were not adjusted for XtraDB. This could cause server assertion errors. Bugs xed #934377, bug #1111211, bug #1116447 and #1110102 (Laurynas Biveinis).
165
The XtraDB used to print the open read view list without taking the kernel mutex. Thus any list element might become invalid during its iteration. Fixed by taking the kernel mutex. Bug xed #1101030 (Laurynas Biveinis). When option innodb_flush_method=O_DIRECT was set up, log bitmap les were created and treated as InnoDB data les for ushing purposes, which wasnt original intention. Bug xed #1105709 (Laurynas Biveinis). INFORMATION_SCHEMA plugin name innodb_changed_pages serves also as a command line option, but it is also a prex of another command line option innodb_changed_pages_limit. MySQL option handling would then shadow the former with the latter, resulting in start up errors. Fixed by renaming the innodb_changed_pages_limit option to innodb_max_changed_pages. Bug xed #1105726 (Laurynas Biveinis). Time in slow query log was displayed incorrectly when slow_query_log_timestamp_precision variable was set to microseconds. Bug xed #887928 (Laurynas Biveinis). Writing bitmap larger than 4GB would cause write to fail. Also a write error for every bitmap page, except the rst one, would result in a heap corruption. Bug xed #1111226 (Laurynas Biveinis). Fixed the upstream bug #67504 that caused spurious duplicate key errors. Errors would happen if a trigger is red while a slave was processing replication events for a table that is present only on slave server while there are updates on the replicated table on the master which is used in that trigger. For this to happen master needs to have more than one auto-increment table and the slave needs to have at least one of those tables specied in the replicate-ignore-table. Bug xed #1068210 (George Ormond Lorch III ). Fixed failing rpm builds, that were caused by missing les. Bug xed #1099809 (Alexey Bychko). Fixed the upstream #68116 that caused the server crash with assertion error when InnoDB monitor with verbose lock info was used under heavy load. This bug is affecting only -debug builds. Bug xed #1100178 (Laurynas Biveinis). XtraDB changed page tracking wasnt compatible with innodb_force_recovery=6. When starting the server log tracking initialization would fail. The server would abort on startup. Bug xed #1083596 (Laurynas Biveinis). Newly created bitmap le would silently overwrite the old one if they had the same le name. Bug xed #1111144 (Laurynas Biveinis). A server would stop with an assertion error in I/O and AIO routines if large innodb_log_block_size value is used in the combination with changed page tracking. Bug xed #1114612 (Laurynas Biveinis). Optimizer_fix patch has been removed from Percona Server. Bug xed #986247 (Stewart Smith). InnoDB monitor was prefetching the data pages for printing lock information even if no lock information was going to be printed. Bug xed #1100643 (Laurynas Biveinis). InnoDB and the query plan information were being logged even if they werent enabled for the slow query log. Bug xed #730173 (Laurynas Biveinis). Fixed the incorrect help text for slow_query_log_timestamp_precision. Bug xed #1090965 (Laurynas Biveinis). Other bug xes: bug xed #909376 (Laurynas Biveinis), bug xed #1082437 (Laurynas Biveinis), bug xed #1083669 (Laurynas Biveinis), bug xed #1096904 (Laurynas Biveinis), bug xed #1091712 (Laurynas Biveinis), bug xed #1096899 (Laurynas Biveinis), bug xed #1088954 (Laurynas Biveinis), bug xed #1096895 (Laurynas Biveinis), bug xed #1092142 (Laurynas Biveinis), bug xed #1090874 (Laurynas Biveinis), bug xed #1089961 (Laurynas Biveinis), bug xed #1088867 (Laurynas Biveinis), bug xed #1089031 (Laurynas Biveinis), bug xed #1108874 (Laurynas Biveinis).
166
10.9.8 Percona Server 5.5.29-29.4

Percona is glad to announce the release of Percona Server 5.5.29-29.4 on January 23rd, 2013 (Downloads are available here and from the Percona Software Repositories). Based on MySQL 5.5.29, including all the bug xes in it, Percona Server 5.5.29-29.4 is now the current stable release in the 5.5 series. All of Perconas software is open-source and free, all the details of the release can be found in the 5.5.29-29.4 milestone at Launchpad. Bug Fixes Fixed the upstream bug #68045 and ported a x for the security vulnerability CVE-2012-4414 from the Percona Server 5.5.28-29.3. This bug x replaces the upstream x for the MySQL bug #66550. More details about this can be found in Stewarts blogpost. Bug xed #1049871 (Vlad Lesin).
10.9.9 Percona Server 5.5.28-29.3

Percona is glad to announce the release of Percona Server 5.5.28-29.3 on January 8th, 2013 (Downloads are available here and from the Percona Software Repositories). Based on MySQL 5.5.28, including all the bug xes in it, Percona Server 5.5.28-29.3 is now the current stable release in the 5.5 series. All of Perconas software is open-source and free, all the details of the release can be found in the 5.5.28-29.3 milestone at Launchpad. Bug Fixes Fixed the upstream bug #66550 and the security vulnerability CVE-2012-4414. This was caused because user-supplied identiers (table names, eld names, etc.) are not always properly quoted, so authorized users that have privileges to modify a table (any non-temporary table) can inject arbitrary SQL into the binary log and that could cause multiple SQL injection like vulnerabilities. This bug x comes originally from MariaDB (see MDEV-382). Bug xed #1049871 (Vlad Lesin). Fixed the upstream bug #67685 and the security vulnerability CVE-2012-5611. This vulnerability allowed remote authenticated users to execute arbitrary code via a long argument to the GRANT FILE command. This bug x comes originally from MariaDB (see MDEV-3884). Bug xed #1083377 (Vlad Lesin). Rows_read was calculated in a way which lead to a negative value being printed in the slow query log. Fixed by making Rows_read to be a synonym for Rows_examined in the slow query log. Bug xed #830286 (Alexey Kopytov). Fixed the upstream bug #66237. Temporary les created by binary log cache were not purged after transaction commit. Fixed by truncating the temporary le, if used for a binary log transaction cache, when committing or rolling back a statement or a transaction. Bug xed #1070856 (Alexey Kopytov). Values for Rows_sent and Rows_read would be identical in the Slow Query Log. This bug was introduced when slow_extended.patch was ported to Percona Server 5.5. Fixed by making Rows_read identical to Rows_examined instead. Bug xed #721176 (Alexey Kopytov). Fixed unsigned math error in fsp_reserve_free_extents that in some specic cases would cause the function to believe that billions more extents have been reserved than have actually been reserved. Bug xed #1083700 (George Ormond Lorch III ). When mysqldump was used with --innodb-optimize-keys, it did not handle composite indexes correctly when verifying if the optimization is applicable with respect to AUTO_INCREMENT columns. Bug xed #1039536 (Alexey Kopytov).
167
Upstream bug #67606 would cause Percona Server to crash with segmentation fault when disk quota was reached. Bug xed #1079596 (George Ormond Lorch III ). In cases where indexes with AUTO_INCREMENT columns where correctly detected, mysqldump prevented all such keys from optimization, even though it is sufcient to skip just one (e.g. the rst one). Bug xed #1081003 (Alexey Kopytov). Other bug xes: bug xed #1071986 (Alexey Kopytov), bug xed #901060 (Laurynas Biveinis), bug xed #1090596 (Stewart Smith), bug xed #1087202 (Vladislav Vaintroub, Laurynas Biveinis) and bug xed #1087218 (Vladislav Vaintroub, Laurynas Biveinis).
10.9.10 Percona Server 5.5.28-29.2

Percona is glad to announce the release of Percona Server 5.5.28-29.2 on December 7th, 2012 (Downloads are available here and from the Percona Software Repositories). Based on MySQL 5.5.28, including all the bug xes in it, Percona Server 5.5.28-29.2 is now the current stable release in the 5.5 series. All of Perconas software is open-source and free, all the details of the release can be found in the 5.5.28-29.2 milestone at Launchpad. New Features Multiple bitmap le support for XtraDB changed page tracking has been implemented. Percona Server now has an option to build the binary tarball with enabled debugging. New ag --dubug has been added to the build script, that will create a build with the debug-enabled binaries. New binaries will have -debug appended in case it is a debug build, ie. mysqld-debug. HandlerSocket has been updated to version 1.1.0 (rev. 83d8f3af176e1698acd9eb3ac5174700ace40fe0). innochecksum has been extended with an option to read le format information from a given InnoDB data le. As only the rst page needs to be read to detect the format/version information, it can also be used on a running server. This information can be useful when doing the Expand Table Import. Support for Fake Changes has been improved by fetching the sibling pages. Fast InnoDB Checksum feature has now been deprecated. Bug Fixes innodb_fake_changes didnt handle duplicate keys on REPLACE. In some cases this could cause innite loop. Bug xed #898306 (Mark Callaghan, Laurynas Biveinis). Fixed the package dependencies for CentOS 6, that caused conicts during the install. Bug xed #908620 (Ignacio Nin). innodb_fake_changes would allocate too many extents on UPDATE. In some cases this could cause innite loop. Bug xed #917942 (Mark Callaghan, Laurynas Biveinis). Fixed the upstream bug #67737. mysqldump test would fail due to mixing STDOUT and STDERR. Bug xed #959198 (Stewart Smith). Although fake change transactions downgrade the requested exclusive (X) row locks to shared (S) locks, these S locks prevent X locks from being taken and block the real changes. This x introduces a new option innodb_locking_fake_changes which, when set to FALSE, makes fake transactions not to take any row locks. Bug xed #1064326 (Mark Callaghan, Laurynas Biveinis).
168
Fake changes were increasing the changed row and userstat counters. Bug xed #1064333 (Laurynas Biveinis). Log tracking was initialized too late during the InnoDB startup. Bug xed #1076892 (Laurynas Biveinis). Debuginfo Debian packages have been added for Percona Server. Bugs xed #711062 and #1043873 (Ignacio Nin). There is no need to scan buffer pool for AHI entries after the B-trees for the tablespace have been dropped, as that will already clean them. Bug xed #1076215 (Laurynas Biveinis). Slow Query Log code did not handle the case of individual statements in stored procedures correctly. This caused Query_time to increase for every query stored procedure logged to the slow query log. Bug xed #719386 (Alexey Kopytov). Other bug xes: bug xed #890404 (Laurynas Biveinis), bug xed #1071877 (Laurynas Biveinis), bug xed #1050466 (Laurynas Biveinis).
10.9.11 Percona Server 5.5.28-29.1

Percona is glad to announce the release of Percona Server 5.5.28-29.1 on October 26th, 2012 (Downloads are available here and from the Percona Software Repositories). Based on MySQL 5.5.28, including all the bug xes in it, Percona Server 5.5.28-29.1 is now the current stable release in the 5.5 series. All of Perconas software is open-source and free, all the details of the release can be found in the 5.5.28-29.1 milestone at Launchpad. New Features Percona Server has ported Twitters MySQL NUMA patch. This patch implements Improved NUMA support as it prevents imbalanced memory allocation across NUMA nodes. Bug Fixes Percona Server would disconnect clients if gdb was attached and detached. This was caused by wrong signal handling. Bugs xed: #805805 and #1060136 (upstream MySQL bug #67052) (Laurynas Biveinis). Fixed the upstream MySQL bug #66890, where slave server would crash after update statement. Bug xed #1053342 (George Ormond Lorch III ). Reads from tablespaces being deleted would result in buffer pool locking error. This regression was introduced by porting the recently introduced InnoDB code to XtraDB in Percona Server 5.5.27-28.0. Bug xed #1042640 (Stewart Smith). Resolved the Ubuntu Percona Server package conicts with upstream packages. Bug xed #907499 (Ignacio Nin). Crash-resistant replication would break with binlog XA transaction recovery. If a crash would happened between XA PREPARE and COMMIT stages, the prepared InnoDB transaction would not have the slave position recorded and thus would fail to update it once it is replayed during binlog crash recovery. Bug xed #1012715 (Laurynas Biveinis).
10.9.12 Percona Server 5.5.27-29.0

Percona is glad to announce the release of Percona Server 5.5.27-29.0 on October 11th, 2012 (Downloads are available here and from the Percona Software Repositories). 10.9. Percona Server 5.5 Release notes 169
Based on MySQL 5.5.27, including all the bug xes in it, Percona Server 5.5.27-29.0 is now the current stable release in the 5.5 series. All of Perconas software is open-source and free, all the details of the release can be found in the 5.5.27-29.0 milestone at Launchpad. New Features Percona Server now supports XtraDB changed page tracking. This feature will be used for implementing faster incremental backups that use this information to avoid full data scans. Number of binlog les can be restricted when using Percona Server with the new max_binlog_files option. Bug Fixes Fixed server assertion error related to buffer pool, only visible in debug builds. Bug xed #905334 (Stewart Smith). Fix for bug #978036 introduced the innodb_sys_stats_root_page debugging option (only present in debug builds), rendering the previously-existing innodb_sys_stats option its prex. As such, it became unsettable from command line. Fixed by renaming innodb_sys_stats_root_page to innodb_persistent_stats_root_page. Bug xed #1013644 (Laurynas Biveinis). Multiple adaptive hash index partitions would cause overly large hash index. Fixed by changing the way partition sizes are calculated initially. Bug xed #1018264 (George Ormond Lorch III ). Postx would crash on CentOS/RHEL 6.x when using shared dependency (libmysqlclient.so). Fixed by building packages with OpenSSL support rather than the bundled YaSSL library. Bug xed #1028240 (Ignacio Nin). Fixed the issue where LRU dump would hold LRU_list_mutex during the entire dump process. Now the mutex is periodically released in order not to block server while the dump is in progress. Bug xed #686534 (George Ormond Lorch III ). Option expire_logs_days was broken by group_commit patch introduced in Percona Server 5.5.18-23.0. Bug xed #1006214 (Stewart Smith). Fixed issue where innodb_blocking_lru_restore did not take an optional bool argument similar to other bool options. Bug xed #881001 (George Ormond Lorch III ). The binlog shouldnt be rotated while it contains XA transactions in the PREPARED state. Bug xed #1036040 (Stewart Smith). Flashcache support resulted in confusing messages in the error log on Percona Server startup even when ashcache was not used. This was xed by adding new boolean option flashcache. When set to 0 (default), ashcache checks are disabled and when set to 1 checks are enabled. Error message has been made more verbose including error number and system error message as well. Bug xed #747032 (Sergei Glushchenko). Custom server builds would crash when compiled with a non-default maximum number of indexes per table. Upstream MySQL bugs: #54127, #61178, #61179 and #61180. Bug xed #1042517 (Sergei Glushchenko).
10.9.13 Percona Server 5.5.27-28.1

Percona is glad to announce the release of Percona Server 5.5.27-28.1 on September 5th, 2012 (Downloads are available here and from the Percona Software Repositories).
170
Based on MySQL 5.5.27, including all the bug xes in it, Percona Server 5.5.27-28.1 is now the current stable release in the 5.5 series. All of Perconas software is open-source and free, all the details of the release can be found in the 5.5.27-28.1 milestone at Launchpad. Bug Fixes Percona Server 5.5.27-28.0 would crash or deadlock in XtraDB buffer pool code. This was caused by incorrect mutex handling in porting of the recently introduced InnoDB code to XtraDB. Bug xed #1038225 (Laurynas Biveinis). Variables innodb_adaptive_flushing_method and innodb_flush_neighbor_pages would not correctly translate some values internally. Bug xed #1039384 (Laurynas Biveinis).
10.9.14 Percona Server 5.5.27-28.0

Percona is glad to announce the release of Percona Server 5.5.27-28.0 on August 23rd, 2012 (Downloads are available here and from the Percona Software Repositories). Based on MySQL 5.5.27, including all the bug xes in it, Percona Server 5.5.27-28.0 is now the current stable release in the 5.5 series. All of Perconas software is open-source and free, all the details of the release can be found in the 5.5.27-28.0 milestone at Launchpad. Bug x for bug #1007268 has been targeted for the next Percona Server release. Workaround for this bug exists and its setting up the innodb_lazy_drop_table to 1. New Features Percona Server supports tunable buffer size for fast index creation in InnoDB. This value was calculated based on the merge block size (which was hardcoded to 1 MB) and the minimum index record size. By adding the session variable innodb_merge_sort_block_size block size that is used in the merge sort can now be adjusted for better performance. Percona Server has implemented ability to have a MySQL Utility user who has system access to do administrative tasks but limited access to user schema. This feature is especially useful to those operating MySQL As A Service. New Expanded Program Option Modiers have been added to allow access control to system variables. New table INNODB_UNDO_LOGS has been added to allow access to undo segment information. Each row represents an individual undo segment and contains information about which rollback segment the undo segment is currently owned by, which transaction is currently using the undo segment, and other size and type information for the undo segment. This information is live and calculated for each query of the table. Bug Fixes Fixed incorrect merge of MySQL bug #61188 x which caused server to freeze with has waited at buf0buf.c line 2529 for XXX seconds the semaphore errors. This regression was introduced in Percona Server 5.5.2325.3. Bug xed #1026926 (Stewart Smith). Fixed regression introduced in Percona Server 5.5.23-25.3 when merging the upstream x for MySQL bug #64284. Bug xed #1015109 (Stewart Smith). Fixed the upstream MySQL bug #66301. Concurrent INSERT ... ON DUPLICATE KEY UPDATE statements on a table with an AUTO_INCREMENT column could result in spurious duplicate key errors (and,
171
as a result, lost data due to some rows being updated rather than inserted) with the default value of innodb_autoinc_lock_mode=1. Bug xed #1035225 (Alexey Kopytov). Removed error log warnings that occured after enabling innodb_use_sys_stats_table and before ANALYZE TABLE is run for each table. Bug xed #890623 (Alexey Kopytov). Removed the unneeded lrusort.py script. The server now does this sorting automatically and has done for some time. Bug xed #882653 (Stewart Smith). Fixed the malformed CHANGE MASTER query in the output of --include-master-host-port option. Bug xed #1013432 (Stewart Smith). mysqldump with
10.9.15 Percona Server 5.5.25a-27.1

Percona is glad to announce the release of Percona Server 5.5.25a-27.1 on July 20th, 2012 (Downloads are available here and from the Percona Software Repositories). Based on MySQL 5.5.25a, including all the bug xes in it, Percona Server 5.5.25a-27.1 is now the current stable release in the 5.5 series. All of Perconas software is open-source and free, all the details of the release can be found in the 5.5.25a-27.1 milestone at Launchpad. Features Percona Server has extended standard behavior of variable secure-file-priv. When used with no argument, the LOAD_FILE() function will always return NULL. The LOAD DATA INFILE and SELECT INTO OUTFILE statements will fail with the following error: The MySQL server is running with the --secure-file-priv option so it cannot execute this statement. LOAD DATA LOCAL INFILE is not affected by the --secure-file-priv option and will still work when its used without an argument. Percona Server now uses thread based proling by default, instead of process based proling. This was implemented because with process based proling, threads on the server, other than the one being proled, can affect the proling information. Bug Fixes Percona Server 5.5.24 would crash if userstats were enabled with any replication congured. This was a regression introduced with ssl connections count in statistics tables in Percona Server 5.5.24-26.0. Bug xed #1008278 (Vladislav Lesin). PAM authentication plugin was in different directories in 32bit and 64bit binary tarballs. Bug xed #1007271 (Ignacio Nin). Querying I_S.GLOBAL_TEMPORARY_TABLES or TEMPORARY_TABLES would crash threads working with temporary tables. Bug xed #951588 (Laurynas Biveinis). mysqld crash message wasnt pointing to Percona Server bugtracker. Bug xed #1007254 (Vadim Tkachenko). If the tablespace has been created with MySQL 5.0 or older, importing that table could crash Percona Server in some cases. Bug xed #1000221 (Alexey Kopytov). Server started with skip-innodb crashes on SELECT * FROM INNODB_TABLE_STATS or INNODB_INDEX_STATS. Bug xed #896439 (Stewart Smith). Fixed typo for log_slow_verbosity in the code. Bug xed #987737 (Stewart Smith). Removed some patch-based source code management leftovers from the bzr branch migration. Bug xed #988383 (Stewart Smith).
172
Fixed upstream mysql bug #60743, typo in cmake/dtrace.cmake that was making dtrace unusable. Bug xed #1013455 (Stewart Smith). Other bugxes: bug #1022481 (Ignacio Nin) and bug #987348 (Ignacio Nin).
10.9.16 Percona Server 5.5.24-26.0

Percona is glad to announce the release of Percona Server 5.5.24-26.0 on June 1st, 2012 (Downloads are available here and from the Percona Software Repositories). Based on MySQL 5.5.24, including all the bug xes in it, Percona Server 5.5.24-26.0 is now the current stable release in the 5.5 series. All of Perconas software is open-source and free, all the details of the release can be found in the 5.5.24-26.0 milestone at Launchpad. Features Percona PAM Authentication Plugin has now been integrated into the Percona Server. Percona Server has implemented variable enforce_storage_engine which can be used for enforcing the use of a specic storage engine. New column, TOTAL_CONNECTIONS_SSL, has been added in the CLIENT_STATISTICS, THREAD_STATISTICS and USER_STATISTICS tables in the INFORMATION_SCHEMA database. Bug Fixes A Server acting as a replication slave with the query cache enabled could crash with glibc detected memory corruption. This bug was introduced in MySQL 5.5.18 and Percona Server inherited it from MySQL. Bug xed #915814 (George Ormond Lorch III ). Loading LRU dump was preventing shutdown. Bug xed #712055 (George Ormond Lorch III ). A crash could leave behind an InnoDB temporary table with temporary indexes resulting in an unbootable server. Bug xed #999147 (Laurynas Biveinis). Since the output le is simply overwritten when dumping the LRU list, we could end up with a partially written dump le in case of a crash, or when making a backup copy of it. Safer approach has been implemente. It now dumps to a temporary le rst, and then rename it to the actual dump le. Bug xed #686392 (George Ormond Lorch III ). LRU messages are now more verbose for LRU dump. Bug xed #713481 (George Ormond Lorch III ). Building Percona Server with the Clang compiler resulted in a compiler error. Bug xed #997496 (Alexey Kopytov). Variable thread_statistics was a reserved word in Percona Server 5.5. As a result, the server variable with that name had to be quoted with backticks when used. Bug xed #997036 (Vladislav Lesin).
10.9.17 Percona Server 5.5.23-25.3

Percona is glad to announce the release of Percona Server 5.5.23-25.3 on May 16, 2012 (Downloads are available here and from the Percona Software Repositories). Based on MySQL 5.5.23, including all the bug xes in it, Percona Server 5.5.23-25.3 is now the current stable release in the 5.5 series. All of Perconas software is open-source and free, all the details of the release can be found in the 5.5.23-25.3 milestone at Launchpad.
173
Bug Fixes Percona Server would crash on a DDL statement if an XtraDB internal SYS_STATS table was corrupted or overwritten. This is now xed by detecting the corruption and creating a new SYS_STATS table. Bug xed #978036 (Laurynas Biveinis).
10.9.18 Percona Server 5.5.22-25.2

Percona is glad to announce the release of Percona Server 5.5.22-25.2 on April 23, 2012 (Downloads are available here and from the Percona Software Repositories). Based on MySQL 5.5.22, including all the bug xes in it, Percona Server 5.5.22-25.2 is now the current stable release in the 5.5 series. All of Perconas software is open-source and free, all the details of the release can be found in the 5.5.22-25.2 milestone at Launchpad. Bug Fixes Fixed non-determinism in one test case of MEMORY engine. Bug xed #892951 (Laurynas Biveinis).
10.9.19 Percona Server 5.5.21-25.1

Percona is glad to announce the release of Percona Server 5.5.21-25.1 on March 30, 2012 (Downloads are available here and from the Percona Software Repositories). Based on MySQL 5.5.21, including all the bug xes in it, Percona Server 5.5.21-25.1 is now the current stable release in the 5.5 series. All of Perconas software is open-source and free, all the details of the release can be found in the 5.5.21-25.1 milestone at Launchpad. Bug Fixes Fixed a memory corruption regression introduced in 5.5.18-23.0. Bug xed #915814 (Alexey Kopytov). Fixed InnoDB compilation warnings on CentOS 5. Bug xed #962940 (Laurynas Biveinis). Fixed MySQL upstream bug #64160 that was causing issues on upgrade to 5.5.20 and 5.5.21. Bug xed #966844 (Stewart Smith).
10.9.20 Percona Server 5.5.21-25.0

Percona is glad to announce the release of Percona Server 5.5.21-25.0 on March 20, 2012 (Downloads are available here and from the Percona Software Repositories). Based on MySQL 5.5.21, including all the bug xes in it, Percona Server 5.5.21-25.0 is now the current stable release in the 5.5 series. All of Perconas software is open-source and free, all the details of the release can be found in the 5.5.21-25.0 milestone at Launchpad. Improvements to the XtraDBs sync ush algorithm made in Percona Server 5.5.19-24.0 have been reverted because of the performance issues on SSDs (Laurynas Biveinis).
174
New Features Slow query logging features have been expanded by adding new variable log_slow_rate_type. It now provides option to specify the query sampling being taken. If the variable is set up to query, sampling is done on per query basics instead of session, which is the default (Oleg Tsarev). Bug Fixes Fixed MySQL bug #49336, mysqlbinlog couldnt handle stdin when | used. Bug xed: #933969 (Sergei Glushchenko). Fixed MySQL bugs: #64432 and #54330, broken fast index creation. Bug xed: #939485 (Laurynas Biveinis).
10.9.21 Percona Server 5.5.20-24.1

Percona is glad to announce the release of Percona Server 5.5.20-24.1 on February 9th, 2012 (Downloads are available here and from the Percona Software Repositories). Based on MySQL 5.5.20, including all the bug xes in it, Percona Server 5.5.20-24.1 is now the current stable release in the 5.5 series. All of Percona s software is open-source and free, all the details of the release can be found in the 5.5.20-24.1 milestone at Launchpad. Bug Fixes GCC 4.6 has expanded diagnostics. New warnings reported: #878164 (Laurynas Biveinis). Dependency issue while installing libmysqlclient15-dev on Ubuntu systems: #803151 (Ignacio Nin). Dependency issues for libmysqlclient*-dev package(s) on Debian: #656933 (Ignacio Nin). HandlerSocket failed to compile if the package mysql-devel 5.0 is installed on RHEL5 #922768 (Ignacio Nin).
10.9.22 Percona Server 5.5.19-24.0

Percona is glad to announce the release of Percona Server 5.5.19-24.0 on January 13th, 2012 (Downloads are available here and from the Percona Software Repositories). Based on MySQL 5.5.19, including all the bug xes in it, Percona Server 5.5.19-24.0 is now the current stable release in the 5.5 series. All of Percona s software is open-source and free, all the details of the release can be found in the 5.5.19-24.0 milestone at Launchpad. New Features Variable innodb_flush_neighbor_pages can be now set to a new value cont. The previously-available option values 0 and 1 now have more descriptive names none and area. The value of none disables the neighbor page ush and area matches the default InnoDB behavior: any dirty pages in the vicinity of the page selected for ushing may be ushed too. The new option value cont improves the neighbor ushing by considering only contiguous blocks of neighbor pages, thus performing the ush by sequential instead of random I/O. (Yasufumi Kinoshita, Laurynas Biveinis) Improvements to the XtraDBs sync ush algorithm. If the XtraDB checkpoint age grows dangerously close to its limit and XtraDB is forced to perform a sync ush, these changes should slightly improve the user query performance instead of completely blocking them. (Yasufumi Kinoshita, Laurynas Biveinis)
175
Bug Fixes Minor MEMORY engine test suite x: #849921 (Laurynas Biveinis) A x for testsuite integration into Jenkins: #911237 (Oleg Tsarev)
10.9.23 Percona Server 5.5.18-23.0

Percona is glad to announce the release of Percona Server 5.5.18-23.0 on December 17th, 2011 (Downloads are available here and from the Percona Software Repositories). Based on MySQL 5.5.18, including all the bug xes in it, Percona Server 5.5.18-23.0 is now the current stable release in the 5.5 series. All of Percona s software is open-source and free, all the details of the release can be found in the 5.5.18-23.0 milestone at Launchpad. New Features Percona Server now supports group commit between XtraDB and the replication binlog. Percona has imported the group commit patch from MariaDB and is making the performance improvements that group commit brings available to users of Percona Server 5.5. See the Testing the Group Commit Fix blog post for the kind of performance improments that can be expected. Bug Fixes Several crashes were reported when using the --query-cache-strip-comments feature of Percona Server. We have xed several causes for crashes, especially around the handling of escaped characters. Bugs xed: #856404, #705688 (Oleg Tsarev) The Expand Table Import was improved not to hold the InnoDB data dictionary mutex for the full duration of the import operation. This allows queries accessing other InnoDB tables to proceed normally and not be blocked until the import completes. Bug xed: #901775 (Alexey Kopytov) As a follow-up to the already-xed #803865, further xes were made to the implementation of atomic operations which is used on 32-bit systems when compiled without i686+ support. There were no observed issues with the previous implementation, the xes were made proactively for benign issues. Additionally, the Response Time Distribution, which uses those operations, was made slightly more efcient. Bug xed: #878022 (Laurynas Biveinis) An output buffer truncation check in Response Time Distribution was xed. Bug xed: #810272 (Laurynas Biveinis) The compilation warnings, produced by GCC versions up to and including 4.6, were audited and xed. Bug xed: #878164 (Laurynas Biveinis) Testsuite stability x for the percona_status_wait_query_cache_mutex test. Bug xed: #878709 (Oleg Tsarev) A missing link was added to the Percona Server upgrade documentation. Bug xed: #885633 (Alexey Kopytov)
10.9.24 Percona Server 5.5.17-22.1

Percona is glad to announce the release of Percona Server 5.5.17-22.1 on November 19th, 2011 (Downloads are available here and from the Percona Software Repositories).
176
Based on MySQL 5.5.17, including all the bug xes in it, Percona Server 5.5.17-22.1 is now the current stable release in the 5.5 series. All of Percona s software is open-source and free, all the details of the release can be found in the 5.5.17-22.1 milestone at Launchpad. Bug Fixes MyISAM repair-by-sort buffer could not be greater than 4GB even on 64bit architectures. Bug Fixed: #878404 (Alexey Kopytov). The kill idle transactions feature in XtraDB (if enabled) could sometimes cause the server to crash. Bug Fixed: #871722 (Yasufumi Kinoshita). In a master-master setup when using SET user variables it was possible to have SHOW SLAVE STATUS give incorrect output due to a corrupted relay log. Bug Fixed: #860910 (Alexey Kopytov).
10.9.25 Percona Server 5.5.16-22.0

Percona is glad to announce the release of Percona Server 5.5.16-22.0 on October 14, 2011 (Downloads are available here and from the Percona Software Repositories). Based on MySQL 5.5.16, including all the bug xes in it, Percona Server 5.5.16-22.0 is now the current stable release in the 5.5 series. All of Percona s software is open-source and free, all the details of the release can be found in the 5.5.16-22.0 milestone at Launchpad. InnoDB Fake Changes When restarting a slave server in a replication environment, the process can be speed up by having prefetch threads to warm the server: replay statements and then rollback at commit. That makes prefetch simple but has high overhead from locking rows only to undo changes at rollback. Using this approach, support for Fake Changes have been implemented in order to remove the overhead and make it faster. By reading the rows for INSERT, UPDATE and DELETE statements but not updating them (Fake Changes), the rollback is very fast as in most cases there is nothing to do. Kill Idle Transactions NOTE: Percona classes this feature as Beta and possibly not yet suited for production environments. This feature limits the age of idle XtraDB transactions. If a transaction is idle for more seconds than the threshold specied, it will be killed. This prevents users from blocking purge by mistake. Block Startup until LRU dump is loaded Added a new boolean option, innodb_blocking_buffer_pool_restore, which is OFF by default. When set to ON, restoring from the LRU dump le is synchronous, i.e. XtraDB waits until it is complete before reporting successful startup to the server. Bug Fixed: #785489 (Alexey Kopytov).
177
Behavior changes The Fast Index Creation Feature has been disabled by default to align the behavior with upstream. The boolean variable innodb_expand_fast_index_creation has been introduced for enabling or disabling this feature. Bug Fixed: #858945 (Alexey Kopytov).
Bug Fixes
XtraDB requires a full table rebuild for foreign key changes. This unnecessarily delays their creation in a mysqldump output, so --innodb-optimize-keys should ignore foreign key constrains. Bug Fixed: #859078 (Alexey Kopytov). After adding an index using the Fast Index Creation Feature, statistics for that index provided by XtraDB were left in a bogus state until an explicit ANALYZE TABLE is executed. Bug Fixed: #857590 (Alexey Kopytov). QUERY_RESPONSE_TIME did not respect QUERY_RESPONSE_TIME_STATS. Bug Fixed: #855312 (Oleg Tsarev). The mysqldump option --innodb-optimize-keys did not work correctly with tables where the rst UNIQUE key on non-nullable columns was picked as the clustered index by XtraDB in the absence of a PRIMARY KEY. Bug Fixed: #851674 (Alexey Kopytov). The Slow Query Log did not log the error number correctly. #830199 (Oleg Tsarev). Variable log-slow-admin-statements was not listed with SHOW VARIABLES. Bug Fixed: #830199 (Oleg Tsarev). Fixed assertion failure in XtraDB. Bug Fixed: #814404 (Yasufumi Kinoshita). Since AUTO_INCREMENT columns must be dened as keys, omitting key specications and then adding them back in ALTER TABLE doesnt work for them. mysqldump innodb-optimize-keys has been xed to take this into account. Bug Fixed: #812179 (Alexey Kopytov).
Other Changes
Improvements and xes on general distribution: #845019, #702376, #795747 (Alexey Kopytov, Ignacio Nin, Yasufumi Kinoshita). Improvements and xes on the Percona Server Test Suite: #760085, #803140, #803137, #803120, #803110, #803100, #803093, #803088, #803076, #803071, #794780, #803072 (Oleg Tsarev, Alexey Kopytov, Valentine Gostev).
10.9.26 Percona Server 5.5.15-21.0

Percona is glad to announce the release of Percona Server 5.5.15-21.0 on August 31, 2011 (Downloads are available here and from the Percona Software Repositories). Based on MySQL 5.5.15, including all the bug xes in it, Percona Server 5.5.15-21.0 is now the current stable release in the 5.5 series. All of Perconas software is open-source and free, all the details of the release can be found in the 5.5.15-21.0 milestone at Launchpad.
178
New features As of MySQL 5.5.15, a Fixed Row Format (FRF) is still being used in the MEMORY storage engine. The xed row format imposes restrictions on the type of columns as it assigns on advance a limited amount of memory per row. This renders a VARCHAR eld in a CHAR eld in practice, making impossible to have a TEXT or BLOB eld with that engine implementation. This feature also xed the upstream #25007. To overcome this limitation, the Improved MEMORY Storage Engine is introduced in this release for supporting true VARCHAR, VARBINARY, TEXT and BLOB elds in MEMORY tables. This implementation is based on the Dynamic Row Format (DFR) introduced by the mysql-heap-dynamic-rows patch. DFR is used to store column values in a variable-length form, thus helping to decrease memory footprint of those columns and making possible BLOB and TEXT elds and real VARCHAR and VARBINARY. For performance reasons, a mixed solution is implemented: the xed format is used at the beginning of the row, while the dynamic one is used for the rest of it. All values for columns used in indexes are stored in xed format at the rst block of the row, then the following columns are handled with DRF.
10.9.27 Percona Server 5.5.14-20.5

Percona is glad to announce the release of Percona Server 5.5.14-20.5 on August 12, 2011 (Downloads are available here and from the Percona Software Repositories). Based on MySQL 5.5.14, including all the bug xes in it, Percona Server 5.5.14-20.5 is now the current stable release in the 5.5 series. All of Perconas software is open-source and free, all the details of the release can be found in the 5.5.14-20.5 milestone at Launchpad. Improvements
Performance Improvements
fsync() has been replaced with fdatasync() to improve perfomance where possible. The former is intended to sync the metadata of the le also (size, name, access time, etc.), but for the transaction log and the doublewrite buffer, such sync of metadata isnt needed. Bug Fixed: #803270 (Yasufumi Kinoshita).
Compatibility Collations
Two new collations, utf8_general50_ci and ucs2_general50_ci, have been to improve compatibility for those upgrading from MySQL 5.0 or 5.1 prior to version 5.1.24. A x for a MySQL bug (#27877) introduced an incompatible change in collations in MySQL 5.1.24. If the following collations were used: utf8_general_ci ucs2_general_ci and any of the indexes contained the German letter U+00DF SHARP S (which became equal to s), when upgrading from 5.0 / 5.1.23 or lower: any indexes on columns in that situation must be rebuilt after the upgrade, and unique constrains may get broken after upgrade due to possible duplicates. This problem is avoided when upgrading to Percona Server by converting the affected tables or columns to the collations introduced: utf8_general_ci to utf8_general50_ci, and 10.9. Percona Server 5.5 Release notes 179
ucs2_general_ci to ucs2_general50_ci. Blueprint: utf8-general50-ci-5.5 (Alexey Kopytov). Bug Fixes When adding a table to the cache, the server may evict and close another if the table cache is full. If the closed table was on the FEDERATED engine and a replication environment, its client connection to the remote server was closed leading to an unappropriated network error and stopping the Slave SQL thread. Bugs Fixed #813587 / #51196 and #61790 in MySQL (Alexey Kopytov). Querying global_temporary_tables caused the server to crash in some scenarios due to insufcient locking. Fixed by introducing a new mutex to protect from race conditions. Bug Fixed: #745241 (Alexey Kopytov). Using the innodb_lazy_drop_table option led to an assertion error when truncating a table in some scenarios. Bug Fixed: #798371 (Yasufumi Kinoshita). Other Changes Improvements and xes on platform-specic distribution: The compilation of the Response Time Distribution patch has been xed on Solaris (supported platform) and Windows (experimental). Bug Fixed: #737947 (Laurynas Biveinis) Improvements and xes on general distribution: #766266, #794837, #806975 (Laurynas Biveinis, Stewart Smith, Alexey Kopytov) Improvements and xes on the Percona Server documentation: #803109, #803106, #803097 (Rodrigo Gadea)
10.9.28 Percona Server 5.5.13-20.4

Percona is glad to announce the release of Percona Server 5.5.13-20.4 on July 1, 2011 (Downloads are available here and from the Percona Software Repositories). Based on MySQL 5.5.13, Percona Server Percona Server 5.5.13-20.4 is now the current stable release in the 5.5 series. All of Percona s software is open-source and free, all the details of the release can be found in the 5.5.13-20.4 milestone at Launchpad. Improvements
SHM Buffer Pool has been replaced with LRU Dump/Restore
The SHM buffer pool patch, which provided the ability to use a shared memory segment for the buffer pool to enable faster server restarts, has been removed. Instead, we recommend using the LRU Dump/Restore patch which provides similar improvements in restart performance. Replacement is due to SHM buffer pool both being very invasive and not widely used. Improved restart times are better provided by the much safer LRU D/R patch which has the advantage of also persisting across machine restarts. The conguration variables for my.cnf have been kept for compatibility and warnings will be printed for the deprecated options (innodb_buffer_pool_shm_key and innodb_buffer_pool_shm_checksum) if used. Instructions for disabling the SHM buffer pool can be found here. 180 Chapter 10. Reference
Instructions on setting up LRU dump/restore can be found here. Bug Fixes On a high concurrency environment with compressed tables, users may experience crashes due to improper mutex handling in buf_page_get_zip(). Bug Fix: #802348 (Yasufumi Kinoshita). XtraDB crashed when importing big tables (e.g. 350G) using the Expand Table Import feature due to a timeout. Bug Fix: #684829 (Yasufumi Kinoshita). Partitioning adaptive hash index may leave to a hangup of the server in some scenarios. Bug Fix: #791030 (Yasufumi Kinoshita). Statistics gathering for each records update. Bug #791092 (Yasufumi Kinoshita) Other Changes
Improvements and xes on the Percona Server Test Suite
#693415, #794840, #800035, #800559, #782391, #785566, #790199 (Oleg Tsarev, Yasufumi Kinoshita, Stewart Smith).
Improvements and xes on platform-specic distribution:
#737947, #764038 (!), #656933 (Ignacio Nin, Laurynas Biveinis)
10.9.29 Percona Server 5.5.12-20.3

Percona is glad to announce the release of Percona Server 5.5.12-20.3 on June 9, 2011 (Downloads are available here and from the Percona Software Repositories). Based on MySQL 5.5.12, Percona Server 5.5.12-20.3 is now the current stable release in the 5.5 series. Other Changes The list of authors of the plugins used have been corrected. Bug Fixes: #723050 (Yasufumi Kinoshita)
10.9.30 Percona Server 5.5.11-20.2

Released on April 28, 2011 (Downloads are available here and from the Percona Software Repositories. An experimental build for MacOS is available.) Percona Server 5.5.11-20.2 is a stable release. New Features HandlerSocket, a NoSQL plugin for MySQL, has been updated to the latest stable version as April 11th, 2011. InnoDB Fast Index Creation now works with mysqldump, ALTER TABLE and OPTIMIZE TABLE. (Alexey Kopytov)
181
Variable Changes Variable innodb_extra_rsegments was removed because the equivalent, innodb_rollback_segments, has been implemented in MySQL 5.5. (Yasufumi Kinoshita) Bug Fixes Bug #757749 - Using ALTER TABLE to convert an InnoDB table to a MEMORY table could fail due to a bug in the Fast Index Creation patch. (Alexey Kopytov) Bug #764395 - InnoDB crashed with an assertion failure when receiving a signal on pwrite(). The problem was that InnoDB I/O code was not fully conforming to the standard on POSIX systems. Calls to fsync(), pread(), and pwrite() can be interrupted by a signal. In such cases, InnoDB would crash with an assertion failure, rather than just restarting the interrupted call. (Alexey Kopytov) Bug #766236 - A crash was occurring in some cases when innodb_lazy_drop_table was enabled with very large buffer pools. (Yasufumi Kinoshita) Bug #733317 - SYS_STATS internal table of XtraDB has innodb_stats_method from InnoDB -plugin. (Yasufumi Kinoshita) Known Bugs The version of Percona XtraDB shown in logs is not correct. The actual version is 1.1.6-20.2 (instead of 1.1.6-20.1). been expanded for supporting
10.9.31 Percona Server 5.5.10-20.1

Released on April 4, 2011 (Downloads are available here and from the Percona Software Repositories.) Percona Server 5.5.10-20.1 is a release candidate. New Features Added columns ROWS_EXAMINED, ROWS_SENT, and ROWS_READ to table PROCESSLIST and to the output of SHOW PROCESSLIST. (Laurynas Biveinis) Variable Changes Old status variable innodb_row_lock_numbers was renamed to innodb_current_row_locks. (Yasufumi Kinoshita) Old system variable innodb_enable_unsafe_group_commit was deleted. The existing MySQL variable innodb_support_xa can be used instead. (Yasufumi Kinoshita) Old system variable log_warnings_silence was renamed to log_warnings_suppress. (Oleg Tsarev) Old system variable log_slow_timestamp_every slow_query_log_timestamp_always. (Oleg Tsarev) was was renamed renamed renamed to to to
Old system variable slow_query_log_microseconds_timestamp slow_query_log_timestamp_precision. (Oleg Tsarev) Old system variable use_global_log_slow_control slow_query_log_use_global_control. (Oleg Tsarev) 182 was
Old system variable userstat_running was renamed to userstat. (Oleg Tsarev) Old system variable innodb_expand_import was renamed to innodb_import_table_from_xtrabackup. (Yasufumi Kinoshita) Old system variable innodb_auto_lru_dump was renamed to innodb_buffer_pool_restore_at_startup. (Yasufumi Kinoshita) Old system variable innodb_overwrite_relay_log_info innodb_recovery_update_relay_log. (Yasufumi Kinoshita) Old system variable innodb_pass_corrupt_table innodb_corrupt_table_action. (Yasufumi Kinoshita) Bug Fixes Bug #724674 - Ported an updated version of the original implementation of the Remove Excessive Function Calls (fcntl) feature, which removes some fcntl calls to improve performance. (Oleg Tsarev) Bug #727704 - When using the Expand Table Import feature, importing .ibd les created on MySQL 5.0 or Percona Server versions prior to 5.1.7 could crash the server. (Yasufumi Kinoshita) MySQL bugs 56433 and 51325 - These MySQL bugs have been xed in Percona Server. (Yasufumi Kinoshita) was was renamed renamed to to
10.9.32 Percona Server 5.5.8-20.0

Released on February 16, 2011 (Downloads are available here and from the Percona Software Repositories.) Percona Server 5.5.8-20.0 is a beta release. New Features InnoDB adaptive hash function searches can now be spread across multiple partitions (see Multiple Adaptive Hash Search Partitions). Bug xed: #688866. (Yasufumi Kinoshita) Information from SHOW ENGINE INNODB STATUS was made available in new status variables in InnoDB Show Status. Bug xed: #698797. Variable Changes New variable innodb_adaptive_flushing_method was added. New variable innodb_use_global_flush_log_at_trx_commit was added. Bug xed: #635399. (Yasufumi Kinoshita) New variable log_warnings_silence replaced old variable suppress_log_warning_1592. Bug xed: #692413. (Oleg Tsarev) Old variable innodb_adaptive_checkpoint was deleted. Bug xed: #689450. (Yasufumi Kinoshita) Old variable innodb_flush_log_at_trx_commit_session was deleted. Bug xed: #635399. (Yasufumi Kinoshita) Old variable use_global_long_query_time was deleted. Bug xed: #692415. (Oleg Tsarev) Old variable innodb_ibuf_accel_rate was renamed to innodb_ibuf_merge_rate. Bug xed: #695906 (Yasufumi Kinoshita)
183
Old variable enable_query_response_time_stats was renamed to query_response_time_stats. (Oleg Tsarev) Existing variable log_slow_verbosity had profiling_use_getrusage. (Oleg Tsarev) two new values added: profiling and
Existing variables profiling_server and profiling_use_getrusage were merged into the Slow Query Log page. (Oleg Tsarev) Other Changes Additional information was added to the LOG section of the SHOW STATUS command. Bug xed: #693269. (Yasufumi Kinoshita) The SHOW PATCHES command was removed. (Vadim Tkachenko) The INFORMATION_SCHEMA table XTRADB_ENHANCEMENTS was removed. (Yasufumi Kinoshita) Several elds in the INFORMATION_SCHEMA table INNODB_INDEX_STATS were renamed. Bug xed: #691777. (Yasufumi Kinoshita) The XtraDB version was set to 20.0. (Aleksandr Kuzminsky) Many InnoDB compilation warnings were xed. Bug xed: #695273. (Yasufumi Kinoshita) An Amazon OS repository was created. Bug xed: #691996. (Aleksandr Kuzminsky)
10.10 Glossary
ACID Set of properties that guarantee database transactions are processed reliably. Stands for Atomicity, Consistency, Isolation, Durability. Atomicity Atomicity means that database operations are applied following a all or nothing rule. A transaction is either fully applied or not at all. Consistency Consistency means that each transaction that modies the database takes it from one consistent state to another. Drizzle Drizzle: a database for the cloud. Drizzle is a community-driven open source project that is forked from the popular MySQL database. The Drizzle team has removed non-essential code, re-factored the remaining code into a plugin-based architecture and modernized the code base moving to C++. Drizzle Charter A database optimized for Cloud infrastructure and Web applications. Design for massive concurrency on modern multi-cpu architecture Optimize memory for increased performance and parallelism Open source, open community, open design Scope Re-designed modular architecture providing plugins with dened APIs Simple design for ease of use and administration Reliable, ACID transactional Durability Once a transaction is committed, it will remain so.
184
Foreign Key A referential constraint between two tables. Example: A purchase order in the purchase_orders table must have been made by a customer that exists in the customers table. Isolation The Isolation requirement means that no transaction can interfere with another. InnoDB A Storage Engine for MySQL and derivatives (Percona Server, MariaDB, Drizzle) originally written by Innobase Oy, since acquired by Oracle. It provides ACID compliant storage engine with foreign key support. As of MySQL version 5.5, InnoDB became the default storage engine on all platforms. Jenkins Jenkins is a continuous integration system that we use to help ensure the continued quality of the software we produce. It helps us achieve the aims of: no failed tests in trunk on any platform, aid developers in ensuring merge requests build and test on all platforms, no known performance regressions (without a damn good explanation). LSN Log Serial Number. A term used in relation to the InnoDB or XtraDB storage engines. MariaDB A fork of MySQL that is maintained primarily by Monty Program AB. It aims to add features, x bugs while maintaining 100% backwards compatibility with MySQL. my.cnf The le name of the default MySQL conguration le. MyISAM A MySQL Storage Engine that was the default until MySQL 5.5. MySQL An open source database that has spawned several distributions and forks. MySQL AB was the primary maintainer and distributor until bought by Sun Microsystems, which was then acquired by Oracle. As Oracle owns the MySQL trademark, the term MySQL is often used for the Oracle distribution of MySQL as distinct from the drop-in replacements such as MariaDB and Percona Server. NUMA Non-Uniform Memory Access (NUMA) is a computer memory design used in multiprocessing, where the memory access time depends on the memory location relative to a processor. Under NUMA, a processor can access its own local memory faster than non-local memory, that is, memory local to another processor or memory shared between processors. The whole system may still operate as one unit, and all memory is basically accessible from everywhere, but at a potentially higher latency and lower performance. Percona Server Perconas branch of MySQL with performance and management improvements. Storage Engine A Storage Engine is a piece of software that implements the details of data storage and retrieval for a database system. This term is primarily used within the MySQL ecosystem due to it being the rst widely used relational database to have an abstraction layer around storage. It is analogous to a Virtual File System layer in an Operating System. A VFS layer allows an operating system to read and write multiple le systems (e.g. FAT, NTFS, XFS, ext3) and a Storage Engine layer allows a database server to access tables stored in different engines (e.g. MyISAM , InnoDB). XtraDB Perconas improved version of InnoDB providing performance, features and reliability above what is shipped by Oracle in InnoDB. genindex modindex search
10.10. Glossary
185
186
INDEX
Symbols
5.5.10-20.1 (release notes), 182 5.5.11-20.2 (release notes), 181 5.5.12-20.3 (release notes), 181 5.5.13-20.4 (release notes), 180 5.5.14-20.5 (release notes), 179 5.5.15-21.0 (release notes), 178 5.5.16-22.0 (release notes), 177 5.5.17-22.1 (release notes), 176 5.5.18-23.0 (release notes), 176 5.5.19-24.0 (release notes), 175 5.5.20-24.1 (release notes), 175 5.5.21-25.0 (release notes), 174 5.5.21-25.1 (release notes), 174 5.5.22-25.2 (release notes), 174 5.5.23-25.3 (release notes), 173 5.5.24-26.0 (release notes), 173 5.5.25a-27.1 (release notes), 172 5.5.27-28.0 (release notes), 171 5.5.27-28.1 (release notes), 170 5.5.27-29.0 (release notes), 169 5.5.28-29.1 (release notes), 169 5.5.28-29.2 (release notes), 168 5.5.28-29.3 (release notes), 167 5.5.29-29.4 (release notes), 166 5.5.29-30.0 (release notes), 165 5.5.30-30.1 (release notes), 164 5.5.30-30.2 (release notes), 162 5.5.31-30.3 (release notes), 161 5.5.32-31.0 (release notes), 160 5.5.33-31.1 (release notes), 159 5.5.34-32.0 (release notes), 158 5.5.8-20.0 (release notes), 183
C
CLIENT_STATISTICS (table), 99 Consistency, 184
D
Drizzle, 184 Drizzle Charter, 184 Durability, 184
E
enforce_storage_engine (variable), 82 expand_fast_index_creation (variable), 77 extra_max_connections (variable), 46 extra_port (variable), 45
F
fast_index_creation (variable), 75 Flashcache_enabled (variable), 78 ush_caches (variable), 40 Foreign Key, 185
G
GLOBAL_TEMPORARY_TABLES (table), 131
H
have_ashcache (variable), 78 have_response_time_distribution (variable), 127
I
INDEX_STATISTICS (table), 100 InnoDB, 185 innodb_adaptive_ushing (variable), 26 innodb_adaptive_ushing_method (variable), 26 Innodb_adaptive_hash_cells (variable), 117 Innodb_adaptive_hash_hash_searches (variable), 117 Innodb_adaptive_hash_heap_buffers (variable), 117 innodb_adaptive_hash_index_partitions (variable), 31 Innodb_adaptive_hash_non_hash_searches (variable), 117 innodb_auto_lru_dump (variable), 73 Innodb_background_log_sync (variable), 114 187
A
ACID, 184 Atomicity, 184
B
binlog_commits (variable), 47 binlog_group_commits (variable), 47
innodb_blocking_buffer_pool_restore (variable), 73 INNODB_BUFFER_POOL_PAGES (table), 132 INNODB_BUFFER_POOL_PAGES_BLOB (table), 133 INNODB_BUFFER_POOL_PAGES_INDEX (table), 133 Innodb_buffer_pool_pages_LRU_ushed (variable), 120 Innodb_buffer_pool_pages_made_not_young (variable), 120 Innodb_buffer_pool_pages_made_young (variable), 120 Innodb_buffer_pool_pages_old (variable), 120 innodb_buffer_pool_populate (variable), 40 innodb_buffer_pool_restore_at_startup (variable), 74 innodb_buffer_pool_shm_checksum (variable), 137 innodb_buffer_pool_shm_key (variable), 137 INNODB_CHANGED_PAGES (table), 89 Innodb_checkpoint_age (variable), 118 innodb_checkpoint_age_target (variable), 27 Innodb_checkpoint_max_age (variable), 118 Innodb_checkpoint_target_age (variable), 118 innodb_corrupt_table_action (variable), 63 Innodb_current_row_locks (variable), 122 Innodb_deadlocks (variable), 123 Innodb_descriptors_memory (variable), 120 innodb_dict_size_limit (variable), 67 Innodb_dict_tables (variable), 67 innodb_doublewrite_le (variable), 36 innodb_expand_import (variable), 70 innodb_fake_changes (variable), 80 innodb_fast_checksum (variable), 38 innodb_ush_method (variable), 27 innodb_ush_neighbor_pages (variable), 28 Innodb_history_list_length (variable), 121 innodb_ibuf_accel_rate (variable), 24 innodb_ibuf_active_contract (variable), 24 Innodb_ibuf_discarded_delete_marks (variable), 115 Innodb_ibuf_discarded_deletes (variable), 116 Innodb_ibuf_discarded_inserts (variable), 116 Innodb_ibuf_free_list (variable), 116 innodb_ibuf_max_size (variable), 25 Innodb_ibuf_merged_delete_marks (variable), 116 Innodb_ibuf_merged_deletes (variable), 116 Innodb_ibuf_merged_inserts (variable), 116 Innodb_ibuf_merges (variable), 116 Innodb_ibuf_segment_size (variable), 117 Innodb_ibuf_size (variable), 117 innodb_import_table_from_xtrabackup (variable), 70 INNODB_INDEX_STATS (table), 96 innodb_kill_idle_transaction (variable), 81 innodb_lazy_drop_table (variable), 34 innodb_locking_fake_changes (variable), 80 innodb_log_block_size (variable), 29 innodb_log_le_size (variable), 29 Innodb_lsn_current (variable), 118 Innodb_lsn_ushed (variable), 118
Innodb_lsn_last_checkpoint (variable), 118 Innodb_master_thread_10_second_loops (variable), 113 Innodb_master_thread_1_second_loops (variable), 113 Innodb_master_thread_background_loops (variable), 113 Innodb_master_thread_main_ush_loops (variable), 113 Innodb_master_thread_sleeps (variable), 113 innodb_max_bitmap_le_size (variable), 90 innodb_max_changed_pages (variable), 89 Innodb_max_trx_id (variable), 121 Innodb_mem_adaptive_hash (variable), 119 Innodb_mem_dictionary (variable), 119 Innodb_mem_total (variable), 119 innodb_merge_sort_block_size (variable), 75 Innodb_mutex_os_waits (variable), 114 Innodb_mutex_spin_rounds (variable), 114 Innodb_mutex_spin_waits (variable), 114 Innodb_oldest_view_low_limit_trx_id (variable), 121 innodb_overwrite_relay_log_info (variable), 60 innodb_page_size (variable), 49 innodb_pass_corrupt_table (variable), 62 innodb_purge_threads (variable), 30 Innodb_purge_trx_id (variable), 122 Innodb_purge_undo_no (variable), 122 innodb_read_ahead (variable), 28 Innodb_read_views_memory (variable), 120 innodb_recovery_stats (variable), 66 innodb_recovery_update_relay_log (variable), 60 INNODB_RSEG (table), 32 Innodb_s_lock_os_waits (variable), 114 Innodb_s_lock_spin_rounds (variable), 115 Innodb_s_lock_spin_waits (variable), 115 innodb_show_locks_held (variable), 112 innodb_show_verbose_locks (variable), 112 innodb_stats_auto_update (variable), 93 innodb_stats_method (variable), 93 innodb_stats_update_need_lock (variable), 93 INNODB_SYS_COLUMNS (table), 95 INNODB_SYS_FIELDS (table), 95 INNODB_SYS_FOREIGN (table), 95 INNODB_SYS_FOREIGN_COLS (table), 96 INNODB_SYS_INDEXES (table), 95 INNODB_SYS_STATS (table), 94 INNODB_SYS_TABLES (table), 94 INNODB_SYS_TABLESTATS (table), 94 INNODB_TABLE_STATS (table), 96 innodb_thread_concurrency_timer_based (variable), 39 innodb_track_changed_pages (variable), 89 INNODB_UNDO_LOGS (table), 134 innodb_use_atomic_writes (variable), 33 innodb_use_global_ush_log_at_trx_commit (variable), 29 innodb_use_sys_stats_table (variable), 94 Innodb_x_lock_os_waits (variable), 115 Innodb_x_lock_spin_rounds (variable), 115
188
Index
Innodb_x_lock_spin_waits (variable), 115 Isolation, 185
J
Jenkins, 185
L
log_slow_admin_statements (variable), 105 log_slow_lter (variable), 105 log_slow_rate_limit (variable), 106 log_slow_rate_type (variable), 105 log_slow_slave_statements (variable), 106 log_slow_sp_statements (variable), 107 log_slow_verbosity (variable), 107 log_warnings_suppress (variable), 50 LSN, 185
thread_pool_max_threads (variable), 44 thread_pool_oversubscribe (variable), 44 thread_pool_size (variable), 45 thread_pool_stall_limit (variable), 45 THREAD_STATISTICS (table), 101 thread_statistics (variable), 98 Threadpool_idle_threads (variable), 46 Threadpool_threads (variable), 46
U
USER_STATISTICS (table), 102 userstat (variable), 98 utility_user (variable), 84 utility_user_password (variable), 84 utility_user_privileges (variable), 85 utility_user_schema_access (variable), 84
M
MariaDB, 185 max_binlog_les (variable), 56 my.cnf, 185 MyISAM, 185 MySQL, 185
X
XtraDB, 185 XTRADB_ADMIN_COMMAND (table), 74
N
no-remove-eol-carret (variable), 51 NUMA, 185 numa_interleave (variable), 40
P
Percona Server, 185 PROCESSLIST (table), 130
Q
query_cache_strip_comments (variable), 37 QUERY_RESPONSE_TIME (table), 128 query_response_time_range_base (variable), 128 query_response_time_stats (variable), 128
S
secure-le-priv (variable), 85 slow_query_log_always_write_time (variable), 109 slow_query_log_timestamp_always (variable), 107 slow_query_log_timestamp_precision (variable), 108 slow_query_log_use_global_control (variable), 108 Storage Engine, 185 syslog (variable), 124
T
TABLE_STATISTICS (table), 101 TEMPORARY_TABLES (table), 131 thread_pool_high_prio_tickets (variable), 44 thread_pool_idle_timeout (variable), 44 Index 189

Percona Server 5.5.34-32.0

Uploaded by

Copyright:

Available Formats

Percona Server 5.5.34-32.0

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Percona Server 5.5.34-32.0

Uploaded by

Copyright:

Available Formats

Percona Server Documentation

Percona LLC and/or its afliates 2009-2013

October 28, 2013

Ignoring missing tables in mysqldump . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Extended SELECT INTO OUTFILE/DUMPFILE . . . . . . . . . . . . . . . . . . . . . . . . . .

10.10 Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184 Index 187

Percona Server Documentation, Release 5.5.34-32.0

Percona Server Documentation, Release 5.5.34-32.0

Percona Server Documentation, Release 5.5.34-32.0

MySQL 5.5.27 37 310

MySQL 5.5.27 Yes Yes

Percona Server 5.5.27 Yes Yes Yes Yes

Percona Server Documentation, Release 5.5.34-32.0

1.2 The Percona XtraDB Storage Engine

1.2. The Percona XtraDB Storage Engine

Percona Server Documentation, Release 5.5.34-32.0

2.1.1 Using Percona Software Repositories

Remember to update the local cache:

x86 x86_64 (also known as amd64)

Percona Server Documentation, Release 5.5.34-32.0

Apt-Pinning the packages

You should see some output such as the following:

Percona Server Documentation, Release 5.5.34-32.0

Retrieving http://www.percona.com/downloads/percona-release/percona-release-0.0-1.x86_64.rpm Preparing... ########################################### [100%] 1:percona-release ########################################### [100%]

To install the repository manually, /etc/yum.repos.d/Percona.repo:

Also, copy the Percona GPG key into a le named /etc/pki/rpm-gpg/RPM-GPG-KEY-percona.

You should see output similar to the following:

Percona Server Documentation, Release 5.5.34-32.0

Percona yum Experimental repository

2.1.2 Using Standalone Packages

Install them in one command:

Percona Server Documentation, Release 5.5.34-32.0

Whats in each RPM?

$ wget -r -l 1 -nd -A deb -R "*dev*" \ http://www.percona.com/redir/downloads/Percona-Server-5.5/Percona-Server-5.5.14-20.5/deb/maverick/x86

Install them in one command:

2.1. Installing Percona Server 5.5 from Binaries

Percona Server Documentation, Release 5.5.34-32.0

2.2 Installing Percona Server from a Source Tarball

$ wget http://www.percona.com/redir/downloads/Percona-Server-5.5/Percona-Server-5.5.15-21.0/source/Pe $ tar xfz Percona-Server-5.5.15-rel21.0.tar.gz

$ cmake . -DCMAKE_BUILD_TYPE=RelWithDebInfo -DBUILD_CONFIG=mysql_release -DFEATURE_SET=community -DWI

Now, compile using make

2.3 Installing Percona Server from the Bazaar Source Tree

$ cmake . -DCMAKE_BUILD_TYPE=RelWithDebInfo -DBUILD_CONFIG=mysql_release -DFEATURE_SET=community -DWI $ make $ make install

Percona Server Documentation, Release 5.5.34-32.0

2.4 Percona Sever In-Place Upgrading Guide: From 5.1 to 5.5

2.4.1 Changes in Server Conguration

Response Time Distribution Multiple Rollback Segments Dedicated Purge Thread

2.4. Percona Sever In-Place Upgrading Guide: From 5.1 to 5.5

Percona Server Documentation, Release 5.5.34-32.0

Multiple Rollback Segments

For more information, see its documentation documentation.

egrep -ni innodb_adaptive_checkpoint|suppress_log_warning_1592|innodb_pass_corrupt_table|innodb_expa

For more information, see: 14 Chapter 2. Installation

Percona Server Documentation, Release 5.5.34-32.0

2.4.2 Changes in Server Behavior and Functioning

2.4. Percona Sever In-Place Upgrading Guide: From 5.1 to 5.5

Percona Server Documentation, Release 5.5.34-32.0

Percona Server Documentation, Release 5.5.34-32.0

2.4.3 BEFORE STARTING: FULL BACKUP

2.4.4 Upgrading using the Percona repositories

2.4. Percona Sever In-Place Upgrading Guide: From 5.1 to 5.5

$ wget -r -l 1 -nd -A deb -R "dev" \ http://www.percona.com/redir/downloads/Percona-Server-5.5/Percona-Server-5.5.14-20.5/deb/maverick/x86

$ wget -r -l 1 -nd -A deb -R "dev" http://www.percona.com/redir/downloads/Percona-Server-5.5/Percon

$ wget -r -l 1 -nd -A rpm -R "devel,debuginfo" http://www.percona.com/redir/downloads/Percona-Ser