Merge lp:~hrvojem/percona-server/doc-28 into lp:percona-server/5.6

[Hrvoje Matijakovic]

[Laurynas Biveinis (laurynas-biveinis)]

- Please rebase on the latest trunk that has the file-id fixes. They have touched docs as well.

- Please also use https://code.launchpad.net/~laurynas-biveinis/percona-server/5.6-merge-4 as a prerequisite branch. It merges more 5.5 revisions, including doc ones.

review: Needs Resubmitting

[Laurynas Biveinis (laurynas-biveinis)]

    - the list of status variables itself does not look updated?
      i.e. AFAIK it should not have 1 or 10 second loops one but
      should have some new ones like background or active loops.
    - innodb_show_status.rst: just "feature ported ... ", no need for
      the other changes under version-specific change list.
    - doc/source/diagnostics/innodb_stats.rst - I think it's
      redundant, it should be fully replaced by the upstream
      features, so it needs upgrade documentation.
      - innodb_stats_method is an upstream feature.
      - other variables do not exist.
      - INNODB_SYS_TABLES, INNODB_SYS_TABLESTATS, INNODB_SYS_INDEXES,
        INNODB_SYS_COLUMNS, INNODB_SYS_FIELDS, INNODB_SYS_FOREIGN,
        INNODB_SYS_FOREIGN_COLS, INNODB_TABLE_STATS,
        INNODB_INDEX_STATS are upstream tables. Their schemas are
        different too IIRC.
    - doc/source/diagnostics/slow_extended.rst:
      - Maciej is no longer with Percona
      - No need to document upstream variables
        log_slow_admin_statements and log_slow_slave_statements
      - The log entry example is outdated, i.e. rows_read: is not
        there anymore, needs updating to the actual current output.
      - The profiling one too.
    - doc/source/diagnostics/user_stats.rst:
      - 5.6.11 changes: "Feature ported from PS 5.5"
    - doc/source/index_info_schema_tables.rst:
      - XTRADB_INTERNAL_HASH_TABLES, XTRADB_READ_VIEW, XTRADB_RSEG
        tables do not exist?
    - doc/source/installation.rst:
      ":ref:`pam_plugin` is not built with the server by
      default. ... "
    - doc/source/management/innodb_fast_index_creation.rst has been
      ported to 5.6.
    - doc/source/management/pam_plugin.rst: "integrated with |Percona
      Server|."

review: Needs Fixing

[Laurynas Biveinis (laurynas-biveinis)]

    - Line 59: bug 29123/29126 conflict, probably in the lower
      versions as well.
    - Line 102: should be fixed in lower versions as well?
    - Line 702: can be removed (also from 5.5 too I guess).
    - doc/source/diagnostics/thread_based_profiling.rst has been
      ported to 5.6.
    - Where are innodb_log_block_size docs?

Should I report the lower version issues separately?

review: Needs Fixing

[Laurynas Biveinis (laurynas-biveinis)]

    - innodb_io.rst: innodb_flush_method=ALL_O_DIRECT (dropped),
      innodb_log_file_size (replaced in upstream) have not been
      ported. innodb_purge_threads default has not been ported
      (replaced in upstream). That leaves ported status vars,
      innodb_log_block_size, and
      innodb_use_global_flush_log_at_trx_commit. The introduction
      needs updating, it doesn't seem to have received any since 5.0,
      i.e. "Note that some of these parameters are already available
      in the |InnoDB| plugin." should be removed, the rest rewritten
      perhaps.

review: Needs Fixing

[Laurynas Biveinis (laurynas-biveinis)]

review: Approve

[Stewart Smith (stewart)]

Hrvoje Matijakovic <email address hidden> writes:
> - * 5.5.8-20.0:
> + * :rn:`5.6.11-60.3`:

I wonder if we should keep the 5.5 introduction number in the 5.6 docs
too (perhaps as well as the 5.6 introduction version).

--
Stewart Smith

[Laurynas Biveinis (laurynas-biveinis)]

Stewart -

What would be the advantage? The 5.5 docs are there too. I'd prefer to have only 5.6 versions in 5.6, I think I already asked Hrvoje to remove the 5.5 versions earlier

[Stewart Smith (stewart)]

Laurynas Biveinis <email address hidden> writes:
> What would be the advantage? The 5.5 docs are there too. I'd prefer to
> have only 5.6 versions in 5.6, I think I already asked Hrvoje to
> remove the 5.5 versions earlier

I guess it's fine either way....

--
Stewart Smith

=== modified file 'doc/source/changed_in_56.rst'
--- doc/source/changed_in_56.rst	2013-05-10 13:29:38 +0000
+++ doc/source/changed_in_56.rst	2013-06-03 10:03:31 +0000
@@ -10,15 +10,15 @@
 
  * `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.
+ * SHOW [GLOBAL] TEMPORARY TABLES functionality is now only available via the INFORMATION_SCHEMA tables :table:`TEMPORARY_TABLES` and :table:`GLOBAL_TEMPORARY_TABLES`.
  * `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:
 
- * SHOW INNODB STATUS section "OLDEST VIEW" has been replaced by the XTRADB_READ_VIEW INFORMATION_SCHEMA table.
- * SHOW INNODB STATUS sections on memory usage for InnoDB/XtraDB hash tables has been replaced by the XTRADB_INTERNAL_HASH_TABLES INFORMATION_SCHEMA table.
- * The INNODB_RSEG table has been renamed to XTRADB_RSEG
+ * ``SHOW ENGINE INNODB STATUS`` section "OLDEST VIEW" has been replaced by the :table:`XTRADB_READ_VIEW` INFORMATION_SCHEMA table.
+ * ``SHOW ENGINE INNODB STATUS`` sections on memory usage for InnoDB/XtraDB hash tables has been replaced by the :table:`XTRADB_INTERNAL_HASH_TABLES` INFORMATION_SCHEMA table.
+ * The :table:`INNODB_RSEG` table has been renamed to :table:`XTRADB_RSEG`.
 
 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:
 

=== modified file 'doc/source/conf.py'
--- doc/source/conf.py	2013-05-27 03:01:29 +0000
+++ doc/source/conf.py	2013-06-03 10:03:31 +0000
@@ -108,6 +108,8 @@
 
 .. |XtraBackup|  replace:: *XtraBackup*
 
+.. |Percona XtraBackup|  replace:: *Percona XtraBackup*
+
 .. |Percona Server|  replace:: *Percona Server*
 
 .. |Percona|  replace:: *Percona*
@@ -265,6 +267,6 @@
 intersphinx_mapping = {
     'ps51' : ('http://www.percona.com/doc/percona-server/5.1/', None),
     'ps55' : ('http://www.percona.com/doc/percona-server/5.5/', None),
-    'xtrabackup' : ('http://www.percona.com/doc/percona-xtrabackup', None),
+    'xtrabackup' : ('http://www.percona.com/doc/percona-xtrabackup/2.1/', None),
     'ptoolkit' : ('http://www.percona.com/doc/percona-toolkit/2.1/', None)
  }

=== modified file 'doc/source/diagnostics/innodb_deadlock_count.rst'
--- doc/source/diagnostics/innodb_deadlock_count.rst	2013-05-27 13:59:13 +0000
+++ doc/source/diagnostics/innodb_deadlock_count.rst	2013-06-03 10:03:31 +0000
@@ -36,7 +36,7 @@
 Version Specific Information
 ============================
 
-  * 5.5.8-20.0:
+  * :rn:`5.6.11-60.3`:
     Full functionality available.
 
 Status Variables

=== modified file 'doc/source/diagnostics/innodb_show_status.rst'
--- doc/source/diagnostics/innodb_show_status.rst	2013-05-10 09:39:17 +0000
+++ doc/source/diagnostics/innodb_show_status.rst	2013-06-03 10:03:31 +0000
@@ -1,16 +1,16 @@
 .. _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:
+======================================
+ Extended Show Engine |InnoDB| Status
+======================================
+
+This feature reorganizes the output of ``SHOW ENGINE INNODB STATUS`` for a better readability and prints the amount of memory used by the internal hash tables. In addition, new variables are available to control the output.
+
+This feature modified the ``SHOW ENGINE INNODB STATUS`` command as follows:
 
   * ``TRANSACTION`` section was moved to the end of the output, so that important information is not overlooked when the there is a large amount of it.
 
-  * Added two variables to control ``SHOW INNODB STATUS`` information presented (bugfix for `#29123 <http://bugs.mysql.com/bug.php?id=29126>`_):
+  * Added two variables to control ``SHOW ENGINE INNODB STATUS`` information presented (bugfix for `#29123 <http://bugs.mysql.com/bug.php?id=29123>`_):
 
     * :variable:`innodb_show_verbose_locks` - Whether to show records locked
 
@@ -18,19 +18,15 @@
 
   * 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).
+  * Added additional LOG section information.
 
 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`.
+  * :rn:`5.6.11-60.3`:
+
+    Feature ported from |Percona Server| 5.5.
+
 
 Other Information
 =================
@@ -52,7 +48,7 @@
      :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.
+Specifies to show records locked in ``SHOW ENGINE INNODB STATUS``. The default is 0, which means only the higher-level information about the lock (which table and index is locked, etc.) is printed. If set to 1, then traditional |InnoDB| behavior is enabled: the records that are locked are dumped to the output.
 
 .. variable:: innodb_show_locks_held
 
@@ -64,62 +60,44 @@
      :default: 10
      :range: 0 - 1000
 
-Specifies the number of locks held to print for each |InnoDB| transaction in SHOW INNODB STATUS.
+Specifies the number of locks held to print for each |InnoDB| transaction in ``SHOW ENGINE 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.
+The status variables here contain information available in the output of ``SHOW ENGINE INNODB STATUS``, organized by the sections ``SHOW ENGINE INNODB STATUS`` displays. If you are familiar with the output of ``SHOW ENGINE INNODB STATUS``, you will probably already recognize the information these variables contain.
 
 
 BACKGROUND THREAD
 -----------------
 
-The following variables contain information in the BACKGROUND THREAD section of the output from ``SHOW 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
+The following variables contain information in the BACKGROUND THREAD section of the output from ``SHOW ENGINE INNODB STATUS``. An example of that output is: :: 
+
+  -----------------
+  BACKGROUND THREAD
+  -----------------
+  srv_master_thread loops: 1 srv_active, 0 srv_shutdown, 11844 srv_idle
+  srv_master_thread log flush and writes: 11844
+
+
+.. variable:: innodb_master_thread_active_loops
+
+     :version 5.6.11-60.3: Introduced.
+     :vartype: Numeric
+     :scope: Global
+
+.. variable:: innodb_master_thread_idle_loops
+
+     :version 5.6.11-60.3: 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: ::
+The following variables contain information in the SEMAPHORES section of the output from ``SHOW ENGINE INNODB STATUS``. An example of that output is: ::
 
   ----------
   SEMAPHORES
@@ -131,281 +109,255 @@
 
 .. variable:: innodb_mutex_os_waits
 
-     :version 5.5.8-20.0: Introduced.
+     :version 5.6.11-60.3: Introduced.
      :vartype: Numeric
      :scope: Global
 
 .. variable:: innodb_mutex_spin_rounds
 
-     :version 5.5.8-20.0: Introduced.
+     :version 5.6.11-60.3: Introduced.
      :vartype: Numeric
      :scope: Global
 
 .. variable:: innodb_mutex_spin_waits
 
-     :version 5.5.8-20.0: Introduced.
+     :version 5.6.11-60.3: Introduced.
      :vartype: Numeric
      :scope: Global
 
 .. variable:: innodb_s_lock_os_waits
 
-     :version 5.5.8-20.0: Introduced.
+     :version 5.6.11-60.3: Introduced.
      :vartype: Numeric
      :scope: Global
 
 .. variable:: innodb_s_lock_spin_rounds
 
-     :version 5.5.8-20.0: Introduced.
+     :version 5.6.11-60.3: Introduced.
      :vartype: Numeric
      :scope: Global
 
 .. variable:: innodb_s_lock_spin_waits
 
-     :version 5.5.8-20.0: Introduced.
+     :version 5.6.11-60.3: Introduced.
      :vartype: Numeric
      :scope: Global
 
 .. variable:: innodb_x_lock_os_waits
 
-     :version 5.5.8-20.0: Introduced.
+     :version 5.6.11-60.3: Introduced.
      :vartype: Numeric
      :scope: Global
 
 .. variable:: innodb_x_lock_spin_rounds
 
-     :version 5.5.8-20.0: Introduced.
+     :version 5.6.11-60.3: Introduced.
      :vartype: Numeric
      :scope: Global
 
 .. variable:: innodb_x_lock_spin_waits
 
-     :version 5.5.8-20.0: Introduced.
+     :version 5.6.11-60.3: 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: ::
+The following variables contain information in the INSERT BUFFER AND ADAPTIVE HASH INDEX section of the output from ``SHOW ENGINE INNODB STATUS``. An example of that output is: ::
 
   -------------------------------------
   INSERT BUFFER AND ADAPTIVE HASH INDEX
   -------------------------------------
   Ibuf: size 1, free list len 6089, seg size 6091,
   44497 inserts, 44497 merged recs, 8734 merges
-  Hash table size 276707, node heap has 1 buffer(s)
   0.00 hash searches/s, 0.00 non-hash searches/s
 
 .. variable:: innodb_ibuf_discarded_delete_marks
 
-     :version 5.5.8-20.0: Introduced.
+     :version 5.6.11-60.3: Introduced.
      :vartype: Numeric
      :scope: Global
 
 .. variable:: innodb_ibuf_discarded_deletes
 
-     :version 5.5.8-20.0: Introduced.
+     :version 5.6.11-60.3: Introduced.
      :vartype: Numeric
      :scope: Global
 
 .. variable:: innodb_ibuf_discarded_inserts
 
-     :version 5.5.8-20.0: Introduced.
+     :version 5.6.11-60.3: Introduced.
      :vartype: Numeric
      :scope: Global
 
 .. variable:: innodb_ibuf_free_list
 
-     :version 5.5.8-20.0: Introduced.
+     :version 5.6.11-60.3: Introduced.
      :vartype: Numeric
      :scope: Global
 
 .. variable:: innodb_ibuf_merged_delete_marks
 
-     :version 5.5.8-20.0: Introduced.
+     :version 5.6.11-60.3: Introduced.
      :vartype: Numeric
      :scope: Global
 
 .. variable:: innodb_ibuf_merged_deletes
 
-     :version 5.5.8-20.0: Introduced.
+     :version 5.6.11-60.3: Introduced.
      :vartype: Numeric
      :scope: Global
 
 .. variable:: innodb_ibuf_merged_inserts
 
-     :version 5.5.8-20.0: Introduced.
+     :version 5.6.11-60.3: Introduced.
      :vartype: Numeric
      :scope: Global
 
 .. variable:: innodb_ibuf_merges
 
-     :version 5.5.8-20.0: Introduced.
+     :version 5.6.11-60.3: Introduced.
      :vartype: Numeric
      :scope: Global
 
 .. variable:: innodb_ibuf_segment_size
 
-     :version 5.5.8-20.0: Introduced.
+     :version 5.6.11-60.3: 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.
+     :version 5.6.11-60.3: 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: ::
+The following variables contain information in the LOG section of the output from ``SHOW ENGINE 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
+  Log sequence number 10145937666
+  Log flushed up to   10145937666
+  Pages flushed up to 10145937666
+  Last checkpoint at  10145937666
+  Max checkpoint age    80826164
+  Checkpoint age target 78300347
+  Modified age          0
+  Checkpoint age        0
   0 pending log writes, 0 pending chkp writes
-  8570 log i/o's done, 2000.00 log i/o's/second
+  9 log i/o's done, 0.00 log i/o's/second
+  Log tracking enabled
+  Log tracked up to   10145937666
+  Max tracked LSN age 80826164
 
 .. variable:: innodb_lsn_current
 
-     :version 5.5.8-20.0: Introduced.
+     :version 5.6.11-60.3: Introduced.
      :vartype: Numeric
      :scope: Global
 
 .. variable:: innodb_lsn_flushed
 
-     :version 5.5.8-20.0: Introduced.
+     :version 5.6.11-60.3: Introduced.
      :vartype: Numeric
      :scope: Global
 
 .. variable:: innodb_lsn_last_checkpoint
 
-     :version 5.5.8-20.0: Introduced.
+     :version 5.6.11-60.3: Introduced.
      :vartype: Numeric
      :scope: Global
 
 .. variable:: innodb_checkpoint_age
 
-     :version 5.5.8-20.0: Introduced.
+     :version 5.6.11-60.3: 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.
+     :version 5.6.11-60.3: 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: ::
+The following variables contain information in the BUFFER POOL AND MEMORY section of the output from ``SHOW ENGINE INNODB STATUS``. An example of that output is: ::
 
   ----------------------
   BUFFER POOL AND MEMORY
   ----------------------
-  Total memory allocated 137625600; in additional pool allocated 0
+  Total memory allocated 137363456; in additional pool allocated 0
+  Total memory allocated by read views 88
   Internal hash tables (constant factor + variable factor)
-      Adaptive hash index 3774352 (2213656 + 1560696)
-      Page hash 139144
-      Dictionary cache 629811 (554864 + 74947)
-      File system 83536 (82672 + 864)
-      Lock system 380792 (332872 + 47920)
-      Recovery system 0 (0 + 0)
-      Threads 84040 (82696 + 1344)
-  Dictionary memory allocated 74947
-  Buffer pool size 8192
-  Buffer pool size, bytes 134217728
-  Free buffers 0
-  Database pages 8095
-  Old database pages 2968
-  Modified db pages 5914
+      Adaptive hash index 2266736         (2213368 + 53368)
+      Page hash           139112 (buffer pool 0 only)
+      Dictionary cache    729463  (554768 + 174695)
+      File system         824800  (812272 + 12528)
+      Lock system         333248  (332872 + 376)
+      Recovery system     0       (0 + 0)
+  Dictionary memory allocated 174695
+  Buffer pool size        8191
+  Buffer pool size, bytes 134201344
+  Free buffers            7481
+  Database pages          707
+  Old database pages      280
+  Modified db pages       0
   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
+  Pending writes: LRU 0, flush list 0 single page 0
+  Pages made young 0, not young 0
+  0.00 youngs/s, 0.00 non-youngs/s
+  Pages read 707, created 0, written 1
+  0.00 reads/s, 0.00 creates/s, 0.00 writes/s
+  No buffer pool page gets since the last printout
+  Pages read ahead 0.00/s, evicted without access 0.00/s, Random read ahead 0.00/s
+  LRU len: 707, unzip_LRU len: 0
+
 
 .. variable:: innodb_mem_adaptive_hash
 
-     :version 5.5.8-20.0: Introduced.
+     :version 5.6.11-60.3: Introduced.
      :vartype: Numeric
      :scope: Global
 
 .. variable:: innodb_mem_dictionary
 
-     :version 5.5.8-20.0: Introduced.
+     :version 5.6.11-60.3: Introduced.
      :vartype: Numeric
      :scope: Global
 
 .. variable:: innodb_mem_total
 
-     :version 5.5.8-20.0: Introduced.
+     :version 5.6.11-60.3: Introduced.
      :vartype: Numeric
      :scope: Global
 
 .. variable:: innodb_buffer_pool_pages_LRU_flushed
 
-     :version 5.5.8-20.0: Introduced.
+     :version 5.6.11-60.3: Introduced.
      :vartype: Numeric
      :scope: Global
 
 .. variable:: innodb_buffer_pool_pages_made_not_young
 
-     :version 5.5.8-20.0: Introduced.
+     :version 5.6.11-60.3: Introduced.
      :vartype: Numeric
      :scope: Global
 
 .. variable:: innodb_buffer_pool_pages_made_young
 
-     :version 5.5.8-20.0: Introduced.
+     :version 5.6.11-60.3: Introduced.
      :vartype: Numeric
      :scope: Global
 
 .. variable:: innodb_buffer_pool_pages_old
 
-     :version 5.5.8-20.0: Introduced.
+     :version 5.6.11-60.3: Introduced.
      :vartype: Numeric
      :scope: Global
 
@@ -427,44 +379,63 @@
   ---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.
+     :version 5.6.11-60.3: Introduced.
      :vartype: Numeric
      :scope: Global
 
 .. variable:: innodb_max_trx_id
 
-     :version 5.5.8-20.0: Introduced.
+     :version 5.6.11-60.3: Introduced.
      :vartype: Numeric
      :scope: Global
 
 .. variable:: innodb_oldest_view_low_limit_trx_id
 
-     :version 5.5.8-20.0: Introduced.
+     :version 5.6.11-60.3: Introduced.
      :vartype: Numeric
      :scope: Global
 
 .. variable:: innodb_purge_trx_id
 
-     :version 5.5.8-20.0: Introduced.
+     :version 5.6.11-60.3: Introduced.
      :vartype: Numeric
      :scope: Global
 
 .. variable:: innodb_purge_undo_no
 
-     :version 5.5.8-20.0: Introduced.
+     :version 5.6.11-60.3: Introduced.
      :vartype: Numeric
      :scope: Global
 
 .. variable:: innodb_current_row_locks
 
-     :version 5.5.8-20.0: Introduced.
-     :version 5.5.10-20.1: Renamed.
+     :version 5.6.11-60.3: Introduced.
      :vartype: Numeric
      :scope: Global
 
- This variable was named :variable:`innodb_row_lock_numbers` in release 5.5.8-20.0.
+INFORMATION_SCHEMA Tables
+=========================
+
+The following table contains information about the oldest active transaction in the system.
+
+.. table:: INFORMATION_SCHEMA.XTRADB_READ_VIEW
+
+   :column READ_VIEW_UNDO_NUMBER:
+   :column READ_VIEW_LOW_LIMIT_TRX_NUMBER: This is the highest transactions number at the time the view was created. 
+   :column READ_VIEW_UPPER_LIMIT_TRX_ID: This is the highest transactions ID at the time the view was created. This means that it should not see newer transactions with IDs bigger than or equal to that value.
+   :column READ_VIEW_LOW_LIMIT_TRX_ID: This is the latest committed transaction ID at the time the oldest view was created. This means that it should see all transactions with IDs smaller than or equal to that value.
+
+The following table contains information about the memory usage for InnoDB/XtraDB hash tables.
+
+.. table:: INFORMATION_SCHEMA.XTRADB_INTERNAL_HASH_TABLES
+
+   :column INTERNAL_HASH_TABLE_NAME: Hash table name
+   :column TOTAL_MEMORY: Total amount of memory
+   :column CONSTANT_MEMORY: Constant memory
+   :column VARIABLE_MEMORY: Variable memory
 
 
 Other reading

=== modified file 'doc/source/diagnostics/misc_info_schema_tables.rst'
--- doc/source/diagnostics/misc_info_schema_tables.rst	2013-05-27 13:59:13 +0000
+++ doc/source/diagnostics/misc_info_schema_tables.rst	2013-06-03 10:03:31 +0000
@@ -46,3 +46,43 @@
    :column UPDATE_TIME: Date and time of the latest update of the temporary table
 
 This table holds information on the temporary tables existing for the running connection.
+
+Multiple Rollback Segments
+==========================
+
+|Percona Server|, in addition to the upstream multiple rollback segment implementation, provides the additional Information Schema table: INFORMATION_SCHEMA.XTRADB_RSEG.
+
+``INFORMATION_SCHEMA`` Tables
+=============================
+
+This feature provides the following table:
+
+.. table:: INFORMATION_SCHEMA.XTRADB_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)
+

=== modified file 'doc/source/diagnostics/mysql_syslog.rst'
--- doc/source/diagnostics/mysql_syslog.rst	2013-05-27 13:46:13 +0000
+++ doc/source/diagnostics/mysql_syslog.rst	2013-06-03 10:03:31 +0000
@@ -9,8 +9,8 @@
 Version Specific Information
 ============================
 
-  * :rn:`5.5.8-20.0`:
-    Full functionality available.
+  * :rn:`5.6.11-60.3`:
+    Feature ported from |Percona Server| 5.5.
 
 Other Information
 =================

=== modified file 'doc/source/diagnostics/show_engines.rst'
--- doc/source/diagnostics/show_engines.rst	2013-05-27 13:59:13 +0000
+++ doc/source/diagnostics/show_engines.rst	2013-06-03 10:03:31 +0000
@@ -29,12 +29,6 @@
 Version-Specific Information
 ============================
 
-  * 5.5.8-20.0:
+  * :rn:`5.6.11-60.3`:
     Full functionality available.
 
-Other Information
-=================
-
-  * Author / Origin:
-    Percona
-

=== added file 'doc/source/diagnostics/slow_extended.rst'
--- doc/source/diagnostics/slow_extended.rst	1970-01-01 00:00:00 +0000
+++ doc/source/diagnostics/slow_extended.rst	2013-06-03 10:03:31 +0000
@@ -0,0 +1,355 @@
+.. _slow_extended:
+
+================
+ 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.
+
+You can use *Percona-Toolkit*'s `pt-query-digest <http://www.percona.com/doc/percona-toolkit/2.1/pt-query-digest.html>`_ tool to aggregate similar queries together and report on those that consume the most execution time.
+
+
+Version Specific Information
+============================
+
+  * :rn:`5.6.11-60.3`:
+
+     * Feature ported from |Percona Server| 5.5.
+
+Other Information
+=================
+
+  * Author / Origin:
+    Maciej Dobrzanski
+
+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 percent of queries will be 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_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.
+
+.. note::
+
+ Support for logging stored procedures doesn't involve triggers, so they won't be logged even if this feature is enabled.
+
+.. variable:: log_slow_verbosity
+
+     :cli: Yes
+     :conf: Yes
+     :scope: Global, session
+     :dyn: Yes
+
+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.
+
+  * ``query_plan``:
+    Log information about the query's execution plan.
+
+  * ``innodb``:
+    Log |InnoDB| statistics.
+
+  * ``minimal``:
+    Equivalent to enabling just ``microtime``.
+
+  * ``standard``:
+    Equivalent to enabling ``microtime,innodb``.
+
+  * ``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`` or ``standard``. To turn all options on, set the option to ``full``.
+
+.. variable:: slow_query_log_timestamp_always
+
+     :cli: Yes
+     :conf: Yes
+     :scope: Global
+     :dyn: Yes
+     :vartype: Boolean
+     :default: FALSE
+     :range: TRUE/FALSE
+
+If ``TRUE``, a timestamp is printed on every slow log record. Multiple records may have the same time.
+
+.. variable:: slow_query_log_timestamp_precision
+
+     :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]
+
+.. variable:: slow_query_log_use_global_control
+
+     :cli: Yes
+     :conf: Yes
+     :scope: Global
+     :dyn: Yes
+     :default: None
+
+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)
+
+
+Other Information
+=================
+
+Changes to the Log Format
+-------------------------
+
+The feature adds more information to the slow log output. Here is a sample log entry: ::
+
+  # Time: 130601  8:01:06.058915
+  # User@Host: root[root] @ localhost []  Id:    42
+  # Schema: imdb  Last_errno: 0  Killed: 0
+  # Query_time: 7.725616  Lock_time: 0.000328  Rows_sent: 4  Rows_examined: 1543720  Rows_affected: 0
+  # Bytes_sent: 272  Tmp_tables: 0  Tmp_disk_tables: 0  Tmp_table_sizes: 0
+  # QC_Hit: No  Full_scan: Yes  Full_join: No  Tmp_table: No  Tmp_table_on_disk: No
+  # Filesort: No  Filesort_on_disk: No  Merge_passes: 0
+  SET timestamp=1370073666;
+  SELECT id,title,production_year FROM title WHERE title = 'Bambi';
+
+
+Another example (:variable:`log_slow_verbosity` ``=profiling``): ::
+
+  # Time: 130601  8:03:20.700441
+  # User@Host: root[root] @ localhost []  Id:    43
+  # Schema: imdb  Last_errno: 0  Killed: 0
+  # Query_time: 7.815071  Lock_time: 0.000261  Rows_sent: 4  Rows_examined: 1543720  Rows_affected: 0
+  # Bytes_sent: 272
+  # Profile_starting: 0.000125 Profile_starting_cpu: 0.000120 
+  Profile_checking_permissions: 0.000021 Profile_checking_permissions_cpu: 0.000021 
+  Profile_Opening_tables: 0.000049 Profile_Opening_tables_cpu: 0.000048 Profile_init: 0.000048 
+  Profile_init_cpu: 0.000049 Profile_System_lock: 0.000049 Profile_System_lock_cpu: 0.000048 
+  Profile_optimizing: 0.000024 Profile_optimizing_cpu: 0.000024 Profile_statistics: 0.000036 
+  Profile_statistics_cpu: 0.000037 Profile_preparing: 0.000029 Profile_preparing_cpu: 0.000029 
+  Profile_executing: 0.000012 Profile_executing_cpu: 0.000012 Profile_Sending_data: 7.814583 
+  Profile_Sending_data_cpu: 7.811634 Profile_end: 0.000013 Profile_end_cpu: 0.000012 
+  Profile_query_end: 0.000014 Profile_query_end_cpu: 0.000014 Profile_closing_tables: 0.000023 
+  Profile_closing_tables_cpu: 0.000023 Profile_freeing_items: 0.000051 
+  Profile_freeing_items_cpu: 0.000050 Profile_logging_slow_query: 0.000006 
+  Profile_logging_slow_query_cpu: 0.000006 
+  # Profile_total: 7.815085 Profile_total_cpu: 7.812127 
+  SET timestamp=1370073800;
+  SELECT id,title,production_year FROM title WHERE title = 'Bambi';
+
+
+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. ::
+
+  # Id: 43  Schema: imdb
+
+Microsecond Time Resolution and Extra Row Information
+-----------------------------------------------------
+
+This is the original functionality offered by the ``microslow`` feature. ``Query_time`` and ``Lock_time`` are logged with microsecond resolution.
+
+The feature also adds information about how many rows were examined for ``SELECT`` queries, and how many were analyzed and affected for ``UPDATE``, ``DELETE``, and ``INSERT`` queries, ::
+
+  # Query_time: 0.962742  Lock_time: 0.000202  Rows_sent: 4  Rows_examined: 1543719  Rows_affected: 0
+
+Values and context:
+
+  * ``Rows_examined``:
+    Number of rows scanned - ``SELECT``
+
+  * ``Rows_affected``:
+    Number of rows changed - ``UPDATE``, ``DELETE``, ``INSERT``
+
+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: Yes  Full_join: No  Tmp_table: No  Tmp_table_on_disk: No
+  # Filesort: No  Filesort_on_disk: 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: 6415  InnoDB_IO_r_bytes: 105103360  InnoDB_IO_r_wait: 0.001279
+  #   InnoDB_rec_lock_wait: 0.000000  InnoDB_queue_wait: 0.000000
+  #   InnoDB_pages_distinct: 6430
+
+Values:
+
+  * ``innodb_IO_r_ops``:
+    Counts the number of page read operations scheduled. The actual number of read operations may be different, but since this can be done asynchronously, there is no good way to measure it.
+
+  * ``innodb_IO_r_bytes``:
+    Similar to innodb_IO_r_ops, but the unit is bytes.
+
+  * ``innodb_IO_r_wait``:
+    Shows how long (in seconds) it took |InnoDB| to actually read the data from storage.
+
+  * ``innodb_rec_lock_wait``:
+    Shows how long (in seconds) the query waited for row locks.
+
+  * ``innodb_queue_wait``:
+    Shows how long (in seconds) the query spent either waiting to enter the |InnoDB| queue or inside that queue waiting for execution.
+
+  * ``innodb_pages_distinct``:
+    Counts approximately the number of unique pages the query accessed. The approximation is based on a small hash array representing the entire buffer pool, because it could take a lot of memory to map all the pages. The inaccuracy grows with the number of pages accessed by a query, because there is a higher probability of hash collisions.
+
+If the query did not use |InnoDB| tables, that information is written into the log instead of the above statistics.
+
+Related Reading
+===============
+
+  * `Impact of logging on MySQL's performance <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/slow_extended_55.rst'
--- doc/source/diagnostics/slow_extended_55.rst	2013-05-10 09:39:17 +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 *Percona-Toolkit*'s `pt-query-digest <http://www.percona.com/doc/percona-toolkit/2.1/pt-query-digest.html>`_ 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_admin_statements
-
-     :cli: Yes
-     :conf: Yes
-     :scope: Global
-     :dyn: yes
-
-When this variable is enabled, administrative statements will be logged to the slow query log. Upstream version of the |MySQL| server has implemented command line option with same name. Significant difference is that this feature is implemented as variable in |Percona Server|, that means it can be enabled/disabled dynamically without restarting the server.
-
-.. variable:: log_slow_filter
-
-     :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 slow queries replayed by the slave SQL thread on a |MySQL| slave will be logged. Upstream version of the |MySQL| server has implemented command line option with same name. Significant difference is that this feature is implemented as variable in |Percona Server|, that means it can be enabled/disabled dynamically without restarting the server.
-
-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.
-
-.. note::
-
- Support for logging stored procedures doesn't involve triggers, so they won't be logged even if this feature is enabled.
-
-.. variable:: log_slow_verbosity
-
-     :version 5.5.8-20.0: Added ``profiling`` and ``profiling_use_getrusage``
-     :cli: Yes
-     :conf: Yes
-     :scope: Global, session
-     :dyn: Yes
-
-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.
-
-  * ``query_plan``:
-    Log information about the query's execution plan.
-
-  * ``innodb``:
-    Log |InnoDB| statistics.
-
-  * ``minimal``:
-    Equivalent to enabling just ``microtime``.
-
-  * ``standard``:
-    Equivalent to enabling ``microtime,innodb``.
-
-  * ``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`` or ``standard``. To turn all options on, set the option to ``full``.
-
-.. variable:: slow_query_log_timestamp_always
-
-     :version 5.5.10-20.1: Introduced  (renamed from :variable:`log_slow_timestamp_every`)
-     :cli: Yes
-     :conf: Yes
-     :scope: Global
-     :dyn: Yes
-     :vartype: Boolean
-     :default: FALSE
-     :range: TRUE/FALSE
-
-If ``TRUE``, a timestamp is printed on every slow log record. Multiple records may have the same time.
-
-.. variable:: slow_query_log_timestamp_precision
-
-     :version 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]
-
-.. 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>`_

=== modified file 'doc/source/diagnostics/thread_based_profiling.rst'
--- doc/source/diagnostics/thread_based_profiling.rst	2012-09-18 05:04:43 +0000
+++ doc/source/diagnostics/thread_based_profiling.rst	2013-06-03 10:03:31 +0000
@@ -13,5 +13,5 @@
 Version Specific Information
 ============================
 
-  * :rn:`5.5.25a-27.1`:
-    Thread based profiling introduced
+  * :rn:`5.6.11-60.3`:
+    Thread based profiling ported from |Percona Server| 5.5.

=== modified file 'doc/source/diagnostics/user_stats.rst'
--- doc/source/diagnostics/user_stats.rst	2013-05-27 13:59:13 +0000
+++ doc/source/diagnostics/user_stats.rst	2013-06-03 10:03:31 +0000
@@ -12,21 +12,21 @@
 Version Specific Information
 ============================
 
-  * :rn:`5.5.10-20.1`:
-     Renamed variable :variable:`userstat_running` to :variable:`userstat`.
+  * :rn:`5.6.11-60.3`:
+     Feature ported from |Percona Server| 5.5.
 
 Other Information
 =================
 
   * Author/Origin:
-     *Google*; *Percona* added the ``INFORMATION_SCHEMA`` tables and the :variable:`userstat_running` variable.
+     *Google*; *Percona* added the ``INFORMATION_SCHEMA`` tables and the :variable:`userstat` variable.
 
 System Variables
 ================
 
-.. variable:: userstat_running
+.. variable:: userstat
 
-     :version 5.5.10-20.1: Renamed to :variable:`userstat`
+     :version 5.6.11-60.3: Variable introduced
      :cli: Yes
      :conf: Yes
      :scope: Global

=== removed file 'doc/source/flexibility/buff_read_ahead_area.rst'
--- doc/source/flexibility/buff_read_ahead_area.rst	2013-05-27 13:46:13 +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/mysqlfacebook/using-pmp-to-double-mysql-throughput-part-2/405092575932>`_

=== removed file 'doc/source/flexibility/innodb_files_extend.rst'
--- doc/source/flexibility/innodb_files_extend.rst	2013-05-26 07:09:29 +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!

=== modified file 'doc/source/flexibility/log_warnings_suppress.rst'
--- doc/source/flexibility/log_warnings_suppress.rst	2013-05-27 13:46:13 +0000
+++ doc/source/flexibility/log_warnings_suppress.rst	2013-06-03 10:03:31 +0000
@@ -10,11 +10,8 @@
 Version Specific Information
 ============================
 
-  * :rn:`5.5.8-20.0`:
-    System variable :variable:`log_warnings_silence` introduced.
-
-  * :rn:`5.5.10-20.1`:
-    Renamed variable :variable:`log_warnings_silence` to :variable:`log_warnings_suppress`.
+  * :rn:`5.6.11-60.3`:
+    Variable :variable:`log_warnings_suppress` ported from |Percona Server| 5.5.
 
 
 System Variables
@@ -22,8 +19,7 @@
 
 .. variable:: log_warnings_suppress
 
-     :version 5.5.8-20.0: Introduced.
-     :version 5.5.10-20.1: Renamed.
+     :version 5.6.11-60.3: Introduced.
      :cli: Yes
      :conf: Yes
      :scope: Global
@@ -32,12 +28,8 @@
      :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 :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.
 
 

=== modified file 'doc/source/flexibility/max_binlog_files.rst'
--- doc/source/flexibility/max_binlog_files.rst	2013-01-30 10:01:50 +0000
+++ doc/source/flexibility/max_binlog_files.rst	2013-06-03 10:03:31 +0000
@@ -11,7 +11,7 @@
 Version Specific Information
 ============================
 
-  * 5.5.27-29.0:
+  * 5.6.11-60.3:
     Variable :variable:`max_binlog_files` introduced.
 
 System Variables
@@ -19,7 +19,7 @@
 
 .. variable:: max_binlog_files
 
-     :version 5.5.27-29.0: Introduced.
+     :version 5.6.11-60.3: Introduced.
      :cli: Yes
      :conf: Yes
      :scope: Global

=== modified file 'doc/source/index.rst'
--- doc/source/index.rst	2013-05-13 04:25:56 +0000
+++ doc/source/index.rst	2013-06-03 10:03:31 +0000
@@ -51,6 +51,15 @@
    installation
    upgrading_guide_55_56
 
+Scalability Improvements
+========================
+
+.. toctree::
+   :maxdepth: 1
+   :glob:
+
+   scalability/innodb_io
+
 Performance Improvements
 ========================
 
@@ -69,6 +78,9 @@
    :maxdepth: 1
    :glob:
 
+   flexibility/log_warnings_suppress
+   flexibility/improved_memory_engine
+   flexibility/max_binlog_files
    flexibility/mysqldump_ignore_create_error
 
 Reliability Improvements
@@ -81,6 +93,7 @@
    reliability/log_connection_error
    reliability/error_pad
    reliability/innodb_corrupt_table_action
+   reliability/show_slave_status_nolock
 
 Management Improvements
 =======================
@@ -89,7 +102,7 @@
    :maxdepth: 1
    :glob:
 
-   management/udf_maatkit
+   management/udf_percona_toolkit
    management/innodb_fake_changes
    management/innodb_kill_idle_trx
    management/enforce_engine
@@ -107,16 +120,16 @@
    :maxdepth: 1
    :glob:
 
-   diagnostics/index_info_schema_tables
-   diagnostics/innodb_stats
    diagnostics/user_stats
-   diagnostics/slow_extended_55
+   diagnostics/slow_extended
    diagnostics/innodb_show_status
    diagnostics/innodb_deadlock_count
    diagnostics/mysql_syslog
    diagnostics/show_engines
+   diagnostics/innodb_show_lock_names
    diagnostics/process_list
    diagnostics/misc_info_schema_tables
+   diagnostics/thread_based_profiling
 
 Reference
 =========
@@ -128,6 +141,7 @@
    upstream-bug-fixes
    development
    trademark-policy
+   index_info_schema_tables
    faq
    compatibility
    release-notes/release-notes_index

=== modified file 'doc/source/index_info_schema_tables.rst'
--- doc/source/index_info_schema_tables.rst	2012-12-10 15:24:56 +0000
+++ doc/source/index_info_schema_tables.rst	2013-06-03 10:03:31 +0000
@@ -8,11 +8,11 @@
 
   * :table:`CLIENT_STATISTICS`
 
+  * :table:`GLOBAL_TEMPORARY_TABLES`
+
   * :table:`INDEX_STATISTICS`
 
-  * :table:`GLOBAL_TEMPORARY_TABLES`
-
-  * :table:`QUERY_RESPONSE_TIME`
+  * :table:`INNODB_CHANGED_PAGES`
 
   * :table:`TABLE_STATISTICS`
 
@@ -22,37 +22,9 @@
 
   * :table:`USER_STATISTICS`
 
-  * :table:`INNODB_RSEG`
-
-  * :table:`INNODB_UNDO_LOGS`
-
-  * :table:`INNODB_SYS_TABLESTATS`
-
-  * :table:`INNODB_INDEX_STATS`
-
-  * :table:`INNODB_CHANGED_PAGES`
-
-  * :table:`INNODB_BUFFER_POOL_PAGES`
-
-  * :table:`INNODB_BUFFER_POOL_PAGES_BLOB`
-
-  * :table:`INNODB_BUFFER_POOL_PAGES_INDEX`
-
-  * :table:`INNODB_SYS_TABLES`
-
-  * :table:`INNODB_SYS_FIELDS`
-
-  * :table:`INNODB_SYS_COLUMNS`
-
-  * :table:`INNODB_SYS_STATS`
-
-  * :table:`INNODB_SYS_FOREIGN`
-
-  * :table:`INNODB_SYS_INDEXES`
-
-  * :table:`XTRADB_ADMIN_COMMAND`
-
-  * :table:`INNODB_TABLE_STATS`
-
-  * :table:`INNODB_SYS_FOREIGN_COLS`
+  * :table:`XTRADB_INTERNAL_HASH_TABLES`
+
+  * :table:`XTRADB_READ_VIEW`
+
+  * :table:`XTRADB_RSEG`
 

=== modified file 'doc/source/installation.rst'
--- doc/source/installation.rst	2013-05-27 13:59:13 +0000
+++ doc/source/installation.rst	2013-06-03 10:03:31 +0000
@@ -201,4 +201,4 @@
 
 .. note::
 
-  :ref:`pam_plugin` has been merged into |Percona Server| in :rn:`5.5.24-26.0` but it is not built with the server by default. In order to build the Percona Server with PAM plugin, additional option :option:`-DWITH_PAM=ON` should be used.
+  :ref:`pam_plugin` is not built with the server by default. In order to build the Percona Server with PAM plugin, additional option :option:`-DWITH_PAM=ON` should be used.

=== modified file 'doc/source/management/changed_page_tracking.rst'
--- doc/source/management/changed_page_tracking.rst	2013-03-06 06:41:38 +0000
+++ doc/source/management/changed_page_tracking.rst	2013-06-03 10:03:31 +0000
@@ -18,7 +18,7 @@
 User statements for handling the XtraDB changed page bitmaps
 ============================================================
 
-In |Percona Server| :rn:`5.5.29-30.0` new statements have been introduced for handling the changed page bitmap tracking. All of these statements require ``SUPER`` privilege.
+In |Percona Server| :rn:`5.6.11-60.3` new statements have been introduced for handling the changed page bitmap tracking. All of these statements require ``SUPER`` privilege.
 
  * ``FLUSH CHANGED_PAGE_BITMAPS`` - this statement can be used for synchronous bitmap write for immediate catch-up with the log checkpoint. This is used by innobackupex to make sure that XtraBackup indeed has all the required data it needs.
  * ``RESET CHANGED_PAGE_BITMAPS`` - this statement will delete all the bitmap log files and restart the bitmap log file sequence.
@@ -52,8 +52,7 @@
 
 .. variable:: innodb_max_changed_pages
 
-   :version 5.5.27-29.0: Variable :variable:`innodb_changed_pages_limit` introduced
-   :version 5.5.29-30.0: Variable renamed to :variable:`innodb_max_changed_pages`
+   :version 5.6.11-60.3: Variable :variable:`innodb_max_changed_pages` introduced
    :cli: Yes
    :conf: Yes
    :scope: Global
@@ -64,7 +63,7 @@
 
 .. variable:: innodb_track_changed_pages
 
-   :version 5.5.27-29.0: Variable introduced
+   :version 5.6.11-60.3: Variable introduced
    :cli: Yes
    :conf: Yes
    :scope: Global
@@ -75,7 +74,7 @@
 
 .. variable:: innodb_max_bitmap_file_size
 
-   :version 5.5.28-29.2: Variable introduced
+   :version 5.6.11-60.3: Variable introduced
    :cli: Yes
    :conf: Yes
    :scope: Global

=== modified file 'doc/source/management/enforce_engine.rst'
--- doc/source/management/enforce_engine.rst	2012-12-14 09:58:23 +0000
+++ doc/source/management/enforce_engine.rst	2013-06-03 10:03:31 +0000
@@ -13,7 +13,7 @@
 Version Specific Information
 ============================
 
-  * :rn:`5.5.24-26.0`
+  * :rn:`5.6.11-60.3`
     Variable :variable:`enforce_storage_engine` implemented.
 
 System Variables

=== modified file 'doc/source/management/expanded_program_option_modifiers.rst'
--- doc/source/management/expanded_program_option_modifiers.rst	2012-09-04 23:24:39 +0000
+++ doc/source/management/expanded_program_option_modifiers.rst	2013-06-03 10:03:31 +0000
@@ -31,7 +31,7 @@
 Version Specific Information
 ============================
 
-  * :rn:`5.5.27-28.0`
+  * :rn:`5.6.11-60.3`
     Expanded program option modifiers implemented
 
 Examples

=== modified file 'doc/source/management/innodb_fake_changes.rst'
--- doc/source/management/innodb_fake_changes.rst	2013-05-27 13:59:13 +0000
+++ doc/source/management/innodb_fake_changes.rst	2013-06-03 10:03:31 +0000
@@ -4,7 +4,7 @@
  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.
+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 sped 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.
 
@@ -35,7 +35,7 @@
 
 .. variable:: innodb_fake_changes
    
-   :version 5.5.16-22.0: Introduced
+   :version 5.6.11-60.3: Introduced
    :scope: ``GLOBAL``
    :type: ``BOOLEAN``
    :dyn: ``YES``
@@ -43,6 +43,16 @@
 
    This variable enables the *Fake Changes* feature.
 
+.. variable:: innodb_locking_fake_changes
+
+   :version 5.6.11-60.3: Introduced
+   :scope: ``GLOBAL``
+   :type: ``BOOLEAN``
+   :dyn: ``YES``
+   :default: ``TRUE``
+ 
+   When this variable is set to ``FALSE``, it makes fake transactions not to take any row locks. This feature was implemented because, although fake change transactions downgrade the requested exclusive (X) row locks to shared (S) locks, these S locks prevent X locks from being taken and block the real changes. However, this option is not safe to set to FALSE by default, because the fake changes implementation is not ready for lock-less operation for all workloads. Namely, if a real transaction will remove a row that a fake transaction is doing a secondary index maintenance for, the latter will fail. This option is considered experimental and might be removed in the future if lockless operation mode fixes are implemented.
+
 Implementation Details
 ======================
 

=== removed file 'doc/source/management/innodb_fast_index_creation.rst'
--- doc/source/management/innodb_fast_index_creation.rst	2012-12-14 09:58:23 +0000
+++ doc/source/management/innodb_fast_index_creation.rst	1970-01-01 00:00:00 +0000
@@ -1,63 +0,0 @@
-.. _innodb_fast_index_creation:
-
-=====================
- Fast Index Creation
-=====================
-
-Percona has implemented several changes related to |MySQL|'s fast index creation feature. Extended features, besides disabling :variable:`fast_index_creation`, can be enabled with :variable:`expand_fast_index_creation`. 
-
-Disabling Fast Index Creation
-=============================
-
-Fast index creation was implemented in |MySQL| as a way to speed up the process of adding or dropping indexes on tables with many rows. However, cases have been found in which fast index creation creates an inconsistency between |MySQL| and |InnoDB| data dictionaries.
-
-This feature implements a session variable that disables fast index creation. This causes indexes to be created in the way they were created before fast index creation was implemented. While this is slower, it avoids the problem of data dictionary inconsistency between |MySQL| and |InnoDB|.
-
-
-Tunable buffer size for fast index creation
-===========================================
-
-|Percona Server| supports tunable buffer size for fast index creation in |InnoDB|. This value was calculated based on the merge block size (which was hardcoded to 1 MB) and the minimum index record size. By adding the session variable :variable:`innodb_merge_sort_block_size` block size that is used in the merge sort can now be adjusted for better performance.
-
-
-Version Specific Information
-============================
-
-  * :rn:`5.5.8-20.0`: 
-    Variable :variable:`fast_index_creation` implemented.
-
-  * :rn:`5.5.11-20.2`:
-    Expanded the applicability of fast index creation to :command:`mysqldump`, ``ALTER TABLE``, and ``OPTIMIZE TABLE``.
-
-  * :rn:`5.5.27-28.0`
-    Variable :variable:`innodb_merge_sort_block_size` implemented.
-
-System Variables
-================
-
-.. variable:: fast_index_creation
-
-     :cli: Yes
-     :conf: No
-     :scope: Local
-     :dyn: Yes
-     :vartype: Boolean
-     :default: ON
-     :range: ON/OFF
-
-.. variable:: innodb_merge_sort_block_size
- 
-     :cli: Yes
-     :conf: Yes
-     :scope: Global
-     :dyn: Yes
-     :vartype: ULONG
-     :default: 1048576 (1M)
-     :range: 1048576 - 1073741824 (1G)
-
-Other Reading
-=============
-
-  * `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/>`_
-
-  * `Building Indexes by Sorting In Innodb <http://www.mysqlperformanceblog.com/2012/06/19/building-indexes-by-sorting-in-innodb-aka-fast-index-creation/>`_

=== modified file 'doc/source/management/innodb_kill_idle_trx.rst'
--- doc/source/management/innodb_kill_idle_trx.rst	2013-05-26 13:51:37 +0000
+++ doc/source/management/innodb_kill_idle_trx.rst	2013-06-03 10:03:31 +0000
@@ -11,7 +11,7 @@
 
 .. variable:: innodb_kill_idle_transaction
    
-   :version 5.5.16-22.0: Introduced
+   :version 5.6.11-60.3: Introduced
    :scope: ``GLOBAL``
    :config: ``YES``
    :dyn: ``YES``

=== modified file 'doc/source/management/pam_plugin.rst'
--- doc/source/management/pam_plugin.rst	2013-02-06 10:26:45 +0000
+++ doc/source/management/pam_plugin.rst	2013-06-03 10:03:31 +0000
@@ -68,5 +68,5 @@
 Version Specific Information
 ============================
 
-  * :rn:`5.5.24-26.0`
+  * :rn:`5.6.11-60.3`
     PAM authentication plugin has been integrated with |Percona Server|.

=== modified file 'doc/source/management/secure_file_priv_extended.rst'
--- doc/source/management/secure_file_priv_extended.rst	2012-09-04 23:24:39 +0000
+++ doc/source/management/secure_file_priv_extended.rst	2013-06-03 10:03:31 +0000
@@ -10,7 +10,7 @@
 Version Specific Information
 ============================
 
-  * :rn:`5.5.25a-27.1`
+  * :rn:`5.6.11-60.3`
     Variable :variable:`secure-file-priv` extended behavior implemented.
 
 System Variables

=== removed file 'doc/source/management/udf_maatkit.rst'
--- doc/source/management/udf_maatkit.rst	2013-05-10 09:39:17 +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/

=== added file 'doc/source/management/udf_percona_toolkit.rst'
--- doc/source/management/udf_percona_toolkit.rst	1970-01-01 00:00:00 +0000
+++ doc/source/management/udf_percona_toolkit.rst	2013-06-03 10:03:31 +0000
@@ -0,0 +1,54 @@
+.. _udf_percona_toolkit:
+
+========================
+ *Percona Toolkit* UDFs
+========================
+
+Three *Percona Toolkit* UDFs that provide faster checksums are provided:
+
+  * ``fnv_udf``
+
+  * ``fnv1a_udf``
+
+  * ``murmur_udf``
+
+Version Specific Information
+============================
+
+  * :rn:`5.6.11-60.3`:
+    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.
+
+Troubleshooting
+================
+
+If you get the error: :: 
+
+  ERROR 1126 (HY000): Can't open shared library 'fnv_udf.so' (errno: 22 fnv_udf.so: cannot open shared object file: No such file or directory)
+
+Then you may need to copy the .so file to another location in your system. Try both ``/lib`` and ``/usr/lib``. Look at your environment's ``$LD_LIBRARY_PATH`` variable for clues. If none is set, and neither ``/lib`` nor ``/usr/lib`` works, you may need to set ``LD_LIBRARY_PATH`` to ``/lib`` or ``/usr/lib``.
+
+Other Reading
+=============
+
+  * *Percona Toolkit* `documentation <http://www.percona.com/doc/percona-toolkit/>`_

=== modified file 'doc/source/management/utility_user.rst'
--- doc/source/management/utility_user.rst	2012-09-04 23:24:39 +0000
+++ doc/source/management/utility_user.rst	2013-06-03 10:03:31 +0000
@@ -26,7 +26,7 @@
 
 In order to have the ability for a special type of MySQL user, which will have a very limited and special amount of control over the system and can not be see or modified by any other user including the root user, three new options have been added.
 
-Option :variable:`utility_user` specifies the user which the system will create and recognize as the utility user. The host in the utility user specification follows conventions described in the `MySQL manual <http://dev.mysql.com/doc/refman/5.5/en/connection-access.html>`_, i.e. it allows wildcards and IP masks. Anonymous user names are not permitted to be used for the utility user name.
+Option :variable:`utility_user` specifies the user which the system will create and recognize as the utility user. The host in the utility user specification follows conventions described in the `MySQL manual <http://dev.mysql.com/doc/refman/5.6/en/connection-access.html>`_, i.e. it allows wildcards and IP masks. Anonymous user names are not permitted to be used for the utility user name.
 
 This user must not be an exact match to any other user that exists in the mysql.user table. If the server detects that the user specified with this option exactly matches any user within the mysql.user table on start up, the server will report an error and shut down gracefully. If host name wildcards are used and a more specific user specification is identified on start up, the server will report a warning and continue. 
 
@@ -51,7 +51,7 @@
 
 .. variable:: utility_user
 
-     :version 5.5.27-28.0: Implemented
+     :version 5.6.11-60.3: Implemented
      :cli: Yes
      :conf: utility_user=<user@host>
      :scope: Global
@@ -63,7 +63,7 @@
 
 .. variable:: utility_user_password
 
-     :version 5.5.27-28.0: Implemented
+     :version 5.6.11-60.3: Implemented
      :cli: Yes
      :conf: utility_user_password=<password>
      :scope: Global
@@ -75,7 +75,7 @@
 
 .. variable:: utility_user_schema_access
 
-     :version 5.5.27-28.0: Implemented
+     :version 5.6.11-60.3: Implemented
      :cli: Yes
      :conf: utility_user_schema_access=<schema>,<schema>,<schema>
      :scope: Global

=== modified file 'doc/source/performance/innodb_numa_support.rst'
--- doc/source/performance/innodb_numa_support.rst	2013-05-12 09:13:00 +0000
+++ doc/source/performance/innodb_numa_support.rst	2013-06-03 10:03:31 +0000
@@ -13,7 +13,7 @@
 Version Specific Information
 ============================
 
- * :rn:`5.5.28-29.1`
+ * :rn:`5.6.11-60.3`
     Improved ``NUMA`` support implemented. This feature was ported from Twitter's |MySQL| patches.
 
 System Variables

=== modified file 'doc/source/performance/query_cache_enhance.rst'
--- doc/source/performance/query_cache_enhance.rst	2013-05-26 07:09:29 +0000
+++ doc/source/performance/query_cache_enhance.rst	2013-06-03 10:03:31 +0000
@@ -38,19 +38,19 @@
 
 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: ::
+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 PROCESSLIST`` 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;
+  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
@@ -66,36 +66,6 @@
 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
 ================
 
@@ -116,8 +86,4 @@
 
   * `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/>`_

=== modified file 'doc/source/reliability/error_pad.rst'
--- doc/source/reliability/error_pad.rst	2013-05-27 13:59:13 +0000
+++ doc/source/reliability/error_pad.rst	2013-06-03 10:03:31 +0000
@@ -4,17 +4,17 @@
  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.
+|Percona Server| with |XtraDB| has error code incompatibilities with |MySQL| 5.6. 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.
+  * |Percona Server| with |XtraDB| contains features that have been backported from MyQL 5.6. Some of the |MySQL| 5.6 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.
+The solution to the first problem is to preserve |MySQL| 5.6 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.6.
 
-After migrating |Percona Server| / |XtraDB| to |MySQL| 5.5, users might experience troubles because of this.
+After migrating |Percona Server| / |XtraDB| to |MySQL| 5.6, 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.
 
@@ -51,5 +51,5 @@
 Version-Specific Information
 ============================
 
-  * 5.5.8-20.0
-    Full functionality available.
+  * :rn:`5.6.11-60.3`
+    Feature ported from |Percona Server| 5.5.

=== modified file 'doc/source/reliability/log_connection_error.rst'
--- doc/source/reliability/log_connection_error.rst	2013-05-27 13:59:13 +0000
+++ doc/source/reliability/log_connection_error.rst	2013-06-03 10:03:31 +0000
@@ -10,5 +10,5 @@
 Version-Specific Information
 ============================
 
-  * 5.5.8-20.0:
-    Full functionality available.
+  * :rn:`5.6.11-30.3`:
+    Feature ported from |Percona Server| 5.5.

=== modified file 'doc/source/reliability/show_slave_status_nolock.rst'
--- doc/source/reliability/show_slave_status_nolock.rst	2013-05-06 15:43:51 +0000
+++ doc/source/reliability/show_slave_status_nolock.rst	2013-06-03 10:03:31 +0000
@@ -14,10 +14,12 @@
 
 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.
+.. 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:
+  * :rn:`5.6.11-60.3`: Feature ported from |Percona Server| 5.5.

=== added file 'doc/source/scalability/innodb_io.rst'
--- doc/source/scalability/innodb_io.rst	1970-01-01 00:00:00 +0000
+++ doc/source/scalability/innodb_io.rst	2013-06-03 10:03:31 +0000
@@ -0,0 +1,71 @@
+.. _innodb_io_page:
+
+===================================
+ Improved |InnoDB| I/O Scalability
+===================================
+
+Because |InnoDB| is a complex storage engine it must be configured properly in order to perform at its best. Some points are not configurable in standard |InnoDB|. The goal of this feature is to provide a more exhaustive set of options for |XtraDB|, like ability to change the log block size. 
+
+Version Specific Information
+============================
+
+  * :rn:`5.6.11-60.3`
+
+    * Feature ported from |Percona Server| 5.5
+
+System Variables
+================
+
+
+.. variable:: innodb_use_global_flush_log_at_trx_commit
+
+   :cli: Yes
+   :conf: Yes
+   :scope: Global
+   :dyn: Yes
+   :type: Boolean
+   :default: True
+   :range: True/False
+
+This variable is used to control the ability of the user to set the value of the global |MySQL| variable ``innodb_flush_log_at_trx_commit``.
+
+If ``innodb_use_global_flush_log_at_trx_commit=0`` (False), the client can set the global |MySQL| variable, using: ::
+
+  SET innodb_use_global_flush_log_at_trx_commit=N
+
+If ``innodb_use_global_flush_log_at_trx_commit=1`` (True), the user session will use the current value of ``innodb_flush_log_at_trx_commit``, and the user cannot reset the value of the global variable using a ``SET`` command.
+
+.. variable:: innodb_log_block_size
+
+     :cli: Yes
+     :conf: Yes
+     :scope: Global
+     :dyn: No
+     :vartype: Numeric
+     :default: 512
+     :units: Bytes
+
+This variable changes the size of transaction log records. The default size of 512 bytes is good in most situations. However, setting it to 4096 may be a good optimization with SSD cards. While settings other than 512 and 4096 are possible, as a practical matter these are really the only two that it makes sense to use. Clean restart and removal of the old logs is needed for the variable :variable:`innodb_log_block_size` to be changed.
+
+Status Variables
+----------------
+
+The following information has been added to ``SHOW ENGINE INNODB STATUS`` to confirm the checkpointing activity: ::
+
+  The max checkpoint age
+  The current checkpoint age target
+  The current age of the oldest page modification which has not been flushed to disk yet.
+  The current age of the last checkpoint
+  ...
+  ---
+  LOG
+  ---
+  Log sequence number 0 1059494372
+  Log flushed up to   0 1059494372
+  Last checkpoint at  0 1055251010
+  Max checkpoint age  162361775
+  Checkpoint age target 104630090
+  Modified age        4092465
+  Checkpoint age      4243362
+  0 pending log writes, 0 pending chkp writes
+  ...