Merge lp:~hrvojem/percona-xtrabackup/bug1295444-2.1 into lp:percona-xtrabackup/2.1

[Hrvoje Matijakovic]

[Alexey Kopytov (akopytov)]

review: Approve

[Alexey Kopytov (akopytov)]

Should we merge (or link to) http://www.percona.com/doc/percona-xtrabackup/2.2/innobackupex/storing_history.html#privileges?

review: Needs Information

[Alexey Kopytov (akopytov)]

Err, wrong MP.

=== modified file 'doc/source/innobackupex/improved_ftwrl.rst'
--- doc/source/innobackupex/improved_ftwrl.rst	2013-09-11 06:23:12 +0000
+++ doc/source/innobackupex/improved_ftwrl.rst	2014-12-18 13:01:24 +0000
@@ -18,7 +18,7 @@
 
 Another possibility is to specify the type of query to wait on. In this case :option:`innobackupex --lock-wait-query-type`. Possible values are ``all`` and ``update``. When ``all`` is used |innobackupex| will wait for all long running queries (execution time longer than allowed by :option:`innobackupex --lock-wait-threshold`) to finish before running the ``FLUSH TABLES WITH READ LOCK``. When ``update`` is used |innobackupex| will wait on ``UPDATE/ALTER/REPLACE/INSERT`` queries to finish.
 
-Although time needed for specific query to complete is hard to predict, we can assume that queries that are running for a long time already will likely not be completed soon, and queries which are running for a short time will likely be completed shortly. |innobackupex| can use the value of :option:`innobackupex --lock-wait-threshold` option to specify which query is long running and will likely block global lock for a while.
+Although time needed for specific query to complete is hard to predict, we can assume that queries that are running for a long time already will likely not be completed soon, and queries which are running for a short time will likely be completed shortly. |innobackupex| can use the value of :option:`innobackupex --lock-wait-threshold` option to specify which query is long running and will likely block global lock for a while. In order to use this option xtrabackup user should have ``PROCESS`` and ``SUPER`` privileges.
 
 Killing the blocking queries
 ----------------------------

=== modified file 'doc/source/innobackupex/privileges.rst'
--- doc/source/innobackupex/privileges.rst	2013-08-30 09:55:04 +0000
+++ doc/source/innobackupex/privileges.rst	2014-12-18 13:01:24 +0000
@@ -49,13 +49,15 @@
 
 The database user needs the following privileges on the tables / databases to be backed up:
 
-  * ``RELOAD`` and ``LOCK TABLES`` (unless the :option:`--no-lock <innobackupex --no-lock>` option is specified) in order to ``FLUSH TABLES WITH READ LOCK`` prior to start copying the files and 
+  * ``RELOAD`` and ``LOCK TABLES`` (unless the :option:`--no-lock <innobackupex --no-lock>` option is specified) in order to ``FLUSH TABLES WITH READ LOCK`` and ``FLUSH ENGINE LOGS`` prior to start copying the files,  
 
   * ``REPLICATION CLIENT`` in order to obtain the binary log position,
 
-  * ``CREATE TABLESPACE`` in order to import tables (see :ref:`imp_exp_ibk`) and
-
-  * ``SUPER`` in order to start/stop the slave threads in a replication environment.
+  * ``CREATE TABLESPACE`` in order to import tables (see :ref:`imp_exp_ibk`),
+
+  * ``PROCESS`` in order to see all threads which are running on the server (see :ref:`improved_ftwrl`),
+
+  * ``SUPER`` in order to start/stop the slave threads in a replication environment, use `XtraDB Changed Page Tracking <https://www.percona.com/doc/percona-server/5.6/management/changed_page_tracking.html>`_ for :ref:`xb_incremental` and for :ref:`improved_ftwrl`.
 
 The explanation of when these are used can be found in :ref:`how_ibk_works`.