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

Proposed by Hrvoje Matijakovic on 2012-01-16
Status: Merged
Approved by: Alexey Kopytov on 2012-01-17
Approved revision: 379
Merged at revision: 379
Proposed branch: lp:~hrvojem/percona-xtrabackup/docfix
Merge into: lp:percona-xtrabackup/2.0
Diff against target: 452 lines (+163/-94)
8 files modified
doc/source/conf.py (+3/-1)
doc/source/glossary.rst (+4/-4)
doc/source/howtos/recipes_ibkx_inc.rst (+1/-1)
doc/source/howtos/setting_up_replication.rst (+150/-85)
doc/source/howtos/ssh_server.rst (+1/-1)
doc/source/innobackupex/innobackupex_option_reference.rst (+2/-1)
doc/source/innobackupex/preparing_a_backup_ibk.rst (+1/-1)
doc/source/xtrabackup_bin/preparing_the_backup.rst (+1/-0)
To merge this branch: bzr merge lp:~hrvojem/percona-xtrabackup/docfix
Reviewer Review Type Date Requested Status
Alexey Kopytov (community) 2012-01-16 Approve on 2012-01-17
Review via email: mp+88670@code.launchpad.net

Description of the change

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

To post a comment you must log in.
Alexey Kopytov (akopytov) wrote :

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) wrote :

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) wrote :

Looks good now.

review: Approve
Alexey Kopytov (akopytov) wrote :

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

review: Needs Fixing
Alexey Kopytov (akopytov) wrote :

OK to merge.

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 2011-09-24 04:42:37 +0000
3+++ doc/source/conf.py 2012-01-17 09:06:25 +0000
4@@ -44,7 +44,7 @@
5
6 # General information about the project.
7 project = u'Percona XtraBackup'
8-copyright = u'2011, Percona Inc'
9+copyright = u'2012, Percona Inc'
10
11 # The version info for the project you're documenting, acts as replacement for
12 # |version| and |release|, also used in various other places throughout the
13@@ -100,6 +100,8 @@
14
15 .. |MyISAM| replace:: :term:`MyISAM`
16
17+.. |Percona Toolkit| replace:: *Percona Toolkit*
18+
19 .. |LSN| replace:: :term:`LSN`
20
21 .. |XtraBackup| replace:: *XtraBackup*
22
23=== modified file 'doc/source/glossary.rst'
24--- doc/source/glossary.rst 2011-07-07 05:32:50 +0000
25+++ doc/source/glossary.rst 2012-01-17 09:06:25 +0000
26@@ -18,7 +18,7 @@
27 or start the server with ``--innodb_file_per_table``.
28
29 innodb_expand_import
30- This feature of |Percona Server| implements the abililty to import arbitrary :term:`.ibd` files exported using the |XtraBackup| :option:`--export` option.
31+ This feature of |Percona Server| implements the ability to import arbitrary :term:`.ibd` files exported using the |XtraBackup| :option:`--export` option.
32
33 See the `the full documentation <http://www.percona.com/docs/wiki/percona-server:features:innodb_import_table_from_xtrabackup?redirect=2>`_ for more information.
34
35@@ -55,7 +55,7 @@
36 innodb_buffer_pool_size=8MB
37
38 InnoDB
39- 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.
40+ 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.
41
42 MyISAM
43 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`
44@@ -91,10 +91,10 @@
45 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.
46
47 .TRG
48- File containing the TRiGgers associated to a table, e.g. `:file:`mytable.TRG`. With the :term:`.TRN` file, they represent all the Trigger definitions.
49+ File containing the Triggers associated to a table, e.g. `:file:`mytable.TRG`. With the :term:`.TRN` file, they represent all the Trigger definitions.
50
51 .TRN
52- 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.
53+ 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.
54
55 .ARM
56 Each table with the :program:`Archive Storage Engine` has ``.ARM`` file which contains the metadata of it.
57
58=== modified file 'doc/source/howtos/recipes_ibkx_inc.rst'
59--- doc/source/howtos/recipes_ibkx_inc.rst 2011-07-07 05:32:50 +0000
60+++ doc/source/howtos/recipes_ibkx_inc.rst 2012-01-17 09:06:25 +0000
61@@ -38,7 +38,7 @@
62
63 *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``.
64
65-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.
66+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.
67
68 You can check the file xtrabackup_checkpoints at the directory of each one.
69
70
71=== modified file 'doc/source/howtos/setting_up_replication.rst'
72--- doc/source/howtos/setting_up_replication.rst 2012-01-04 03:37:24 +0000
73+++ doc/source/howtos/setting_up_replication.rst 2012-01-17 09:06:25 +0000
74@@ -1,84 +1,140 @@
75 .. _replication_howto:
76
77 ========================================================================
78- How to setup a slave for replication in 5 simple steps with Xtrabackup
79+ How to setup a slave for replication in 6 simple steps with Xtrabackup
80 ========================================================================
81
82 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.
83
84- You can have almost real-time backups in 5 simple steps by setting up a replication environment with |XtraBackup|.
85+ You can have almost real-time backups in 6 simple steps by setting up a replication environment with |XtraBackup|.
86
87- *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.
88+ *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.
89
90 All the things you will need
91 ============================
92
93 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:
94
95-* ``The Master``
96- 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:
97+* ``TheMaster``
98+ 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:
99
100 * the |MySQL| server is able to communicate with others by the standard TCP/IP port;
101
102 * the *SSH* server is installed and configured;
103
104- * you have an user account in the system with the appropiate permissions;
105-
106- * you have a MySQL's user account with appropiate privileges.
107-
108-
109-* ``The Slave``
110- 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``.
111+ * you have an user account in the system with the appropriate permissions;
112+
113+ * you have a MySQL's user account with appropriate privileges.
114+
115+ * server has binlogs enabled and server-id set up to 1.
116+
117+
118+* ``TheSlave``
119+ 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``.
120
121 * ``Xtrabackup``
122 The backup tool we will use. It should be installed in both computers for convenience.
123
124-STEP 1: Make a backup on ``The Master`` and stream it to ``The Slave``
125-======================================================================
126-
127-At ``The Master``, issue the following to a shell:
128-
129-.. code-block:: console
130-
131- TheMaster$ innobackupex --user=yourDBuser --password=MaGiCdB1 \
132- --stream=tar /tmp/ | \
133- ssh user@THESLAVE "tar xfi - -C /var/lib/mysql"
134-
135-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).
136-
137-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.
138+STEP 1: Make a backup on ``TheMaster`` and prepare it
139+=====================================================
140+
141+At ``TheMaster``, issue the following to a shell:
142+
143+.. code-block:: console
144+
145+ TheMaster$ innobackupex --user=yourDBuser --password=MaGiCdB1 /path/to/backupdir
146+
147+After this is finished you should get:
148+
149+.. code-block:: console
150+
151+ innobackupex: completed OK!
152+
153+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).
154+
155+In order for snapshot to be consistent you need to prepare the data:
156+
157+.. code-block:: console
158+
159+ TheMaster$ innobackupex --user=yourDBuser --password=MaGiCdB1 /
160+ --apply-log /path/to/backupdir/$TIMESTAMP/
161+
162+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.
163
164 |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``.
165
166-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``.
167-
168-STEP 2: Apply the logs to the data
169-==================================
170-
171-At ``The Slave``, tell |XtraBackup| to apply the binary logs to the data with:
172-
173-.. code-block:: console
174-
175- TheSlave$ innobackupex --apply-log --use-memory=2G /var/lib/mysql
176-
177-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.
178-
179-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.
180-
181-STEP 3: Configure The Slave's MySQL server
182+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:
183+
184+.. code-block:: console
185+
186+ [client]
187+ user=root
188+ pass=MaGiCdB1
189+
190+This is will give you root access to MySQL.
191+
192+STEP 2: Copy backed up data to TheSlave
193+========================================
194+
195+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.
196+
197+.. code-block:: console
198+
199+ TheMaster$ rsync -avprP -e ssh /path/to/backupdir/$TIMESTAMP TheSlave:/path/to/mysql/
200+
201+After data has been copied you can back up the original or previously installed |MySQL| datadir:
202+
203+.. code-block:: console
204+
205+ TheSlave$ mv /path/to/mysql/datadir /path/to/mysql/datadir_bak
206+
207+and move the snapshot from ``TheMaster`` in its place:
208+
209+.. code-block:: console
210+
211+ TheSlave$ mv /path/to/mysql/$TIMESTAMP /path/to/mysql/datadir
212+
213+After you copy data over, make sure |MySQL| has proper permissions to access them.
214+
215+.. code-block:: console
216+
217+ TheSlave$ chown mysql:mysql /path/to/mysql/datadir
218+
219+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.
220+
221+STEP 3: Configure The Master's MySQL server
222+===========================================
223+
224+Add the appropriate grant in order for slave to be able to connect to master:
225+
226+.. code-block:: mysql
227+
228+ TheMaster|mysql> GRANT REPLICATION SLAVE ON *.* TO 'repl'@'$slaveip'
229+ IDENTIFIED BY '$slavepass';
230+
231+Also make sure that firewall rules are correct and that ``TheSlave`` can connect to ``TheMaster``.
232+
233+STEP 4: Configure The Slave's MySQL server
234 ==========================================
235
236-First copy the :term:`my.cnf` file from ``The Master`` to ``The Slave``:
237+First copy the :term:`my.cnf` file from ``TheMaster`` to ``TheSlave``:
238
239 .. code-block:: console
240
241 TheSlave$ scp user@TheMaster:/etc/mysql/my.cnf /etc/mysql/my.cnf
242
243-and start/restart :command:`mysqld` on ``The Slave``.
244-
245-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.
246-
247-STEP 4: Start the replication
248+then change the following options in /etc/mysql/my.cnf:
249+
250+.. code-block:: console
251+
252+ server-id=2
253+
254+and start/restart :command:`mysqld` on ``TheSlave``.
255+
256+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`.
257+
258+
259+STEP 5: Start the replication
260 =============================
261
262 Look at the content of the file :file:`xtrabackup_binlog_info`, it will be something like:
263@@ -86,15 +142,16 @@
264 .. code-block:: console
265
266 TheSlave$ cat /var/lib/mysql/xtrabackup_binlog_info
267- TheMaster-bin.000001 481
268+ TheMaster-bin.000001 481
269
270-Execute the ``CHANGE MASTER`` statement on a mysql console but remember to add to it your database user and password in ``The Master``:
271+Execute the ``CHANGE MASTER`` statement on a MySQL console and use the username and password you've set up in STEP 3:
272
273 .. code-block:: mysql
274
275 TheSlave|mysql> CHANGE MASTER TO
276- MASTER_USER='DBuserInTheMaster',
277- MASTER_PASSWORD='m4g1cM4st3r',
278+ MASTER_HOST='$masterip',
279+ MASTER_USER='repl',
280+ MASTER_PASSWORD='$slavepass',
281 MASTER_LOG_FILE='TheMaster-bin.000001',
282 MASTER_LOG_POS=481;
283
284@@ -104,7 +161,7 @@
285
286 TheSlave|mysql> START SLAVE;
287
288-STEP 5: Check
289+STEP 6: Check
290 =============
291
292 You should check that everything went OK with:
293@@ -119,56 +176,64 @@
294 Seconds_Behind_Master: 13
295 ...
296
297-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``.
298+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``.
299
300 Adding more slaves to The Master
301 ================================
302
303-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.
304-
305-At ``The Slave``, do a full backup and stream it to ``The New Slave``:
306-
307-.. code-block:: console
308-
309- TheSlave$ innobackupex --user=yourDBuser --password=MaGiCiGaM \
310- --stream=tar /tmp/ --slave-info | \
311- ssh user@TheNEWSlave "tar xfi - -C /var/lib/mysql"
312-
313-and apply the logs on ``The NEW Slave``:
314-
315-.. code-block:: console
316-
317- TheNEWSlave$ innobackupex --apply-log --use-memory=2G /var/lib/mysql
318-
319-and copy the configuration file from ``The Slave``:
320+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.
321+
322+At ``TheSlave``, do a full backup:
323+
324+.. code-block:: console
325+
326+ TheSlave$ innobackupex --user=yourDBuser --password=MaGiCiGaM /
327+ --slave-info /path/to/backupdir
328+
329+By using the :option:`--slave-info` Xtrabackup creates additional file called :file:`xtrabackup_slave_info`.
330+
331+Apply the logs:
332+
333+.. code-block:: console
334+
335+ TheSlave$ innobackupex --apply-log --use-memory=2G /path/to/backupdir/$TIMESTAMP/
336+
337+Copy the directory from the ``TheSlave`` to ``TheNewSlave``:
338+
339+.. code-block:: console
340+
341+ rsync -avprP -e ssh /path/to/backupdir/$TIMESTAMP TheNewSlave:/path/to/mysql/datadir
342+
343+Add additional grant on the master:
344+
345+.. code-block:: mysql
346+
347+ TheMaster|mysql> GRANT REPLICATION SLAVE ON *.* TO 'repl'@'$newslaveip'
348+ IDENTIFIED BY '$slavepass';
349+
350+Copy the configuration file from ``TheSlave``:
351
352 .. code-block:: console
353
354 TheNEWSlave$ scp user@TheSlave:/etc/mysql/my.cnf /etc/mysql/my.cnf
355
356-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
357+Make sure you change the server-id variable in :file:`/etc/mysql/my.cnf` to 3 and disable the replication on start:
358
359 .. code-block:: console
360
361- TheNEWSlave$ echo '\nSERVER_ID=3' >> /etc/mysql/my.cnf
362-
363-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``.
364+ skip-slave-start
365+ server-id=3
366
367 After setting ``server_id``, start :command:`mysqld`.
368
369-As we backed up a slave that was doing a replication, in a :command:`mysql` console tell the server to stop doing it:
370-
371-.. code-block:: mysql
372-
373- TheNEWSlave|mysql> STOP SLAVE;
374-
375-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``:
376+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``:
377
378 .. code-block:: mysql
379
380 TheNEWSlave|mysql> CHANGE MASTER TO
381- MASTER_USER='DBuserInTheMaster',
382- MASTER_PASSWORD='m4g1cM4st3r',
383+ MASTER_HOST='$masterip'
384+ MASTER_USER='repl',
385+ MASTER_PASSWORD='$slavepass',
386 MASTER_LOG_FILE='TheMaster-bin.000001',
387 MASTER_LOG_POS=481;
388
389@@ -178,4 +243,4 @@
390
391 TheSlave|mysql> START SLAVE;
392
393-and we have a The NEW Slave replicating The Master.
394+If both IO and SQL threads are running when you check the ``TheNewSlave``, server is replicating ``TheMaster``.
395
396=== modified file 'doc/source/howtos/ssh_server.rst'
397--- doc/source/howtos/ssh_server.rst 2011-07-07 05:32:50 +0000
398+++ doc/source/howtos/ssh_server.rst 2012-01-17 09:06:25 +0000
399@@ -7,7 +7,7 @@
400 ubuntu$ sudo apt-get install openssh-server
401 archlinux$ sudo pacman -S openssh
402
403-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.
404+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.
405
406 Some links of them are:
407
408
409=== modified file 'doc/source/innobackupex/innobackupex_option_reference.rst'
410--- doc/source/innobackupex/innobackupex_option_reference.rst 2011-11-15 14:54:45 +0000
411+++ doc/source/innobackupex/innobackupex_option_reference.rst 2012-01-17 09:06:25 +0000
412@@ -89,6 +89,7 @@
413 .. option:: --no-lock
414
415 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.
416+ 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`.
417
418 .. option:: --ibbackup = 'autodetect'
419
420@@ -112,7 +113,7 @@
421
422 .. option:: --extra-lsndir
423
424- 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.
425+ 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.
426
427 .. option:: --remote-host
428
429
430=== modified file 'doc/source/innobackupex/preparing_a_backup_ibk.rst'
431--- doc/source/innobackupex/preparing_a_backup_ibk.rst 2011-07-07 05:32:50 +0000
432+++ doc/source/innobackupex/preparing_a_backup_ibk.rst 2012-01-17 09:06:25 +0000
433@@ -19,7 +19,7 @@
434 ==============
435 reading the configuration from the files in the backup directory,
436
437-|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.
438+|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.
439
440 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>`.
441
442
443=== modified file 'doc/source/xtrabackup_bin/preparing_the_backup.rst'
444--- doc/source/xtrabackup_bin/preparing_the_backup.rst 2012-01-03 10:14:48 +0000
445+++ doc/source/xtrabackup_bin/preparing_the_backup.rst 2012-01-17 09:06:25 +0000
446@@ -36,6 +36,7 @@
447 All following prepares (third and following) will not change the already prepared data files, you can only see that output says
448
449 .. code-block:: console
450+
451 xtrabackup: This target seems to be already prepared.
452 xtrabackup: notice: xtrabackup_logfile was already used to '--prepare'.
453

Subscribers

People subscribed via source and target branches