Merge lp:~hrvojem/percona-server/rn-5.6.10-60.2 into lp:percona-server/5.6

[Hrvoje Matijakovic]

[Stewart Smith (stewart)]

review: Approve

[Stewart Smith (stewart)]

also merged into release branch

[Laurynas Biveinis (laurynas-biveinis)]

    - s/beta/alpha
    - Line 38 and innodb_split_buf_pool_mutex.rst: let's not discuss buffer pool mutex split for now.
    - please add http://bugs.mysql.com/bug.php?id=65946 to the list
      of bugs fixed in PS 5.6. (upstream fixed in 5.7.0)

review: Needs Fixing

[Laurynas Biveinis (laurynas-biveinis)]

Also, please include the corrupt table action patch in this release (the milestone will be updated shortly).

review: Needs Fixing

=== modified file 'doc/source/changed_in_56.rst'
--- doc/source/changed_in_56.rst	2013-02-08 16:56:30 +0000
+++ doc/source/changed_in_56.rst	2013-03-08 07:34:35 +0000
@@ -8,13 +8,11 @@
 
 Some features that were present in |Percona Server| 5.5 have been removed in |Percona Server| 5.6. These are:
 
- * optimizer_fix
- * fast_index_creation (use MySQL 5.6's ALGORITHM= option instead)
- * HandlerSocket (may return when HandlerSocket supports MySQL 5.6)
+ * `fast_index_creation <http://www.percona.com/doc/percona-server/5.5/management/innodb_fast_index_creation.html>`_ (use MySQL 5.6's ALGORITHM= option instead)
+ * `HandlerSocket <http://www.percona.com/doc/percona-server/5.5/performance/handlersocket.html>`_ (may return when HandlerSocket supports MySQL 5.6)
  * SHOW [GLOBAL] TEMPORARY TABLES functionality is now only available via the INFORMATION_SCHEMA tables TEMPORARY_TABLES and GLOBAL_TEMPORARY_TABLES.
- * thread concurrency timer based
- * innodb_recovery_stats
- * innodb_show_lock_name.patch - replaced by PERFORMANCE_SCHEMA
+ * `InnoDB timer-based Concurrency Throttling <http://www.percona.com/doc/percona-server/5.5/performance/innodb_thread_concurrency_timer_based.html>`_
+ * `InnoDB Recovery Stats <http://www.percona.com/doc/percona-server/5.5/management/innodb_recovery_patches.html>`_
 
 Some features that were present in |Percona Server| 5.5 have been replaced by a different implementation of the same/similar functionality in |Percona Server| 5.6. These are:
 
@@ -24,11 +22,11 @@
 
 Some |Percona Server| 5.5 features have been replaced by similar or equivalent MySQL 5.6 features, so we now keep the MySQL 5.6 implementations in |Percona Server| 5.6. These are:
 
- * innodb_recovery_update_relay_log (replaced by MySQL crash safe replication)
- * innodb_io_patches (replaced by improvements and changes in MySQL 5.6, although Percona may make improvements in the future)
- * innodb_dict_size_limit has been replaced by MySQL 5.6 using the existing table-definition-cache variable to limit the size of the InnoDB data dictionary.
- * split innodb buffer pool mutex. This has been replaced by improvements in upstream InnoDB
- * expanded IMPORT TABLESPACE has been replaced by MySQL "InnoDB transportable tablespaces"
- * The InnoDB data dictionary INFORMATION_SCHEMA tables have been superseded by the MySQL implementations 
- * XtraDB SYS_STATS persistent table and index statistics has been replaced by the MySQL 5.6 implementation
- * lru dump/restore is now available in MySQL 5.6, so we have replaced the Percona Server implementation with the MySQL one.
+ * `Show Lock Names <http://www.percona.com/doc/percona-server/5.5/diagnostics/innodb_show_lock_names.html>`_ has been replaced by PERFORMANCE_SCHEMA
+ * `Crash-Resistant Replication <http://www.percona.com/doc/percona-server/5.5/reliability/crash_resistant_replication.html>`_ has been replaced by |MySQL| crash safe replication
+ * `Improved InnoDB I/O Scalability <http://www.percona.com/doc/percona-server/5.5/scalability/innodb_io_55.html>`_ patches have been replaced by improvements and changes in MySQL 5.6, although Percona may make improvements in the future
+ * `InnoDB Data Dictionary Size Limit <http://www.percona.com/doc/percona-server/5.5/management/innodb_dict_size_limit.html>`_ has been replaced by |MySQL| 5.6 using the existing table-definition-cache variable to limit the size of the |InnoDB| data dictionary.
+ * `Expand Table Import <http://www.percona.com/doc/percona-server/5.5/management/innodb_expand_import.html>`_ has been replaced by |MySQL| "InnoDB transportable tablespaces"
+ * The |InnoDB| data dictionary INFORMATION_SCHEMA tables have been superseded by the |MySQL| implementations 
+ * |XtraDB| SYS_STATS persistent table and index statistics has been replaced by the MySQL 5.6 implementation
+ * `Dump/Restore of the Buffer Pool <http://www.percona.com/doc/percona-server/5.5/management/innodb_lru_dump_restore.html>`_ is now available in |MySQL| 5.6, so we have replaced the |Percona Server| implementation with the MySQL one.

=== modified file 'doc/source/compatibility.rst'
--- doc/source/compatibility.rst	2013-03-05 12:46:43 +0000
+++ doc/source/compatibility.rst	2013-03-08 07:34:35 +0000
@@ -4,18 +4,6 @@
 Options that make XtraDB tablespaces not compatible with MySQL
 ==============================================================
 
-Fast checksums
-==============
-
-Enabling :variable:`innodb_fast_checksum` will use more CPU-efficient algorithm, based on 4-byte words which can be beneficial 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 files created when :variable:`innodb_fast_checksums` was enabled.
-
-In case you've migrated from |Percona Server| to |MySQL| you could get the "corrupted checksum" error message. In order to recover that table you'll 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). 
-
 Page sizes other than 16KiB
 ===========================
 

=== modified file 'doc/source/conf.py'
--- doc/source/conf.py	2013-02-08 16:56:30 +0000
+++ doc/source/conf.py	2013-03-08 07:34:35 +0000
@@ -54,7 +54,7 @@
 # The short X.Y version.
 version = '5.6'
 # The full version, including alpha/beta/rc tags.
-release = '5.6.5-60.0'
+release = '5.6.10-60.2'
 
 # The language for content autogenerated by Sphinx. Refer to documentation
 # for a list of supported languages.

=== modified file 'doc/source/diagnostics/index_info_schema_tables.rst'
--- doc/source/diagnostics/index_info_schema_tables.rst	2011-10-07 23:38:41 +0000
+++ doc/source/diagnostics/index_info_schema_tables.rst	2013-03-08 07:34:35 +0000
@@ -8,30 +8,8 @@
 
   * :table:`GLOBAL_TEMPORARY_TABLES`
 
-  * :table:`INNODB_CMP`
-
-  * :table:`INNODB_CMP_RESET`
-
-  * :table:`INNODB_CMPMEM`
-
-  * :table:`INNODB_CMPMEM_RESET`
-
-  * :table:`INNODB_INDEX_STATS`
-
-  * :table:`INNODB_LOCK_WAITS`
-
-  * :table:`INNODB_LOCKS`
-
-  * :table:`INNODB_RSEG`
-
-  * :table:`INNODB_TABLE_STATS`
-
-  * :table:`INNODB_TRX`
-
   * :table:`PROCESSLIST`
 
-  * :table:`QUERY_RESPONSE_TIME`
-
   * :table:`TEMPORARY_TABLES`
 
 

=== removed file 'doc/source/diagnostics/innodb_deadlock_count.rst'
--- doc/source/diagnostics/innodb_deadlock_count.rst	2013-03-05 12:46:43 +0000
+++ doc/source/diagnostics/innodb_deadlock_count.rst	1970-01-01 00:00:00 +0000
@@ -1,57 +0,0 @@
-.. _innodb_deadlocks_page:
-
-==========================
- 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 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 <http://ebergen.net/wordpress/2009/08/27/innodb-deadlock-count-patch/>`_).
-
-It adds a new global status variable (:variable:`innodb_deadlocks`) showing the number of deadlocks.*
-
-You can use it with ``SHOW GLOBAL STATUS``, e.g.: ::
-
-  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_deadlocks'; 
-  +----------------+
-  | VARIABLE_VALUE |
-  +----------------+
-  | 323            |
-  +----------------+
-
-A deadlock will occur when at least two transactions are mutually waiting for the other to finish, 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.
-
-
-Version Specific Information
-============================
-
-  * 5.5.8-20.0:
-    Full functionality available.
-
-Status Variables
-================
-
-One new status variable was introduced by this feature.
-
-.. variable:: innodb_deadlocks
-
-     :vartype: LONG
-     :scope: Global
-
-
-Related Reading
-===============
-
-  * `Original post by Eric Bergen <http://ebergen.net/wordpress/2009/08/27/|InnoDB|-deadlock-count-patch/>`_
-

=== removed file 'doc/source/diagnostics/innodb_show_status.rst'
--- doc/source/diagnostics/innodb_show_status.rst	2013-03-05 12:46:43 +0000
+++ doc/source/diagnostics/innodb_show_status.rst	1970-01-01 00:00:00 +0000
@@ -1,475 +0,0 @@
-.. _innodb_show_status:
-
-======================
- Show |InnoDB| Status
-======================
-
-This feature reorganizes the output of ``SHOW 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.
-
-This feature modified the ``SHOW 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 INNODB STATUS`` information presented (bugfix for `#29123 <http://bugs.mysql.com/bug.php?id=29126>`_):
-
-    * :variable:`innodb_show_verbose_locks` - Whether to show records locked
-
-    * :variable:`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).
-
-Version Specific Information
-============================
-
-  * 5.5.8-20.0
-    Added status variables showing information from ``SHOW INNODB STATUS``.
-
-  * 5.5.8-20.0
-    Added additional information in the LOG section.
-
-  * 5.5.10-20.1:
-    Renamed status variable :variable:`innodb_row_lock_numbers` to :variable:`innodb_current_row_locks`.
-
-Other Information
-=================
-
-  * Author / Origin:
-    Baron Schwartz, http://lists.mysql.com/internals/35174
-
-
-System Variables
-================
-
-.. variable:: innodb_show_verbose_locks
-
-     :cli: Yes
-     :conf: Yes
-     :scope: Global
-     :dyn: Yes
-     :vartype: ULONG
-     :default: 0
-     :range: 0 - 1
-
-Specifies to show records locked in ``SHOW 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
-
-     :cli: Yes
-     :conf: Yes
-     :scope: Global
-     :dyn: Yes
-     :vartype: ULONG
-     :default: 10
-     :range: 0 - 1000
-
-Specifies the number of locks held to print for each |InnoDB| transaction in SHOW INNODB STATUS.
-
-
-Status Variables
-================
-
-The status variables here contain information available in the output of ``SHOW INNODB STATUS``, organized by the sections ``SHOW INNODB STATUS`` displays. If you are familiar with the output of ``SHOW 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 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 5.5.8-20.0: Introduced.
-     :vartype: Numeric
-     :scope: Global
-
-.. variable:: innodb_master_thread_10_second_loops
-
-     :version 5.5.8-20.0: Introduced.
-     :vartype: Numeric
-     :scope: Global
-
-.. variable:: innodb_master_thread_background_loops
-
-     :version 5.5.8-20.0: Introduced.
-     :vartype: Numeric
-     :scope: Global
-
-.. variable:: innodb_master_thread_main_flush_loops
-
-     :version 5.5.8-20.0: Introduced.
-     :vartype: Numeric
-     :scope: Global
-
-.. variable:: innodb_master_thread_sleeps
-
-     :version 5.5.8-20.0: Introduced.
-     :vartype: Numeric
-     :scope: Global
-
-.. variable:: innodb_background_log_sync
-
-     :version 5.5.8-20.0: Introduced.
-     :vartype: Numeric
-     :scope: Global
-
-SEMAPHORES
-----------
-
-The following variables contain information in the SEMAPHORES section of the output from ``SHOW 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 5.5.8-20.0: Introduced.
-     :vartype: Numeric
-     :scope: Global
-
-.. variable:: innodb_mutex_spin_rounds
-
-     :version 5.5.8-20.0: Introduced.
-     :vartype: Numeric
-     :scope: Global
-
-.. variable:: innodb_mutex_spin_waits
-
-     :version 5.5.8-20.0: Introduced.
-     :vartype: Numeric
-     :scope: Global
-
-.. variable:: innodb_s_lock_os_waits
-
-     :version 5.5.8-20.0: Introduced.
-     :vartype: Numeric
-     :scope: Global
-
-.. variable:: innodb_s_lock_spin_rounds
-
-     :version 5.5.8-20.0: Introduced.
-     :vartype: Numeric
-     :scope: Global
-
-.. variable:: innodb_s_lock_spin_waits
-
-     :version 5.5.8-20.0: Introduced.
-     :vartype: Numeric
-     :scope: Global
-
-.. variable:: innodb_x_lock_os_waits
-
-     :version 5.5.8-20.0: Introduced.
-     :vartype: Numeric
-     :scope: Global
-
-.. variable:: innodb_x_lock_spin_rounds
-
-     :version 5.5.8-20.0: Introduced.
-     :vartype: Numeric
-     :scope: Global
-
-.. variable:: innodb_x_lock_spin_waits
-
-     :version 5.5.8-20.0: Introduced.
-     :vartype: 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 |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 5.5.8-20.0: Introduced.
-     :vartype: Numeric
-     :scope: Global
-
-.. variable:: innodb_ibuf_discarded_deletes
-
-     :version 5.5.8-20.0: Introduced.
-     :vartype: Numeric
-     :scope: Global
-
-.. variable:: innodb_ibuf_discarded_inserts
-
-     :version 5.5.8-20.0: Introduced.
-     :vartype: Numeric
-     :scope: Global
-
-.. variable:: innodb_ibuf_free_list
-
-     :version 5.5.8-20.0: Introduced.
-     :vartype: Numeric
-     :scope: Global
-
-.. variable:: innodb_ibuf_merged_delete_marks
-
-     :version 5.5.8-20.0: Introduced.
-     :vartype: Numeric
-     :scope: Global
-
-.. variable:: innodb_ibuf_merged_deletes
-
-     :version 5.5.8-20.0: Introduced.
-     :vartype: Numeric
-     :scope: Global
-
-.. variable:: innodb_ibuf_merged_inserts
-
-     :version 5.5.8-20.0: Introduced.
-     :vartype: Numeric
-     :scope: Global
-
-.. variable:: innodb_ibuf_merges
-
-     :version 5.5.8-20.0: Introduced.
-     :vartype: Numeric
-     :scope: Global
-
-.. variable:: innodb_ibuf_segment_size
-
-     :version 5.5.8-20.0: Introduced.
-     :vartype: Numeric
-     :scope: Global
-
-.. variable:: innodb_ibuf_size
-
-     :version 5.5.8-20.0: Introduced.
-     :vartype: Numeric
-     :scope: Global
-
-.. variable:: innodb_adaptive_hash_cells
-
-     :version 5.5.8-20.0: Introduced.
-     :vartype: Numeric
-     :scope: Global
-
-.. variable:: innodb_adaptive_hash_heap_buffers
-
-     :version 5.5.8-20.0: Introduced.
-     :vartype: Numeric
-     :scope: Global
-
-.. variable:: innodb_adaptive_hash_hash_searches
-
-     :version 5.5.8-20.0: Introduced.
-     :vartype: Numeric
-     :scope: Global
-
-.. variable:: innodb_adaptive_hash_non_hash_searches
-
-     :version 5.5.8-20.0: Introduced.
-     :vartype: Numeric
-     :scope: Global
-
-LOG
----
-
-The following variables contain information in the LOG section of the output from ``SHOW INNODB STATUS``. An example of that output is: ::
-
-  ---
-  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/o's done, 2000.00 log i/o's/second
-
-.. variable:: innodb_lsn_current
-
-     :version 5.5.8-20.0: Introduced.
-     :vartype: Numeric
-     :scope: Global
-
-.. variable:: innodb_lsn_flushed
-
-     :version 5.5.8-20.0: Introduced.
-     :vartype: Numeric
-     :scope: Global
-
-.. variable:: innodb_lsn_last_checkpoint
-
-     :version 5.5.8-20.0: Introduced.
-     :vartype: Numeric
-     :scope: Global
-
-.. variable:: innodb_checkpoint_age
-
-     :version 5.5.8-20.0: Introduced.
-     :vartype: Numeric
-     :scope: Global
-
-.. variable:: innodb_checkpoint_max_age
-
-     :version 5.5.8-20.0: Introduced.
-     :vartype: Numeric
-     :scope: Global
-
-.. variable:: innodb_checkpoint_target_age
-
-     :version 5.5.8-20.0: Introduced.
-     :vartype: Numeric
-     :scope: Global
-
-BUFFER POOL AND MEMORY
-----------------------
-
-The following variables contain information in the BUFFER POOL AND MEMORY section of the output from ``SHOW INNODB STATUS``. An example of that output is: ::
-
-  ----------------------
-  BUFFER POOL AND MEMORY
-  ----------------------
-  Total memory allocated 137625600; in additional pool allocated 0
-  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 5.5.8-20.0: Introduced.
-     :vartype: Numeric
-     :scope: Global
-
-.. variable:: innodb_mem_dictionary
-
-     :version 5.5.8-20.0: Introduced.
-     :vartype: Numeric
-     :scope: Global
-
-.. variable:: innodb_mem_total
-
-     :version 5.5.8-20.0: Introduced.
-     :vartype: Numeric
-     :scope: Global
-
-.. variable:: innodb_buffer_pool_pages_LRU_flushed
-
-     :version 5.5.8-20.0: Introduced.
-     :vartype: Numeric
-     :scope: Global
-
-.. variable:: innodb_buffer_pool_pages_made_not_young
-
-     :version 5.5.8-20.0: Introduced.
-     :vartype: Numeric
-     :scope: Global
-
-.. variable:: innodb_buffer_pool_pages_made_young
-
-     :version 5.5.8-20.0: Introduced.
-     :vartype: Numeric
-     :scope: Global
-
-.. variable:: innodb_buffer_pool_pages_old
-
-     :version 5.5.8-20.0: Introduced.
-     :vartype: Numeric
-     :scope: Global
-
-TRANSACTIONS
-------------
-
-The following variables contain information in the TRANSACTIONS section of the output from ``SHOW INNODB STATUS``. An example of that output is: ::
-
-  ------------
-  TRANSACTIONS
-  ------------
-  Trx id counter F561FD
-  Purge done for trx's 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 innodb status
-  ---TRANSACTION F561FC, ACTIVE 29 sec, process no 993, OS thread id 140213152769808 updating or deleting
-  mysql tables in use 1, locked 1
-
-.. variable:: innodb_history_list_length
-
-     :version 5.5.8-20.0: Introduced.
-     :vartype: Numeric
-     :scope: Global
-
-.. variable:: innodb_max_trx_id
-
-     :version 5.5.8-20.0: Introduced.
-     :vartype: Numeric
-     :scope: Global
-
-.. variable:: innodb_oldest_view_low_limit_trx_id
-
-     :version 5.5.8-20.0: Introduced.
-     :vartype: Numeric
-     :scope: Global
-
-.. variable:: innodb_purge_trx_id
-
-     :version 5.5.8-20.0: Introduced.
-     :vartype: Numeric
-     :scope: Global
-
-.. variable:: innodb_purge_undo_no
-
-     :version 5.5.8-20.0: Introduced.
-     :vartype: 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 :variable:`innodb_row_lock_numbers` in release 5.5.8-20.0.
-
-
-Other reading
-=============
-
-  * `SHOW INNODB STATUS walk through <http://www.mysqlperformanceblog.com/2006/07/17/show-innodb-status-walk-through/>`_
-
-  * `Table locks in SHOW INNODB STATUS <http://www.mysqlperformanceblog.com/2010/06/08/table-locks-in-show-innodb-status/>`_

=== removed file 'doc/source/diagnostics/innodb_stats.rst'
--- doc/source/diagnostics/innodb_stats.rst	2013-03-05 12:46:43 +0000
+++ doc/source/diagnostics/innodb_stats.rst	1970-01-01 00:00:00 +0000
@@ -1,160 +0,0 @@
-.. _innodb_stats:
-
-=====================
- |InnoDB| Statistics
-=====================
-
-This feature provides new startup options (control method and collection of index statistics estimation) and information schema views to confirm the statistics.
-
-This implements the fix for `MySQL Bug #30423 <http://bugs.mysql.com/bug.php?id=30423>`_.
-
-Version Specific Information
-============================
-
-  * 5.5.8-20.0:
-    Renamed three fields in table ``INNODB_INDEX_STATS``.
-
-
-System Variables
-================
-
-Four new system variables were introduced by this feature.
-
-.. variable:: innodb_stats_method
-
-   :cli: YES
-   :configfile: YES
-   :scope: GLOBAL
-   :dyn: YES
-   :type: STRING
-   :default: ``nulls_equal``
-   :allowed: ``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| doesn't have several patterns of statistics currently. So, though this option able to be changed dynamically, we need re-calculate statistics to change the method for the table.
-
-(reference: `MyISAM Index Statistics Collection <http://dev.mysql.com/doc/refman/5.1/en/myisam-index-statistics.html>`_)
-
-**Note:** Beginning in release 5.1.56-12.7, a variable with the same and functionality was implemented in the upstream |InnoDB|.
-
-.. variable:: innodb_stats_auto_update
-
-   :type: BOOLEAN
-   :default: 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 “first open” and “ANALYZE TABLE command”.
-
-
-.. variable:: innodb_stats_update_need_lock
-
-   :type: BOOLEAN
-   :default: 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: 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 first time, it loads the statistics from ``SYS_STATS`` instead of sampling index pages. If you use a high ``stats_sample_pages`` value, the first open of a table is expensive. In such a case, this option will help. Note: This option may cause less frequent updating of statistics. So, you should intentionally use the ``ANALYZE TABLE`` command more often.
-
-(This variable was introduced in release 5.1.50-11.4.)
-
-
-INFORMATION_SCHEMA Tables
-=========================
-
-Two new tables were introduced by this feature.
-
-.. table:: INFORMATION_SCHEMA.INNODB_TABLE_STATS
-
-   Shows table statistics information of dictionary cached.
-
-   :column table_schema: Database name of the table.
-   :column table_name: Table name.
-   :column rows: estimated number of all rows.
-   :column clust_size: cluster index (table/primary key) size in number of pages.
-   :column other_size: Other index (non primary key) size in number of pages.
-   :column modified: Internal counter to judge whether statistics recalculation should be done.
-
-If the value of modified 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.
-
-   :column table_schema: Database name of the table.
-   :column table_name: Table name.
-   :column index_name: Index name.
-   :column fields: How many fields the index key has. (it is internal structure of |InnoDB|, it may be larger than the ``CREATE TABLE``).
-   :column rows_per_key: Estimate rows per 1 key value. ([1 column value], [2 columns value], [3 columns value], ...).
-   :column index_total_pages: Number of index pages.
-   :column index_leaf_pages: Number of leaf pages.
-
-In releases before 5.5.8-20.0, these fields had different names:
-
-  * ``rows_per_key`` was ``row_per_keys``
-
-  * ``index_total_pages`` was ``index_size``
-
-  * ``index_leaf_pages`` was ``leaf_pages``
-
-Example
-=======
-
-This example uses the same data to Bug #30423 of |MySQL|.
-
-``[innodb_stats_method = nulls_equal (default behavior of |InnoDB|)]`` ::
-
-  mysql> explain SELECT COUNT(*), 0 FROM orgs2 orgs LEFT JOIN sa_opportunities2 sa_opportunities ON orgs.org_id=sa_opportunities.org_id LEFT JOIN contacts2 contacts ON orgs.org_id=contacts.org_id;
-  +----+-------------+------------------+-------+-----------------+-----------------+---------+-------------------+-------+-------------+
-  | id | select_type | table            | type  | possible_keys   | key             | key_len | ref               | rows  | Extra       |
-  +----+-------------+------------------+-------+-----------------+-----------------+---------+-------------------+-------+-------------+
-  |  1 | SIMPLE      | orgs             | index | NULL            | orgs$org_id     | 4       | NULL              |   128 | Using index |
-  |  1 | SIMPLE      | sa_opportunities | ref   | sa_opp$org_id   | sa_opp$org_id   | 5       | test2.orgs.org_id |  5751 | Using index |
-  |  1 | SIMPLE      | contacts         | ref   | contacts$org_id | contacts$org_id | 5       | test2.orgs.org_id | 23756 | Using index |
-  +----+-------------+------------------+-------+-----------------+-----------------+---------+-------------------+-------+-------------+
-  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 orgs.org_id=sa_opportunities.org_id LEFT JOIN contacts2 contacts ON orgs.org_id=contacts.org_id;
-  +----+-------------+------------------+-------+-----------------+-----------------+---------+-------------------+------+-------------+
-  | id | select_type | table            | type  | possible_keys   | key             | key_len | ref               | rows | Extra       |
-  +----+-------------+------------------+-------+-----------------+-----------------+---------+-------------------+------+-------------+
-  |  1 | SIMPLE      | orgs             | index | NULL            | orgs$org_id     | 4       | NULL              |  128 | Using index |
-  |  1 | SIMPLE      | sa_opportunities | ref   | sa_opp$org_id   | sa_opp$org_id   | 5       | test2.orgs.org_id |    1 | Using index |
-  |  1 | SIMPLE      | contacts         | ref   | contacts$org_id | contacts$org_id | 5       | test2.orgs.org_id |    1 | Using index |
-  +----+-------------+------------------+-------+-----------------+-----------------+---------+-------------------+------+-------------+
-  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)
-
-Other reading
-=============
-
-  * `InnoDB Table/Index stats <http://www.mysqlperformanceblog.com/2010/03/20/|InnoDB|-tableindex-stats/>`_
-

=== removed file 'doc/source/diagnostics/mysql_syslog.rst'
--- doc/source/diagnostics/mysql_syslog.rst	2013-03-05 12:46:43 +0000
+++ doc/source/diagnostics/mysql_syslog.rst	1970-01-01 00:00:00 +0000
@@ -1,43 +0,0 @@
-.. _mysql_syslog:
-
-======================================
- 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.
-
-Version Specific Information
-============================
-
-  * :rn:`5.5.8-20.0`:
-    Full functionality available.
-
-Other Information
-=================
-
-  * Author / Origin:
-    Percona
-
-Client Variables
-================
-
-.. variable:: syslog
-
-     :cli: Yes
-     :conf: Yes
-     :server: No
-     :scope: Global
-     :dyn: Yes
-     :vartype: Boolean
-     :default: OFF
-     :range: ON/OFF
-
-The variable enables (ON)/disables (OFF) logging to syslog.
-
-
-Other Reading
-=============
-
-  * http://en.wikipedia.org/wiki/Syslog
-
-  * http://tools.ietf.org/html/rfc5424

=== removed file 'doc/source/diagnostics/response_time_distribution.rst'
--- doc/source/diagnostics/response_time_distribution.rst	2013-03-05 12:46:43 +0000
+++ doc/source/diagnostics/response_time_distribution.rst	1970-01-01 00:00:00 +0000
@@ -1,266 +0,0 @@
-.. _response_time_distribution:
-
-============================
- 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 define time intervals that divide the range 0 to positive infinity 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 slave's SQL thread (whether they are slow or not) for the time distribution unless the log_slow_slave_statements variable is set.
-
-The feature isn't implemented in all versions of the server. The variable :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 defined 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; positive infinity]
-
-or ::
-
-  (0; 0.000001], (0.000001; 0.000010], (0.000010; 0.000100], ..., (0.100000; 1.0]; (1.0; 10.0]...(1000000; positive infinity]
-
-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; positive infinity]
-
-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., don't 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 17 queries = 0.000094 seconds
-
-  * 4301 queries with 0.000010 < query execution time < = 0.000100 seconds; total execution time of the 4301 queries = 0.236555 seconds
-
-  * 1499 queries with 0.000100 < query execution time < = 0.001000 seconds; total execution time of the 1499 queries = 0.824450 seconds
-
-  * 14851 queries with 0.001000 < query execution time < = 0.010000 seconds; total execution time of the 14851 queries = 81.680502 seconds
-
-  * 8066 queries with 0.010000 < query execution time < = 0.100000 seconds; total execution time of the 8066 queries = 443.635693 seconds
-
-  * 1 query with 10.000000 < query execution time < = 100.0000 seconds; total execution time of the 1 query = 55.937094 seconds
-
-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
-  0.000100	         1	 0.000072
-  0.001000	         0	 0.000000
-  0.010000	         0	 0.000000
-  0.100000	         0	 0.000000
-  1.000000	         0	 0.000000
-  10.000000	         8	 47.268416
-  100.000000	         0	 0.000000
-  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
-
-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_count,
-  (SELECT COUNT(*)     FROM INFORMATION_SCHEMA.QUERY_RESPONSE_TIME as b WHERE b.count != 0) as not_zero_region_count,
-  (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 :variable:`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	 total
-  0.000001	         0	 0.000000
-  0.000010	         0	 0.000000
-  0.000100	         1	 0.000072
-  0.001000	         0	 0.000000
-  0.010000	         0	 0.000000
-  0.100000	         0	 0.000000
-  1.000000	         0	 0.000000
-  10.000000	         8	 47.268416
-  100.000000	         0	 0.000000
-  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
-
-**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 :table:`QUERY_RESPONSE_TIME` table
-
-  * Reads the value of :variable:`query_response_time_range_base` and uses it to set the range base for the table
-
-**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).
-
-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
-
-Version Specific Information
-============================
-
-  * 5.5.8-20.0:
-    Introduced variable variable:`have_response_time_distribution`.
-
-  * 5.5.8-20.0:
-    Introduced  variable variable:`query_response_time_stats`.
-
-System Variables
-================
-
-.. variable:: have_response_time_distribution
-
-     :version 5.5.8-20.0: Introduced.
-     :scope: Global
-     :dyn: No
-     :vartype: Boolean
-     :default: YES
-     :range: YES/NO
-
-Contains the value YES if the server you're running supports this feature; contains NO if the feature is not supported. It is enabled by default.
-
-
-.. variable::  query_response_time_range_base
-
-     :cli: Yes
-     :conf: Yes
-     :scope: Global
-     :dyn: Yes
-     :vartype: Numeric
-     :default: 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 5.5.8-20.0: Introduced.
-     :cli: Yes
-     :conf: Yes
-     :scope: Global
-     :dyn: Yes
-     :vartype: Boolean
-     :default: OFF
-     :range: ON/OFF
-
-This variable enables and disables collection of query times if the feature is available in the server that's running. If the value of variable :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 :variable:`enable_query_response_time_stats`.
-
-
-INFORMATION_SCHEMA Tables
-=========================
-
-.. table:: INFORMATION_SCHEMA.QUERY_RESPONSE_TIME
-
-   :column VARCHAR TIME: 
-   :column INT(11) COUNT: 
-   :column VARCHAR TOTAL:  
-
-Implementation Details
-======================
-
-Implementation details on this feature are provided here.
-
-Related Reading
-===============
-
-  * `Blueprint about Response Time Distribution <https://blueprints.launchpad.net/percona-server/+spec/response-time-distribution>`_

=== removed file 'doc/source/diagnostics/show_engines.rst'
--- doc/source/diagnostics/show_engines.rst	2013-03-05 12:46:43 +0000
+++ doc/source/diagnostics/show_engines.rst	1970-01-01 00:00:00 +0000
@@ -1,40 +0,0 @@
-.. _show_engines:
-
-======================
- Show Storage Engines
-======================
-
-This feature changes the comment field 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                                                        | Transactions | XA   | Savepoints |
-  +------------+---------+----------------------------------------------------------------+--------------+------+------------+
-  | InnoDB     | YES     | Supports transactions, row-level locking, and foreign keys     | YES          | YES  | YES        |
-  ...
-  +------------+---------+----------------------------------------------------------------+--------------+------+------------+
-
-After the Change: ::
-
-  mysql> show storage engines;
-  +------------+---------+----------------------------------------------------------------------------+--------------+------+------------+ 
-  | Engine     | Support | Comment                                                                    | Transactions |   XA | Savepoints |
-  +------------+---------+----------------------------------------------------------------------------+--------------+------+------------+
-  | InnoDB     | YES     | Percona-XtraDB, Supports transactions, row-level locking, and foreign keys |          YES | YES  | YES        |
-  ...
-  +------------+---------+----------------------------------------------------------------------------+--------------+------+------------+
-
-Version-Specific Information
-============================
-
-  * 5.5.8-20.0:
-    Full functionality available.
-
-Other Information
-=================
-
-  * Author / Origin:
-    Percona
-

=== removed file 'doc/source/diagnostics/slow_extended_55.rst'
--- doc/source/diagnostics/slow_extended_55.rst	2013-03-05 12:46:43 +0000
+++ doc/source/diagnostics/slow_extended_55.rst	1970-01-01 00:00:00 +0000
@@ -1,377 +0,0 @@
-.. _slow_extended_55:
-
-================
- 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 fine-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 Maatkit``s mk-query-digest tool to aggregate similar queries together and report on those that consume the most execution time.
-
-
-Version Specific Information
-============================
-
-  * 5.5.8-20.0:
-    Added values ``profiling`` and ``profiling_use_getrusage`` to variable log_slow_verbosity.
-
-  * 5.5.10-20.1:
-     * Renamed variable :variable:`slow_query_log_timestamp_always` to :variable:`slow_query_log_timestamp_always`.
-
-     * Renamed variable :variable:`slow_query_log_microseconds_timestamp` to :variable:`slow_query_log_timestamp_precision`.
-
-     * Renamed variable :variable:`use_global_log_slow_control` to :variable:`slow_query_log_use_global_control`.
-
-Other Information
-=================
-
-  * Author / Origin:
-    Maciej Dobrzanski, Percona
-
-System Variables
-================
-
-.. variable:: log_slow_filter
-
-     :cli: Yes
-     :conf: Yes
-     :scope: Global, Session
-     :dyn: Yes
-
-Filters the slow log by the query's 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 query``s temporary table was stored on disk.
-
-  * ``filesort``:
-    The query used a filesort.
-
-  * ``filesort_on_disk``:
-    The filesort was performed on disk.
-
-Values are OR'ed together. If the string is empty, then the filter 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 filter.
-
-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
-
-     :cli: Yes
-     :conf: Yes
-     :scope: Global
-     :dyn: Yes
-     :vartype: Enumerated
-     :default: ``session``
-     :range: ``session``, ``query``
-
-Specifies semantic of :variable:`log_slow_rate_limit` - ``session`` or ``query``.
-
-.. variable:: log_slow_rate_limit
-
-     :cli: Yes
-     :conf: Yes
-     :scope: Global, session
-     :dyn: Yes
-
-Behavior of this variable depends from :variable:`log_slow_rate_type`.
-
-Specifies 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 :variable:`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 file to grow large.
- * When :variable:`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 :variable:`log_slow_rate_limit` in ``session`` mode, you should reconnect for get effect.
-
- * When :variable:`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 percona of queryies will logged.
-
-Note that every query has global unique ``query_id`` and every connection can has it own (session) :variable:``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 flexible setup logging behavior.
-
-For example, if you set the value to 100, then one percent of ``sessions/queries`` will be logged.
-
-.. variable:: log_slow_slave_statements
-
-     :cli: Yes
-     :conf: Yes
-     :scope: Global, session
-     :dyn: Yes (in 5.1 releases only)
-
-Specifies that queries replayed by the slave SQL thread on a |MySQL| slave will be logged. The standard |MySQL| server will not log any queries executed by the slave``s SQL thread.
-
-To start the logging from the slave thread, you should change the global value: set global :variable:`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: set global :variable:`log_slow_slave_statements` ``=OFF``; the logging stops immediately.
-
-
-.. variable:: log_slow_sp_statements
-
-     :cli: Yes
-     :conf: Yes
-     :scope: Global
-     :dyn: Yes
-     :vartype: Boolean
-     :default: TRUE
-     :range: TRUE/FALSE
-
-If ``TRUE``, statements executed by stored procedures are logged to the slow if it is open.
-
-.. variable:: log_slow_verbosity
-
-     :cli: Yes
-     :conf: Yes
-     :scope: Global, session
-     :dyn: Yes
-     :version 5.5.8-20.0: Added ``profiling`` and ``profiling_use_getrusage``
-
-Specifies 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 (mandatory).
-
-  * ``query_plan``:
-    Log information about the query``s execution plan (optional).
-
-  * ``innodb``:
-    Log |InnoDB| statistics (optional).
-
-  * ``full``:
-    Equivalent to all other values OR``ed together.
-
-  * ``profiling``:
-    Enables profiling of all queries in all connections.
-
-  * ``profiling_use_getrusage``:
-    Enables usage of the getrusage function.
-
-Values are OR``ed together.
-
-For example, to enable microsecond query timing and |InnoDB| statistics, set this option to ``microtime,innodb``. To turn all options on, set the option to ``full``.
-
-.. variable:: long_query_time
-
-     :cli: Yes
-     :conf: Yes
-     :scope: Global, session
-     :dyn: Yes
-
-Specifies the time threshold for filtering queries out of the slow query log. The unit of time is seconds. This option has the same meaning as in a standard |MySQL| server, with the following changes:
-
-The option accepts fractional values. If set to 0.5, for example, queries longer than 1/2 second will be logged.
-
-If the value is set to 0, then all queries are logged. This is different from the standard |MySQL| build, where a value of 0 disables logging.
-Before version 1.01 of this feature, the value was an integer, and the unit of time was microseconds, not seconds.
-
-.. variable:: slow_query_log_timestamp_always
-
-     :cli: Yes
-     :conf: Yes
-     :scope: Global
-     :dyn: Yes
-     :vartype: Boolean
-     :default: FALSE
-     :range: TRUE/FALSE
-     :version 5.5.10-20.1: Introduced  (renamed from :variable:`log_slow_timestamp_every`)
-
-If ``TRUE``, a timestamp is printed on every slow log record. Multiple records may have the same time.
-
-**NOTE:** This variable has been renamed from log_slow_timestamp_every since 5.5.10-20.1.
-
-.. variable:: slow_query_log_timestamp_precision
-
-     :version 5.5.10-20.1: Introduced (renamed from ``slow_query_log_microseconds_timestamp``)
-     :cli: Yes
-     :conf: Yes
-     :scope: Global
-     :dyn: Yes
-     :vartype: Enumerated
-     :default: ``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 :variable:`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]
-
-**NOTE:** This variable has been renamed from :variable:`slow_query_log_microseconds_timestamp` since 5.5.10-20.1.
-
-
-.. variable:: slow_query_log_use_global_control
-
-     :cli: Yes
-     :conf: Yes
-     :scope: Global
-     :dyn: Yes
-     :default: None
-     :version 5.5.10-20.1: Introduced (renamed from :variable:`log_slow_timestamp_every`)
-
-Specifies which variables have global scope instead of local. Value is a “flag” variable - you can specify multiple values separated by commas
-
-  * ``none``:
-    All variables use local scope
-
-  * ``log_slow_filter``:
-    Global variable :variable:`log_slow_filter` has effect (instead of local)
-
-  * ``log_slow_rate_limit``:
-    Global variable :variable:`log_slow_rate_limit` has effect (instead of local)
-
-  * ``log_slow_verbosity``:
-    Global variable :variable:`log_slow_verbosity` has effect (instead of local)
-
-  * ``long_query_time``:
-    Global variable :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 :variable:`log_slow_timestamp_every` since 5.5.10-20.1.
-
-
-Other Information
-=================
-
-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
-  # QC_Hit: No  Full_scan: No  Full_join: No  Tmp_table: Yes  Disk_tmp_table: No
-  # Filesort: Yes  Disk_filesort: No  Merge_passes: 0
-  # Query_time: 0.000659  Lock_time: 0.000070  Rows_sent: 0  Rows_examined: 30  Rows_affected: 0  Rows_read: 30
-  #   innodb_IO_r_ops: 1  innodb_IO_r_bytes: 16384  innodb_IO_r_wait: 0.028487
-  #   innodb_rec_lock_wait: 0.000000  innodb_queue_wait: 0.000000
-  #   innodb_pages_distinct: 5
-  select count(distinct author_id) from art87.article87 force index (forum_id) where forum_id = 240215 and thread_id = ``710575`` 
-
-Another example (:variable:`log_slow_verbosity` ``=profiling``): ::
-
-  # Query_time: 4.555235  Lock_time: 0.000000  Rows_sent: 1  Rows_examined: 0  Rows_affected: 0  Rows_read: 1
-  # Profile_starting: 4.554799 Profile_starting_cpu: 0.000000 Profile_checking_permissions: 0.000095 Profile_checking_permissions_cpu: 0.000000 Profile_Opening_tables: 0.000088 Profile_Opening_tables_cpu: 0.000000 Profile_init: 0.000056 Profile_init_cpu: 0.000000 Profile_optimizing: 0.000046 Profile_optimizing_cpu: 0.000000 Profile_executing: 0.000098 Profile_executing_cpu: 0.000000 Profile_end: 0.000049 Profile_end_cpu: 0.000000 Profile_query_end: 0.000045 Profile_query_end_cpu: 0.000000 Profile_freeing_items: 0.000084 Profile_freeing_items_cpu: 0.000000 Profile_logging_slow_query: 0.000045 Profile_logging_slow_query_cpu: 0.000000 
-  # Profile_total: 4.555405 Profile_total_cpu: 0.000000 
-  insert into teee4 select * from teee4 limit 10000000;
-
-Connection and Schema Identifier
---------------------------------
-
-Each slow log entry now contains a connection identifier, 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.000659  Lock_time: 0.000070  Rows_sent: 0  Rows_examined: 30  Rows_affected: 0  Rows_read: 30
-
-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
-
-  * ``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 file. ::
-
-  # QC_Hit: No  Full_scan: No  Full_join: No  Tmp_table: Yes  Disk_tmp_table: No
-  # Filesort: Yes  Disk_filesort: No  Merge_passes: 0
-
-The values and their meanings are documented with the :variable:`log_slow_filter` option.
-
-|InnoDB| Usage Information
---------------------------
-
-The final 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: 1  innodb_IO_r_bytes: 16384  innodb_IO_r_wait: 0.028487
-  # innodb_rec_lock_wait: 0.000000  innodb_queue_wait: 0.000000
-  # innodb_pages_distinct: 5
-
-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.
-
-Related Reading
-===============
-
-  * http://www.mysqlperformanceblog.com/2009/02/10/impact-of-logging-on-mysql%E2%80%99s-performance/
-
-  * `log_slow_filter Usage <http://www.mysqlperformanceblog.com/2008/09/22/finding-what-created_tmp_disk_tables-with-log_slow_filter/>`_
-
-  * `Blueprint in Launchpad <https://blueprints.launchpad.net/percona-server/+spec/microseconds-in-query-log>`_

=== removed file 'doc/source/diagnostics/user_stats.rst'
--- doc/source/diagnostics/user_stats.rst	2013-03-05 12:46:43 +0000
+++ doc/source/diagnostics/user_stats.rst	1970-01-01 00:00:00 +0000
@@ -1,242 +0,0 @@
-.. _user_stats:
-
-=================
- 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.
-
-
-Version Specific Information
-============================
-
-  * :rn:`5.5.10-20.1`:
-     Renamed variable :variable:`userstat_running` to :variable:`userstat`.
-
-Other Information
-=================
-
-  * Author/Origin:
-     *Google*; *Percona* added the ``INFORMATION_SCHEMA`` tables and the :variable:`userstat_running` variable.
-
-System Variables
-================
-
-.. variable:: userstat_running
-
-     :version 5.5.10-20.1: Renamed to :variable:`userstat`
-     :cli: Yes
-     :conf: Yes
-     :scope: Global
-     :dyn: Yes
-     :vartype: BOOLEAN
-     :default: 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 doesn't cause any extra load on the server unless desired.
-
-
-INFORMATION_SCHEMA Tables
-=========================
-
-.. table:: INFORMATION_SCHEMA.CLIENT_STATISTICS
-
-  :column CLIENT: The IP address or hostname from which the connection originated.
-  :column TOTAL_CONNECTIONS: The number of connections created for this client.
-  :column CONCURRENT_CONNECTIONS: The number of concurrent connections for this client.
-  :column CONNECTED_TIME: The cumulative number of seconds elapsed while there were connections from this client.
-  :column BUSY_TIME: The cumulative number of seconds there was activity on connections from this client.
-  :column CPU_TIME: The cumulative CPU time elapsed, in seconds, while servicing this client``s connections.
-  :column BYTES_RECEIVED: The number of bytes received from this client's connections.
-  :column BYTES_SENT: The number of bytes sent to this client's connections.
-  :column BINLOG_BYTES_WRITTEN:	The number of bytes written to the binary log from this client's connections.
-  :column ROWS_FETCHED: The number of rows fetched by this client's connections.
-  :column ROWS_UPDATED: The number of rows updated by this client's connections.
-  :column TABLE_ROWS_READ: The number of rows read from tables by this client's connections. (It may be different from ``ROWS_FETCHED``.)
-  :column SELECT_COMMANDS: The number of ``SELECT`` commands executed from this client's connections.
-  :column UPDATE_COMMANDS: The number of ``UPDATE`` commands executed from this client's connections.
-  :column OTHER_COMMANDS: The number of other commands executed from this client's connections.
-  :column COMMIT_TRANSACTIONS: The number of ``COMMIT`` commands issued by this client's connections.
-  :column ROLLBACK_TRANSACTIONS: The number of ``ROLLBACK`` commands issued by this client's connections.
-  :column DENIED_CONNECTIONS: The number of connections denied to this client.
-  :column LOST_CONNECTIONS: The number of this client's connections that were terminated uncleanly.
-  :column ACCESS_DENIED: The number of times this client's connections issued commands that were denied.
-  :column EMPTY_QUERIES: The number of times this client's connections sent empty queries to the server.
-
-This table holds statistics about client connections. The Percona version of the feature restricts this table's 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
-
-
-.. table:: INFORMATION_SCHEMA.INDEX_STATISTICS
-
-  :column TABLE_SCHEMA: The schema (database) name.
-  :column TABLE_NAME: The table name.
-  :column INDEX_NAME: The index name (as visible in ``SHOW CREATE TABLE``).
-  :column 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 difficult or impossible previously. For example, you can use it to find unused indexes and generate DROP commands to remove them.
-
-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 |
-  +--------------+-----------------------+--------------------+-----------+
-
-
-
-.. table:: INFORMATION_SCHEMA.TABLE_STATISTICS
-
-  :column TABLE_SCHEMA: The schema (database) name.
-  :column TABLE_NAME: The table name.
-  :column ROWS_READ: The number of rows read from the table.
-  :column ROWS_CHANGED: The number of rows changed in the table.
-  :column 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 | 
-  +--------------+-------------------------------+-----------+--------------+------------------------+
-
-
-.. table:: INFORMATION_SCHEMA.THREAD_STATISTICS
-
-  :column THREAD_ID: int(21)
-  :column TOTAL_CONNECTIONS: int(21)
-  :column CONCURRENT_CONNECTIONS: int(21)
-  :column CONNECTED_TIME: int(21)
-  :column BUSY_TIME: int(21)
-  :column CPU_TIME: int(21)
-  :column BYTES_RECEIVED: int(21)
-  :column BYTES_SENT: int(21)
-  :column BINLOG_BYTES_WRITTEN: int(21)
-  :column ROWS_FETCHED: int(21)
-  :column ROWS_UPDATED: int(21)
-  :column TABLE_ROWS_READ: int(21)
-  :column SELECT_COMMANDS: int(21)
-  :column UPDATE_COMMANDS: int(21)
-  :column OTHER_COMMANDS: int(21)
-  :column COMMIT_TRANSACTIONS: int(21)
-  :column ROLLBACK_TRANSACTIONS: int(21)
-  :column DENIED_CONNECTIONS: int(21)
-  :column LOST_CONNECTIONS: int(21)
-  :column ACCESS_DENIED: int(21)
-  :column EMPTY_QUERIES: int(21)
-
-.. table:: INFORMATION_SCHEMA.USER_STATISTICS
-
-  :column USER: The username. The value ``#mysql_system_user#`` appears when there is no username (such as for the slave SQL thread).
-  :column TOTAL_CONNECTIONS: The number of connections created for this user.
-  :column CONCURRENT_CONNECTIONS: The number of concurrent connections for this user.
-  :column CONNECTED_TIME: The cumulative number of seconds elapsed while there were connections from this user.
-  :column BUSY_TIME: The cumulative number of seconds there was activity on connections from this user.
-  :column CPU_TIME: The cumulative CPU time elapsed, in seconds, while servicing this user's connections.
-  :column BYTES_RECEIVED: The number of bytes received from this user's connections.
-  :column BYTES_SENT: The number of bytes sent to this user's connections.
-  :column BINLOG_BYTES_WRITTEN: The number of bytes written to the binary log from this user's connections.
-  :column ROWS_FETCHED: The number of rows fetched by this user's connections.
-  :column ROWS_UPDATED: The number of rows updated by this user's connections.
-  :column TABLE_ROWS_READ: The number of rows read from tables by this user's connections. (It may be different from ``ROWS_FETCHED``.)
-  :column SELECT_COMMANDS: The number of ``SELECT`` commands executed from this user's connections.
-  :column UPDATE_COMMANDS: The number of ``UPDATE`` commands executed from this user's connections.
-  :column OTHER_COMMANDS: The number of other commands executed from this user's connections.
-  :column COMMIT_TRANSACTIONS: The number of ``COMMIT`` commands issued by this user's connections.
-  :column ROLLBACK_TRANSACTIONS: The number of ``ROLLBACK`` commands issued by this user's connections.
-  :column DENIED_CONNECTIONS: The number of connections denied to this user.
-  :column LOST_CONNECTIONS: The number of this user's connections that were terminated uncleanly.
-  :column ACCESS_DENIED: The number of times this user's connections issued commands that were denied.
-  :column EMPTY_QUERIES: The number of times this user's connections sent empty queries to the server.
-
-This table contains information about user activity. The |Percona| version of the patch restricts this table's 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 find 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
-
-Commands Provided
-=================
-
-  * ``FLUSH CLIENT_STATISTICS``
-
-  * ``FLUSH INDEX_STATISTICS``
-
-  * ``FLUSH TABLE_STATISTICS``
-
-  * ``FLUSH THREAD_STATISTICS``
-
-  * ``FLUSH USER_STATISTICS``
-
-These commands discard the specified 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.
-
-

=== removed file 'doc/source/flexibility/buff_read_ahead_area.rst'
--- doc/source/flexibility/buff_read_ahead_area.rst	2013-03-05 12:46:43 +0000
+++ doc/source/flexibility/buff_read_ahead_area.rst	1970-01-01 00:00:00 +0000
@@ -1,36 +0,0 @@
-.. _buff_read_ahead_area:
-
-====================================
- 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 :variable:`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 fixed 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
-
-
-Version Specific Information
-============================
-
-  * :rn:`5.5.8-20.0` :
-    Full functionality available.
-
-Other Information
-=================
-
-  * Author/Origin:
-    Facebook
-
-  * Bugs fixed:
-    :bug:`606811`
-
-Other Reading
-=============
-
-  * `BUF_READ_AHEAD_AREA Bottleneck <http://www.facebook.com/notes/|MySQL|facebook/using-pmp-to-double-|MySQL|-throughput-part-2/405092575932>`_

=== removed file 'doc/source/flexibility/improved_memory_engine.rst'
--- doc/source/flexibility/improved_memory_engine.rst	2013-03-05 12:46:43 +0000
+++ doc/source/flexibility/improved_memory_engine.rst	1970-01-01 00:00:00 +0000
@@ -1,190 +0,0 @@
-.. _improved_memory_engine:
-
-====================================
- ``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 fixed 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`` field in a ``CHAR`` field in practice and makes impossible to have a ``TEXT`` or ``BLOB`` field 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`` fields in ``MEMORY`` tables.
-
-This implementation is based on the *Dynamic Row Format* (``DFR``) introduced by the `mysql-heap-dynamic-rows <http://code.google.com/p/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`` fields and real ``VARCHAR`` and ``VARBINARY``.
-
-Unlike the fixed implementation, each column value in ``DRF`` only uses as much space as required. This is, for variable-length 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.
-
-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 configured when creating a table (see below).
-
-This ``DFR`` implementation has two caveats regarding to ordering and indexes.
-
-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 specific order without an ``ORDER BY`` clause may deliver unexpected results. A specific 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>' can't be used in key specification with the used table type.
-
-Restrictions
-============
-
-For performance reasons, a mixed solution is implemented: the fixed 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 fixed format at the first block of the row, then the following columns are handled with ``DRF``.
-
-This sets two restrictions to tables:
-
-  * the order of the fields and therefore,
-
-  * the minimum size of the block used in the table.
-
-Ordering of Columns
--------------------
-
-The columns used in fixed format must be defined 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 fields and they will be treated as fixed.
-
-Minimum Block Size
-------------------
-
-The block size has to be big enough to store all fixed-length information in the first block. If not, the ``CREATE TABLE`` or ``ALTER TABLE`` statements will fail (see below).
-
-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 beneficial.
-
-Implicit Request
-----------------
-
-The implicit request by the user is taken when there is at least one ``BLOB`` or ``TEXT`` column in the table definition. 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 specified 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 specified 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 definition, the *Improved MEMORY Engine* will check if using the dynamic format provides any space saving benefits as compared to the fixed one:
-
-  * if the fixed row length is less than the dynamic block size (plus the dynamic row overhead - platform dependent) **OR**
-
-  * there isn't any variable-length columns in the table or ``VARCHAR`` fields are declared with length 31 or less,
-
-the engine will revert to the fixed format as it is more space efficient in such case. The row format being used by the engine can be checked using ``SHOW TABLE STATUS``.
-
-Examples
-========
-
-On a 32-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	Rows	Avg_row_length	Data_length	Max_data_length	Index_length	Data_free	Auto_increment	Create_time	Update_time	Check_time	Collation	Checksum	Create_options	Comment
-  t1	MEMORY	10	Dynamic	0	X	0	X	0	0	NULL	NULL	NULL	NULL	latin1_swedish_ci	NULL	row_format=DYNAMIC KEY_BLOCK_SIZE=124	
-
-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	Rows	Avg_row_length	Data_length	Max_data_length	Index_length	Data_free	Auto_increment	Create_time	Update_time	Check_time	Collation	Checksum	Create_options	Comment	
-  t1	MEMORY	10	Fixed	0	X	0	X	0	0	NULL	NULL	NULL	NULL	latin1_swedish_ci	NULL	row_format=DYNAMIC KEY_BLOCK_SIZE=124	
-
-Implementation Details
-======================
-
-|MySQL| *MEMORY* tables keep data in arrays of fixed-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 fixed-size mode, one record is always represented as one chunk. The index structures would always point to the first 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 fixed-size format. You should always put such columns at the end of the table definition 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, fixed-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.
-
-The allocation and contents of the actual chunks varies between fixed and variable-size modes:
-
-  * Format of a fixed-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 field (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 table's ``key_block_size``
-
-    * ``uchar*`` 
-
-      * Pointer to the next chunk in this chunkset, or NULL for the last chunk
-
-    * ``uchar``
-
-      * Status field (1 means “first”, 0 means “deleted”, 2 means “linked”)
-
-Total chunk length is always aligned to the next ``sizeof(uchar*)``.
-
-See Also
-========
-
-  * `Dynamic row format for MEMORY tables <http://www.mysqlperformanceblog.com/2011/09/06/dynamic-row-format-for-memory-tables/>`_

=== removed file 'doc/source/flexibility/innodb_fast_shutdown.rst'
--- doc/source/flexibility/innodb_fast_shutdown.rst	2013-03-05 12:46:43 +0000
+++ doc/source/flexibility/innodb_fast_shutdown.rst	1970-01-01 00:00:00 +0000
@@ -1,36 +0,0 @@
-.. _innodb_fast_shutdown:
-
-===============
- 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 significant 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 modifies 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.
-
-Version Specific Information
-============================
-
-  * 5.5.8-20
-    Full functionality available.
-
-Other Information
-=================
-
-  * Author / Origin:
-    Kristian Nielsen
-
-  * Bugs fixed:
-    :bug:`643463`
-
-Other reading
-=============
-
-  * `How to decrease InnoDB shutdown times <http://www.mysqlperformanceblog.com/2009/04/15/how-to-decrease-innodb-shutdown-times/>`_
-
-  * `How long InnoDB shutdown may take <http://www.mysqlperformanceblog.com/2010/09/02/how-long-innodb-shutdown-may-take/>`_
-

=== removed file 'doc/source/flexibility/innodb_files_extend.rst'
--- doc/source/flexibility/innodb_files_extend.rst	2013-03-05 12:46:43 +0000
+++ doc/source/flexibility/innodb_files_extend.rst	1970-01-01 00:00:00 +0000
@@ -1,25 +0,0 @@
-.. _innodb_files_extend:
-
-================================
- Support of Multiple Page Sizes
-================================
-
-In standard |InnoDB|, the size of the read-ahead area is computed dynamically, but it always has the same value. This change makes the size fixed, avoiding unuseful computations.
-
-This feature adds a new system variable for setting it.
-
-
-System Variables
-================
-
-.. variable:: innodb_page_size
-
-     :cli: Yes
-     :conf: Yes
-     :scope:
-     :dyn: No
-     :vartype: ULONG
-     :default: 1 « 14
-     :range: 1 « 12 to 1 « ``UNIV_PAGE_SIZE_SHIFT_MAX``
-
-**EXPERIMENTAL**: The universal page size of the database. Changing for an existing database is not supported. Use at your own risk!

=== removed file 'doc/source/flexibility/log_warnings_suppress.rst'
--- doc/source/flexibility/log_warnings_suppress.rst	2013-03-05 12:46:43 +0000
+++ doc/source/flexibility/log_warnings_suppress.rst	1970-01-01 00:00:00 +0000
@@ -1,49 +0,0 @@
-.. _log_warning_suppress:
-
-===========================
- Suppress Warning Messages
-===========================
-
-This feature is intended to provide a general mechanism (using ``log_warnings_silence``) to disable certain warning messages to the log file. Currently, it is only implemented for disabling message #1592 warnings.
-
-
-Version Specific Information
-============================
-
-  * 5.5.8-20.0:
-    System variable :variable:`log_warnings_silence` introduced.
-
-  * 5.5.10-20.1:
-    Renamed variable :variable:`log_warnings_silence` to :variable:`log_warnings_suppress`.
-
-.. variable:: log_warnings_suppress
-
-     :version 5.5.8-20.0: Introduced.
-     :version 5.5.10-20.1: Renamed.
-     :cli: Yes
-     :conf: Yes
-     :scope: Global
-     :dyn: Yes
-     :vartype: SET
-     :default: ``(empty string)``
-     :range: ``(empty string)``, ``1592``
-
-This variable was added in beta release ``5.5.8-20.0`` as :variable:`log_warnings_silence` and renamed in release 5.5.10-20.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.
-
-
-Related Reading
-===============
-
-  * `MySQL bug 42851 <http://bugs.mysql.com/bug.php?id=42851>`_
-
-  * `MySQL InnoDB replication <http://dev.mysql.com/doc/refman/5.1/en/innodb-and-mysql-replication.html>`_
-
-  * `InnoDB Startup Options and System Variables <http://dev.mysql.com/doc/refman/5.1/en/innodb-parameters.html>`_
-
-  * `InnoDB Error Handling <http://dev.mysql.com/doc/refman/5.1/en/innodb-error-handling.html>`_

=== removed file 'doc/source/flexibility/mysql_remove_eol_carret.rst'
--- doc/source/flexibility/mysql_remove_eol_carret.rst	2013-03-05 12:46:43 +0000
+++ doc/source/flexibility/mysql_remove_eol_carret.rst	1970-01-01 00:00:00 +0000
@@ -1,31 +0,0 @@
-.. _mysql_remove_eol_carret:
-
-=============================
- Handle ``BLOB`` End of Line
-=============================
-
-At some point in the past, the |MySQL| command line client was modified to remove ``\r`` before ``\n`` in its input.
-
-This caused problems in some workloads, specifically when loading ``BLOB`` fields containing ``\r`` characters. |Percona Server| solves this by implementing a new command line client option, :variable:`no-remove-eol-carret`.
-
-When the :variable:`no-remove-eol-carret` option is specified, ``\r`` before ``\n`` is not removed.
-
-
-Version Specific Information
-============================
-
-  * 5.5.8-20.0:
-    Full functionality.
-
-Client Command Line Parameter
-=============================
-
-.. variable:: no-remove-eol-carret
-
-     :cli: Yes
-     :conf: Yes
-     :scope: Local
-     :dyn: No
-     :vartype: Boolean
-     :default: Off
-     :range: On/Off

=== modified file 'doc/source/index.rst'
--- doc/source/index.rst	2013-02-08 16:56:30 +0000
+++ doc/source/index.rst	2013-03-08 07:34:35 +0000
@@ -9,12 +9,9 @@
  Percona Server 5.6 - Documentation
 ===================================
 
-WARNING: Alpha quality software ahead
-=====================================
-Please note: |Percona Server| 5.6 is ALPHA quality software. It should *NOT* be used in production environments. This documentation may be out of date for Percona Server 5.6 before the final release, please check the release notes closely.
+.. warning::
 
-Introduction
-============
+ Please note: |Percona Server| 5.6 is ALPHA quality software. It should *NOT* be used in production environments.
 
 |Percona Server| is an enhanced drop-in replacement for |MySQL|. With |Percona Server|,
 
@@ -54,20 +51,6 @@
    installation
    upgrading_guide_55_56
 
-
-Scalability Improvements
-========================
-
-.. toctree::
-   :maxdepth: 1
-   :glob:
-
-   scalability/innodb_split_buf_pool_mutex
-   scalability/innodb_insert_buffer
-   scalability/innodb_expand_undo_slots
-   scalability/innodb_adaptive_hash_index_partitions
-   scalability/innodb_extra_rseg
-
 Performance Improvements
 ========================
 
@@ -75,13 +58,7 @@
    :maxdepth: 1
    :glob:
 
-   performance/innodb_lazy_drop_table
-   performance/innodb_doublewrite_path
-   performance/query_cache_enhance
-   performance/innodb_fast_checksum
-   performance/remove_fcntl_excessive_calls
-   performance/innodb_opt_lru_count
-   performance/innodb_thread_concurrency_timer_based
+   performance/threadpool
 
 Flexibility Improvements
 ========================
@@ -90,12 +67,6 @@
    :maxdepth: 1
    :glob:
 
-   flexibility/innodb_files_extend
-   flexibility/log_warnings_suppress
-   flexibility/mysql_remove_eol_carret
-   flexibility/buff_read_ahead_area
-   flexibility/innodb_fast_shutdown
-   flexibility/improved_memory_engine
    flexibility/mysqldump_ignore_create_error
 
 Reliability Improvements
@@ -105,10 +76,7 @@
    :maxdepth: 1
    :glob:
 
-   reliability/log_connection_error
-   reliability/error_pad
    reliability/innodb_corrupt_table_action
-   reliability/show_slave_status_nolock
 
 Management Improvements
 =======================
@@ -117,11 +85,7 @@
    :maxdepth: 1
    :glob:
 
-   management/innodb_recovery_patches
-   management/sql_no_fcache
-   management/udf_maatkit
-   management/innodb_fake_changes
-   management/innodb_kill_idle_trx
+   management/innodb_expanded_fast_index_creation
 
 Diagnostics Improvements
 ========================
@@ -131,14 +95,6 @@
    :glob:
 
    diagnostics/index_info_schema_tables
-   diagnostics/innodb_stats
-   diagnostics/user_stats
-   diagnostics/slow_extended_55
-   diagnostics/innodb_show_status
-   diagnostics/innodb_deadlock_count
-   diagnostics/mysql_syslog
-   diagnostics/response_time_distribution
-   diagnostics/show_engines
    diagnostics/process_list
    diagnostics/misc_info_schema_tables
 
@@ -149,6 +105,7 @@
    :maxdepth: 1
    :glob:
 
+   upstream-bug-fixes
    development
    trademark-policy
    faq

=== added file 'doc/source/management/innodb_expanded_fast_index_creation.rst'
--- doc/source/management/innodb_expanded_fast_index_creation.rst	1970-01-01 00:00:00 +0000
+++ doc/source/management/innodb_expanded_fast_index_creation.rst	2013-03-08 07:34:35 +0000
@@ -0,0 +1,82 @@
+.. _expanded_innodb_fast_index_creation:
+
+============================
+Expanded Fast Index Creation
+============================
+
+Percona has implemented several changes related to |MySQL|'s 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.
+
+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, :variable:`expand_fast_index_creation` may also optimize index access for subsequent DML statements because using it results in much less fragmented indexes.
+
+
+:command:`mysqldump`
+--------------------
+
+A new option, ``--innodb-optimize-keys``, was implemented in :command:`mysqldump`. It changes the way |InnoDB| tables are dumped, so that secondary and foreign keys are created after loading the data, thus taking advantage of fast index creation. More specifically:
+
+  * ``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.
+
+``OPTIMIZE TABLE``
+------------------
+
+Internally, ``OPTIMIZE TABLE`` is mapped to ``ALTER TABLE ... ENGINE=innodb`` for |InnoDB| tables. As a consequence, it now also benefits from fast index creation, with the same restrictions as for ``ALTER TABLE``.
+
+
+Caveats
+-------
+
+|InnoDB| fast index creation uses temporary files in tmpdir for all indexes being created. So make sure you have enough tmpdir space when using :variable:`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 don’t want this optimization to be used for a specific table. 
+
+There’s 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 :variable:`expand_fast_index_creation` is OFF to avoid dropping keys that are part of a FOREIGN KEY constraint;
+
+  * :command:`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;
+
+  * :command:`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;
+
+  * :command:`mysqldump --innodb-optimize-keys` ignores the first UNIQUE index on non-nullable columns when the table has no ``PRIMARY KEY`` defined, because in this case |InnoDB| picks such an index as the clustered one.
+
+Version Specific Information
+============================
+
+  * :rn:`5.6.10-60.2`
+    Variable :variable:`expand_fast_index_creation` implemented.
+    This variable is controling whether fast index creation optimizations made by Perocna are used.
+
+System Variables
+================
+
+.. variable:: expand_fast_index_creation
+
+     :cli: Yes
+     :conf: No
+     :scope: Local/Global
+     :dyn: Yes
+     :vartype: Boolean
+     :default: OFF
+     :range: ON/OFF
+
+Other Reading
+=============
+
+  * `Improved InnoDB fast index creation <http://www.mysqlperformanceblog.com/2011/11/06/improved-innodb-fast-index-creation/>`_
+  * `Thinking about running OPTIMIZE on your InnoDB Table? Stop! <http://www.mysqlperformanceblog.com/2010/12/09/thinking-about-running-optimize-on-your-innodb-table-stop/>`_
+

=== removed file 'doc/source/management/innodb_fake_changes.rst'
--- doc/source/management/innodb_fake_changes.rst	2013-03-05 12:46:43 +0000
+++ doc/source/management/innodb_fake_changes.rst	1970-01-01 00:00:00 +0000
@@ -1,70 +0,0 @@
-.. _innodb_fake_changes_page:
-
-==========================
- 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.
-
-Caveats
-=======
-
-``DML`` operations **are supported**
-------------------------------------
-
-Currently only ``DML`` operations **are supported**, i.e. ``UPDATE``, ``INSERT``, ``REPLACE`` and ``DELETE`` (set deleted flag).
-
-``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.
-
-System Variables
-================
-
-.. variable:: innodb_fake_changes
-   
-   :version 5.5.16-22.0: Introduced
-   :scope: ``GLOBAL``
-   :type: ``BOOLEAN``
-   :dyn: ``YES``
-   :default: ``FALSE``
-
-   This variable enables the *Fake Changes* feature.
-
-Implementation Details
-======================
-
-  * 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 doesn't use the ``INSERT BUFFER``, it always causes the reading of the page actually for the option. ``DELETE`` also doesn't 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.
-
-Related Reading
-===============
-
-  * `on MySQL replication prefetching <http://dom.as/2011/12/03/replication-prefetching/>`_

=== removed file 'doc/source/management/innodb_kill_idle_trx.rst'
--- doc/source/management/innodb_kill_idle_trx.rst	2013-03-05 12:46:43 +0000
+++ doc/source/management/innodb_kill_idle_trx.rst	1970-01-01 00:00:00 +0000
@@ -1,25 +0,0 @@
-.. _innodb_kill_idle_trx:
-
-========================
- Kill Idle Transactions
-========================
-
-**NOTE:** This feature is currently considered **BETA** quality and may not yet be suitable for use in production environments.
-
-This feature limits the age of idle |XtraDB| transactions. If a transaction is idle for more seconds than the threshold specified, it will be killed. This prevents users from blocking purge by mistake.
-
-System Variables
-================
-
-.. variable:: innodb_kill_idle_transaction
-   
-   :version 5.5.16-22.0: Introduced
-   :scope: ``GLOBAL``
-   :config: ``YES``
-   :dyn: ``YES``
-   :vartype: ``INTEGER``
-   :default: 0 (disabled)
-   :unit: Seconds
-
-   To enable this feature, set this variable to the desired seconds wait until the transaction is killed.   
-

=== removed file 'doc/source/management/innodb_recovery_patches.rst'
--- doc/source/management/innodb_recovery_patches.rst	2013-03-05 12:46:43 +0000
+++ doc/source/management/innodb_recovery_patches.rst	1970-01-01 00:00:00 +0000
@@ -1,155 +0,0 @@
-.. _innodb_recovery_patches:
-
-================================
- Fast |InnoDB| Recovery Process
-================================
-
-This feature implements several changes related to the recovery process (bug fixes and speed changes). The |InnoDB| plugin subsequently implemented similar functionality, so the feature is currently unused. The system variable it implemented now does nothing and has been kept to maintain compatibility.
-
-  * ``recv_apply_hashed_log_recs()`` may hang up when meets DB_TABLESPACE_DELETED pages
-
-  * Insert buffer operation may destroy the page during its recovery process adjustment of smaller sleep period in loop
-
-  * ``buf_flush_insert_sorted_into_flush_list()`` change to don't sort (new variable ``innodb_fast_recovery`` (default false(~1.0.5), true(1.0.6~)) - if set true, sorting is enabled.)
-
-Output statistics of recovery process after it ::
-
-  -------------------
-  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: 128
-    Overwritten pages from doublewrite:  0
-    Recovered pages by io_thread:        9145
-    Recovered pages by main thread:      0
-    Parsed log records to apply:         2572491
-              Sum of the length:         71274689
-    Applied log records:                 2376356
-              Sum of the length:         68098300
-    Pages which are already new enough:  93
-    Oldest page's LSN:                   926917970
-    Newest page's LSN:                   1526578232
-
-
-Other Information
-=================
-
-Is the ``buf_flush_insert_sorted_into_flush_list()`` change correct?
---------------------------------------------------------------------
-
-|InnoDB| recovers the each pages not in order of the oldest un-flushed change``s :term:`LSN`. But flush_list must has un-flushed blocks in order of the :term:`LSN`. So, normal |InnoDB| does bubble sorting for each inserting block to ``flush_lsn`` … It is very expensive operation…
-
-Then, why the order must be kept?
----------------------------------
-
-|InnoDB| should get the LSN of the oldest un-flushed change in all blocks for checkpointing. It is the oldest un-flushed change's :term:`LSN` of the last block in the ``flush_list``.
-
-So, it may be correct that the last blocks' ``oldest_modification`` only have to keep the oldest ``oldest_modification`` in the buffer pool.
-
-This change is simple. If the new page's ``oldest_modification`` is... ::
-
-  [newer than any oldest_modification in flushlist]
-
-add to first of the ``flush_list`` ::
-
-  [older than any oldest_modification in flushlist]
-
-add to last of the ``flush_list`` ::
-
-  [else]
-
-overwrite ``oldest_modification`` by the oldest ``oldest_modification`` in ``flush_list``
-
-add to last of the ``flush_list``
-
-These operation should not break consistency of ``flush_list``. However, it may cause same-LSN-aged cluster of many pages and much flushing operation. But anyway, the most of the flushing should be done during the recovery process. ::
-
-  --- innodb_plugin-1.0.3_orig/buf/buf0flu.c      2009-07-07 18:03:24.000000000 +0900
-  +++ innodb_plugin-1.0.3_tmp/buf/buf0flu.c       2009-07-07 18:06:47.000000000 +0900
-  @@ -108,6 +108,17 @@
-          prev_b = NULL;
-          b = UT_LIST_GET_FIRST(buf_pool->flush_list);
-  
-  +       if (b == NULL || b->oldest_modification < block->page.oldest_modification) {
-  +               UT_LIST_ADD_FIRST(flush_list, buf_pool->flush_list, &block->page);
-  +      } else {
-  +               b = UT_LIST_GET_LAST(buf_pool->flush_list);
-  +               if (b->oldest_modification < block->page.oldest_modification) {
-  +                       /* align oldest_modification not to sort */
-  +                       block->page.oldest_modification = b->oldest_modification;
-  +               }
-  +               UT_LIST_ADD_LAST(flush_list, buf_pool->flush_list, &block->page);
-  +       }
-  +/*
-          while (b && b->oldest_modification > block->page.oldest_modification) {
-                  ut_ad(b->in_flush_list);
-                  prev_b = b;
-  @@ -120,6 +131,7 @@
-                  UT_LIST_INSERT_AFTER(flush_list, buf_pool->flush_list,
-                                       prev_b, &block->page);
-          }
-  +*/
-  
-   #if defined UNIV_DEBUG || defined UNIV_BUF_DEBUG
-          ut_a(buf_flush_validate_low());
-
-System Variables
-================
-
-One new system variable was introduced by this feature.
-
-
-.. variable:: innodb_fast_recovery
-
-     :cli: Yes
-     :conf: Yes
-     :scope: Global
-     :dyn: No
-     :vartype: BOOL
-     :default: FALSE
-     :range: TRUE/FALSE
-     :default: false(~1.0.5), true(1.0.6~)) - if set true, the change is enabled.
-
-.. variable:: innodb_recovery_stats
-
-     :cli: No
-     :conf:
-     :scope:
-     :dyn:
-     :vartype: BOOL
-     :default: FALSE
-     :range: TRUE/FALSE
-
-
-
-Other reading
-=============
-
-  * `How to estimate time it takes InnoDB to recover? <http://www.mysqlperformanceblog.com/2007/05/09/how-to-estimate-time-it-takes-innodb-to-recover/>`_
-
-  * `InnoDB recovery - is large buffer pool always better? <http://www.mysqlperformanceblog.com/2007/07/17/innodb-recovery-is-large-buffer-pool-always-better/>`_
-
-  * `What is the longest part of InnoDB recovery process? <http://www.mysqlperformanceblog.com/2007/12/20/what-is-the-longest-part-of-innodb-recovery-process/>`_
-
-  * `Improving InnoDB recovery time <http://www.mysqlperformanceblog.com/2009/07/07/improving-innodb-recovery-time/>`_
-
-  * `How long is recovery from 8G innodb_log_file <http://www.mysqlperformanceblog.com/2010/12/22/how-long-is-recovery-from-8g-innodb_log_file/>`_

=== removed file 'doc/source/management/sql_no_fcache.rst'
--- doc/source/management/sql_no_fcache.rst	2012-02-13 08:49:21 +0000
+++ doc/source/management/sql_no_fcache.rst	1970-01-01 00:00:00 +0000
@@ -1,34 +0,0 @@
-.. _sql_no_fcache:
-
-==============================
-Prevent Caching to FlashCache
-==============================
-
-*FlashCache* increases performance by caching data in SSDs. It works even better when only hot data is cached. This feature prevents unwanted blocks of data to be cached.
-
-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 :command:`mysqldump` binary was changed to use this option.
-
-
-Version-Specific Information
-============================
-
-  * 5.5.8-20.0:
-    Full functionality available.
-
-Other Information
-=================
-
-The feature is a port of the original *Facebook* change.
-
-Other reading
-=============
-
-  * `Releasing Flashcache <http://www.facebook.com/note.php?note_id=388112370932>`_
-
-  * `Level 2 Flash cache is there <http://www.mysqlperformanceblog.com/2010/04/27/level-2-flash-cache-is-there/>`_

=== removed file 'doc/source/management/udf_maatkit.rst'
--- doc/source/management/udf_maatkit.rst	2013-03-05 12:46:43 +0000
+++ doc/source/management/udf_maatkit.rst	1970-01-01 00:00:00 +0000
@@ -1,49 +0,0 @@
-.. _udf_maatkit:
-
-======================================
- *Percona Toolkit* and *Maatkit* UDFs
-======================================
-
-Three *Percona Toolkit* and *Maatkit* UDFs that provide faster checksums are provided:
-
-  * ``fnv_udf``
-
-  * ``fnv1a_udf``
-
-  * ``murmur_udf``
-
-Version Specific Information
-============================
-
-  * 5.1.53-12.4:
-    Began distributing ``fnv_udf``, ``fnv1a_udf``, and ``murmur_udf``.
-
-Other Information
-=================
-
-  * Author / Origin:
-    Baron Schwartz
-
-Installation
-============
-
-Use of the Percona Software Repositories simplifies the installation of *Percona Toolkit*. Once the repository has been set up on your system, *Percona Toolkit* can be installed by executing: ::
-
-  $ yum install percona-toolkit
-
-This will place the *Percona Toolkit* UDFs onto your system. However, they will not yet be installed into the |MySQL| server. To install one of the UDF``s into the server, execute one of the following commands, depending on which UDF you want to install: ::
-
-  $ mysql -e "CREATE FUNCTION fnv_64 RETURNS INTEGER SONAME ``fnv_udf.so``" 
-  $ mysql -e "CREATE FUNCTION fnv1a_64 RETURNS INTEGER SONAME ``fnv1a_udf.so``" 
-  $ mysql -e "CREATE FUNCTION murmur_hash RETURNS INTEGER SONAME ``murmur_udf.so``"
-
-Executing each of these commands will install its respective UDF into the server.
-
-If you have any difficulty, or require more detailed information, refer to the *Maatkit* `Installing UDFs <http://code.google.com/p/maatkit/wiki/InstallingUdfs>`_ documentation.
-
-
-Other Reading
-=============
-
-  * *Percona Toolkit* - http://www.percona.com/doc/percona-toolkit
-  * *Maatkit* - http://www.maatkit.org/

=== removed file 'doc/source/performance/innodb_doublewrite_path.rst'
--- doc/source/performance/innodb_doublewrite_path.rst	2012-02-13 08:49:21 +0000
+++ doc/source/performance/innodb_doublewrite_path.rst	1970-01-01 00:00:00 +0000
@@ -1,87 +0,0 @@
-.. _innodb_doublewrite_path:
-
-=========================================
- Configuration 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 files. 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.
-
-
-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 efficiently as possible. To have an overview of the different components see this post. Let``s 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 flushed to disk, |InnoDB| / |XtraDB| will flush 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| first writes the page in the doublewrite buffer and then to the data files.
-
-If a partial page write occurs in the data files, |InnoDB| / |XtraDB| will check on recovery if the checksum of the page in the data file 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. For further information on the doublewrite buffer, you can see this post.
-
-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 fit 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.
-
-What's 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 benefits 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.
-
-Version Specific Information
-============================
-
-  * 5.5.8-20.0	 
-    Full functionality available.
-
-
-System Variables
-================
-
-The following system variable was introduced.
-
-
-.. variable:: innodb_doublewrite_file
-
-   :cli: Yes
-   :conf: Yes
-   :scope: Global
-   :dyn: No
-   :vartype: STR
-   :def: NULL
-
-Use this option to create a dedicated tablespace for the doublewrite buffer.
-
-This option expects a filename which can be specified either with an absolute or a relative path. A relative path is relative to the data directory.
-
-
-Related Reading
-===============
-
-  * `XtraDB / InnoDB internals in drawing <http://www.mysqlperformanceblog.com/2010/04/26/xtradb-innodb-internals-in-drawing/>`_
-
-  * `InnoDB Double Write <http://www.mysqlperformanceblog.com/2006/08/04/innodb-double-write/>`_
-
-  * `SSD and HDD for InnoDB <http://yoshinorimatsunobu.blogspot.com/2009/05/tables-on-ssd-redobinlogsystem.html>`_

=== removed file 'doc/source/performance/innodb_fast_checksum.rst'
--- doc/source/performance/innodb_fast_checksum.rst	2013-03-05 12:46:43 +0000
+++ doc/source/performance/innodb_fast_checksum.rst	1970-01-01 00:00:00 +0000
@@ -1,28 +0,0 @@
-.. _innodb_fast_checksum_page:
-
-========================
- Fast |InnoDB| Checksum
-========================
-
-|InnoDB| writes a checksum at the end of each data page in order to detect data files corruption. However computing this checksum requires CPU cycles and in some circumstances this extra overhead can become significant.
-
-|XtraDB| can use a more CPU-efficient algorithm, based on 4-byte words, which can be beneficial 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 benefit 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 files created when ``innodb_fast_checksums`` was enabled. In this case ALTER TABLE won't work due to its implementation. 
-
-
-System Variables
-================
-
-.. variable:: innodb_fast_checksum
-
-   :cli: Yes
-   :conf: Yes
-   :scope: Global
-   :dyn: No
-   :vartype: BOOL
-   :default: 0
-
- 

=== removed file 'doc/source/performance/innodb_lazy_drop_table.rst'
--- doc/source/performance/innodb_lazy_drop_table.rst	2013-03-05 12:46:43 +0000
+++ doc/source/performance/innodb_lazy_drop_table.rst	1970-01-01 00:00:00 +0000
@@ -1,36 +0,0 @@
-.. _innodb_lazy_drop_table_page:
-
-======================
-Drop table performance
-======================
-
-When  *innodb_file_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".
-
-Version Specific Information
-============================
-
-  * 5.5.10-20.1 Feature added.
-
-System Variables
-================
-
-.. variable:: innodb_lazy_drop_table
-
-   :cli: Yes
-   :conf: Yes
-   :scope: Global       
-   :dyn: Yes   
-   :vartype: BOOL
-   :default: 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 find some free pages in the buffer pool.
-
-When this option is OFF, the usual behavior for dropping tables is in effect.
-
-Related Reading
-===============
-
-   * Drop table performance `blog post <http://www.mysqlperformanceblog.com/2011/04/20/drop-table-performance/>`_.

=== removed file 'doc/source/performance/innodb_opt_lru_count.rst'
--- doc/source/performance/innodb_opt_lru_count.rst	2013-03-05 12:46:43 +0000
+++ doc/source/performance/innodb_opt_lru_count.rst	1970-01-01 00:00:00 +0000
@@ -1,7 +0,0 @@
-.. _innodb_opt_lru_count:
-
-======================================
- 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.

=== removed file 'doc/source/performance/innodb_thread_concurrency_timer_based.rst'
--- doc/source/performance/innodb_thread_concurrency_timer_based.rst	2011-10-07 23:38:41 +0000
+++ doc/source/performance/innodb_thread_concurrency_timer_based.rst	1970-01-01 00:00:00 +0000
@@ -1,20 +0,0 @@
-.. _innodb_thread_concurrency_timer_based_page:
-
-=============================================
- |InnoDB| timer-based Concurrency Throttling
-=============================================
-
-System Variables
-================
-
-.. variable:: innodb_thread_concurrency_timer_based
-
-   :cli: Yes
-   :conf: Yes
-   :scope:  	 
-   :dyn:	
-   :vartype: BOOL
-   :default: FALSE
-   :range: TRUE/FALSE
-
-Use |InnoDB| timer based concurrency throttling.

=== removed file 'doc/source/performance/query_cache_enhance.rst'
--- doc/source/performance/query_cache_enhance.rst	2013-03-05 12:46:43 +0000
+++ doc/source/performance/query_cache_enhance.rst	1970-01-01 00:00:00 +0000
@@ -1,123 +0,0 @@
-.. _query_cache_enhance:
-
-==========================
- 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
-
-Disabling the cache completely
-==============================
-
-This feature allows the user to completely disable use of the query cache. When the server is compiled with the query cache enabled, the query cache is locked during use by the query cache mutex. This lock can cause performance to decrease in some situations. By disabling use of the query cache altogether when the server is started, any possibility of locking it is eliminated, and performance may be improved.
-
-The query cache can now be disabled at server startup or in an option file by: ::
-
-  --query_cache_type=0
-
-The default is 1 (query cache enabled).
-
-**Note:** This variable already exists in standard |MySQL|, but when setting query_cache_type=0, the query cache mutex will still be in used. Setting query_cache_type=0 in |Percona Server| ensures that both the cache is disabled and the mutex is not used.
-
-If query caching is off and a user tries to turn it on from within a session, the following error will be reported: ::
-
-  SET GLOBAL query_cache_type=ON;
-  ERROR 1651(HY000): Query cache is disabled; restart the server with query_cache_type=1 to enable it
-
-**Note:** This variable is implemented in standard |MySQL| from version 5.5.0.
-
-
-Diagnosing contention more easily
-=================================
-
-This features provides a new thread state - ``Waiting on query cache mutex``. It has always been difficult 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            db      Command Time    State                          Info
-  2       root    localhost       test    Sleep   2       NULL
-  3       root    localhost       test    Query   2       Waiting on query cache mutex  SELECT number from t where id > 0;
-  4       root    localhost       test    Query   1       Waiting on query cache mutex   SELECT number from t where id > 0;
-  5       root    localhost       test    Query   0       NULL
-
-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 first one and will serve the second one directly from the query cache.
-
-
-.. Version Specific Information
-.. ----------------------------
-
-.. Disabling the query cache completely
-
-..  Percona Server Version	 Comments
-.. 5.1.49-12.0	 Full functionality available.
-.. Diagnosing contention more easily
-
-..  Percona Server Version	 Comments
-.. 5.1.49-12.0	 Full functionality available.
-.. Ignoring comments
-
-..  Percona Server Version	 Comments
-.. 5.1.47-11.0	 Critical bug (see MySQL bug 55032). Release was recalled.
-.. 5.1.47-11.1	 Fixed critical bug from previous release. MySQL bug 55032 actual. Bug b603618 actual. Bug 603619 actual.
-.. 5.1.47-11.2	 Full functionality available.
-.. 5.1.48-12.0	 Full functionality available.
-
-.. Other Information
-
-.. Disabling the query cache completely
-
-.. Author/Origin	 Percona
-.. Bugs fixed	LP bug 609027, MySQL bug 38551
-.. Diagnosing contention more easily
-
-.. Author/Origin	 Percona
-.. Bugs fixed	LP bug589484
-
-System Variables
-================
-
-.. variable:: query_cache_strip_comments
-
-   :cli: Yes
-   :conf: Yes
-   :scope: Global
-   :dyn: Yes
-   :vartype: Boolean
-   :default: Off
-
-
-Makes the server ignore comments when checking for a query cache hit.
-
-Other Reading
--------------
-
-  * `MySQL general thread states <http://dev.mysql.com/doc/refman/5.1/en/general-thread-states.html>`_
-
-  * `RAII <http://en.wikibooks.org/wiki/More_C%2B%2B_Idioms/Resource_Acquisition_Is_Initialization>`_
-
-  * `Scope guard <http://en.wikibooks.org/wiki/More_C%2B%2B_Idioms/Scope_Guard>`_
-
-  * `Query cache freezes <http://www.mysqlperformanceblog.com/2009/03/19/mysql-random-freezes-could-be-the-query-cache/>`_

=== removed file 'doc/source/performance/remove_fcntl_excessive_calls.rst'
--- doc/source/performance/remove_fcntl_excessive_calls.rst	2013-03-05 12:46:43 +0000
+++ doc/source/performance/remove_fcntl_excessive_calls.rst	1970-01-01 00:00:00 +0000
@@ -1,35 +0,0 @@
-.. _remove_fcntl_excessive_calls:
-
-=============================================
- 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 first 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.
-
-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.
-
-
-.. Version Specific Information
-
-..  Percona Server Version	 Comments
-.. 5.1.49-12.0	 Ported from Facebook; full functionality available.
-.. 5.1.55-12.6, 5.5.10-20.1	 Ported an updated version in which several incorrect lines in the original implementation changed.
-
-.. Other Information
-
-.. Author/Origin	Facebook
-.. Bugs fixed	#606810, #724674
-.. This is a port of the official MySQL version of the original Facebook change. You can see the commits for both the original implementation and the updated version in Bazaar.
-
-
-Other Reading
-=============
-
-  * `fcntl Bottleneck <http://www.facebook.com/note.php?note_id=404965725932>`_
-
-  * `Use of non-blocking mode for sockets limits performance <http://bugs.mysql.com/bug.php?id=54790>`_
-

=== added file 'doc/source/performance/threadpool.rst'
--- doc/source/performance/threadpool.rst	1970-01-01 00:00:00 +0000
+++ doc/source/performance/threadpool.rst	2013-03-08 07:34:35 +0000
@@ -0,0 +1,113 @@
+.. _threadpool:
+
+=============
+ 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 :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| configuration file :file:`my.cnf`.
+
+Although the default values for the thread pool should provide good performance, additional `tuning <https://kb.askmonty.org/en/threadpool-in-55/#optimizing-server-variables-on-unix>`_ 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 significant implementation difference is that this implementation doesn't try to minimize the number of concurrent transactions like the ``MySQL Enterprise Threadpool``. Because of these things this implementation isn't compatible with the upstream one.
+
+Version Specific Information
+============================
+
+ * :rn:`5.6.10-60.2`
+    ``Thread Pool`` feature implemented. This feature was ported from |MariaDB|.
+
+System Variables
+================
+
+.. variable:: thread_pool_idle_timeout
+
+     :cli: Yes
+     :conf: Yes
+     :scope: Global
+     :dyn: Yes
+     :vartype: Numeric
+     :default: 60 (seconds)
+
+This variable can be used to limit the time an idle thread should wait before exiting.
+
+.. variable:: thread_pool_max_threads
+
+     :cli: Yes
+     :conf: Yes
+     :scope: Global
+     :dyn: Yes
+     :vartype: Numeric
+     :default: 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.
+
+.. variable:: thread_pool_oversubscribe
+
+     :cli: Yes
+     :conf: Yes
+     :scope: Global
+     :dyn: Yes
+     :vartype: Numeric
+     :default: 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
+
+     :cli: Yes
+     :conf: Yes
+     :scope: Global
+     :dyn: Yes
+     :vartype: Numeric
+     :default: Number of processors
+
+This variable can be used to define the number of threads that can use the CPU at the same time.
+
+.. variable:: thread_pool_stall_limit
+
+     :cli: Yes
+     :conf: No
+     :scope: Global
+     :dyn: No
+     :vartype: Numeric
+     :default: 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.
+
+Status Variables
+=====================
+
+.. variable:: Threadpool_idle_threads
+
+     :cli: Yes
+     :vartype: Numeric
+
+This status variable shows the number of idle threads in the pool.
+
+.. variable:: Threadpool_threads
+
+     :cli: Yes
+     :vartype: Numeric
+
+This status variable shows the number of threads in the pool.
+
+Other Reading
+=============
+
+ * `Thread pool in MariaDB 5.5  <https://kb.askmonty.org/en/threadpool-in-55/>`_
+
+ * `Thread pool implementation in Oracle MySQL <http://mikaelronstrom.blogspot.com/2011_10_01_archive.html>`_

=== added file 'doc/source/release-notes/Percona-Server-5.6.10-60.2.rst'
--- doc/source/release-notes/Percona-Server-5.6.10-60.2.rst	1970-01-01 00:00:00 +0000
+++ doc/source/release-notes/Percona-Server-5.6.10-60.2.rst	2013-03-08 07:34:35 +0000
@@ -0,0 +1,23 @@
+.. rn:: 5.6.10-60.2
+
+==============================
+ |Percona Server| 5.6.10-60.2
+==============================
+
+Percona is glad to announce the Alpha release of |Percona Server| 5.6.10-60.2 on March 11, 2013 (Downloads are available `here <http://www.percona.com/downloads/Percona-Server-5.6/Percona-Server-5.6.10-60.2/>`_ and from the EXPERIMENTAL `Percona Software Repositories <http://www.percona.com/docs/wiki/repositories:start>`_).
+
+Based on `MySQL 5.6.10 <http://dev.mysql.com/doc/relnotes/mysql/5.6/en/news-5-6-10.html>`_, including all the bug fixes in it, |Percona Server| 5.6.10-60.2 is the third ALPHA release in the |Percona Server| 5.6 series. All of |Percona|'s software is open-source and free, all the details of the release can be found in the `5.6.10-60.2 milestone at Launchpad <https://launchpad.net/percona-server/+milestone/5.6.10-60.2>`_.
+
+New Features
+=============
+
+ :ref:`expanded_innodb_fast_index_creation` has been ported from |Percona Server| 5.5
+
+ Ported the :ref:`threadpool` patch from |MariaDB|. This feature enables the server to keep the top performance even with the increased number of client connections.
+
+ :ref:`innodb_corrupt_table_action_page` has been ported from |Percona Server| 5.5
+
+Bug Fixes
+==========
+
+ Fixed the upstream :mysqlbug:`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 fixed :bug:`1100178` (*Laurynas Biveinis*).

=== modified file 'doc/source/release-notes/Percona-Server-5.6.5-60.0.rst'
--- doc/source/release-notes/Percona-Server-5.6.5-60.0.rst	2013-02-08 16:56:30 +0000
+++ doc/source/release-notes/Percona-Server-5.6.5-60.0.rst	2013-03-08 07:34:35 +0000
@@ -14,6 +14,7 @@
 =================
 
   * Fixed upstream |MySQL| bug :mysqlbug:`49336`, mysqlbinlog couldn't handle ``stdin`` when "|" was used. Bug fixed: :bug:`933969` (*Sergei Glushchenko*). 
+  * Fixed upstream |MySQL| bug :mysqlbug:`65946`, which could cause the server to segfault if if using ``libeatmydata`` (and possibly other LD_PRELOADs). Bug fixed: :bug:`933969` (*Stewart Smith*).
   * Added the ``TIME_MS`` column in the :table:`PROCESSLIST` table
   * :ref:`mysqldump_ignore_create_error` feature has been ported from |Percona Server| 5.5
   * :variable:`fast_index_creation` feature has been ported from |Percona Server| 5.5

=== modified file 'doc/source/release-notes/release-notes_index.rst'
--- doc/source/release-notes/release-notes_index.rst	2013-03-05 12:46:43 +0000
+++ doc/source/release-notes/release-notes_index.rst	2013-03-08 07:34:35 +0000
@@ -6,4 +6,6 @@
    :maxdepth: 1
    :glob:
 
-   Percona-Server-5.6.*
+   Percona-Server-5.6.10-60.2
+   Percona-Server-5.6.6-60.1
+   Percona-Server-5.6.5-60.0

=== removed file 'doc/source/reliability/error_pad.rst'
--- doc/source/reliability/error_pad.rst	2013-03-05 12:46:43 +0000
+++ doc/source/reliability/error_pad.rst	1970-01-01 00:00:00 +0000
@@ -1,55 +0,0 @@
-.. _error_pad:
-
-==========================
- 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 first 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 defined 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:
-
-  - :file:`errmsg.sys` files
-
-  - header file :file:`include/mysqld_error.h`
-
-  - header file :file:`include/mysqld_ername.h`
-
-from the file :file:`errmsg.txt`.
-
-To keep error numbers consistent, we should add some fictive errors to :file:`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 prefix ``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 prefix ``PADD_`` and padds error in sys files. All other |MySQL| code (load*.sys files, my_error, etc) works as old one.
-
-
-Version-Specific Information
-============================
-
-  * 5.5.8-20.0
-    Full functionality available.

=== modified file 'doc/source/reliability/innodb_corrupt_table_action.rst'
--- doc/source/reliability/innodb_corrupt_table_action.rst	2013-03-05 12:46:43 +0000
+++ doc/source/reliability/innodb_corrupt_table_action.rst	2013-03-08 07:34:35 +0000
@@ -11,32 +11,15 @@
 Version Specific Information
 ============================
 
-  * 5.5.10-20.1:
-    Renamed variable :variable:`innodb_pass_corrupt_table` to :variable:`innodb_corrupt_table_action`.
+  * 5.6.10-60.2:
+    Feature ported from |Percona Server| 5.5
 
 System Variables
 ================
 
-.. variable:: innodb_pass_corrupt_table
-
-     :version 5.5.10-20.1: Renamed.
-     :cli: Yes
-     :conf: Yes
-     :scope: Global
-     :dyn: Yes
-     :vartype: ULONG
-     :default: 0
-     :range: 0 - 1
-
-
-Pass corruptions of user tables as ``corrupt table`` instead of crashing itself, when used with innodb_file_per_table. All file I/O for the datafile after detected as corrupt is disabled, except for the deletion.
-
- This variable was renamed to innodb_corrupt_table_action, beginning in release 5.5.10-20.1. It still exists as :variable:`innodb_pass_corrupt_table` in versions prior to that.
-
-
 .. variable:: innodb_corrupt_table_action
 
-     :version 5.5.10-20.1: Introduced.
+     :version 5.6.10-60.2: Introduced.
      :cli: Yes
      :conf: Yes
      :scope: Global
@@ -45,6 +28,4 @@
      :default: ``assert``
      :range: ``assert``, ``warn``
 
-Pass corruptions of user tables as ``corrupt table`` instead of not crashing itself, when used with file_per_table. All file I/O for the datafile after detected as corrupt is disabled, except for the deletion.
-
- This variable was added in release 5.5.10-20.1. Prior to that, it was named :variable:`innodb_pass_corrupt_table`, which still exists in earlier versions.
+When the default value is used InnoDB will stop the server if it finds a checksum mismatch on the tables. If warn values is used it will pass corruption of the table as corrupt table instead of crashing itself. For this to work variable :variable:`innodb_file_per_table` should be enabled. All file I/O for the datafile after detected as corrupt is disabled, except for the deletion.

=== removed file 'doc/source/reliability/log_connection_error.rst'
--- doc/source/reliability/log_connection_error.rst	2013-03-05 12:46:43 +0000
+++ doc/source/reliability/log_connection_error.rst	1970-01-01 00:00:00 +0000
@@ -1,14 +0,0 @@
-.. _log_connection_error:
-
-==============================
- Too Many Connections Warning
-==============================
-
-
-This feature issues the warning ``Too many connections`` to the log, if ``log_warnings`` is enabled.
-
-Version-Specific Information
-============================
-
-  * 5.5.8-20.0:
-    Full functionality available.

=== removed file 'doc/source/reliability/show_slave_status_nolock.rst'
--- doc/source/reliability/show_slave_status_nolock.rst	2012-02-13 08:49:21 +0000
+++ doc/source/reliability/show_slave_status_nolock.rst	1970-01-01 00:00:00 +0000
@@ -1,23 +0,0 @@
-.. _show_slave_status_nolock:
-
-=================================
- Lock-Free ``SHOW SLAVE STATUS``
-=================================
-
-The ``STOP SLAVE`` and ``SHOW SLAVE STATUS`` commands can conflict 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 modifies the ``SLOW SLAVE STATUS`` syntax to allow: ::
-
-  SLOW SLAVE STATUS NOLOCK
-
-This will display the slave's 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.
-
-
-Version Specific Information
-============================
-
-  * 5.5.8-20.0:

=== removed file 'doc/source/scalability/innodb_adaptive_hash_index_partitions.rst'
--- doc/source/scalability/innodb_adaptive_hash_index_partitions.rst	2013-03-05 12:46:43 +0000
+++ doc/source/scalability/innodb_adaptive_hash_index_partitions.rst	1970-01-01 00:00:00 +0000
@@ -1,38 +0,0 @@
-.. _innodb_adaptive_hash_index_partitions_page:
-
-==========================================
- 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 specified 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 Specific Information
-
-|Percona Server| Version	 Comments
-5.5.8-20.0	 Initially released.
-
-System Variables
-----------------
-
-.. variable:: innodb_adaptive_hash_index_partitions
-
-   :version 5.5.8-20.0: Introduced
-   :cli: Yes
-   :conf: Yes
-   :scope: Global
-   :dyn: No
-   :vartype: Numeric
-   :def: 1
-   :range: 0-MAXINT
-
-Specifies the number of partitions to use in the adaptive hash search process.
-
-When set to zero, no extra partitions are created and the normal process is in effect. When greater than zero, the specified number of partitions are created across which to perform the adaptive search.
-
-Other reading
--------------
-
-  * `Index lock and adaptive search <http://www.mysqlperformanceblog.com/2010/02/25/index-lock-and-adaptive-search-next-two-biggest-innodb-problems/>`_

=== removed file 'doc/source/scalability/innodb_expand_undo_slots.rst'
--- doc/source/scalability/innodb_expand_undo_slots.rst	2012-02-16 10:24:41 +0000
+++ doc/source/scalability/innodb_expand_undo_slots.rst	1970-01-01 00:00:00 +0000
@@ -1,44 +0,0 @@
-.. _innodb_expand_undo_slots:
-
-======================================
-More Concurrent Transactions Available
-======================================
-
-|InnoDB| provides a fixed number of 1024 undo slots in its rollback segment, leaving room for 1024 transactions to run in parallel. If all the slots are used any new transaction will fail until a slot is freed, which can cause strange behaviors. This change provides a variable to expand the number of undo slots, up to 4072.
-
-This option is provided for servers that run out of undo slots. Use it if you find the following warning in the error log: ``Warning: cannot find a free slot for an undo log``.
-
-We discourage its use unless you get this warning, because it breaks compatibility with other programs. Specifically, it makes the datafiles unusable for ibbackup or for a |MySQL| server that is not run with this option.
-
-When you enable the option, the maximum number of undo slots is extended to 4072, instead of the default fixed value of 1024.
-
-You can then check whether the expanded slots (1025-4072) are used by starting :command:`mysqld` with ``innodb_extra_undoslots=OFF``:
-
-  * If the expanded slots are used: :command:`mysqld` refuses to start and prints an error in the error log: ::
-
-      InnoDB: Error: innodb_extra_undoslots option is disabled, but it was enabled before.
-      InnoDB: The datafile is not normal for |MySQL|d and disabled innodb_extra_undoslots.
-      InnoDB: Enable innodb_extra_undoslots if it was enabled before, and
-      InnoDB: ### don't use this datafile with other |MySQL|d or ibbackup! ###
-      InnoDB: Cannot continue operation for the safety. Calling exit(1).
-
-  * If the expanded slots are not used: :command:`mysqld` starts and prints only a warning in the error log: ::
-
-      InnoDB: Warning: innodb_extra_undoslots option is disabled, but it was enabled before.
-      InnoDB: But extended undo slots seem not used, so continue operation.
-
-
-System Variables
-----------------
-
-.. psdom:variable:: innodb_extra_undoslots
-
-   :cli: Yes
-   :Conf: Yes
-   :scope: Global
-   :dyn: No
-   :vartype: BOOL
-   :def: OFF
-   :range: ON/OFF
-
-If ``ON``, expands the number of undo slots to 4072.

=== removed file 'doc/source/scalability/innodb_extra_rseg.rst'
--- doc/source/scalability/innodb_extra_rseg.rst	2013-03-05 12:46:43 +0000
+++ doc/source/scalability/innodb_extra_rseg.rst	1970-01-01 00:00:00 +0000
@@ -1,49 +0,0 @@
-.. _innodb_extra_rseg:
-
-============================
- 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.
-
-Percona Server, in addition to the upstream multiple rollback segment implementation, provides the additonal Information Schema table: INFORMATION_SCHEMA.INNODB_RSEG.
-
-``INFORMATION_SCHEMA`` Tables
-=============================
-
-This feature provides the following table:
-
-.. table:: INFORMATION_SCHEMA.INNODB_RSEG
-
-   :column rseg_id: rollback segment id
-   :column space_id: space where the segment placed
-   :column zip_size: compressed page size in bytes if compressed otherwise 0
-   :column page_no: page number of the segment header
-   :column max_size: max size in pages
-   :column 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)
-

=== removed file 'doc/source/scalability/innodb_insert_buffer.rst'
--- doc/source/scalability/innodb_insert_buffer.rst	2013-03-05 12:46:43 +0000
+++ doc/source/scalability/innodb_insert_buffer.rst	1970-01-01 00:00:00 +0000
@@ -1,68 +0,0 @@
-.. _innodb_insert_buffer: 
-
-==========================
-Configurable Insert Buffer
-==========================
-
-Percona has implemented several changes related to MySQL's InnoDB Insert Buffer. These features enable adjusting the insert buffer to the different workloads and hardware configurations.
-
-System variables:
-=================
-
-.. variable:: innodb_ibuf_active_merge
-
-   :version 5.5.8-20.0: Introduced
-   :cli: Yes
-   :conf: Yes
-   :scope: Global
-   :dyn: Yes
-   :vartype: Numeric
-   :default:  0 (~1.0.5), 1 (1.0.6~)
-   :range: 0 - 1
-
-This variable specifies 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_merge_rate
-
-   :version 5.5.8-20.0: Introduced
-   :cli: Yes
-   :conf: Yes
-   :scope: Global
-   :dyn: Yes
-   :default: 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_merge_rate`` this way: ::
-
-  [real activity] = [default activity] * (innodb_io_capacity/100) * (innodb_ibuf_merge_rate/100)
-
-By increasing the value of ``innodb_ibuf_merge_rate``, you will increase the insert buffer activity.
-
-.. variable:: innodb_ibuf_max_size
-
-     :cli: Yes
-     :conf: Yes
-     :scope: Global
-     :dyn: No
-     :vartype: Numeric
-     :default: Half the size of the |InnoDB| buffer pool
-     :range: 0 - Half the size of the |InnoDB| buffer pool
-     :unit: Bytes
-
-This variable specifies 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.
-
-Other Reading
-=============
-
-* `Some little known facts about InnoDB Insert Buffer <http://www.mysqlperformanceblog.com/2009/01/13/some-little-known-facts-about-innodb-insert-buffer/>`_
-* `5.0.75-build12 Percona binaries <http://www.mysqlperformanceblog.com/2009/01/23/5075-build12-percona-binaries/>`_

=== removed file 'doc/source/scalability/innodb_split_buf_pool_mutex.rst'
--- doc/source/scalability/innodb_split_buf_pool_mutex.rst	2013-03-05 12:46:43 +0000
+++ doc/source/scalability/innodb_split_buf_pool_mutex.rst	1970-01-01 00:00:00 +0000
@@ -1,77 +0,0 @@
-.. _innodb_split_buf_pool_mutex:
-
-==================================
- 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:
-
-.. list-table::
-   :widths: 20 40
-   :header-rows: 1
-
-   * - Name
-     - Protects
-   * - buf_pool_mutex
-     - flags about IO
-   * - LRU_list_mutex
-     - LRU list of blocks in buffer pool
-   * - flush_list_mutex
-     - flush list of dirty blocks to flush
-   * - page_hash_latch	 
-     - hash table to search blocks in buffer pool
-   * - free_list_mutex	 
-     - list of free blocks in buffer pool
-   * - zip_free_mutex	 
-     - lists of free area to treat compressed pages
-   * - zip_hash_mutex	 
-     - 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 fit in memory.
-
-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 INNODB STATUS:
-
-Under normal circumstances this section should look like this:
-
-.. code-block:: guess
-
-   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:
-
-.. code-block:: guess
-
-   1 ----------
-   2 SEMAPHORES
-   3 ----------
-   4 OS WAIT ARRAY INFO: reservation count 36255, signal count 12675
-   5 --Thread 10607472 has waited at buf/buf0rea.c line 420 for 0.00 seconds the semaphore:
-   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 file buf/buf0buf.c (lines 5 to 7 or 8 to 10). Such an indication is a sign of buffer pool contention.

=== added file 'doc/source/upstream-bug-fixes.rst'
--- doc/source/upstream-bug-fixes.rst	1970-01-01 00:00:00 +0000
+++ doc/source/upstream-bug-fixes.rst	2013-03-08 07:34:35 +0000
@@ -0,0 +1,19 @@
+.. _upstream_bug_fixes:
+
+=============================================================
+ List of upstream |MySQL| bugs fixed in |Percona Server| 5.6
+=============================================================
+
++-------------------------------------------------------------------------------------------------------------+
+|:Upstream bug: :mysqlbug:`68116` - InnoDB monitor may hit an assertion error in buf_page_get_gen in debug ...|
+|:Launchpad bug: :bug:`1100178`                                                                               |
+|:Upstream state: Analyzing (checked on 2013-02-21)                                                           |
+|:Fix Released: :rn:`5.6.10-60.2`                                                                             |
+|:Upstream fix: N/A                                                                                           |
++-------------------------------------------------------------------------------------------------------------+
+|:Upstream bug: :mysqlbug:`65946` - Sid_map::Sid_map calls DBUG which may have unitialized THR_KEY_mysys and..|
+|:Launchpad bug: :bug:`1050758`                                                                               |
+|:Upstream state: Duplicate                                                                                   |
+|:Fix Released: :rn:`5.6.5-60.0`                                                                              |
+|:Upstream fix: N/A                                                                                           |
++-------------------------------------------------------------------------------------------------------------+