Author: paul
Date: 2010-03-03 19:11:13 +0100 (Wed, 03 Mar 2010)
New Revision: 19401
Log:
r50080@frost: paul | 2010-03-03 12:09:49 -0500
MySQL Backup revisions
Modified:
trunk/mysql-backup/backup.xml
trunk/mysql-backup/repl-backup-tmp.xml
trunk/mysql-backup/replication.xml
trunk/mysql-backup/syntax.xml
Property changes on: trunk
___________________________________________________________________
Name: svk:merge
- 07c7e7b4-24e3-4b51-89d0-6dc09fec6bec:/mysqldoc-local/mysqldoc/trunk:35498
07c7e7b4-24e3-4b51-89d0-6dc09fec6bec:/mysqldoc-local/trunk:37130
4767c598-dc10-0410-bea0-d01b485662eb:/mysqldoc-local/mysqldoc/trunk:43968
4767c598-dc10-0410-bea0-d01b485662eb:/mysqldoc-local/trunk:44480
7d8d2c4e-af1d-0410-ab9f-b038ce55645b:/mysqldoc-local/mysqldoc:50074
b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:14218
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:39036
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/trunk:39546
+ 07c7e7b4-24e3-4b51-89d0-6dc09fec6bec:/mysqldoc-local/mysqldoc/trunk:35498
07c7e7b4-24e3-4b51-89d0-6dc09fec6bec:/mysqldoc-local/trunk:37130
4767c598-dc10-0410-bea0-d01b485662eb:/mysqldoc-local/mysqldoc/trunk:43968
4767c598-dc10-0410-bea0-d01b485662eb:/mysqldoc-local/trunk:44480
7d8d2c4e-af1d-0410-ab9f-b038ce55645b:/mysqldoc-local/mysqldoc:50080
b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:14218
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:39036
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/trunk:39546
Modified: trunk/mysql-backup/backup.xml
===================================================================
--- trunk/mysql-backup/backup.xml 2010-03-03 16:01:02 UTC (rev 19400)
+++ trunk/mysql-backup/backup.xml 2010-03-03 18:11:13 UTC (rev 19401)
Changed blocks: 2, Lines Added: 7, Lines Deleted: 6; 1474 bytes
@@ -792,11 +792,11 @@
<literal role="stmt">RESTORE</literal> statements are not written
to the binary log and therefore are not replicated to slaves. Nor
is any data backed up or restored logged or replicated. However,
- for <literal role="stmt">RESTORE</literal>, a gap event is logged
- unless <literal>SKIP_GAP_EVENT</literal> is specified. This event
- signals slaves that they should stop replicating because an event
- has occurred on the master that results in loss of master/slave
- synchrony.
+ for <literal role="stmt">RESTORE</literal>, an incident event is
+ logged unless <literal>SKIP_GAP_EVENT</literal> is specified. This
+ event signals slaves that they should stop replicating because an
+ event has occurred on the master that results in loss of
+ master/slave synchrony.
</para>
<para>
@@ -813,7 +813,8 @@
apply for <literal role="stmt">BACKUP DATABASE</literal>, so it is
not written to the backup image or
<literal>backup_history</literal>. For
- <literal role="stmt">RESTORE</literal>, not gap event is written.
+ <literal role="stmt">RESTORE</literal>, no incident event is
+ written.
</para>
</section>
Modified: trunk/mysql-backup/repl-backup-tmp.xml
===================================================================
--- trunk/mysql-backup/repl-backup-tmp.xml 2010-03-03 16:01:02 UTC (rev 19400)
+++ trunk/mysql-backup/repl-backup-tmp.xml 2010-03-03 18:11:13 UTC (rev 19401)
Changed blocks: 9, Lines Added: 20, Lines Deleted: 15; 4393 bytes
@@ -123,7 +123,7 @@
<listitem>
<para>
- Copy the backup image to the slave.
+ Copy the backup image from the master to the slave.
</para>
</listitem>
@@ -355,7 +355,8 @@
<listitem>
<para>
- Copy the backup image to the new slave.
+ Copy the backup image from the existing slave to the new
+ slave.
</para>
</listitem>
@@ -438,8 +439,8 @@
</itemizedlist>
<para>
- To restore a single server from a backup image and perform
- point-in-time recovery, the following procedure suffices:
+ To restore a single nonreplicated server from a backup image and
+ perform point-in-time recovery, the following procedure suffices:
</para>
<orderedlist>
@@ -483,8 +484,8 @@
<para>
The <literal role="stmt">RESTORE</literal> statement does not
include the <literal>SKIP_GAP_EVENT</literal> option. That
- way, it writes a gap event to the binary log so that you have
- a <quote>marker</quote> to look for to identify when the
+ way, it writes an incident event to the binary log so that you
+ have a <quote>marker</quote> to look for to identify when the
restore operation occurred. The point in the binary log just
past this event is where you will need to tell the slaves to
begin replicating again after they have been restored. Suppose
@@ -506,7 +507,7 @@
<para>
<literal>end_log_pos</literal> is the position just past the
- gap event. This indicates that slaves will need to begin
+ incident event. This indicates that slaves will need to begin
replicating at log file <filename>binlog.001057</filename>,
position 177 after they have been restored.
</para>
@@ -532,7 +533,7 @@
<listitem>
<para>
- Copy the backup image to the slave.
+ Copy the backup image from the master to the slave.
</para>
</listitem>
@@ -549,7 +550,7 @@
<listitem>
<para>
Tell the slave the new master binary log coordinates (just
- past the gap event) and restart replication:
+ past the incident event) and restart replication:
</para>
<programlisting>
@@ -582,17 +583,18 @@
On the master, perform point-in-time recovery. As events are
re-executed, they will be written to the binary log and
replicated to the slaves. To perform point-in-time recovery on
- the master, follow these instructions:
+ the master, determine the applicable range of events from the
+ binary log, and then re-execute them:
</para>
<orderedlist>
<listitem>
<para>
- Determine the range of events to be executed from the
- binary log. The beginning coordinates are those associated
- with the backup image used to restore the master and
- slaves (the backup validity point). Use the
+ Determine the beginning coordinates for the range of
+ events. These coordinates are those associated with the
+ backup image used to restore the master and slaves (the
+ backup validity point). Use the
<command>mysqlbackup</command> program to obtain these
coordinates from the backup image:
</para>
@@ -607,9 +609,12 @@
This indicates that the beginning coordinates are
(<filename>binlog.001053</filename>, 40878).
</para>
+ </listitem>
+ <listitem>
<para>
- The ending coordinates are those just before the crash or
+ Determine the ending coordinates for the range of events.
+ These coordinates are those just before the crash or
data-loss event. To determine these, you must look through
the binary log to find out where that event occurs.
Suppose that data loss has occurred due to a mistaken
Modified: trunk/mysql-backup/replication.xml
===================================================================
--- trunk/mysql-backup/replication.xml 2010-03-03 16:01:02 UTC (rev 19400)
+++ trunk/mysql-backup/replication.xml 2010-03-03 18:11:13 UTC (rev 19401)
Changed blocks: 7, Lines Added: 26, Lines Deleted: 24; 4483 bytes
@@ -46,11 +46,11 @@
<literal role="stmt">RESTORE</literal> statements are not written
to the binary log and therefore are not replicated to slaves. Nor
is any data backed up or restored logged or replicated. However,
- for <literal role="stmt">RESTORE</literal>, a gap event is logged
- unless <literal>SKIP_GAP_EVENT</literal> is specified. This event
- signals slaves that they should stop replicating because an event
- has occurred on the master that results in loss of master/slave
- synchrony.
+ for <literal role="stmt">RESTORE</literal>, an incident event is
+ logged unless <literal>SKIP_GAP_EVENT</literal> is specified. This
+ event signals slaves that they should stop executing events
+ because an event has occurred on the master that results in loss
+ of master/slave synchrony.
</para>
<para>
@@ -67,7 +67,8 @@
apply for <literal role="stmt">BACKUP DATABASE</literal>, so it is
not written to the backup image or
<literal>backup_history</literal>. For
- <literal role="stmt">RESTORE</literal>, not gap event is written.
+ <literal role="stmt">RESTORE</literal>, no incident event is
+ written.
</para>
<para>
@@ -169,10 +170,11 @@
<listitem>
<para>
- The <literal role="stmt">RESTORE</literal> operation writes a
- gap event to the binary log unless
+ The <literal role="stmt">RESTORE</literal> operation writes an
+ incident event to the binary log unless
<literal>SKIP_GAP_EVENT</literal> is specified. This causes
- any slave that receives this event to stop replicating.
+ any slave that receives this event to stop executing any
+ further events.
</para>
</listitem>
@@ -281,11 +283,11 @@
<para>
When <literal>SKIP_GAP_EVENT</literal> is not specified,
- <literal role="stmt">RESTORE</literal> generates a gap event in
- the binary log to cause slaves to stop replicating when they
- receive the event. As each slave stops, the following procedure
- should be performed on that slave to resynchronize it to the
- master and restart replication:
+ <literal role="stmt">RESTORE</literal> generates an incident event
+ in the binary log to cause slaves to stop executing further events
+ when they receive the event. As each slave stops, the following
+ procedure should be performed on that slave to resynchronize it to
+ the master and restart replication:
</para>
<orderedlist>
@@ -305,7 +307,7 @@
<listitem>
<para>
- Skip the gap event that was received from the master and
+ Skip the incident event that was received from the master and
restart replication:
</para>
@@ -375,8 +377,8 @@
</programlisting>
<para>
- In this case, <literal>db2</literal> is restored, no gap event is
- written to the binary log, and replication of
+ In this case, <literal>db2</literal> is restored, no incident
+ event is written to the binary log, and replication of
<literal>db1</literal> is uninterrupted (which is the desired
result).
</para>
@@ -392,13 +394,13 @@
<para>
In this case, <literal>db2</literal> is restored, but the
- <literal role="stmt">RESTORE</literal> statement generates a gap
- event in the binary log that causes the slave to stop replicating
- when it receives the event. As a result, replication stops for
- <literal>db1</literal>, even though <literal>db1</literal> was not
- involved in the backup or restore operations. At this point, it is
- necessary on the slave to skip the gap event and restart
- replication:
+ <literal role="stmt">RESTORE</literal> statement generates an
+ incident event in the binary log that causes the slave to stop
+ executing further events when it receives the event. As a result,
+ replication stops for <literal>db1</literal>, even though
+ <literal>db1</literal> was not involved in the backup or restore
+ operations. At this point, it is necessary on the slave to skip
+ the incident event and restart replication:
</para>
<programlisting>
Modified: trunk/mysql-backup/syntax.xml
===================================================================
--- trunk/mysql-backup/syntax.xml 2010-03-03 16:01:02 UTC (rev 19400)
+++ trunk/mysql-backup/syntax.xml 2010-03-03 18:11:13 UTC (rev 19401)
Changed blocks: 2, Lines Added: 6, Lines Deleted: 6; 1535 bytes
@@ -504,10 +504,10 @@
The <literal>SKIP_GAP_EVENT</literal> can be useful when executing
a <literal role="stmt">RESTORE</literal> statement on a
replication master. Normally, when a restore operation executes on
- a master, a gap event is written to the binary log to signal all
- slaves to stop replication. This is a protective measure to ensure
- that whatever changes the restore makes on the master do not break
- replication.
+ a master, an incident event is written to the binary log to signal
+ all slaves to stop executing events. This is a protective measure
+ to ensure that whatever changes the restore makes on the master do
+ not break replication.
</para>
<para>
@@ -519,8 +519,8 @@
slave. Under these conditions, the slaves need not be stopped and
the restore is safe to execute without disrupting replication. The
<literal>SKIP_GAP_EVENT</literal> option accomplishes this because
- it causes the gap event not to be written to the binary log. See
- <xref linkend="restore-non-replicated-databases"/>.
+ it causes the incident event not to be written to the binary log.
+ See <xref linkend="restore-non-replicated-databases"/>.
</para>
<remark role="help-description-end"/>
| Thread |
|---|
| • svn commit - mysqldoc@docsrva: r19401 - in trunk: . mysql-backup | paul.dubois | 3 Mar |
