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

[Hrvoje Matijakovic]

[Laurynas Biveinis (laurynas-biveinis)]

   - 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

[Laurynas Biveinis (laurynas-biveinis)]

review: Approve

=== added file 'doc/source/flexibility/mysqldump_ignore_create_error.rst'
--- doc/source/flexibility/mysqldump_ignore_create_error.rst	1970-01-01 00:00:00 +0000
+++ doc/source/flexibility/mysqldump_ignore_create_error.rst	2013-01-30 09:34:40 +0000
@@ -0,0 +1,22 @@
+.. _mysqldump_ignore_create_error:
+
+======================================
+ Ignoring missing tables in mysqldump
+======================================
+
+In case table name was changed during the :command:`mysqldump` process taking place, :command:`mysqldump` would stop with error: :: 
+
+   Couldn't execute 'show create table testtable'
+   Table 'testdb.tabletest' doesn't exist (1146)\n")
+
+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.
+
+With this option :command:`mysqldump` will still show error to ``stderr``, but it will continue to work and dump the rest of the tables.
+
+Version Specific Information
+============================
+
+  * :rn:`1.0.6-rel10.1`
+    :command:`mysqldump` option :option:`--ignore-create-error` introduced
+
+

=== modified file 'doc/source/flexibility/replication_skip_single_statement.rst'
--- doc/source/flexibility/replication_skip_single_statement.rst	2012-12-13 12:31:02 +0000
+++ doc/source/flexibility/replication_skip_single_statement.rst	2013-01-30 09:34:40 +0000
@@ -50,7 +50,7 @@
 Consider this case: ::
 
   SET GLOBAL sql_slave_statement_skip_counter=n;
-  SET GLOBAL sql_slave__skip_counter=m;
+  SET GLOBAL sql_slave_skip_counter=m;
 
 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**.
 

=== modified file 'doc/source/index.rst'
--- doc/source/index.rst	2012-12-13 12:31:02 +0000
+++ doc/source/index.rst	2013-01-30 09:34:40 +0000
@@ -92,6 +92,7 @@
    flexibility/replication_skip_single_statement
    flexibility/buff_read_ahead_area
    flexibility/innodb_fast_shutdown
+   flexibility/mysqldump_ignore_create_error
 
 Reliability Improvements
 ========================

=== modified file 'doc/source/management/sql_no_fcache.rst'
--- doc/source/management/sql_no_fcache.rst	2012-12-13 12:31:02 +0000
+++ doc/source/management/sql_no_fcache.rst	2013-01-30 09:34:40 +0000
@@ -4,7 +4,7 @@
 Prevent Caching to FlashCache
 ==============================
 
-*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.
+`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.
 
 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.
 
@@ -21,6 +21,33 @@
   * :rn:`5.1.49-rel12.0`:
     Full functionality available.
 
+  * :rn:`5.1.66-14.1`:
+    Variable :variable:`have_flashcache` introduced.
+
+System Variables
+================
+.. variable:: have_flashcache
+
+   :version 5.1.66-14.1: Variable introduced
+   :cli: Yes
+   :conf: Yes
+   :scope: Global
+   :dyn: No
+   :vartype: Boolean
+   :range: Yes/No
+
+This variable shows if the server was compiled with Flashcache support.
+
+Status Variables
+================
+.. variable:: Flashcache_enabled
+
+   :scope: Global
+   :vartype: Boolean
+   :range: OFF/ON
+
+This status variable shows if the Flashcache support has been enabled.
+
 Other Information
 =================
 
@@ -32,3 +59,4 @@
   * `Releasing Flashcache <http://www.facebook.com/note.php?note_id=388112370932>`_
 
   * `Level 2 Flash cache is there <http://www.mysqlperformanceblog.com/2010/04/27/level-2-flash-cache-is-there/>`_
+ 

=== modified file 'doc/source/performance/innodb_doublewrite_path.rst'
--- doc/source/performance/innodb_doublewrite_path.rst	2012-12-13 12:31:02 +0000
+++ doc/source/performance/innodb_doublewrite_path.rst	2013-01-30 09:34:40 +0000
@@ -19,7 +19,7 @@
 Goal of the Doublewrite Buffer
 ------------------------------
 
-|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.
+|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.
 
 |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.
 
@@ -27,7 +27,7 @@
 
 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.
 
-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.
+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.
 
 Performance Impact of the Doublewrite Buffer
 --------------------------------------------

=== modified file 'doc/source/release-notes/Percona-Server-5.1.67-14.3.rst'
--- doc/source/release-notes/Percona-Server-5.1.67-14.3.rst	2013-01-18 09:27:58 +0000
+++ doc/source/release-notes/Percona-Server-5.1.67-14.3.rst	2013-01-30 09:34:40 +0000
@@ -4,7 +4,7 @@
  |Percona Server| 5.1.67-14.3 
 ==============================
 
-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>`_).
+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>`_).
 
 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>`_.
 

=== modified file 'doc/source/scalability/innodb_io.rst'
--- doc/source/scalability/innodb_io.rst	2012-12-13 12:31:02 +0000
+++ doc/source/scalability/innodb_io.rst	2013-01-30 09:34:40 +0000
@@ -131,6 +131,7 @@
 
 .. variable:: innodb_flush_method
 
+     :version 5.1.54-12.5: ``ALL_O_DIRECT`` option added
      :cli: Yes
      :conf: Yes
      :scope: Global
@@ -152,7 +153,7 @@
   * ``O_DIRECT``: 
     Use ``O_DIRECT`` (or ``directio()`` on Solaris) to open the data files; use ``fsync()`` to flush both the data and log files.
 
-  * ``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`.
+  * ``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.
 
 
 .. variable:: innodb_flush_neighbor_pages