Author: paul
Date: 2008-09-03 21:44:36 +0200 (Wed, 03 Sep 2008)
New Revision: 11656
Log:
r32966@arctic: paul | 2008-09-03 14:36:33 -0500
Misc. replication revisions
Modified:
trunk/refman-5.0/replication-configuration.xml
trunk/refman-5.0/replication.xml
trunk/refman-5.1/replication-configuration.xml
trunk/refman-5.1/replication.xml
trunk/refman-6.0/replication-configuration.xml
trunk/refman-6.0/replication.xml
Property changes on: trunk
___________________________________________________________________
Name: svk:merge
- 4767c598-dc10-0410-bea0-d01b485662eb:/mysqldoc-local/mysqldoc/trunk:35828
7d8d2c4e-af1d-0410-ab9f-b038ce55645b:/mysqldoc-local/mysqldoc:33589
b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:14218
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:32943
+ 4767c598-dc10-0410-bea0-d01b485662eb:/mysqldoc-local/mysqldoc/trunk:35828
7d8d2c4e-af1d-0410-ab9f-b038ce55645b:/mysqldoc-local/mysqldoc:33589
b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:14218
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:32966
Modified: trunk/refman-5.0/replication-configuration.xml
===================================================================
--- trunk/refman-5.0/replication-configuration.xml 2008-09-03 17:32:32 UTC (rev 11655)
+++ trunk/refman-5.0/replication-configuration.xml 2008-09-03 19:44:36 UTC (rev 11656)
Changed blocks: 12, Lines Added: 40, Lines Deleted: 37; 8884 bytes
@@ -10,23 +10,23 @@
<para>
Replication between servers in MySQL works through the use of the
binary logging mechanism. The MySQL instance operating as the master
- (the source of the database changes) writes updates and changes to
- the database to the binary log. The information in the binary log is
- stored in different logging formats according to the database
- changes being recorded. Slaves are configured to read the binary log
- from the master and to execute the events in the binary log on the
- slave's local database.
+ (the source of the database changes) writes updates and changes as
+ <quote>events</quote> to the binary log. The information in the
+ binary log is stored in different logging formats according to the
+ database changes being recorded. Slaves are configured to read the
+ binary log from the master and to execute the events in the binary
+ log on the slave's local database.
</para>
<para>
- The Master is dumb in this scenario. Once binary logging has been
+ The master is dumb in this scenario. Once binary logging has been
enabled, all statements are recorded in the binary log. Each slave
will receive a copy of the entire contents of the binary log. It is
the responsibility of the slave to decide which statements in the
binary log should be executed; you cannot configure the master to
log only certain events. If you do not specify otherwise, all events
in the master binary log are executed on the slave. If required, you
- can configure the slave to only process events that apply to
+ can configure the slave to process only events that apply to
particular databases or tables.
</para>
@@ -39,15 +39,15 @@
disconnected from the server without affecting the master's
operation. Also, because each slave remembers the position within
the binary log, it is possible for slaves to be disconnected,
- reconnect and then 'catch up' by continuing from the recorded
- position.
+ reconnect and then <quote>catch up</quote> by continuing from the
+ recorded position.
</para>
<para>
- Both the master and each slave must be configured with a unique id
+ Both the master and each slave must be configured with a unique ID
(using the <literal>server-id</literal> option). In addition, the
slave must be configured with information about the master host
- name, log file name and position within that file. These details can
+ name, log filename and position within that file. These details can
be controlled from within a MySQL session using the <literal>CHANGE
MASTER</literal> statement. The details are stored within the
<filename>master.info</filename> file.
@@ -83,7 +83,7 @@
<para>
Once started, the replication process should require little
administration or monitoring. However, for advice on common
- tasks that you may want to executed, see
+ tasks that you may want to execute, see
<xref linkend="replication-administration"/>.
</para>
</listitem>
@@ -129,7 +129,7 @@
<listitem>
<para>
You must configure a unique ID for each slave that you want to
- connect to the Master. See
+ connect to the master. See
<xref linkend="replication-howto-slavebaseconfig"/>.
</para>
</listitem>
@@ -147,7 +147,7 @@
<listitem>
<para>
- If you already have data on your Master and you want to
+ If you already have data on your master and you want to
synchronize your slave with this base data, then you will need
to create a data snapshot of your database. You can create a
snapshot using <literal>mysqldump</literal> (see
@@ -159,7 +159,7 @@
<listitem>
<para>
- You will need to configure the slave with the Master settings,
+ You will need to configure the slave with the master settings,
such as the hostname, login credentials and binary log name
and positions. See
<xref linkend="replication-howto-slaveinit"/>.
@@ -178,7 +178,7 @@
<listitem>
<para>
- If you are setting up a new MySQL master and one or more
+ If you are establishing a new MySQL master and one or more
slaves, then you need only set up the configuration, as you
have no data to exchange. For guidance on setting up
replication in this situation, see
@@ -230,9 +230,10 @@
<title>Creating a User for Replication</title>
<para>
- Each Slave must connect to the Master using a standard username
- and password. The user that you use for this operation can be
- any user, providing they have been granted the
+ Each slave must connect to the master using a standard MySQL
+ username and password, so there must be a user account on the
+ master that the slave can use to connect. Any account can be
+ used for this operation, providing it has been granted the
<literal>REPLICATION SLAVE</literal> privilege.
</para>
@@ -240,19 +241,20 @@
You do not need to create a specific user for replication.
However, you should be aware that the username and password will
be stored in plain text within the
- <literal>master.info</literal> file. Therefore you may want to
+ <literal>master.info</literal> file. Therefore, you may want to
create a user that only has privileges for the replication
process.
</para>
<para>
To create a user or grant an existing user the privileges
- required for replication use the <literal>GRANT</literal>
+ required for replication, use the <literal>GRANT</literal>
statement. If you create a user solely for the purposes of
- replication then that user only needs the <literal>REPLICATION
+ replication then that user needs only the <literal>REPLICATION
SLAVE</literal> privilege. For example, to create a user,
- <literal>repl</literal>, that allows all hosts within the domain
- <literal>mydomain.com</literal> to connect for replication:
+ <literal>repl</literal>, that can connect for replication from
+ any host within the <literal>mydomain.com</literal> domain,
+ issue this statement on the master:
</para>
<programlisting>mysql> GRANT REPLICATION SLAVE ON *.*
@@ -285,16 +287,17 @@
</para>
<para>
- Each server within a replication group must have a unique
- <literal>server-id</literal>. The server-id is used to identify
- individual servers within the group, and must be positive
- integer between 1 and (2<superscript>32</superscript>)-1). How
- you organize and select the numbers is entirely up to you.
+ Each server within a replication group must be configured with a
+ unique <literal>server-id</literal> value. The server ID is used
+ to identify individual servers within the group, and must be
+ positive integer between 1 and
+ (2<superscript>32</superscript>)−1. How you organize and
+ select the numbers is entirely up to you.
</para>
<para>
- To configure both these options you will need to shut down your
- MySQL server and edit the configuration of the
+ To configure the binary log and server ID options, you will need
+ to shut down your MySQL server and edit the configuration of the
<filename>my.cnf</filename> or <filename>my.ini</filename> file.
</para>
@@ -303,8 +306,8 @@
file within the <literal>[mysqld]</literal> section. If these
options already exist, but are commented out, uncomment the
options and alter them according to your needs. For example, to
- enable binary logging, using a log filename prefix of mysql-bin,
- and setting a server ID of 1:
+ enable binary logging, using a log filename prefix of
+ <literal>mysql-bin</literal>, and setting a server ID of 1:
</para>
<programlisting>
@@ -771,9 +774,9 @@
<title>Setting Up Replication with New Master and Slaves</title>
<para>
- Setting up replication with a new Master and Slaves (i.e. with
- no existing data) is the easiest and most straightforward method
- for setting up replication.
+ Setting up replication with a new master and slaves (that is,
+ with no existing data) is the easiest and most straightforward
+ method for setting up replication.
</para>
<para>
Modified: trunk/refman-5.0/replication.xml
===================================================================
--- trunk/refman-5.0/replication.xml 2008-09-03 17:32:32 UTC (rev 11655)
+++ trunk/refman-5.0/replication.xml 2008-09-03 19:44:36 UTC (rev 11656)
Changed blocks: 1, Lines Added: 1, Lines Deleted: 1; 631 bytes
@@ -34,7 +34,7 @@
master, which means that updates can occur over long-distance
connections and even temporary solutions such as a dial-up service.
Depending on the configuration, you can replicate all databases,
- selected databases and even selected tables within a database.
+ selected databases, or even selected tables within a database.
</para>
<para>
Modified: trunk/refman-5.1/replication-configuration.xml
===================================================================
--- trunk/refman-5.1/replication-configuration.xml 2008-09-03 17:32:32 UTC (rev 11655)
+++ trunk/refman-5.1/replication-configuration.xml 2008-09-03 19:44:36 UTC (rev 11656)
Changed blocks: 12, Lines Added: 40, Lines Deleted: 37; 8884 bytes
@@ -10,23 +10,23 @@
<para>
Replication between servers in MySQL works through the use of the
binary logging mechanism. The MySQL instance operating as the master
- (the source of the database changes) writes updates and changes to
- the database to the binary log. The information in the binary log is
- stored in different logging formats according to the database
- changes being recorded. Slaves are configured to read the binary log
- from the master and to execute the events in the binary log on the
- slave's local database.
+ (the source of the database changes) writes updates and changes as
+ <quote>events</quote> to the binary log. The information in the
+ binary log is stored in different logging formats according to the
+ database changes being recorded. Slaves are configured to read the
+ binary log from the master and to execute the events in the binary
+ log on the slave's local database.
</para>
<para>
- The Master is dumb in this scenario. Once binary logging has been
+ The master is dumb in this scenario. Once binary logging has been
enabled, all statements are recorded in the binary log. Each slave
will receive a copy of the entire contents of the binary log. It is
the responsibility of the slave to decide which statements in the
binary log should be executed; you cannot configure the master to
log only certain events. If you do not specify otherwise, all events
in the master binary log are executed on the slave. If required, you
- can configure the slave to only process events that apply to
+ can configure the slave to process only events that apply to
particular databases or tables.
</para>
@@ -39,15 +39,15 @@
disconnected from the server without affecting the master's
operation. Also, because each slave remembers the position within
the binary log, it is possible for slaves to be disconnected,
- reconnect and then 'catch up' by continuing from the recorded
- position.
+ reconnect and then <quote>catch up</quote> by continuing from the
+ recorded position.
</para>
<para>
- Both the master and each slave must be configured with a unique id
+ Both the master and each slave must be configured with a unique ID
(using the <literal>server-id</literal> option). In addition, the
slave must be configured with information about the master host
- name, log file name and position within that file. These details can
+ name, log filename and position within that file. These details can
be controlled from within a MySQL session using the <literal>CHANGE
MASTER</literal> statement. The details are stored within the
<filename>master.info</filename> file.
@@ -95,7 +95,7 @@
<para>
Once started, the replication process should require little
administration or monitoring. However, for advice on common
- tasks that you may want to executed, see
+ tasks that you may want to execute, see
<xref linkend="replication-administration"/>.
</para>
</listitem>
@@ -141,7 +141,7 @@
<listitem>
<para>
You must configure a unique ID for each slave that you want to
- connect to the Master. See
+ connect to the master. See
<xref linkend="replication-howto-slavebaseconfig"/>.
</para>
</listitem>
@@ -159,7 +159,7 @@
<listitem>
<para>
- If you already have data on your Master and you want to
+ If you already have data on your master and you want to
synchronize your slave with this base data, then you will need
to create a data snapshot of your database. You can create a
snapshot using <literal>mysqldump</literal> (see
@@ -171,7 +171,7 @@
<listitem>
<para>
- You will need to configure the slave with the Master settings,
+ You will need to configure the slave with the master settings,
such as the hostname, login credentials and binary log name
and positions. See
<xref linkend="replication-howto-slaveinit"/>.
@@ -190,7 +190,7 @@
<listitem>
<para>
- If you are setting up a new MySQL master and one or more
+ If you are establishing a new MySQL master and one or more
slaves, then you need only set up the configuration, as you
have no data to exchange. For guidance on setting up
replication in this situation, see
@@ -242,9 +242,10 @@
<title>Creating a User for Replication</title>
<para>
- Each Slave must connect to the Master using a standard username
- and password. The user that you use for this operation can be
- any user, providing they have been granted the
+ Each slave must connect to the master using a standard MySQL
+ username and password, so there must be a user account on the
+ master that the slave can use to connect. Any account can be
+ used for this operation, providing it has been granted the
<literal>REPLICATION SLAVE</literal> privilege.
</para>
@@ -252,19 +253,20 @@
You do not need to create a specific user for replication.
However, you should be aware that the username and password will
be stored in plain text within the
- <literal>master.info</literal> file. Therefore you may want to
+ <literal>master.info</literal> file. Therefore, you may want to
create a user that only has privileges for the replication
process.
</para>
<para>
To create a user or grant an existing user the privileges
- required for replication use the <literal>GRANT</literal>
+ required for replication, use the <literal>GRANT</literal>
statement. If you create a user solely for the purposes of
- replication then that user only needs the <literal>REPLICATION
+ replication then that user needs only the <literal>REPLICATION
SLAVE</literal> privilege. For example, to create a user,
- <literal>repl</literal>, that allows all hosts within the domain
- <literal>mydomain.com</literal> to connect for replication:
+ <literal>repl</literal>, that can connect for replication from
+ any host within the <literal>mydomain.com</literal> domain,
+ issue this statement on the master:
</para>
<programlisting>mysql> GRANT REPLICATION SLAVE ON *.*
@@ -297,16 +299,17 @@
</para>
<para>
- Each server within a replication group must have a unique
- <literal>server-id</literal>. The server-id is used to identify
- individual servers within the group, and must be positive
- integer between 1 and (2<superscript>32</superscript>)-1). How
- you organize and select the numbers is entirely up to you.
+ Each server within a replication group must be configured with a
+ unique <literal>server-id</literal> value. The server ID is used
+ to identify individual servers within the group, and must be
+ positive integer between 1 and
+ (2<superscript>32</superscript>)−1. How you organize and
+ select the numbers is entirely up to you.
</para>
<para>
- To configure both these options you will need to shut down your
- MySQL server and edit the configuration of the
+ To configure the binary log and server ID options, you will need
+ to shut down your MySQL server and edit the configuration of the
<filename>my.cnf</filename> or <filename>my.ini</filename> file.
</para>
@@ -315,8 +318,8 @@
file within the <literal>[mysqld]</literal> section. If these
options already exist, but are commented out, uncomment the
options and alter them according to your needs. For example, to
- enable binary logging, using a log filename prefix of mysql-bin,
- and setting a server ID of 1:
+ enable binary logging, using a log filename prefix of
+ <literal>mysql-bin</literal>, and setting a server ID of 1:
</para>
<programlisting>
@@ -789,9 +792,9 @@
<title>Setting Up Replication with New Master and Slaves</title>
<para>
- Setting up replication with a new Master and Slaves (i.e. with
- no existing data) is the easiest and most straightforward method
- for setting up replication.
+ Setting up replication with a new master and slaves (that is,
+ with no existing data) is the easiest and most straightforward
+ method for setting up replication.
</para>
<para>
Modified: trunk/refman-5.1/replication.xml
===================================================================
--- trunk/refman-5.1/replication.xml 2008-09-03 17:32:32 UTC (rev 11655)
+++ trunk/refman-5.1/replication.xml 2008-09-03 19:44:36 UTC (rev 11656)
Changed blocks: 1, Lines Added: 1, Lines Deleted: 1; 631 bytes
@@ -34,7 +34,7 @@
master, which means that updates can occur over long-distance
connections and even temporary solutions such as a dial-up service.
Depending on the configuration, you can replicate all databases,
- selected databases and even selected tables within a database.
+ selected databases, or even selected tables within a database.
</para>
<para>
Modified: trunk/refman-6.0/replication-configuration.xml
===================================================================
--- trunk/refman-6.0/replication-configuration.xml 2008-09-03 17:32:32 UTC (rev 11655)
+++ trunk/refman-6.0/replication-configuration.xml 2008-09-03 19:44:36 UTC (rev 11656)
Changed blocks: 12, Lines Added: 40, Lines Deleted: 37; 8884 bytes
@@ -10,23 +10,23 @@
<para>
Replication between servers in MySQL works through the use of the
binary logging mechanism. The MySQL instance operating as the master
- (the source of the database changes) writes updates and changes to
- the database to the binary log. The information in the binary log is
- stored in different logging formats according to the database
- changes being recorded. Slaves are configured to read the binary log
- from the master and to execute the events in the binary log on the
- slave's local database.
+ (the source of the database changes) writes updates and changes as
+ <quote>events</quote> to the binary log. The information in the
+ binary log is stored in different logging formats according to the
+ database changes being recorded. Slaves are configured to read the
+ binary log from the master and to execute the events in the binary
+ log on the slave's local database.
</para>
<para>
- The Master is dumb in this scenario. Once binary logging has been
+ The master is dumb in this scenario. Once binary logging has been
enabled, all statements are recorded in the binary log. Each slave
will receive a copy of the entire contents of the binary log. It is
the responsibility of the slave to decide which statements in the
binary log should be executed; you cannot configure the master to
log only certain events. If you do not specify otherwise, all events
in the master binary log are executed on the slave. If required, you
- can configure the slave to only process events that apply to
+ can configure the slave to process only events that apply to
particular databases or tables.
</para>
@@ -39,15 +39,15 @@
disconnected from the server without affecting the master's
operation. Also, because each slave remembers the position within
the binary log, it is possible for slaves to be disconnected,
- reconnect and then 'catch up' by continuing from the recorded
- position.
+ reconnect and then <quote>catch up</quote> by continuing from the
+ recorded position.
</para>
<para>
- Both the master and each slave must be configured with a unique id
+ Both the master and each slave must be configured with a unique ID
(using the <literal>server-id</literal> option). In addition, the
slave must be configured with information about the master host
- name, log file name and position within that file. These details can
+ name, log filename and position within that file. These details can
be controlled from within a MySQL session using the <literal>CHANGE
MASTER</literal> statement. The details are stored within the
<filename>master.info</filename> file.
@@ -95,7 +95,7 @@
<para>
Once started, the replication process should require little
administration or monitoring. However, for advice on common
- tasks that you may want to executed, see
+ tasks that you may want to execute, see
<xref linkend="replication-administration"/>.
</para>
</listitem>
@@ -141,7 +141,7 @@
<listitem>
<para>
You must configure a unique ID for each slave that you want to
- connect to the Master. See
+ connect to the master. See
<xref linkend="replication-howto-slavebaseconfig"/>.
</para>
</listitem>
@@ -159,7 +159,7 @@
<listitem>
<para>
- If you already have data on your Master and you want to
+ If you already have data on your master and you want to
synchronize your slave with this base data, then you will need
to create a data snapshot of your database. You can create a
snapshot using <literal>mysqldump</literal> (see
@@ -171,7 +171,7 @@
<listitem>
<para>
- You will need to configure the slave with the Master settings,
+ You will need to configure the slave with the master settings,
such as the hostname, login credentials and binary log name
and positions. See
<xref linkend="replication-howto-slaveinit"/>.
@@ -190,7 +190,7 @@
<listitem>
<para>
- If you are setting up a new MySQL master and one or more
+ If you are establishing a new MySQL master and one or more
slaves, then you need only set up the configuration, as you
have no data to exchange. For guidance on setting up
replication in this situation, see
@@ -242,9 +242,10 @@
<title>Creating a User for Replication</title>
<para>
- Each Slave must connect to the Master using a standard username
- and password. The user that you use for this operation can be
- any user, providing they have been granted the
+ Each slave must connect to the master using a standard MySQL
+ username and password, so there must be a user account on the
+ master that the slave can use to connect. Any account can be
+ used for this operation, providing it has been granted the
<literal>REPLICATION SLAVE</literal> privilege.
</para>
@@ -252,19 +253,20 @@
You do not need to create a specific user for replication.
However, you should be aware that the username and password will
be stored in plain text within the
- <literal>master.info</literal> file. Therefore you may want to
+ <literal>master.info</literal> file. Therefore, you may want to
create a user that only has privileges for the replication
process.
</para>
<para>
To create a user or grant an existing user the privileges
- required for replication use the <literal>GRANT</literal>
+ required for replication, use the <literal>GRANT</literal>
statement. If you create a user solely for the purposes of
- replication then that user only needs the <literal>REPLICATION
+ replication then that user needs only the <literal>REPLICATION
SLAVE</literal> privilege. For example, to create a user,
- <literal>repl</literal>, that allows all hosts within the domain
- <literal>mydomain.com</literal> to connect for replication:
+ <literal>repl</literal>, that can connect for replication from
+ any host within the <literal>mydomain.com</literal> domain,
+ issue this statement on the master:
</para>
<programlisting>mysql> GRANT REPLICATION SLAVE ON *.*
@@ -297,16 +299,17 @@
</para>
<para>
- Each server within a replication group must have a unique
- <literal>server-id</literal>. The server-id is used to identify
- individual servers within the group, and must be positive
- integer between 1 and (2<superscript>32</superscript>)-1). How
- you organize and select the numbers is entirely up to you.
+ Each server within a replication group must be configured with a
+ unique <literal>server-id</literal> value. The server ID is used
+ to identify individual servers within the group, and must be
+ positive integer between 1 and
+ (2<superscript>32</superscript>)−1. How you organize and
+ select the numbers is entirely up to you.
</para>
<para>
- To configure both these options you will need to shut down your
- MySQL server and edit the configuration of the
+ To configure the binary log and server ID options, you will need
+ to shut down your MySQL server and edit the configuration of the
<filename>my.cnf</filename> or <filename>my.ini</filename> file.
</para>
@@ -315,8 +318,8 @@
file within the <literal>[mysqld]</literal> section. If these
options already exist, but are commented out, uncomment the
options and alter them according to your needs. For example, to
- enable binary logging, using a log filename prefix of mysql-bin,
- and setting a server ID of 1:
+ enable binary logging, using a log filename prefix of
+ <literal>mysql-bin</literal>, and setting a server ID of 1:
</para>
<programlisting>
@@ -789,9 +792,9 @@
<title>Setting Up Replication with New Master and Slaves</title>
<para>
- Setting up replication with a new Master and Slaves (i.e. with
- no existing data) is the easiest and most straightforward method
- for setting up replication.
+ Setting up replication with a new master and slaves (that is,
+ with no existing data) is the easiest and most straightforward
+ method for setting up replication.
</para>
<para>
Modified: trunk/refman-6.0/replication.xml
===================================================================
--- trunk/refman-6.0/replication.xml 2008-09-03 17:32:32 UTC (rev 11655)
+++ trunk/refman-6.0/replication.xml 2008-09-03 19:44:36 UTC (rev 11656)
Changed blocks: 1, Lines Added: 1, Lines Deleted: 1; 631 bytes
@@ -34,7 +34,7 @@
master, which means that updates can occur over long-distance
connections and even temporary solutions such as a dial-up service.
Depending on the configuration, you can replicate all databases,
- selected databases and even selected tables within a database.
+ selected databases, or even selected tables within a database.
</para>
<para>
| Thread |
|---|
| • svn commit - mysqldoc@docsrva: r11656 - in trunk: . refman-5.0 refman-5.1 refman-6.0 | paul.dubois | 3 Sep |
