Merge lp:~hrvojem/percona-xtrabackup/docfix into lp:percona-xtrabackup/2.0

[Hrvoje Matijakovic]

Fixed some errors that were reporting when building the html docs
Fixed bug #914422

[Alexey Kopytov (akopytov)]

Hrvoje,

The changes look generally good to me. I just had a number of minor comments/questions:

1. |Percona Toolkit| is defined as a macro for ":term:`Percona Toolkit`", but is not actually used anywhere?

There's also an inconsistency. |XtraBackup| and |Percona Server| are defined as just emphasized text rather than terms. Shouldn't |Percona Toolkit| be defined in the same way?

2. s/reffer/refer/g ?

3. Please keep "innobackupex" in examples and not replace it with "innobackupex-1.5.1", as the latter is an old name, it's currently just a symlink to innobackupex.

4. Any specific reasons for removing streaming backups from the replication setup guidelines? It's not like it's wrong, I'm just curious.

5. I'm not sure "mv /path/to/mysql/TIMESTAMP /path/to/mysql/datadir" will do the right thing. I think it will move all files to a subdirectory of datadir, which is not what we really want to do?

6. Shouldn't we make it clear somehow that TIMESTAMP in examples should not be typed literally, but replaced with the actual directory name?

7. s/slights variation/slight variations/ ? (I know it's not your text, but might be a good idea to fix spelling once you are touching that line)

8. s/previuos/previous/

9. Please don't reuse branches for different MPs. As a result, this MP now contains fixes for both bug #878457 and bug #914422. Which makes it harder to manage and review.

review: Needs Fixing

[Hrvoje Matijakovic (hrvojem)]

On 16.01.2012 14:35, Alexey Kopytov wrote:
> Review: Needs Fixing
>
> Hrvoje,
>
> The changes look generally good to me. I just had a number of minor comments/questions:
>
> 1. |Percona Toolkit| is defined as a macro for ":term:`Percona Toolkit`", but is not actually used anywhere?
>
> There's also an inconsistency. |XtraBackup| and |Percona Server| are defined as just emphasized text rather than terms. Shouldn't |Percona Toolkit| be defined in the same way?
>
fixed
> 2. s/reffer/refer/g ?
fixed
>
> 3. Please keep "innobackupex" in examples and not replace it with "innobackupex-1.5.1", as the latter is an old name, it's currently just a symlink to innobackupex.
fixed
>
> 4. Any specific reasons for removing streaming backups from the replication setup guidelines? It's not like it's wrong, I'm just curious.
>
No special reason. I somehow figured out this was more simple solution.
But I can make another one with streaming or put it back as it was.

> 5. I'm not sure "mv /path/to/mysql/TIMESTAMP /path/to/mysql/datadir" will do the right thing. I think it will move all files to a subdirectory of datadir, which is not what we really want to do?

root@arrakis:/# mv /tmp/2012-01-16_11-14-43 /tmp/test/mysql
root@arrakis:/# ls -lah /tmp/test/mysql
total 31M
drwxr-xr-x 6 root root 4,0K Sij 16 11:19 .
drwxr-xr-x 3 root root 4,0K Sij 16 14:41 ..
-rw-r--r-- 1 root root 324 Sij 16 11:14 backup-my.cnf
drwxr-xr-x 2 root root 4,0K Sij 16 11:15 cacti
-rw-r--r-- 1 root root 18M Sij 16 11:19 ibdata1
-rw-r--r-- 1 root root 5,0M Sij 16 11:19 ib_logfile0
-rw-r--r-- 1 root root 5,0M Sij 16 11:19 ib_logfile1

>
> 6. Shouldn't we make it clear somehow that TIMESTAMP in examples should not be typed literally, but replaced with the actual directory name?

I've changed it to $TIMESTAMP and added the short note: You need to
select path where your snapshot has been taken, for example
/home/backups/2012-01-16_11-14-43

>
> 7. s/slights variation/slight variations/ ? (I know it's not your text, but might be a good idea to fix spelling once you are touching that line)
fixed
>
> 8. s/previuos/previous/
fixed
>
> 9. Please don't reuse branches for different MPs. As a result, this MP now contains fixes for both bug #878457 and bug #914422. Which makes it harder to manage and review.
yeah sorry about that one.

[Alexey Kopytov (akopytov)]

Looks good now.

review: Approve

[Alexey Kopytov (akopytov)]

Changing to In Progress to take additional notes in bug #914422 into account.

review: Needs Fixing

[Alexey Kopytov (akopytov)]

OK to merge.

review: Approve

=== modified file 'doc/source/conf.py'
--- doc/source/conf.py	2011-09-24 04:42:37 +0000
+++ doc/source/conf.py	2012-01-17 09:06:25 +0000
@@ -44,7 +44,7 @@
 
 # General information about the project.
 project = u'Percona XtraBackup'
-copyright = u'2011, Percona Inc'
+copyright = u'2012, Percona Inc'
 
 # The version info for the project you're documenting, acts as replacement for
 # |version| and |release|, also used in various other places throughout the
@@ -100,6 +100,8 @@
 
 .. |MyISAM|  replace:: :term:`MyISAM`
 
+.. |Percona Toolkit|  replace:: *Percona Toolkit*
+
 .. |LSN|  replace:: :term:`LSN`
 
 .. |XtraBackup|  replace:: *XtraBackup*

=== modified file 'doc/source/glossary.rst'
--- doc/source/glossary.rst	2011-07-07 05:32:50 +0000
+++ doc/source/glossary.rst	2012-01-17 09:06:25 +0000
@@ -18,7 +18,7 @@
       or start the server with ``--innodb_file_per_table``.
 
    innodb_expand_import
-     This feature of |Percona Server| implements the abililty to import arbitrary :term:`.ibd` files exported using the |XtraBackup| :option:`--export` option.
+     This feature of |Percona Server| implements the ability to import arbitrary :term:`.ibd` files exported using the |XtraBackup| :option:`--export` option.
      
      See the `the full documentation <http://www.percona.com/docs/wiki/percona-server:features:innodb_import_table_from_xtrabackup?redirect=2>`_ for more information.
 
@@ -55,7 +55,7 @@
          innodb_buffer_pool_size=8MB
 
    InnoDB
-      Storage engine which provides ACID-compilant transactions and foreing key support, among others improvements over :term:`MyISAM`. It is the default engine for |MySQL| as of the 5.5 series.
+      Storage engine which provides ACID-compliant transactions and foreign key support, among others improvements over :term:`MyISAM`. It is the default engine for |MySQL| as of the 5.5 series.
 
    MyISAM
      Previous default storage engine for |MySQL| for versions prior to 5.5. It doesn't fully support transactions but in some scenarios may be faster than :term:`InnoDB`. Each table is stored on disk in 3 files: :term:`.frm`, :term:`.MYD`, :term:`.MYI`
@@ -91,10 +91,10 @@
      Each table using the :program:`MERGE` storage engine, besides of a :term:`.frm` file, will have :term:`.MRG` file containing the names of the |MyISAM| tables associated with it.
 
    .TRG
-     File containing the TRiGgers associated to a table, e.g. `:file:`mytable.TRG`. With the :term:`.TRN` file, they represent all the Trigger definitions.
+     File containing the Triggers associated to a table, e.g. `:file:`mytable.TRG`. With the :term:`.TRN` file, they represent all the Trigger definitions.
 
    .TRN
-     File containing the TRiggers' Names associated to a table, e.g. `:file:`mytable.TRN`. With the :term:`.TRG` file, they represent all the Trigger definitions.
+     File containing the Triggers' Names associated to a table, e.g. `:file:`mytable.TRN`. With the :term:`.TRG` file, they represent all the Trigger definitions.
 
    .ARM
      Each table with the :program:`Archive Storage Engine` has ``.ARM`` file which contains the metadata of it.

=== modified file 'doc/source/howtos/recipes_ibkx_inc.rst'
--- doc/source/howtos/recipes_ibkx_inc.rst	2011-07-07 05:32:50 +0000
+++ doc/source/howtos/recipes_ibkx_inc.rst	2012-01-17 09:06:25 +0000
@@ -38,7 +38,7 @@
 
 *The final data will be in the base backup directory*, not in the incremental one. In this example, ``/path/to/backup/dir/2011-12-24_23-01-00`` or ``$FULLBACKUP``.
 
-If you want to apply more incremental backups, repeat this step with the next one. It is important that you do this in the chronological order in where the the backups were done.
+If you want to apply more incremental backups, repeat this step with the next one. It is important that you do this in the chronological order in where the backups were done.
 
 You can check the file xtrabackup_checkpoints at the directory of each one.
 

=== modified file 'doc/source/howtos/setting_up_replication.rst'
--- doc/source/howtos/setting_up_replication.rst	2012-01-04 03:37:24 +0000
+++ doc/source/howtos/setting_up_replication.rst	2012-01-17 09:06:25 +0000
@@ -1,84 +1,140 @@
 .. _replication_howto:
 
 ========================================================================
- How to setup a slave for replication in 5 simple steps with Xtrabackup
+ How to setup a slave for replication in 6 simple steps with Xtrabackup
 ========================================================================
 
   Data is, by far, the most valuable part of a system. Having a backup done systematically and available for a rapid recovery in case of failure is admittedly essential to a system. However, it is not common practice because of its costs, infrastructure needed or even the boredom associated to the task. Xtrabackup is designed to solve this problem.
 
-  You can have almost real-time backups in 5 simple steps by setting up a replication environment with |XtraBackup|. 
+  You can have almost real-time backups in 6 simple steps by setting up a replication environment with |XtraBackup|. 
 
- *Percona* |XtraBackup| is a tool for backing up your data extremely easy and without interruption. It performs "hot backups" on unmodified versions of |MySQL| servers (5.0 and 5.1), as well as |MariaDB| and *Percona Servers*. It is a totally free and open source software distributed only under the *GPLv2* license.
+ *Percona* |XtraBackup| is a tool for backing up your data extremely easy and without interruption. It performs "hot backups" on unmodified versions of |MySQL| servers (5.0, 5.1 and 5.5), as well as |MariaDB| and *Percona Servers*. It is a totally free and open source software distributed only under the *GPLv2* license.
 
 All the things you will need
 ============================
 
 Setting up a slave for replication with |XtraBackup| is really a very straightforward procedure. In order to keep it simple, here is a list of the things you need to follow the steps without hassles:
 
-* ``The Master`` 
-  A system with a |MySQL|-based server installed, configured and running. This system will be called ``The Master``, as it is where your data is stored and the one to be replicated. We will assume the following about this system:
+* ``TheMaster`` 
+  A system with a |MySQL|-based server installed, configured and running. This system will be called ``TheMaster``, as it is where your data is stored and the one to be replicated. We will assume the following about this system:
 
   * the |MySQL| server is able to communicate with others by the standard TCP/IP port;
 
   * the *SSH* server is installed and configured;
 
-  * you have an user account in the system with the appropiate permissions;
-
-  * you have a MySQL's user account with appropiate privileges.
-
-
-* ``The Slave`` 
-  Another system, with a |MySQL|-based server installed on it. We will reffer to this machine as ``The Slave`` and we will assume the same things we did about ``The Master``.
+  * you have an user account in the system with the appropriate permissions;
+
+  * you have a MySQL's user account with appropriate privileges.
+
+  * server has binlogs enabled and server-id set up to 1.
+
+
+* ``TheSlave`` 
+  Another system, with a |MySQL|-based server installed on it. We will refer to this machine as ``TheSlave`` and we will assume the same things we did about ``TheMaster``.
 
 * ``Xtrabackup``
   The backup tool we will use. It should be installed in both computers for convenience.
 
-STEP 1: Make a backup on ``The Master`` and stream it to ``The Slave``
-======================================================================
-
-At ``The Master``, issue the following to a shell:
-
-.. code-block:: console
-
-   TheMaster$ innobackupex --user=yourDBuser --password=MaGiCdB1 \ 
-               --stream=tar /tmp/ | \
-               ssh user@THESLAVE "tar xfi - -C /var/lib/mysql"
-
-You have told |XtraBackup| (through the |innobackupex| script) to connect to the database server using your database user and password, and do a hot backup of all your data in it (all |MyISAM|, |InnoDB| tables and indexes in them).
-
-Instead of writing it to a file, we printed it to ``STDOUT``, so it can be piped - via :command:`ssh` - to :command:`tar` in ``The Slave``, which will extract the files directly to ``The Slave`` 's data directory.
+STEP 1: Make a backup on ``TheMaster`` and prepare it
+=====================================================
+
+At ``TheMaster``, issue the following to a shell:
+
+.. code-block:: console
+
+   TheMaster$ innobackupex --user=yourDBuser --password=MaGiCdB1 /path/to/backupdir 
+
+After this is finished you should get:
+
+.. code-block:: console
+
+   innobackupex: completed OK! 
+
+This will make a copy of your |MySQL| data dir to the /path/to/backupdir/$TIMESTAMP. You have told |XtraBackup| (through the |innobackupex| script) to connect to the database server using your database user and password, and do a hot backup of all your data in it (all |MyISAM|, |InnoDB| tables and indexes in them).
+
+In order for snapshot to be consistent you need to prepare the data:
+
+.. code-block:: console
+
+   TheMaster$ innobackupex --user=yourDBuser --password=MaGiCdB1 /
+              --apply-log /path/to/backupdir/$TIMESTAMP/
+
+You need to select path where your snapshot has been taken, for example /home/backups/2012-01-16_11-14-43. If everything is ok you should get the same OK message. Now the transaction logs are applied to the data files, and new ones are created: your data files are ready to be used by the MySQL server.
 
 |XtraBackup| knows where your data is by reading your :term:`my.cnf`. If you have your configuration file in a non-standard place, you should use the flag :option:`--defaults-file` ``=/location/of/my.cnf``.
 
-If, instead of ``--stream=tar /tmp/``, you give a directory to |innobackupex|, then the backup will be kept in ``The Master`` 's filesystem. A subdirectory will be created on the path you gave it and its name will be the current timestamp. You should copy that entire subdirectory to ``The Slave``, for example, with ``scp -r 2011-12-31_23-59-59``.
-
-STEP 2: Apply the logs to the data
-==================================
-
-At ``The Slave``, tell |XtraBackup| to apply the binary logs to the data with:
-
-.. code-block:: console
-
-   TheSlave$ innobackupex --apply-log --use-memory=2G  /var/lib/mysql
-
-Now the transaction logs are applied to the data files, and new ones are created: your data files are ready to be used by the MySQL server. 
-
-The :option:`--use-memory` ``=2G`` option indicates Xtrabackup to use 2 Gigabytes of RAM for the process. Adjust this amount to your situation in order to speed up the task. 
-
-STEP 3: Configure The Slave's MySQL server
+If you want to skip writing the username/password every time you want to access the MySQL, you can set it up in your $HOME folder. Just edit .my.cnf and add:
+
+.. code-block:: console
+   
+   [client]
+   user=root
+   pass=MaGiCdB1
+
+This is will give you root access to MySQL. 
+
+STEP 2:  Copy backed up data to TheSlave
+========================================
+
+Use rsync or scp to copy the data from Master to Slave. If you're syncing the data directly to slave's data directory it's advised to stop the mysqld there. 
+
+.. code-block:: console
+
+   TheMaster$ rsync -avprP -e ssh /path/to/backupdir/$TIMESTAMP TheSlave:/path/to/mysql/
+
+After data has been copied you can back up the original or previously installed |MySQL| datadir:
+
+.. code-block:: console
+
+   TheSlave$ mv /path/to/mysql/datadir /path/to/mysql/datadir_bak
+
+and move the snapshot from ``TheMaster`` in its place:
+
+.. code-block:: console
+
+   TheSlave$ mv /path/to/mysql/$TIMESTAMP /path/to/mysql/datadir
+
+After you copy data over, make sure |MySQL| has proper permissions to access them.
+
+.. code-block:: console
+
+   TheSlave$ chown mysql:mysql /path/to/mysql/datadir
+
+In case the ibdata and iblog files are located in different directories outside of the datadir, you will have to put them in their proper place after the logs have been applied.
+
+STEP 3: Configure The Master's MySQL server
+===========================================
+
+Add the appropriate grant in order for slave to be able to connect to master: 
+
+.. code-block:: mysql
+
+   TheMaster|mysql> GRANT REPLICATION SLAVE ON *.*  TO 'repl'@'$slaveip'
+    IDENTIFIED BY '$slavepass';
+
+Also make sure that firewall rules are correct and that ``TheSlave`` can connect to ``TheMaster``.
+
+STEP 4: Configure The Slave's MySQL server
 ==========================================
 
-First copy the :term:`my.cnf` file from ``The Master`` to ``The Slave``:
+First copy the :term:`my.cnf` file from ``TheMaster`` to ``TheSlave``:
 
 .. code-block:: console
 
    TheSlave$ scp user@TheMaster:/etc/mysql/my.cnf /etc/mysql/my.cnf
 
-and start/restart :command:`mysqld` on ``The Slave``.
-
-You can do this without problems because you are replicating the "whole server". As it is the first slave that ``The Master`` has, |MySQL| will do the rest automatically.
-
-STEP 4: Start the replication
+then change the following options in /etc/mysql/my.cnf:
+
+.. code-block:: console
+
+   server-id=2
+
+and start/restart :command:`mysqld` on ``TheSlave``.
+
+In case you're using init script to start mysqld, be sure that the password for that user has been updated and it's the same as one on ``TheMaster``. For example, Debian and Ubuntu use debian-sys-maint user to do that. Password can be seen and updated in :file:`/etc/mysql/debian.cnf`.
+
+
+STEP 5: Start the replication
 =============================
 
 Look at the content of the file :file:`xtrabackup_binlog_info`, it will be something like:
@@ -86,15 +142,16 @@
 .. code-block:: console
 
    TheSlave$ cat /var/lib/mysql/xtrabackup_binlog_info
-    TheMaster-bin.000001     481
+   TheMaster-bin.000001     481
 
-Execute the ``CHANGE MASTER`` statement on a mysql console but remember to add to it your database user and password in ``The Master``:
+Execute the ``CHANGE MASTER`` statement on a MySQL console and use the username and password you've set up in STEP 3: 
 
 .. code-block:: mysql
 
    TheSlave|mysql> CHANGE MASTER TO 
-                   MASTER_USER='DBuserInTheMaster',
-                   MASTER_PASSWORD='m4g1cM4st3r',
+                   MASTER_HOST='$masterip',	
+                   MASTER_USER='repl',
+                   MASTER_PASSWORD='$slavepass',
                    MASTER_LOG_FILE='TheMaster-bin.000001', 
                    MASTER_LOG_POS=481;
 
@@ -104,7 +161,7 @@
 
    TheSlave|mysql> START SLAVE;
 
-STEP 5: Check
+STEP 6: Check
 =============
 
 You should check that everything went OK with:
@@ -119,56 +176,64 @@
             Seconds_Behind_Master: 13
             ...
 
-The ``Seconds_Behind_Master`` means the ``SQL`` currently being executed has a ``current_timestamp`` of 13 seconds ago. It is an estimation of the lag between ``The Master`` and ``The Slave``. Note that at the begining, a high value should be shown because ``The Slave`` has to "catch up" with ``The Master``.
+Both ``IO`` and ``SQL`` threads need to be running. The ``Seconds_Behind_Master`` means the ``SQL`` currently being executed has a ``current_timestamp`` of 13 seconds ago. It is an estimation of the lag between ``TheMaster`` and ``TheSlave``. Note that at the beginning, a high value could be shown because ``TheSlave`` has to "catch up" with ``TheMaster``.
 
 Adding more slaves to The Master
 ================================
 
-You can use this procedure with slights variation to add new slaves to a master. We will use |Xtrabackup| to clone an already configured slave. We will continue using the previuos scenario for convenience but we will add ``The NEW Slave`` to the plot.
-
-At ``The Slave``, do a full backup and stream it to ``The New Slave``:
-
-.. code-block:: console
-
-   TheSlave$ innobackupex --user=yourDBuser --password=MaGiCiGaM \ 
-               --stream=tar /tmp/ --slave-info | \
-               ssh user@TheNEWSlave "tar xfi - -C /var/lib/mysql"
-
-and apply the logs on ``The NEW Slave``:
-
-.. code-block:: console
-
-   TheNEWSlave$ innobackupex --apply-log --use-memory=2G /var/lib/mysql
-
-and copy the configuration file from ``The Slave``:
+You can use this procedure with slight variation to add new slaves to a master. We will use |Xtrabackup| to clone an already configured slave. We will continue using the previous scenario for convenience but we will add ``TheNewSlave`` to the plot.
+
+At ``TheSlave``, do a full backup:
+
+.. code-block:: console
+
+   TheSlave$ innobackupex --user=yourDBuser --password=MaGiCiGaM /
+             --slave-info /path/to/backupdir 
+
+By using the :option:`--slave-info` Xtrabackup creates additional file called :file:`xtrabackup_slave_info`.
+
+Apply the logs:
+
+.. code-block:: console
+
+   TheSlave$ innobackupex --apply-log --use-memory=2G /path/to/backupdir/$TIMESTAMP/
+
+Copy the directory from the ``TheSlave`` to ``TheNewSlave``:
+
+.. code-block:: console
+
+   rsync -avprP -e ssh /path/to/backupdir/$TIMESTAMP TheNewSlave:/path/to/mysql/datadir
+
+Add additional grant on the master:
+
+.. code-block:: mysql
+
+	TheMaster|mysql> GRANT REPLICATION SLAVE ON *.*  TO 'repl'@'$newslaveip'
+                     IDENTIFIED BY '$slavepass';
+
+Copy the configuration file from ``TheSlave``:
 
 .. code-block:: console
 
    TheNEWSlave$ scp user@TheSlave:/etc/mysql/my.cnf /etc/mysql/my.cnf
 
-Now comes a slight variation on the procedure: before starting the |MySQL| server, set the variable ``server_id`` in :term:`my.cnf` to a value greater than 2, for example, with
+Make sure you change the server-id variable in :file:`/etc/mysql/my.cnf` to 3 and disable the replication on start:
 
 .. code-block:: console
 
-   TheNEWSlave$ echo '\nSERVER_ID=3' >> /etc/mysql/my.cnf
-
-This is because on a replication environment with one master and one slave, if the variable is not setted (as default) |MySQL| assumes 1 for ``server_id`` in the master and 2 in the slave. If you don't change it, |MySQL| will assume a value of 2 in ``The New Slave`` again: the replication will fail because all servers involved must have a different ``server_id``.
+   skip-slave-start
+   server-id=3
 
 After setting ``server_id``, start :command:`mysqld`.
 
-As we backed up a slave that was doing a replication, in a :command:`mysql` console tell the server to stop doing it:
-
-.. code-block:: mysql
-
-   TheNEWSlave|mysql> STOP SLAVE;
-
-With the help of the file :file:`xtrabackup_slave_info`, execute the statement for setting up the master and the log file for ``The NEW Slave``:
+Fetch the master_log_file and master_log_pos from the file :file:`xtrabackup_slave_info`, execute the statement for setting up the master and the log file for ``The NEW Slave``:
 
 .. code-block:: mysql
 
    TheNEWSlave|mysql> CHANGE MASTER TO 
-                      MASTER_USER='DBuserInTheMaster',
-                      MASTER_PASSWORD='m4g1cM4st3r',
+                      MASTER_HOST='$masterip'
+                      MASTER_USER='repl',
+                      MASTER_PASSWORD='$slavepass',
                       MASTER_LOG_FILE='TheMaster-bin.000001', 
                       MASTER_LOG_POS=481;
 
@@ -178,4 +243,4 @@
 
    TheSlave|mysql> START SLAVE;
 
-and we have a The NEW Slave replicating The Master.
+If both IO and SQL threads are running when you check the ``TheNewSlave``, server is replicating ``TheMaster``.

=== modified file 'doc/source/howtos/ssh_server.rst'
--- doc/source/howtos/ssh_server.rst	2011-07-07 05:32:50 +0000
+++ doc/source/howtos/ssh_server.rst	2012-01-17 09:06:25 +0000
@@ -7,7 +7,7 @@
      ubuntu$ sudo apt-get install openssh-server
   archlinux$ sudo pacman -S openssh
 
-You may need to take a look at your distribution's documentation or search for a tutorial in the internet to configure it if you haven't done it before. 
+You may need to take a look at your distribution's documentation or search for a tutorial in the Internet to configure it if you haven't done it before. 
 
 Some links of them are:
 

=== modified file 'doc/source/innobackupex/innobackupex_option_reference.rst'
--- doc/source/innobackupex/innobackupex_option_reference.rst	2011-11-15 14:54:45 +0000
+++ doc/source/innobackupex/innobackupex_option_reference.rst	2012-01-17 09:06:25 +0000
@@ -89,6 +89,7 @@
 .. option:: --no-lock
 
    Use this option to disable table lock with ``FLUSH TABLES WITH READ LOCK``. Use it only if ALL your tables are InnoDB and you **DO NOT CARE** about the binary log position of the backup.
+   If you are considering to use :option:`--no-lock` because your backups are failing to acquire the lock, this could be because of incoming replication events preventing the lock from succeeding. Please try using :option:`--safe-slave-backup` to momentarily stop the replication slave thread, this may help the backup to succeed and you then don't need to resort to using :option:`--no-lock`.
 
 .. option:: --ibbackup = 'autodetect'
 
@@ -112,7 +113,7 @@
 
 .. option:: --extra-lsndir
 
-   This option accepts a string argument that specifies the directory in which to save an extra copy of the :file:`xtrabackup_checkpoints` file. It is passed directly to |xtrabackup| 's :option:`--extra-lsndir` option. See the :program:`xtrabackup` documentation for details.
+   This option accepts a string argument that specifies the directory in which to save an extra copy of the :file:`xtrabackup_checkpoints` file. It is passed directly to |xtrabackup|'s :option:`--extra-lsndir` option. See the :program:`xtrabackup` documentation for details.
 
 .. option:: --remote-host
 

=== modified file 'doc/source/innobackupex/preparing_a_backup_ibk.rst'
--- doc/source/innobackupex/preparing_a_backup_ibk.rst	2011-07-07 05:32:50 +0000
+++ doc/source/innobackupex/preparing_a_backup_ibk.rst	2012-01-17 09:06:25 +0000
@@ -19,7 +19,7 @@
 ==============
 reading the configuration from the files in the backup directory,
 
-|innobackupex| replayed the committed transactions in the logfiles (some transactions could have been done while the backup was being done) and rolled back the uncommitted ones. Once this is done, all the information lay in the tablespace (the InnoDB files), and the logfiles are re-created.
+|innobackupex| replayed the committed transactions in the log files (some transactions could have been done while the backup was being done) and rolled back the uncommitted ones. Once this is done, all the information lay in the tablespace (the InnoDB files), and the log files are re-created.
 
 This implied calling :program:`xtrabackup --prepare` twice with the right binary (determined through the :file:`xtrabackup_binary` or by connecting the server). More details of this process are shown in the :doc:`xtrabackup section <../xtrabackup_bin/preparing_the_backup>`.
 

=== modified file 'doc/source/xtrabackup_bin/preparing_the_backup.rst'
--- doc/source/xtrabackup_bin/preparing_the_backup.rst	2012-01-03 10:14:48 +0000
+++ doc/source/xtrabackup_bin/preparing_the_backup.rst	2012-01-17 09:06:25 +0000
@@ -36,6 +36,7 @@
 All following prepares (third and following) will not change the already prepared data files, you can only see that output says
 
 .. code-block:: console
+
   xtrabackup: This target seems to be already prepared.
   xtrabackup: notice: xtrabackup_logfile was already used to '--prepare'.