@@ -22457,6 +22457,10 @@ You will be introduced to replication and learn how to implement it.
22457
22457
Towards the end, there are some frequently asked questions and descriptions
22458
22458
of problems and how to solve them.
22459
22459
22460
+ We suggest that you visit our website at @uref{http://www.mysql.com/}
22461
+ often and read updates to this section. Replication is constantly being
22462
+ improved, and we update the manual frequently with the most current
22463
+ information.
22460
22464
22461
22465
@node Replication Intro, Replication Implementation, Replication, Replication
22462
22466
@subsection Introduction
@@ -22505,11 +22509,29 @@ logging on the master. If you start your slaves with data that doesn't
22505
22509
agree with what was on the master @strong{when the binary log was
22506
22510
started}, your slaves may fail.
22507
22511
22508
- A future version (4.0) of MySQL will remove the need to keep a
22509
- (possibly large) snapshot of data for new slaves that you might wish to
22510
- set up through the live backup functionality with no locking required.
22511
- However, at this time, it is necessary to block all writes either with a
22512
- global read lock or by shutting down the master while taking a snapshot.
22512
+ Starting in 4.0.0, one can use @code{LOAD DATA FROM MASTER} to set up
22513
+ a slave. Note that 4.0.0 slaves cannot communicate with 3.23 masters, but 4.0.1
22514
+ and later version slaves can. 3.23 slave cannot talk to 4.0 master.
22515
+
22516
+ You must also be aware that @code{LOAD DATA FROM MASTER} currently works only
22517
+ if all the tables on the master are @code{MyISAM} type, and will acuire a
22518
+ global read lock, so no writes are possible while the tables are being
22519
+ transferred from the master. This limitation is of a temporary nature, and is
22520
+ due to the fact that we have not yet implemented hot lock-free table backup.
22521
+ It will be removed in the future 4.0 branch versions once we implemented hot
22522
+ backup enabling @code{LOAD DATA FROM MASTER} to work without blocking master
22523
+ updates.
22524
+
22525
+ Due to the above limitation, we recommend that at this point you use
22526
+ @code{LOAD DATA FROM MASTER} only if the dataset on the master is relatively
22527
+ small, or if a prolonged read lock on the master is acceptable. While the
22528
+ actual speed of @code{LOAD DATA FROM MASTER} may vary from system to system,
22529
+ a good rule for a rough estimate of how long it is going to take is 1 second
22530
+ per 1 MB of the data file. You will get close to the estimate if both master
22531
+ and slave are equivalent to 700 MHz Pentium, are connected through
22532
+ 100 MBit/s network, and your index file is about half the size of your data
22533
+ file. Of course, your mileage will vary from system to system, the above rule
22534
+ just gives you a rough order of magnitude estimate.
22513
22535
22514
22536
Once a slave is properly configured and running, it will simply connect
22515
22537
to the master and wait for updates to process. If the master goes away
@@ -22533,6 +22555,19 @@ your databases and have not configured replication before. You will need
22533
22555
to shutdown your master server briefly to complete the steps outlined
22534
22556
below.
22535
22557
22558
+ While the above method is the most straightforward way to set up a slave,
22559
+ it is not the only one. For example, if you already have a snapshot
22560
+ of the master, and
22561
+ the master already has server id set and binary logging enabled, one can
22562
+ set up a slave without shutting the master down or even blocking the updates.
22563
+ Please refer to @xref{Replication FAQ}. for more details.
22564
+
22565
+ If you want to become a real MySQL replication guru, we suggest that you
22566
+ begin with studing, pondering, and trying all commands
22567
+ mentioned in @xref{Replication SQL}. You should also familiarize yourself
22568
+ with replication startup options in @code{my.cnf} in
22569
+ @xref{Replication Options}.
22570
+
22536
22571
@enumerate
22537
22572
@item
22538
22573
Make sure you have a recent version of MySQL installed on the master
@@ -22650,7 +22685,6 @@ of the master's binary log is has processed. @strong{Do not} remove or
22650
22685
edit the file, unless you really know what you are doing. Even in that case,
22651
22686
it is preferred that you use @code{CHANGE MASTER TO} command.
22652
22687
22653
-
22654
22688
@menu
22655
22689
* Replication Features:: Replication Features and Known Problems
22656
22690
* Replication Options:: Replication Options in my.cnf
@@ -22684,9 +22718,11 @@ on the master and the slave. If not, you may get duplicate key errors on
22684
22718
the slave, because a key that is regarded as unique on the master may
22685
22719
not be that in the other character set.
22686
22720
@item
22687
- @code{LOAD DATA INFILE} will be handled properly as long as the file
22721
+ In 3.23, @code{LOAD DATA INFILE} will be handled properly as long as the file
22688
22722
still resides on the master server at the time of update
22689
- propagation. @code{LOAD LOCAL DATA INFILE} will be skipped.
22723
+ propagation. @code{LOAD LOCAL DATA INFILE} will be skipped. In 4.0, this
22724
+ limitation is not present - all forms of @code{LOAD DATA INFILE} are properly
22725
+ replicated.
22690
22726
@item
22691
22727
Update queries that use user variables are not replication-safe (yet).
22692
22728
@item
@@ -22806,7 +22842,17 @@ to get rid of old logs while the slave is running.
22806
22842
22807
22843
If you are using replication, we recommend you to use MySQL Version
22808
22844
3.23.30 or later. Older versions work, but they do have some bugs and are
22809
- missing some features.
22845
+ missing some features. Some of the options below may not be available in
22846
+ your version if it is not the most recent one. For all options specific to
22847
+ the 4.0 branch, there is a note indicating so. Otherwise, if you discover
22848
+ that the option you are interested in is not available in your 3.23 version,
22849
+ and you really need it, please upgrade to the most recent 3.23 branch.
22850
+
22851
+ Please be aware that 4.0 branch is still in alpha, so some things may not be
22852
+ working as smoothly as you would like. If you really would like to try
22853
+ the new features of 4.0, we recommend you do it in such a way that in
22854
+ case there is a problem your mission critical applications will not be
22855
+ disrupted.
22810
22856
22811
22857
On both master and slave you need to use the @code{server-id} option.
22812
22858
This sets an unique replication id. You should pick a unique value in the
@@ -22848,15 +22894,15 @@ current database is 'database_name'. All others database are ignored.
22848
22894
Note that if you use this you should ensure that you only do updates in
22849
22895
the current database.
22850
22896
22851
- Example: @code{binlog-do-db=some_database }.
22897
+ Example: @code{binlog-do-db=sales }.
22852
22898
22853
22899
@item @code{binlog-ignore-db=database_name} @tab
22854
22900
Tells the master that updates where the current database is
22855
22901
'database_name' should not be stored in the binary log. Note that if
22856
22902
you use this you should ensure that you only do updates in the current
22857
22903
database.
22858
22904
22859
- Example: @code{binlog-ignore-db=some_database }
22905
+ Example: @code{binlog-ignore-db=accounting }
22860
22906
@end multitable
22861
22907
22862
22908
The following table has the options you can use for the @strong{SLAVE}:
@@ -22866,27 +22912,33 @@ The following table has the options you can use for the @strong{SLAVE}:
22866
22912
@item @strong{Option} @tab @strong{Description}
22867
22913
@item @code{master-host=host} @tab
22868
22914
Master hostname or IP address for replication. If not set, the slave
22869
- thread will not be started.
22915
+ thread will not be started. Note that the setting of @code{master-host}
22916
+ will be ignored if there exists a valid @code{master.info} file. Probably a
22917
+ better name for this options would have been something like
22918
+ @code{bootstrap-master-host}, but it is too late to change now.
22870
22919
22871
22920
Example: @code{master-host=db-master.mycompany.com}.
22872
22921
22873
22922
@item @code{master-user=username} @tab
22874
- The user the slave thread will us for authentication when connecting to
22923
+ The username the slave thread will use for authentication when connecting to
22875
22924
the master. The user must have @code{FILE} privilege. If the master user
22876
- is not set, user @code{test} is assumed.
22925
+ is not set, user @code{test} is assumed. The value in @code{master.info} will
22926
+ take precedence if it can be read.
22877
22927
22878
22928
Example: @code{master-user=scott}.
22879
22929
22880
22930
@item @code{master-password=password} @tab
22881
22931
The password the slave thread will authenticate with when connecting to
22882
- the master. If not set, an empty password is assumed.
22932
+ the master. If not set, an empty password is assumed.The value in
22933
+ @code{master.info} will take precedence if it can be read.
22883
22934
22884
22935
Example: @code{master-password=tiger}.
22885
22936
22886
22937
@item @code{master-port=portnumber} @tab
22887
22938
The port the master is listening on. If not set, the compiled setting of
22888
22939
@code{MYSQL_PORT} is assumed. If you have not tinkered with
22889
- @code{configure} options, this should be 3306.
22940
+ @code{configure} options, this should be 3306. The value in
22941
+ @code{master.info} will take precedence if it can be read.
22890
22942
22891
22943
Example: @code{master-port=3306}.
22892
22944
@@ -22898,17 +22950,21 @@ lost. Default is 60.
22898
22950
Example: @code{master-connect-retry=60}.
22899
22951
22900
22952
@item @code{master-ssl} @tab
22901
- Turn SSL on
22953
+ Available after 4.0.0. Turn SSL on for replication. Be warned that is
22954
+ this is a relatively new feature.
22902
22955
22903
22956
Example: @code{master-ssl}.
22904
22957
22905
22958
@item @code{master-ssl-key} @tab
22906
- Master SSL keyfile name
22959
+ Available after 4.0.0. Master SSL keyfile name. Only applies if you have
22960
+ enabled @code{master-ssl}.
22907
22961
22908
22962
Example: @code{master-ssl-key=SSL/master-key.pem}.
22909
22963
22910
22964
@item @code{master-ssl-cert} @tab
22911
- Master SSL certificate file name
22965
+ Available after 4.0.0. Master SSL certificate file name. Only applies if
22966
+ you have enabled @code{master-ssl}.
22967
+
22912
22968
22913
22969
Example: @code{master-ssl-key=SSL/master-cert.pem}.
22914
22970
@@ -22920,6 +22976,23 @@ is the desire to be rebelious.
22920
22976
22921
22977
Example: @code{master-info-file=master.info}.
22922
22978
22979
+ @item @code{report-host} @tab
22980
+ Available after 4.0.0. Hostname or IP of the slave to be reported to to
22981
+ the master during slave registration. Will appear in the output of
22982
+ @code{SHOW SLAVE HOSTS}. Leave unset if you do not want the slave to
22983
+ register itself with the master. Note that it is not sufficient for the
22984
+ master to simply read the IP of the slave off the socket once the slave
22985
+ connects. Due to @code{NAT} and other routing issues, that IP may not be
22986
+ valid for connecting to the slave from the master or other hosts.
22987
+
22988
+ Example: @code{report-host=slave1.mycompany.com}
22989
+
22990
+ @item @code{report-port} @tab
22991
+ Available after 4.0.0. Port for connecting to slave reported to the
22992
+ master during slave registration. Set it only if the slave is listening
22993
+ on a non-default port or if you have a special tunnel from the master or
22994
+ other clients to the slave. If not sure, leave this option unset.
22995
+
22923
22996
@item @code{replicate-do-table=db_name.table_name} @tab
22924
22997
Tells the slave thread to restrict replication to the specified table.
22925
22998
To specify more than one table, use the directive multiple times, once
@@ -23040,7 +23113,21 @@ logs. In pre 3.23.26 versions the command was called
23040
23113
@code{FLUSH SLAVE}(Slave)
23041
23114
23042
23115
@item @code{LOAD TABLE tblname FROM MASTER}
23043
- @tab Downloads a copy of the table from master to the slave. (Slave)
23116
+ @tab Downloads a copy of the table from master to the slave. Implemented
23117
+ mainly for debugging of @code{LOAD DATA FROM MASTER}, but some "gourmet"
23118
+ users might find it useful for other things. Do not use it if you consider
23119
+ yourself the average "non-hacker" type user. (Slave)
23120
+
23121
+ @item @code{LOAD DATA FROM MASTER} @tab
23122
+ Available starting in 4.0.0. Takes a snapshot of the master and copies
23123
+ it to the slave. Updates the values of @code{MASTER_LOG_FILE} and
23124
+ @code{MASTER_LOG_POS} so that the slave will start replicating from the
23125
+ correct position. Will honor table and database exclusion rules
23126
+ specified with @code{replicate-*} options. So far works only with
23127
+ @code{MyISAM} tables and acquires a global read lock on the master while
23128
+ taking the snapshot. In the future it is planned to make it work with
23129
+ @code{InnoDB} tables and to remove the need for global read lock using
23130
+ the non-blocking online backup feature.
23044
23131
23045
23132
@item @code{CHANGE MASTER TO master_def_list}
23046
23133
@tab Changes the master parameters to the values specified in
@@ -23069,12 +23156,45 @@ automatically be reset to an empty string and 0, respectively (the start
23069
23156
values). Note that if you restart the slave, it will remember its last master.
23070
23157
If this is not desirable, you should delete the @file{master.info} file before
23071
23158
restarting, and the slave will read its master from @code{my.cnf} or the
23072
- command line. (Slave)
23159
+ command line.
23160
+
23161
+ This command is useful for setting up a slave when you have the snapshot of
23162
+ the master and have record the log and the offset on the master that the
23163
+ snapshot corresponds to. You can run
23164
+ @code{CHANGE MASTER TO MASTER_LOG_FILE='log_name_on_master',
23165
+ MASTER_LOG_POS=log_offset_on_master} on the slave after restoring the
23166
+ snapshot.
23167
+
23168
+ (Slave)
23073
23169
23074
23170
@item @code{SHOW MASTER STATUS} @tab Provides status information on the binlog of the master. (Master)
23075
23171
23172
+ @item @code{SHOW SLAVE HOSTS} @tab Available after 4.0.0. Gives a
23173
+ listing of slaves currently registered with the master (Master)
23174
+
23076
23175
@item @code{SHOW SLAVE STATUS} @tab Provides status information on essential parameters of the slave thread. (Slave)
23077
- @item @code{SHOW MASTER LOGS} @tab Only available starting in Version 3.23.28. Lists the binary logs on the master. You should use this command prior to @code{PURGE MASTER LOGS TO} to find out how far you should go.
23176
+ @item @code{SHOW MASTER LOGS} @tab Only available starting in Version
23177
+ 3.23.28. Lists the binary logs on the master. You should use this
23178
+ command prior to @code{PURGE MASTER LOGS TO} to find out how far you
23179
+ should go. (Master)
23180
+
23181
+ @item @code{SHOW BINLOG EVENTS [ IN 'logname' ] [ FROM pos ]
23182
+ [ LIMIT [offset,] rows ] } @tab
23183
+ Shows the events in the binary update log. Primarily used for
23184
+ testing/debugging, but can also be used by regular clients that for some
23185
+ reason need to read the binary log contents. (Master)
23186
+
23187
+ @item @code{SHOW NEW MASTER FOR SLAVE WITH MASTER_LOG_FILE='logfile' AND
23188
+ MASTER_LOG_POS=pos AND
23189
+ MASTER_LOG_SEQ=log_seq AND MASTER_SERVER_ID=server_id} @tab
23190
+ This command is used when a slave of a possibly dead/unavailable master
23191
+ needs to be switched to replicate off another slave that has been
23192
+ replicating the same master. The command will return recalculated
23193
+ replication coordinates, and the output can be used in a subsequent
23194
+ @code{CHANGE MASTER TO} command. Normal users should never need to run
23195
+ this command. It is primarily reserved for internal use by the fail-safe
23196
+ replication code. We may later change the syntax if we find a more
23197
+ intuitive way to describe this operation.
23078
23198
23079
23199
@item @code{PURGE MASTER LOGS TO 'logname'}
23080
23200
@tab Available starting in Version 3.23.28. Deletes all the
@@ -23106,6 +23226,87 @@ last log on the list), backup all the logs you are about to delete
23106
23226
@node Replication FAQ, Replication Problems, Replication SQL, Replication
23107
23227
@subsection Replication FAQ
23108
23228
23229
+ @strong{Q}: How do I configure a slave if the master is already running
23230
+ and I do not want to stop it?
23231
+
23232
+ @strong{A}: There are several options. If you have taken a backup of the
23233
+ master at some point and recorded the binlog name and offset ( from the
23234
+ output of @code{SHOW MASTER STATUS} ) corresponding to the snapshot, do
23235
+ the following:
23236
+
23237
+ @itemize @bullet
23238
+ @item
23239
+ Make sure unique server id is assigned to the slave.
23240
+ @item
23241
+ Execute @code{CHANGE MASTER TO MASTER_HOST='master-host-name',
23242
+ MASTER_USER='master-user-name', MASTER_PASSWORD='master-pass',
23243
+ MASTER_LOG_FILE='recorded-log-name', MASTER_LOG_POS=recorded_log_pos}
23244
+ @item
23245
+ Execute @code{SLAVE START}
23246
+ @end itemize
23247
+
23248
+ If you do not have a backup of the master already, here is a quick way to
23249
+ do it consistently:
23250
+
23251
+ @itemize @bullet
23252
+ @item
23253
+ @code{FLUSH TABLES WITH READ LOCK}
23254
+ @item
23255
+ @code{gtar zcf /tmp/backup.tar.gz /var/lib/mysql} ( or a variation of this)
23256
+ @item
23257
+ @code{SHOW MASTER STATUS} - make sure to record the output - you will need it
23258
+ later
23259
+ @item
23260
+ @code{UNLOCK TABLES}
23261
+ @end itemize
23262
+
23263
+ Afterwards, follow the instructions for the case when you have a snapshot and
23264
+ have records the log name and offset. You can use the same snapshot to set up
23265
+ several slaves. As long as the binary logs of the master are left intact, you
23266
+ can wait as long as several days or in some cases maybe a month to set up a
23267
+ slave once you have the snapshot of the master. In theory the waiting gap can
23268
+ be infinite. The two practical limitations is the diskspace of the master
23269
+ getting filled with old logs, and the amount of time it will take the slave to
23270
+ catch up.
23271
+
23272
+ In version 4.0.0 and newer, you can also use @code{LOAD DATA FROM
23273
+ MASTER}. This is a convenient command that will take a snapshot,
23274
+ restore it to the slave, and adjust the log name and offset on the slave
23275
+ all at once. In the future, @code{LOAD DATA FROM MASTER} will be the
23276
+ recommended way to set up a slave. Be warned, howerver, that the read
23277
+ lock may be held for a long time if you use this command. It is not yet
23278
+ implemented as efficiently as we would like to have it. If you have
23279
+ large tables, the preferred method at this time is still with a local
23280
+ @code{tar} snapshot after executing @code{FLUSH TABLES WITH READ LOCK}.
23281
+
23282
+ @strong{Q}: Does the slave need to be connected to the master all the time?
23283
+
23284
+ @strong{A}: No, it does not. You can have the slave go down or stay
23285
+ disconnected for hours or even days, then reconnect, catch up on the
23286
+ updates, and then disconnect or go down for a while again. So you can,
23287
+ for example, use master-slave setup over a dial-up link that is up only
23288
+ for short periods of time. The implications of that are that at any
23289
+ given time the slave is not guaranteed to be in sync with the master
23290
+ unless you take some special measures. In the future, we will have the
23291
+ option to block the master until at least one slave is in sync.
23292
+
23293
+ @strong{Q}: How do I force the master to block updates until the slave catches
23294
+ up?
23295
+
23296
+ @strong{A}: Execute the following commands:
23297
+
23298
+ @itemize @bullet
23299
+ @item
23300
+ Master: @code{FLUSH TABLES WITH READ LOCK}
23301
+ @item
23302
+ Master: @code{SHOW MASTER STATUS} - record the log name and the offset
23303
+ @item
23304
+ Slave: @code{SELECT MASTER_POS_WAIT('recorded_log_name', recorded_log_offset)}
23305
+ When the select returns, the slave is currently in sync with the master
23306
+ @item
23307
+ Master: @code{UNLOCK TABLES} - now the master will continue updates.
23308
+ @end itemize
23309
+
23109
23310
@cindex @code{Binlog_Dump}
23110
23311
@strong{Q}: Why do I sometimes see more than one @code{Binlog_Dump} thread on
23111
23312
the master after I have restarted the slave?
@@ -46549,6 +46750,13 @@ Our TODO section contains what we plan to have in 4.0. @xref{TODO MySQL 4.0}.
46549
46750
46550
46751
@itemize @bullet
46551
46752
@item
46753
+ Fixed slave to be able to replicate from 3.23 master
46754
+ @item
46755
+ Misc replication clean-ups
46756
+ @item
46757
+ Got shutdown to work on systems that do not interrupt syscall on a signal
46758
+ such as MacOS X
46759
+ @item
46552
46760
Fixed core dump bug in @code{UPDATE ... ORDER BY }.
46553
46761
@item
46554
46762
Changed @code{INSERT INTO .. SELECT} to by default stop on errors.
@@ -46634,8 +46842,6 @@ Renamed @code{safe_mysqld} to @code{mysqld_safe}.
46634
46842
Added support for symbolic links to @code{MyISAM} tables. Symlink handling is
46635
46843
now enabled by default for Windows.
46636
46844
@item
46637
- @code{LOAD DATA FROM MASTER} "auto-magically" sets up a slave.
46638
- @item
46639
46845
Added @code{SQL_CALC_FOUND_ROWS} and @code{FOUND_ROWS()}. This makes it
46640
46846
possible to know how many rows a query would have returned
46641
46847
without a @code{LIMIT} clause.
0 commit comments