Doc patch from Jeremy Zawodny.

Minor corrections to patch.
parent ee3e0a98
...@@ -6,3 +6,4 @@ sasha@work.mysql.com ...@@ -6,3 +6,4 @@ sasha@work.mysql.com
serg@hynda.mysql.fi serg@hynda.mysql.fi
tim@cane.mysql.fi tim@cane.mysql.fi
tim@donna.mysql.com tim@donna.mysql.com
jcole@tetra.spaceapes.com
...@@ -25629,10 +25629,11 @@ Starting in Version 3.23.15, @strong{MySQL} supports one-way replication ...@@ -25629,10 +25629,11 @@ Starting in Version 3.23.15, @strong{MySQL} supports one-way replication
internally. One server acts as the master, while the other acts as the internally. One server acts as the master, while the other acts as the
slave. Note that one server could play the roles of master in one pair slave. Note that one server could play the roles of master in one pair
and slave in the other. The master server keeps a binary log of updates and slave in the other. The master server keeps a binary log of updates
and an index file to binary logs to keep track of log rotation. The (@xref{Binary log}) and an index file of binary logs to keep track of
slave upon connecting informs the master where it left off since the log rotation. The slave, upon connecting, informs the master where it
last successfully propagated update, catches up on the updates, and then left off since the last successfully propagated update, catches up on
blocks and waits for the master to notify it of the new updates. the updates, and then blocks and waits for the master to notify it of
the new updates.
Note that if you are replicating a database, all updates to this Note that if you are replicating a database, all updates to this
database should be done through the master! database should be done through the master!
...@@ -25648,54 +25649,102 @@ master. @xref{Backup}. ...@@ -25648,54 +25649,102 @@ master. @xref{Backup}.
@node Replication Implementation, Replication HOWTO, Replication Intro, Replication @node Replication Implementation, Replication HOWTO, Replication Intro, Replication
@section Replication Implementation Overview @section Replication Implementation Overview
@strong{MySQL} internal replication uses the master-slave approach. One @strong{MySQL} replication is based on the server keeping track of all
server is designated as the master, while the other (or others) as changes to your database (updates, deletes, etc) in the binary
slave(s). The master keeps a binary log of updates. @xref{Binary log}. log (@xref{Binary log}), and the slave server(s) reading the saved
The slave connects to the master, catches up on the missed updates, and queries from the master server's binary log so that the slave can
then starts receiving updates immediately as they come to the master. If execute the same queries on its copy of the data.
the connection is lost, the slave will reconnect. If the master goes
down, the slave will keep trying to connect every It is @strong{very important} to realize that the binary log is simply a
@code{master-connect-retry} seconds until the master comes back up and record starting from a fixed point in time (the moment you enable binary
the connection can be established. The slave keeps track of where it logging). Any slaves which you set up will need copies of all the data
left off in the replication process, so it can use the information in case from your master as it existed the moment that you enabled binary
it goes down and gets restarted later. logging on the master. If you start your slaves with data that doesn't
agree with what was on the master @strong{when the binary log was
started}, your slaves may fail.
A future Version of @strong{MySQL} is planned remove the need to keep a
(possibly large) snapshot of data for new slaves that you might wish to
set up.
Once a slave is properly configured and running, it will simply connect
to the master and wait for updates to process. If the master goes away
or the slave loses connectivity with your master, it will keep trying to
connect every @code{master-connect-retry} seconds until it is able to
reconnect and resume listening for updates.
Each slave keeps track of where it left off. The master server has no
knowledge of how many slaves there are or which ones are up-to-date at
any given time.
The next section explains the master/slave setup process in more detail.
@node Replication HOWTO, Replication Features, Replication Implementation, Replication @node Replication HOWTO, Replication Features, Replication Implementation, Replication
@section HOWTO @section HOWTO
Below is a quick HOWTO on how to set up replication on your current Below is a quick description of how to set up complete replication on
system: your current @strong{MySQL} server. It assumes you want to replicate all
your databases and have not configured replication before. You will need
to shutdown your master server briefly to complete the steps outlined
below.
@itemize @bullet @enumerate
@item @item
Upgrade both slave and master to Version 3.23.15 or higher. We recommend Make sure you have a recent version of @strong{MySQL} installed on the
that you always use the latest release of Version 3.23 on both the slave master and slave(s).
and the master. The binary log format has also changed a couple of times
during development (before 3.23.29) so you should delete old binary logs Use Version 3.23.29 or higher. Previous releases used a different binary
when upgrading @strong{MySQL}. In addition, the newer version will fix log format and had bugs which have been fixed in newer releases. Please
some bugs and add new features. Please, do not report bugs until you do not report bugs until you have verified that the problem is present
have verified that the problem is present in the latest release. in the latest release.
@item @item
Set up special replication user(s) on the master with the @code{FILE} Set up a special replication user on the master with the @code{FILE}
privilege and permission to connect from all the slaves. If the user is privilege and permission to connect from all the slaves. If the user is
only doing replication, you don't need to grant him other privileges. only doing replication (which is recommended), you don't need to grant any
additional privileges.
For example, to create a user named @code{repl} which can access your
master from any host, you might use this command:
@example
GRANT FILE ON *.* TO repl@@"%" IDENTIFIED BY '<password>';
@end example
@item
Shut down @strong{MySQL} on the master.
@example
mysqladmin -u root -p<password> shutdown
@end example
@item @item
Take a snapshot of all the tables/databases on the master that could Snapshot all the data on your master server.
possibly be involved in the update queries before taking the next step.
Starting in Version 3.23.21, there is a command that allows you to take The easiest way to do this (on Unix) is to simply use @strong{tar} to
a snapshot of a table on the master and copy it to the slave, called produce an archive of your entrie data directory. The exact data
@code{LOAD TABLE FROM MASTER}. Until Version 3.23.23, though, it has a directory location depends on your installation.
serious bug, and we recommend that you do not use it until you have
upgraded. @example
tar -cvf /tmp/mysql-snapshot.tar /path/to/data-dir
@end example
Windows users can use WinZip or similar software to create an archive of
the data directory.
@item @item
In @code{my.cnf} on the master add @code{log-bin} and In @code{my.cnf} on the master add @code{log-bin} and
@code{server-id=unique number} and restart it. Make sure there are no @code{server-id=<some unique number>} to the @code{[mysqld]} section.
important updates to the master between the time you have taken the
snapshot and the time the master is restarted with @code{log-bin}
option. @example
[mysqld]
log-bin
server-id=1
@end example
@item @item
Load the snapshot of the master to all the slaves. Restart @strong{MySQL} on the master.
@item @item
Add the following to @code{my.cnf} on the slave(s): Add the following to @code{my.cnf} on the slave(s):
...@@ -25703,32 +25752,47 @@ Add the following to @code{my.cnf} on the slave(s): ...@@ -25703,32 +25752,47 @@ Add the following to @code{my.cnf} on the slave(s):
master-host=<hostname of the master> master-host=<hostname of the master>
master-user=<replication user name> master-user=<replication user name>
master-password=<replication user password> master-password=<replication user password>
server-id=<some unique number between 1 and 2^32-1> server-id=<some unique number between 2 and 2^32-1>
@end example @end example
replacing the values in <> with what is relevant to your system. replacing the values in <> with what is relevant to your system.
@code{server-id} must be different for each server participating in @code{server-id} must be different for each server participating in
replication. If you don't specify a server-id, it will be set to replication. If you don't specify a server-id, it will be set to 1 if
1 if you have not defined @code{master-host}, else it will be set to 2. you have not defined @code{master-host}, else it will be set to 2.
@item
Copy the snapshot data into your data directory on your slave(s). Make
sure that the privileges on the files and directories are correct. The
user which @strong{MySQL} runs as needs to be able to read and write to
them, just as on the master.
@item Restart the slave(s). @item Restart the slave(s).
@end itemize @end itemize
After you have done the above, the master and the slave(s) should be in After you have done the above, the slave(s) should connect to the master
sync. and catch up on any updates which happened since the snapshot was taken.
If you have forgot to set server-id for the slave you will get the following If you have forgotten to set @code{server-id} for the slave you will get
error in the error log file: the following error in the error log file:
@example @example
Warning: one should set server_id to a non-0 value if master_host is set. Warning: one should set server_id to a non-0 value if master_host is set.
The server will not act as a slave. The server will not act as a slave.
@end example @end example
If you have forgot to do this for the master, the slaves will not be able to If you have forgot to do this for the master, the slaves will not be
connect to the master. able to connect to the master.
If a slave is not able to replicate for any reason, you will find error
messages in the error log on the slave.
Once a slave is replicating, you will find a file called
@code{master.info} in the same directory as your error log. The
@code{master.info} file is used by the slave to keep track of how much
of the master's binary log it has processed. @strong{Do not} remove or
edit this file.
@cindex options, replication @cindex options, replication
@cindex @code{my.cnf} file @cindex @code{my.cnf} file
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment