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

Proposed by Hrvoje Matijakovic on 2012-02-16
Status: Merged
Approved by: Stewart Smith on 2012-02-22
Approved revision: 216
Merged at revision: 217
Proposed branch: lp:~hrvojem/percona-server/bug930571-5.5
Merge into: lp:percona-server/5.5
Diff against target: 71 lines (+10/-4)
5 files modified
doc/source/index.rst (+1/-0)
doc/source/management/innodb_fake_changes.rst (+6/-1)
doc/source/performance/innodb_fast_checksum.rst (+1/-1)
doc/source/reliability/innodb_recovery_update_relay_log.rst (+1/-1)
doc/source/scalability/innodb_expand_undo_slots.rst (+1/-1)
To merge this branch: bzr merge lp:~hrvojem/percona-server/bug930571-5.5
Reviewer Review Type Date Requested Status
Stewart Smith (community) 2012-02-16 Approve on 2012-02-22
Review via email: mp+93373@code.launchpad.net
To post a comment you must log in.
Stewart Smith (stewart) :
review: Approve

Preview Diff

[H/L] Next/Prev Comment, [J/K] Next/Prev File, [N/P] Next/Prev Hunk
1=== modified file 'doc/source/index.rst'
2--- doc/source/index.rst 2012-02-03 10:23:20 +0000
3+++ doc/source/index.rst 2012-02-16 10:47:25 +0000
4@@ -164,6 +164,7 @@
5 development
6 trademark-policy
7 faq
8+ compatibility
9 release-notes/release-notes_index
10 glossary
11
12
13=== modified file 'doc/source/management/innodb_fake_changes.rst'
14--- doc/source/management/innodb_fake_changes.rst 2011-10-14 02:54:42 +0000
15+++ doc/source/management/innodb_fake_changes.rst 2012-02-16 10:47:25 +0000
16@@ -4,7 +4,7 @@
17 Support for Fake Changes
18 ==========================
19
20-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.
21+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.
22
23 That makes prefetch simple but has high overhead from locking rows only to undo changes at rollback.
24
25@@ -63,3 +63,8 @@
26 * 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).
27
28 * Foreign key constraints are checked (for causing IO), but passed always.
29+
30+Related Reading
31+===============
32+
33+ * `on MySQL replication prefetching <http://dom.as/2011/12/03/replication-prefetching/>`_
34
35=== modified file 'doc/source/performance/innodb_fast_checksum.rst'
36--- doc/source/performance/innodb_fast_checksum.rst 2011-10-07 23:38:41 +0000
37+++ doc/source/performance/innodb_fast_checksum.rst 2012-02-16 10:47:25 +0000
38@@ -10,7 +10,7 @@
39
40 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.
41
42-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.
43+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.
44
45
46 System Variables
47
48=== modified file 'doc/source/reliability/innodb_recovery_update_relay_log.rst'
49--- doc/source/reliability/innodb_recovery_update_relay_log.rst 2011-10-07 23:38:41 +0000
50+++ doc/source/reliability/innodb_recovery_update_relay_log.rst 2012-02-16 10:47:25 +0000
51@@ -8,7 +8,7 @@
52
53 |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.
54
55-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.
56+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.
57
58
59 Restrictions
60
61=== modified file 'doc/source/scalability/innodb_expand_undo_slots.rst'
62--- doc/source/scalability/innodb_expand_undo_slots.rst 2011-10-07 23:38:41 +0000
63+++ doc/source/scalability/innodb_expand_undo_slots.rst 2012-02-16 10:47:25 +0000
64@@ -4,7 +4,7 @@
65 More Concurrent Transactions Available
66 ======================================
67
68-|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.
69+|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.
70
71 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``.
72

Subscribers

People subscribed via source and target branches