Merge lp:~hrvojem/percona-server/bug930571-5.5 into lp:percona-server/5.5

[Hrvoje Matijakovic]

[Stewart Smith (stewart)]

review: Approve

=== modified file 'doc/source/index.rst'
--- doc/source/index.rst	2012-02-03 10:23:20 +0000
+++ doc/source/index.rst	2012-02-16 10:47:25 +0000
@@ -164,6 +164,7 @@
    development
    trademark-policy
    faq
+   compatibility
    release-notes/release-notes_index
    glossary
 
 
=== modified file 'doc/source/management/innodb_fake_changes.rst'
--- doc/source/management/innodb_fake_changes.rst	2011-10-14 02:54:42 +0000
+++ doc/source/management/innodb_fake_changes.rst	2012-02-16 10:47:25 +0000
@@ -4,7 +4,7 @@
  Support for Fake Changes
 ==========================
 
-When restarting a slave server in a replication environment, the process can be speed up by having prefetch threads to warm the server: replay statements and then rollback at commit.
+Restarting a slave server in a replication environment or setting up new slave server can cause a replication reads slower. This is happening because replication in |MySQL| is single-threaded and because it needs to read the data before it can execute the queries. The process can be speeded up by having prefetch threads to warm the server: replay statements and then rollback at commit.
 
 That makes prefetch simple but has high overhead from locking rows only to undo changes at rollback.
 
@@ -63,3 +63,8 @@
   * It will not prefetch allocate/free, split/merge, ``INODE``, ``XDES`` or other management pages. The same is for extern pages, i.e. large ``BLOB`` s).
 
   * Foreign key constraints are checked (for causing IO), but passed always.
+
+Related Reading
+===============
+
+  * `on MySQL replication prefetching <http://dom.as/2011/12/03/replication-prefetching/>`_
 
=== modified file 'doc/source/performance/innodb_fast_checksum.rst'
--- doc/source/performance/innodb_fast_checksum.rst	2011-10-07 23:38:41 +0000
+++ doc/source/performance/innodb_fast_checksum.rst	2012-02-16 10:47:25 +0000
@@ -10,7 +10,7 @@
 
 The original algorithm is checked after the new one, so you can have data pages with old checksums and data pages with new checksums. However in this case, you may experience slow reads from pages having old checksums. If you want to have the entire benefit of this change, you will need to recreate all your |InnoDB| tables, for instance by dumping and reloading all |InnoDB| tables.
 
-Once enabled, turning it off will require table re-creation as well, since it will fail to start on data files created when ``innodb_fast_checksums`` was enabled.
+Once enabled, turning it off will require table(s) to be dump/imported, since it will fail to start on data files created when ``innodb_fast_checksums`` was enabled. In this case ALTER TABLE won't work due to its implementation. 
 
 
 System Variables
 
=== modified file 'doc/source/reliability/innodb_recovery_update_relay_log.rst'
--- doc/source/reliability/innodb_recovery_update_relay_log.rst	2011-10-07 23:38:41 +0000
+++ doc/source/reliability/innodb_recovery_update_relay_log.rst	2012-02-16 10:47:25 +0000
@@ -8,7 +8,7 @@
 
 |MySQL| replication normally stores its position in a file that is neither durable nor consistent. Thus, if the replica crashes, it can re-execute committed transactions. This usually causes replication to fail, potentially forcing the replica``s data to be re-initialized from the master or from a recent backup.
 
-The improvement in |Percona Server| makes |InnoDB| store the replication position transactionally, and overwrite the usual master.info file upon recovery, so replication restarts from the correct position and does not try to re-execute committed transactions. This change greatly improves the durability of |MySQL| replication. It can be set to activate automatically, so replication “just works” and no intervention is necessary after a crash.
+The improvement in |Percona Server| makes |InnoDB| store the replication position transactionally, and overwrite the usual relay_log.info file upon recovery, so replication restarts from the correct position and does not try to re-execute committed transactions. This change greatly improves the durability of |MySQL| replication. It can be set to activate automatically, so replication “just works” and no intervention is necessary after a crash.
 
 
 Restrictions
 
=== modified file 'doc/source/scalability/innodb_expand_undo_slots.rst'
--- doc/source/scalability/innodb_expand_undo_slots.rst	2011-10-07 23:38:41 +0000
+++ doc/source/scalability/innodb_expand_undo_slots.rst	2012-02-16 10:47:25 +0000
@@ -4,7 +4,7 @@
 More Concurrent Transactions Available
 ======================================
 
-|InnoDB| provides a fixed number of 1024 undo slots in its rollback segment, leaving room for 1024 transactions to run in parallel. If all the slots are used any new transaction will fail until a slot is freed, which can cause st:range: behaviors. This change provides a variable to expand the number of undo slots, up to 4072.
+|InnoDB| provides a fixed number of 1024 undo slots in its rollback segment, leaving room for 1024 transactions to run in parallel. If all the slots are used any new transaction will fail until a slot is freed, which can cause strange behaviors. This change provides a variable to expand the number of undo slots, up to 4072.
 
 This option is provided for servers that run out of undo slots. Use it if you find the following warning in the error log: ``Warning: cannot find a free slot for an undo log``.