Merge lp:~hrvojem/percona-server/bug1065771-5.1 into lp:percona-server/5.1

Proposed by Hrvoje Matijakovic on 2013-01-24
Status: Merged
Approved by: Laurynas Biveinis on 2013-01-30
Approved revision: 519
Merged at revision: 525
Proposed branch: lp:~hrvojem/percona-server/bug1065771-5.1
Merge into: lp:percona-server/5.1
Diff against target: 159 lines (+58/-6)
7 files modified
doc/source/flexibility/mysqldump_ignore_create_error.rst (+22/-0)
doc/source/flexibility/replication_skip_single_statement.rst (+1/-1)
doc/source/index.rst (+1/-0)
doc/source/management/sql_no_fcache.rst (+29/-1)
doc/source/performance/innodb_doublewrite_path.rst (+2/-2)
doc/source/release-notes/Percona-Server-5.1.67-14.3.rst (+1/-1)
doc/source/scalability/innodb_io.rst (+2/-1)
To merge this branch: bzr merge lp:~hrvojem/percona-server/bug1065771-5.1
Reviewer Review Type Date Requested Status
Laurynas Biveinis (community) 2013-01-24 Approve on 2013-01-30
Review via email: mp+144722@code.launchpad.net
To post a comment you must log in.

   - s/This feature prevents unwanted blocks of data to be
     cached./This feature prevents the caching of the unwanted data
     blocks.
   - Diff line 121: is the "this post" removal intentional?

review: Needs Fixing
review: Approve

Preview Diff

[H/L] Next/Prev Comment, [J/K] Next/Prev File, [N/P] Next/Prev Hunk
1=== added file 'doc/source/flexibility/mysqldump_ignore_create_error.rst'
2--- doc/source/flexibility/mysqldump_ignore_create_error.rst 1970-01-01 00:00:00 +0000
3+++ doc/source/flexibility/mysqldump_ignore_create_error.rst 2013-01-30 09:34:40 +0000
4@@ -0,0 +1,22 @@
5+.. _mysqldump_ignore_create_error:
6+
7+======================================
8+ Ignoring missing tables in mysqldump
9+======================================
10+
11+In case table name was changed during the :command:`mysqldump` process taking place, :command:`mysqldump` would stop with error: ::
12+
13+ Couldn't execute 'show create table testtable'
14+ Table 'testdb.tabletest' doesn't exist (1146)\n")
15+
16+This could happen if :command:`mysqldump` was taking a backup of a working slave and during that process table name would get changed. This error happens because :command:`mysqldump` takes the list of the tables at the beginning of the dump process but the ``SHOW CREATE TABLE`` happens just before the table is being dumped.
17+
18+With this option :command:`mysqldump` will still show error to ``stderr``, but it will continue to work and dump the rest of the tables.
19+
20+Version Specific Information
21+============================
22+
23+ * :rn:`1.0.6-rel10.1`
24+ :command:`mysqldump` option :option:`--ignore-create-error` introduced
25+
26+
27
28=== modified file 'doc/source/flexibility/replication_skip_single_statement.rst'
29--- doc/source/flexibility/replication_skip_single_statement.rst 2012-12-13 12:31:02 +0000
30+++ doc/source/flexibility/replication_skip_single_statement.rst 2013-01-30 09:34:40 +0000
31@@ -50,7 +50,7 @@
32 Consider this case: ::
33
34 SET GLOBAL sql_slave_statement_skip_counter=n;
35- SET GLOBAL sql_slave__skip_counter=m;
36+ SET GLOBAL sql_slave_skip_counter=m;
37
38 The first statement will skip the next ``n`` events in the current event group. At that point, one would expect the second statement to operate as described in the |MySQL| documentation for ``sql_slave_skip_counter``. However, depending on the values of ``n`` and ``m`` and the contents of the binary log, the effects of the interactions of the two statements can involve very complicated scenarios. **THESE SCENARIOS HAVE NOT BEEN TESTED**.
39
40
41=== modified file 'doc/source/index.rst'
42--- doc/source/index.rst 2012-12-13 12:31:02 +0000
43+++ doc/source/index.rst 2013-01-30 09:34:40 +0000
44@@ -92,6 +92,7 @@
45 flexibility/replication_skip_single_statement
46 flexibility/buff_read_ahead_area
47 flexibility/innodb_fast_shutdown
48+ flexibility/mysqldump_ignore_create_error
49
50 Reliability Improvements
51 ========================
52
53=== modified file 'doc/source/management/sql_no_fcache.rst'
54--- doc/source/management/sql_no_fcache.rst 2012-12-13 12:31:02 +0000
55+++ doc/source/management/sql_no_fcache.rst 2013-01-30 09:34:40 +0000
56@@ -4,7 +4,7 @@
57 Prevent Caching to FlashCache
58 ==============================
59
60-*FlashCache* increases performance by caching data in SSDs. It works even better when only hot data is cached. This feature prevents unwanted blocks of data to be cached.
61+`FlashCache <https://github.com/facebook/flashcache/blob/master/doc/flashcache-doc.txt>`_ increases performance by caching data on SSDs. It works even better when only hot data is cached. This feature prevents the caching of the unwanted blocks of data.
62
63 Better utilization of *FlashCache* partitions is achieved when caching of rarely used data is avoided. Use of this feature prevents blocks of data from being cached to *FlashCache* during a query.
64
65@@ -21,6 +21,33 @@
66 * :rn:`5.1.49-rel12.0`:
67 Full functionality available.
68
69+ * :rn:`5.1.66-14.1`:
70+ Variable :variable:`have_flashcache` introduced.
71+
72+System Variables
73+================
74+.. variable:: have_flashcache
75+
76+ :version 5.1.66-14.1: Variable introduced
77+ :cli: Yes
78+ :conf: Yes
79+ :scope: Global
80+ :dyn: No
81+ :vartype: Boolean
82+ :range: Yes/No
83+
84+This variable shows if the server was compiled with Flashcache support.
85+
86+Status Variables
87+================
88+.. variable:: Flashcache_enabled
89+
90+ :scope: Global
91+ :vartype: Boolean
92+ :range: OFF/ON
93+
94+This status variable shows if the Flashcache support has been enabled.
95+
96 Other Information
97 =================
98
99@@ -32,3 +59,4 @@
100 * `Releasing Flashcache <http://www.facebook.com/note.php?note_id=388112370932>`_
101
102 * `Level 2 Flash cache is there <http://www.mysqlperformanceblog.com/2010/04/27/level-2-flash-cache-is-there/>`_
103+
104
105=== modified file 'doc/source/performance/innodb_doublewrite_path.rst'
106--- doc/source/performance/innodb_doublewrite_path.rst 2012-12-13 12:31:02 +0000
107+++ doc/source/performance/innodb_doublewrite_path.rst 2013-01-30 09:34:40 +0000
108@@ -19,7 +19,7 @@
109 Goal of the Doublewrite Buffer
110 ------------------------------
111
112-|InnoDB| and |XtraDB| use many structures, some on disk and others in memory, to manage data as efficiently as possible. To have an overview of the different components see this post. Let``s now focus on the doublewrite buffer.
113+|InnoDB| and |XtraDB| use many structures, some on disk and others in memory, to manage data as efficiently as possible. To have an overview of the different components see this `post <http://www.mysqlperformanceblog.com/2010/04/26/xtradb-innodb-internals-in-drawing/>`_. Let's now focus on the doublewrite buffer.
114
115 |InnoDB| / |XtraDB| uses a reserved area in its main tablespace, called the doublewrite buffer, to prevent data corruption that could occur with partial page writes. When the data in the buffer pool is flushed to disk, |InnoDB| / |XtraDB| will flush whole pages at a time (by default 16KB pages) and not just the records that have changed within a page. It means that, if anything unexpected happens during the write, the page can be partially written leading to corrupt data.
116
117@@ -27,7 +27,7 @@
118
119 If a partial page write occurs in the data files, |InnoDB| / |XtraDB| will check on recovery if the checksum of the page in the data file is different from the checksum of the page in the doublewrite buffer and thus will know if the page is corrupt or not. If it is corrupt, the recovery process will use the page stored in the doublewrite buffer to restore the correct data.
120
121-If a partial write occurs in the doublewrite buffer, the original page is untouched and can be used with the redo logs to recover the data. For further information on the doublewrite buffer, you can see this post.
122+If a partial write occurs in the doublewrite buffer, the original page is untouched and can be used with the redo logs to recover the data.
123
124 Performance Impact of the Doublewrite Buffer
125 --------------------------------------------
126
127=== modified file 'doc/source/release-notes/Percona-Server-5.1.67-14.3.rst'
128--- doc/source/release-notes/Percona-Server-5.1.67-14.3.rst 2013-01-18 09:27:58 +0000
129+++ doc/source/release-notes/Percona-Server-5.1.67-14.3.rst 2013-01-30 09:34:40 +0000
130@@ -4,7 +4,7 @@
131 |Percona Server| 5.1.67-14.3
132 ==============================
133
134-Percona is glad to announce the release of |Percona Server| 5.1.67-14.3 on January 21st, 2013 (Downloads are available from `Percona Server 5.1.67-14.3 downloads <http://www.percona.com/downloads/Percona-Server-5.1/Percona-Server-5.1.67-14.3/>`_ and from the `Percona Software Repositories <http://http://www.percona.com/doc/percona-server/5.1/installation.html>`_).
135+Percona is glad to announce the release of |Percona Server| 5.1.67-14.3 on January 23rd, 2013 (Downloads are available from `Percona Server 5.1.67-14.3 downloads <http://www.percona.com/downloads/Percona-Server-5.1/Percona-Server-5.1.67-14.3/>`_ and from the `Percona Software Repositories <http://http://www.percona.com/doc/percona-server/5.1/installation.html>`_).
136
137 Based on `MySQL 5.1.67 <http://dev.mysql.com/doc/refman/5.1/en/news-5.1.67.html>`_, this release will include all the bug fixes in it. All of |Percona|'s software is open-source and free, all the details of the release can be found in the `5.1.67-14.3 milestone at Launchpad <https://launchpad.net/percona-server/+milestone/5.1.67-14.3>`_.
138
139
140=== modified file 'doc/source/scalability/innodb_io.rst'
141--- doc/source/scalability/innodb_io.rst 2012-12-13 12:31:02 +0000
142+++ doc/source/scalability/innodb_io.rst 2013-01-30 09:34:40 +0000
143@@ -131,6 +131,7 @@
144
145 .. variable:: innodb_flush_method
146
147+ :version 5.1.54-12.5: ``ALL_O_DIRECT`` option added
148 :cli: Yes
149 :conf: Yes
150 :scope: Global
151@@ -152,7 +153,7 @@
152 * ``O_DIRECT``:
153 Use ``O_DIRECT`` (or ``directio()`` on Solaris) to open the data files; use ``fsync()`` to flush both the data and log files.
154
155- * ``ALL_O_DIRECT``: use ``O_DIRECT`` open and flush both the data and the log files. This value was added in |Percona Server| release :rn:`5.1.54-12.5`.
156+ * ``ALL_O_DIRECT``: use ``O_DIRECT`` open and flush both the data and the log files. This option is recommended when |InnoDB| log files are big (more than 8GB), otherwise there might be even a performance degradation. **Note**: When using this option on *ext4* filesystem variable :variable:`innodb_log_block_size` should be set to 4096 (default log-block-size in *ext4*) in order to avoid the ``unaligned AIO/DIO`` warnings.
157
158
159 .. variable:: innodb_flush_neighbor_pages

Subscribers

People subscribed via source and target branches