Percona Server moved to https://jira.percona.com/projects/PS

Merge lp:~hrvojem/percona-server/rn-5.6.14-62.0 into lp:percona-server/5.6

  1. rn-5.6.14-62.0
  2. Merge into 5.6
Proposed by Hrvoje Matijakovic
Status: Merged
Approved by: Laurynas Biveinis
Approved revision: no longer in the source branch.
Merged at revision: 486
Proposed branch: lp:~hrvojem/percona-server/rn-5.6.14-62.0
Merge into: lp:percona-server/5.6
Diff against target: 248 lines (+130/-10)
9 files modified
doc/source/conf.py (+1/-1)
doc/source/flexibility/per_query_variable_statement.rst (+43/-0)
doc/source/index.rst (+2/-1)
doc/source/performance/page_cleaner_tuning.rst (+10/-2)
doc/source/performance/xtradb_performance_improvements_for_io-bound_highly-concurrent_workloads.rst (+4/-4)
doc/source/release-notes/Percona-Server-5.6.13-61.0.rst (+2/-2)
doc/source/release-notes/Percona-Server-5.6.14-62.0.rst (+35/-0)
doc/source/release-notes/release-notes_index.rst (+1/-0)
doc/source/scalability/innodb_io.rst (+32/-0)
To merge this branch: bzr merge lp:~hrvojem/percona-server/rn-5.6.14-62.0
Reviewer Review Type Date Requested Status
Laurynas Biveinis (community) Approve
Review via email: mp+192317@code.launchpad.net
To post a comment you must log in.
Revision history for this message
Laurynas Biveinis (laurynas-biveinis) wrote :

    - 24: s/the certain query/a certain query,

    - 24: s/Per-query variable value/Per-query variable values

    - 39: s/if we want to limit the query execution time/to limit the
      execution time for a specific query

    - 49: I'd consider replacing the MyISAM-specific example with a
      combination of the previous two examples.

    - For furious flushing, this is my attempt to describe it:

      In certain situations it makes sense for InnoDB to flush pages
      as fast as possible instead of abiding to innodb_io_capacity
      setting and, starting with 5.6, innodb_lru_scan_depth. This is
      known as "furious flushing".

      Oracle MySQL 5.6 page cleaner flushes may perform furious
      flushing for the flush list up to innodb_io_capacity_max I/Os
      per second. We have extended this flush list flushing so that
      page cleaner thread sleep is skipped whenever the checkpoint age
      is in the sync preflush zone, allowing issuing more than
      innodb_io_capacity_max per second if needed.

      For the LRU flushing, Oracle MySQL 5.6 does not have furious
      flushing, which may cause single page LRU flushes in the case
      of empty free lists. We have implemented the LRU list furious
      flushing by allowing the page cleaner thread to sleep less if
      the free lists are nearly depleted. The sleep time is
      determined as follows: if free list is filled less than 1%: no
      sleep; less than 5%: 50ms shorter sleep time than the previous
      iteration; between 5% and 20%: no change; more than 20%: 50ms
      longer sleep time.

    - Please have a look at my comment at bug 1243067.

    - Bug 1188168: server could crash while accessing BLOB or TEXT
      columns in InnoDB tables if fake changes were enabled.

    - 1188172: other bugfixes.

review: Needs Fixing
Revision history for this message
Laurynas Biveinis (laurynas-biveinis) wrote :

    - 95: s/less than 1%:/less than 1% over all buffer pool instances

    - 173: "Percona Server| could crash server could crash",
      hyperlink "fake changes".

    - innodb_log_checksum_algorithm: experimental feature.

review: Needs Fixing
Revision history for this message
Laurynas Biveinis (laurynas-biveinis) wrote :

    - 144: s/write-intensive/I/O-bound
    - 173: "|Percona Server| could crash server could crash"
    - 211: "**Note**: this feature is currently considered experimental"

review: Needs Fixing
Revision history for this message
Laurynas Biveinis (laurynas-biveinis) :
review: Approve

Preview Diff

[H/L] Next/Prev Comment, [J/K] Next/Prev File, [N/P] Next/Prev Hunk
1=== modified file 'doc/source/conf.py'
2--- doc/source/conf.py 2013-10-23 08:48:28 +0000
3+++ doc/source/conf.py 2013-10-24 09:05:28 +0000
4@@ -54,7 +54,7 @@
5 # The short X.Y version.
6 version = '5.6'
7 # The full version, including alpha/beta/rc tags.
8-release = '5.6.13-61.0'
9+release = '5.6.14-62.0'
10
11 # The language for content autogenerated by Sphinx. Refer to documentation
12 # for a list of supported languages.
13
14=== added file 'doc/source/flexibility/per_query_variable_statement.rst'
15--- doc/source/flexibility/per_query_variable_statement.rst 1970-01-01 00:00:00 +0000
16+++ doc/source/flexibility/per_query_variable_statement.rst 2013-10-24 09:05:28 +0000
17@@ -0,0 +1,43 @@
18+.. _per_query_variable_statement:
19+
20+==============================
21+ Per-query variable statement
22+==============================
23+
24+|Percona Server| has implemented per-query variable statement support in :rn:`5.6.14-62.0`. This feature provides the ability to set variable values only for a certain query, after execution of which the previous values will be restored. Per-query variable values can be set up with the following command:
25+
26+.. code-block:: mysql
27+
28+ mysql> SET STATEMENT <variable=value> FOR <statement>;
29+
30+Examples
31+========
32+
33+If we want to increase the :variable:`sort_buffer_size` value just for one specific sort query we can do it like this:
34+
35+.. code-block:: mysql
36+
37+ mysql> SET STATEMENT sort_buffer_size=100000 FOR SELECT name FROM name ORDER BY name;
38+
39+This feature can also be used with :ref:`statement_timeout` to limit the execution time for a specific query:
40+
41+.. code-block:: mysql
42+
43+ mysql> SET STATEMENT max_statement_time=1000 FOR SELECT name FROM name ORDER BY name;
44+
45+We can provide more than one variable we want to set up:
46+
47+.. code-block:: mysql
48+
49+ mysql> SET STATEMENT sort_buffer_size=100000, max_statement_time=1000 FOR SELECT name FROM name ORDER BY name;
50+
51+Version Specific Information
52+============================
53+
54+ * :rn:`5.6.14-62.0`
55+ Feature implemented
56+
57+Other Reading
58+=============
59+* `WL#681: Per query variable settings <http://dev.mysql.com/worklog/task/?id=681>`_
60+
61
62=== modified file 'doc/source/index.rst'
63--- doc/source/index.rst 2013-10-07 17:07:37 +0000
64+++ doc/source/index.rst 2013-10-24 09:05:28 +0000
65@@ -73,7 +73,7 @@
66 performance/innodb_opt_lru_count
67 performance/threadpool
68 performance/page_cleaner_tuning
69- performance/xtradb_performance_improvements
70+ performance/xtradb_performance_improvements_for_io-bound_highly-concurrent_workloads
71
72 Flexibility Improvements
73 ========================
74@@ -88,6 +88,7 @@
75 flexibility/mysqldump_ignore_create_error
76 flexibility/buff_read_ahead_area
77 flexibility/extended_select_into_outfile
78+ flexibility/per_query_variable_statement
79
80 Reliability Improvements
81 ========================
82
83=== modified file 'doc/source/performance/page_cleaner_tuning.rst'
84--- doc/source/performance/page_cleaner_tuning.rst 2013-10-07 16:01:28 +0000
85+++ doc/source/performance/page_cleaner_tuning.rst 2013-10-24 09:05:28 +0000
86@@ -11,10 +11,17 @@
87
88 Usage of the of multiple buffer pool instances is `not uniform <http://mikaelronstrom.blogspot.com/2010/09/multiple-buffer-pools-in-mysql-55.html>`_. The non-uniform buffer pool instance use means non-uniform free list depletion levels, which in turn causes transient stalls or single page LRU flushes for the query threads, increasing latency, and LRU/free list mutex contention. |Percona Server| has added heuristics that reduce the occurrence of depleted free lists and associated mutex contentions. Instead of issuing all the chunk-size LRU flush requests for the 1st instance, then for the 2nd instance, etc, the requests are issued to all instances in a pseudo-parallel manner: the 1st chunk for the 1st instance, the 1st chunk for the 2nd instance, etc., the 2nd chunk for the 1st instance, the 2nd chunk for the 2nd instance, etc. Moreover, if a particular instance has a nearly depleted free list (currently defined as <10% of (:variable:`innodb_lru_scan_depth`);, might be changed in the future), then the server keeps on issuing requests for that instance until it's not depleted anymore, or the flushing limit for it has been reached.
89
90+Furious Flushing
91+================
92+
93+In certain situations it makes sense for InnoDB to flush pages as fast as possible instead of abiding to :variable:`innodb_io_capacity` setting and, starting with 5.6, :variable:`innodb_lru_scan_depth`. This is known as "furious flushing". Oracle |MySQL| 5.6 page cleaner flushes may perform furious flushing for the flush list up to :variable:`innodb_io_capacity_max` I/Os per second. We have extended this flush list flushing so that page cleaner thread sleep is skipped whenever the checkpoint age is in the sync preflush zone, allowing issuing more than :variable:`innodb_io_capacity_max` per second if needed.
94+
95+For the LRU flushing, Oracle |MySQL| 5.6 does not have furious flushing, which may cause single page LRU flushes in the case of empty free lists. We have implemented the LRU list furious flushing by allowing the page cleaner thread to sleep less if the free lists are nearly depleted. The sleep time is determined as follows: if free list is filled less than 1% over all buffer pool instances: no sleep; less than 5%: 50ms shorter sleep time than the previous iteration; between 5% and 20%: no change; more than 20%: 50ms longer sleep time.
96+
97 Timeouts
98 ========
99
100-|Percona Server| has implemented time limits for LRU and flush list flushes in a single page cleaner thread iteration. The thread assumes that one iteration of its main loop (LRU and flush list flushes) complete under 1 second, but under heavy load we have observed iterations taking up to 17 seconds. Such situations confuse the heuristics, and an LRU or a flush taking a long time prevents the other kind of flush from running, which in turn may cause query threads to perform sync preflushes or single page LRU flushes depending on the starved flush type. If a LRU flush timeout happens, the current flushing pass over all buffer pool instances is still completed in order to ensure that all the instances have received at least a bit of flushing. In order to implement this for flush list flushes, the flush requests for each buffer pool instance were broken up to chunks too.
101+|Percona Server| has implemented time limits for LRU and flush list flushes in a single page cleaner thread iteration. The thread assumes that one iteration of its main loop (LRU and flush list flushes) complete under 1 second, but under heavy load we have observed iterations taking up to 40 seconds. Such situations confuse the heuristics, and an LRU or a flush taking a long time prevents the other kind of flush from running, which in turn may cause query threads to perform sync preflushes or single page LRU flushes depending on the starved flush type. If a LRU flush timeout happens, the current flushing pass over all buffer pool instances is still completed in order to ensure that all the instances have received at least a bit of flushing. In order to implement this for flush list flushes, the flush requests for each buffer pool instance were broken up to chunks too.
102
103 Adaptive Flushing Tuning
104 ========================
105@@ -85,4 +92,5 @@
106
107 Other reading
108 =============
109-* :ref:`xtradb_performance_improvements`
110+* :ref:`xtradb_performance_improvements_for_io-bound_highly-concurrent_workloads`
111+* :mysqlbug:`68481` - InnoDB LRU flushing for MySQL 5.6 needs work
112
113=== renamed file 'doc/source/performance/xtradb_performance_improvements.rst' => 'doc/source/performance/xtradb_performance_improvements_for_io-bound_highly-concurrent_workloads.rst'
114--- doc/source/performance/xtradb_performance_improvements.rst 2013-10-09 13:57:11 +0000
115+++ doc/source/performance/xtradb_performance_improvements_for_io-bound_highly-concurrent_workloads.rst 2013-10-24 09:05:28 +0000
116@@ -1,8 +1,8 @@
117-.. _xtradb_performance_improvements:
118+.. _xtradb_performance_improvements_for_io-bound_highly-concurrent_workloads:
119
120-=================================
121- XtraDB Performance Improvements
122-=================================
123+===============================================================================
124+ XtraDB Performance Improvements for I/O-Bound Highly-Concurrent Workloads
125+===============================================================================
126
127 In |Percona Server| :rn:`5.6.13-61.0` a number of |XtraDB| performance improvements have been implemented for high-concurrency scenarios.
128
129
130=== modified file 'doc/source/release-notes/Percona-Server-5.6.13-61.0.rst'
131--- doc/source/release-notes/Percona-Server-5.6.13-61.0.rst 2013-10-09 13:57:11 +0000
132+++ doc/source/release-notes/Percona-Server-5.6.13-61.0.rst 2013-10-24 09:05:28 +0000
133@@ -6,12 +6,12 @@
134
135 Percona is glad to announce the first GA (Generally Available) release of |Percona Server| 5.6.13-61.0 on October 7th, 2013 (Downloads are available `here <http://www.percona.com/downloads/Percona-Server-5.6/Percona-Server-5.6.13-61.0/>`_ and from the :doc:`Percona Software Repositories </installation>`.
136
137-Based on `MySQL 5.6.13 <http://dev.mysql.com/doc/relnotes/mysql/5.6/en/news-5-6-13.html>`_, including all the bug fixes in it, |Percona Server| 5.6.13-61.0 is the first GA release in the |Percona Server| 5.6 series. All of |Percona|'s software is open-source and free, all the details of the release can be found in the `5.6.13-60.6 milestone at Launchpad <https://launchpad.net/percona-server/+milestone/5.6.13-61.0>`_.
138+Based on `MySQL 5.6.13 <http://dev.mysql.com/doc/relnotes/mysql/5.6/en/news-5-6-13.html>`_, including all the bug fixes in it, |Percona Server| 5.6.13-61.0 is the first GA release in the |Percona Server| 5.6 series. All of |Percona|'s software is open-source and free, all the details of the release can be found in the `5.6.13-61.0 milestone at Launchpad <https://launchpad.net/percona-server/+milestone/5.6.13-61.0>`_.
139
140 New Features
141 ============
142
143- |Percona Server| has implemented a number of :ref:`xtradb_performance_improvements` for high-concurrency scenarios. This feature fixes the upstream bug: :mysqlbug:`68555` (:bug:`1236884`).
144+ |Percona Server| has implemented a number of :ref:`XtraDB performance improvements for I/O-bound high-concurrency workloads <xtradb_performance_improvements_for_io-bound_highly-concurrent_workloads>`. This feature fixes the upstream bug: :mysqlbug:`68555` (:bug:`1236884`).
145
146 |Percona Server| has implemented a number of performance improvements for :ref:`page_cleaner_tuning`. This feature fixes the upstream bugs: :mysqlbug:`69170` (:bug:`1231918`), :mysqlbug:`70453` (:bug:`1232101`) and :mysqlbug:`68481` (:bug:`1232406`).
147
148
149=== added file 'doc/source/release-notes/Percona-Server-5.6.14-62.0.rst'
150--- doc/source/release-notes/Percona-Server-5.6.14-62.0.rst 1970-01-01 00:00:00 +0000
151+++ doc/source/release-notes/Percona-Server-5.6.14-62.0.rst 2013-10-24 09:05:28 +0000
152@@ -0,0 +1,35 @@
153+.. rn:: 5.6.14-62.0
154+
155+==============================
156+ |Percona Server| 5.6.14-62.0
157+==============================
158+
159+Percona is glad to announce the release of |Percona Server| 5.6.14-62.0 on October 24th, 2013 (Downloads are available `here <http://www.percona.com/downloads/Percona-Server-5.6/Percona-Server-5.6.14-62.0/>`_ and from the :doc:`Percona Software Repositories </installation>`.
160+
161+Based on `MySQL 5.6.14 <http://dev.mysql.com/doc/relnotes/mysql/5.6/en/news-5-6-14.html>`_, including all the bug fixes in it, |Percona Server| 5.6.14-62.0 is the current GA release in the |Percona Server| 5.6 series. All of |Percona|'s software is open-source and free, all the details of the release can be found in the `5.6.14-62.0 milestone at Launchpad <https://launchpad.net/percona-server/+milestone/5.6.14-62.0>`_.
162+
163+New Features
164+============
165+
166+ |Percona Server| has implemented more efficient log block checksums with new :variable:`innodb_log_checksum_algorithm` variable.
167+
168+ |Percona Server| has implemented support for :ref:`per_query_variable_statement`.
169+
170+Bugs Fixed
171+==========
172+
173+ |Percona Server| could crash while accessing ``BLOB`` or ``TEXT`` columns in |InnoDB| tables if :ref:`innodb_fake_changes_page` was enabled. Bug fixed :bug:`1188168`.
174+
175+ :ref:`expanded_option_modifiers` did not deallocate memory correctly. Bug fixed :bug:`1167487`.
176+
177+ Some :ref:`expanded_option_modifiers` didn't have an effect if they were specified in non-normalized way (:variable:`innodb_io_capacity` vs :variable:`innodb-io-capacity`). Bug fixed :bug:`1233294`.
178+
179+ Building |Percona Server| with ``-DHAVE_PURIFY`` option would result in an error. Fixed by porting the ``close_socket`` function from |MariaDB|. Bug fixed :bug:`1203567`.
180+
181+ Enabling :ref:`enforce_engine` feature could lead to error on |Percona Server| shutdown. Bug fixed :bug:`1233354`.
182+
183+ Storage engine enforcement (:variable:`enforce_storage_engine`) is now ignored when the server is started in either bootstrap or skip-grant-tables mode. Bug fixed :bug:`1236938`.
184+
185+ When installed |Percona Server| 5.6 GA release was still showing ``RC`` instead of ``GA`` on Debian-based systems. Bug fixed :bug:`1239418`.
186+
187+Other bugs fixed: bug fixed :bug:`1238008`, bug fixed :bug:`1190604`, bug fixed :bug:`1200162`, bug fixed :bug:`1188172`, and bug fixed :bug:`1214727`.
188
189=== modified file 'doc/source/release-notes/release-notes_index.rst'
190--- doc/source/release-notes/release-notes_index.rst 2013-10-23 08:48:28 +0000
191+++ doc/source/release-notes/release-notes_index.rst 2013-10-24 09:05:28 +0000
192@@ -6,6 +6,7 @@
193 :maxdepth: 1
194 :glob:
195
196+ Percona-Server-5.6.14-62.0
197 Percona-Server-5.6.13-61.0
198 Percona-Server-5.6.13-60.6
199 Percona-Server-5.6.13-60.5
200
201=== modified file 'doc/source/scalability/innodb_io.rst'
202--- doc/source/scalability/innodb_io.rst 2013-10-09 13:57:11 +0000
203+++ doc/source/scalability/innodb_io.rst 2013-10-24 09:05:28 +0000
204@@ -12,6 +12,10 @@
205 * :rn:`5.6.11-60.3`
206
207 * Feature ported from |Percona Server| 5.5
208+
209+ * :rn:`5.6.14-62.0`
210+
211+ * New :variable:`innodb_log_checksum_algorithm` variable introduced.
212
213 System Variables
214 ================
215@@ -77,6 +81,34 @@
216 * ``ALL_O_DIRECT``:
217 use O_DIRECT to open both data and log files, and use ``fsync()`` to flush the data files but not 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.
218
219+
220+.. variable:: innodb_log_checksum_algorithm
221+
222+ :Version Info: - :rn:`5.6.14-62.0` - Variable introduced
223+ :cli: Yes
224+ :conf: Yes
225+ :scope: Global
226+ :Dyn: No
227+ :vartype: Enumeration
228+ :default: ``innodb``
229+ :allowed: ``none``, ``innodb``, ``crc32``, ``strict_none``, ``strict_innodb``, ``strict_crc32``
230+
231+This variable is used to specify how log checksums are generated and verified. Behavior of :variable:`innodb_log_checksum_algorithm` depending on its value is mostly identical to :variable:`innodb_checksum_algorithm`, except that the former applies to log rather than page checksums. **NOTE**: this feature is currently considered experimental.
232+
233+The following values are allowed:
234+
235+ * ``none``:
236+ means that a constant value will be written to log blocks instead of calculated checksum values and no checksum validation will be performed on InnoDB/XtraBackup recovery, or changed page tracking (if enabled).
237+
238+ * ``innodb``:
239+ (the default) means the default |InnoDB| behavior -- a custom and inefficient algorithm is used to calculate log checksums, but logs created with this option are compatible with upstream |MySQL| and earlier |Percona Server| or |Percona XtraBackup| versions that do not support other log checksum algorithms.
240+
241+ * ``crc32``:
242+ will use CRC32 for log block checksums. Checksums will also benefit from hardware acceleration provided by recent Intel CPUs.
243+
244+ * ``strict_*``:
245+ Normally, |XtraDB| or |Percona XtraBackup| will tolerate checksums created with other algorithms than is currently specified with the :variable:`innodb_log_checksum_algorithm` option. That is, if checksums don't match when reading the redo log on recovery, the block is considered corrupted only if no algorithm produces the value matching the checksum stored in the log block header. This can be disabled by prepending the value with the ``strict_`` suffix, e.g. ``strict_none``, ``strict_crc32`` or ``strict_innodb`` will only accept checksums created using the corresponding algorithms, but not the other ones.
246+
247 Status Variables
248 ----------------
249

Subscribers

People subscribed via source and target branches