List:Internals« Previous MessageNext Message »
From:sasha Date:November 28 2002 1:24am
Subject:bk commit into mysqldoc tree
View as plain text  
Below is the list of changes that have just been committed into a local
mysqldoc repository of sasha. When sasha does a push these changes will
be propagated to the main repository and, within 24 hours after the
push, to the public repository.
For information on how to access the public repository

  1.102 02/11/27 18:24:21 sasha@stripped +3 -0
  replication update

    1.13 02/11/27 18:24:20 sasha@stripped +1 -0
    Logging to logging@stripped accepted

    1.6 02/11/27 18:24:20 sasha@stripped +2 -0
    Added Docs/manual.html Docs/manual_toc.html to the ignore list

    1.94 02/11/27 18:24:17 sasha@stripped +100 -16
    replication update

# This is a BitKeeper patch.  What follows are the unified diffs for the
# set of deltas contained in the patch.  The rest of the patch, the part
# that BitKeeper cares about, is below these diffs.
# User:	sasha
# Host:
# Root:	/reiser-data/mysqldoc

--- 1.12/BitKeeper/etc/logging_ok	Mon Nov 18 08:22:39 2002
+++ 1.13/BitKeeper/etc/logging_ok	Wed Nov 27 18:24:20 2002
@@ -13,3 +13,4 @@

--- 1.93/Docs/manual.texi	Tue Nov 26 04:38:53 2002
+++ 1.94/Docs/manual.texi	Wed Nov 27 18:24:17 2002
@@ -23804,14 +23804,14 @@
 @end example
-Shut down MySQL on the master.
+If you are using MyISAM tables, flush all the tables and block write queries
+by executing @code{FLUSH TABLES WITH READ LOCK} command.
-mysqladmin -u root -p<password> shutdown
 @end example
-Snapshot all the data on your master server.
+and then take a snapshot of the data on your master server.
 The easiest way to do this (on Unix) is to simply use @strong{tar} to
 produce an archive of your entire data directory. The exact data
@@ -23824,10 +23824,69 @@
 Windows users can use @code{WinZIP} or similar software to create an
 archive of the data directory.
+After or during the process of taking a snapshot, read the value of the
+current binary log name and the offset on the master:
+| File          | Position | Binlog_do_db | Binlog_ignore_db              |
+| mysql-bin.003 | 73       | test,bar     | foo,manual,sasha_likes_to_run |
+1 row in set (0.06 sec)
+@end example
+The @code{File} column shows the name of the log,  while @code{Position} shows
+the offset. n the above example, the binary log value is
+@code{mysql-bin.003} and the offset is 73. Record the values - you will need
+to use them later when you are setting up the slave.
+Once you have taken the snapshot and recorded the log name and offset, you can
+re-enable write activity on the master:
+@end example
+If you are using InnoDB tables, ideally you should use the InnoDB Hot Backup
+tool that is available to those who purchase MySQL commercial licenses,
+support, or the backup tool itself. It will take a consistent snapshot
+without acquiring any locks on the master server, and record the log name and
+offset corresponding to the snapshot to be later used on the slave. More
+information about the tool is avaliable at
+Without the hot backup tool, the quickest way to take a snapshot of  InnoDB
+tables is to shut the master server down and copy the data files, the logs,
+and the table definition files (@code{.frm}). To record the current log file
+name and offset, you should do the following before you shut down the server:
+@end example
+And then record the log name and the offset from the output of
+@code{SHOW MASTER STATUS} as was shown earlier. Once you have recorded the
+log name and the offset, shut the server down without unlocking the tables to
+make sure it goes down with the snapshot corresponding to the current log file
+and offset:
+shell> mysqladmin -uroot shutdown
+@end example
+If the master has been previously running without @code{log-bin} enabled,
+the values of log name and position will be empty when you run
+@code{SHOW MASTER STATUS}. In that case, record empty string ('') for the
+log name, and 4 for the offset.
-In @file{my.cnf} on the master add @code{log-bin} and
-@code{server-id=unique number} to the @code{[mysqld]} section and
-restart it. It is very important that the id of the slave is different from
+Make sure that @file{my.cnf} on the master has  @code{log-bin} if it is not there already
+and @code{server-id=unique number} in the @code{[mysqld]} section. If those
+options are not present, add them and restart the server.
+It is very important that the id of the slave is different from
 the id of the master. Think of @code{server-id} as something similar
 to the IP address - it uniquely identifies the server instance in the
 community of replication partners.
@@ -23839,17 +23898,11 @@
 @end example
-Restart MySQL on the master.
 Add the following to @file{my.cnf} on the slave(s):
-master-host=<hostname of the master>
-master-user=<replication user name>
-master-password=<replication user password>
-master-port=<TCP/IP port for master>
-server-id=<some unique number between 2 and 2^32-1>
+server-id=<some unique number between 1 and 2^32-1 that is different from
+ that of the master>
 @end example
 replacing the values in <> with what is relevant to your system.
@@ -23862,6 +23915,13 @@
 master. Thus, omitting @code{server-id} is only good for backup with a
 binary log.
+While the slave is running, make it forget about the old replication
+configuration if it has been replicating previously:
+mysql> RESET SLAVE;
+@end example
 Copy the snapshot data into your data directory on your slave(s). Make
@@ -23871,6 +23931,26 @@
 @item Restart the slave(s).
+Once the slave comes up, execute the following command:
+mysql> CHANGE MASTER TO MASTER_HOST='<master host name>',
+ MASTER_USER='<replication user name>',
+ MASTER_PASSWORD='<replication password>',
+ MASTER_LOG_FILE='<recorded log file name>',
+ MASTER_LOG_POS=<recorded log offset>;
+@end example
+replacing the values in <> with the actual values relevant to your system.
+Start the slave thread:
+mysql> SLAVE START;
+@end example
 @end enumerate
 After you have done the above, the slave(s) should connect to the master
@@ -23897,6 +23977,10 @@
 edit the file, unless you really know what you are doing. Even in that case,
 it is preferred that you use @code{CHANGE MASTER TO} command.
+Now that you have a snapshot, you can use it to set up other slaves. To do so,
+follow the slave portion of the procedure described above. You do not need to
+take another snapshot of the master.
 @node Replication Features, Replication Options, Replication HOWTO, Replication
 @subsection Replication Features and Known Problems
@@ -24073,7 +24157,7 @@
 @subsection Replication Options in @file{my.cnf}
 If you are using replication, we recommend that you use MySQL Version
-3.23.30 or later. Older versions work, but they do have some bugs and are
+3.23.33 or later. Older versions work, but they do have some bugs and are
 missing some features. Some of the options mentioned here may not be available in
 your version if it is not the most recent one. For all options specific to
 the 4.0 branch, there is a note indicating so. Otherwise, if you discover

--- 1.5/BitKeeper/etc/ignore	Fri Nov  8 02:42:20 2002
+++ 1.6/BitKeeper/etc/ignore	Wed Nov 27 18:24:20 2002
@@ -3,3 +3,5 @@
bk commit into mysqldoc treesasha28 Nov