[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
CHANGE MASTER TO
CHANGE MASTER TO master_def [, master_def] ... master_def = MASTER_HOST = 'host_name' | MASTER_USER = 'user_name' | MASTER_PASSWORD = 'password' | MASTER_PORT = port_num | MASTER_CONNECT_RETRY = count | MASTER_LOG_FILE = 'master_log_name' | MASTER_LOG_POS = master_log_pos | RELAY_LOG_FILE = 'relay_log_name' | RELAY_LOG_POS = relay_log_pos | MASTER_SSL = {0|1} | MASTER_SSL_CA = 'ca_file_name' | MASTER_SSL_CAPATH = 'ca_directory_name' | MASTER_SSL_CERT = 'cert_file_name' | MASTER_SSL_KEY = 'key_file_name' | MASTER_SSL_CIPHER = 'cipher_list' |
Changes the parameters that the slave server uses for connecting to and
communicating with the master server.
The possible master_def
values are shown above.
The relay log options
(RELAY_LOG_FILE
and RELAY_LOG_POS
) are available beginning with
MySQL 4.0.
The SSL options
(MASTER_SSL
,
MASTER_SSL_CA
,
MASTER_SSL_CAPATH
,
MASTER_SSL_CERT
,
MASTER_SSL_KEY
,
and
MASTER_SSL_CIPHER
)
are available beginning with MySQL 4.1.1.
You can change these options even on slaves that are compiled without SSL
support. They will be saved to the `master.info' file but ignored until
you use a server that has SSL support enabled.
For example:
mysql> CHANGE MASTER TO -> MASTER_HOST='master2.mycompany.com', -> MASTER_USER='replication', -> MASTER_PASSWORD='bigs3cret', -> MASTER_PORT=3306, -> MASTER_LOG_FILE='master2-bin.001', -> MASTER_LOG_POS=4, -> MASTER_CONNECT_RETRY=10; mysql> CHANGE MASTER TO -> RELAY_LOG_FILE='slave-relay-bin.006', -> RELAY_LOG_POS=4025; |
MASTER_USER
, MASTER_PASSWORD
,
MASTER_SSL
, MASTER_SSL_CA
,
MASTER_SSL_CAPATH
, MASTER_SSL_CERT
, MASTER_SSL_KEY
,
and MASTER_SSL_CIPHER
are information for the slave to be able to
connect to its master. If you don't specify some of these
informations, the non-specified informations will keep their old
value. For example, if the password to connect to your MySQL master has
changed, you just need to issue
mysql> STOP SLAVE; -- if replication was running mysql> CHANGE MASTER TO MASTER_PASSWORD='new3cret'; mysql> START SLAVE; -- if you want to restart replication |
MASTER_HOST
, MASTER_PORT
are the hostname or IP adress of
the master host, and its TCP port. Note that if MASTER_HOST
is
equal to localhost
, then, like in other parts of MySQL, the port
may be ignored (if Unix socket files can be used for example).
If you specify MASTER_HOST
or MASTER_PORT
,
the slave will assume that the master server is different than
before (even if you specify a host or port value value that is
the same as the current value.) In this case, the old values of master
binlog name and position are considered no longer applicable, so if you
do not specify MASTER_LOG_FILE
and MASTER_LOG_POS
in the
command, MASTER_LOG_FILE="
and MASTER_LOG_POS=4
are
silently appended to it.
MASTER_LOG_FILE
and MASTER_LOG_POS
are the coordinates
at which the slave I/O thread should begin reading from the master the
next time the thread starts.
If you specify any of them, you can't specify RELAY_LOG_FILE
or
RELAY_LOG_POS
.
If none of MASTER_LOG_FILE
and MASTER_LOG_POS
was
specified, then the last coordinates of the slave SQL thread
before CHANGE MASTER
was issued, are used. This ensures that
replication has no discontinuity, even if the slave SQL thread was late
compared to the slave I/O thread, when you just want to change, say, the
password to use. This safe behavior was introduced starting from MySQL
4.0.17 and 4.1.1. (Before these versions, the used coordinates were
the last coordinates of the slave I/O thread before CHANGE MASTER
was issued, which caused the SQL thread to sometimes lose some events
from the master, thus breaking replication.)
CHANGE MASTER
deletes all relay logs (and starts
a new one), unless you specified RELAY_LOG_FILE
or
RELAY_LOG_POS
(in that case relay logs will be kept;
since MySQL 4.1.1 the RELAY_LOG_PURGE
global variable
will silently be set to 0).
CHANGE MASTER TO
updates `master.info' and
`relay-log.info'.
CHANGE MASTER
is useful for setting up a slave when you have the snapshot of
the master and have recorded the log and the offset on the master that the
snapshot corresponds to. You can run
CHANGE MASTER TO MASTER_LOG_FILE='log_name_on_master',
MASTER_LOG_POS=log_offset_on_master
on the slave after restoring the
snapshot.
The first example above
(CHANGE MASTER TO MASTER_HOST='master2.mycompany.com' etc
)
changes the master and master's binlog
coordinates. This is when you want the slave to replicate the master.
The second example, less frequently used, is when the slave has relay logs which, for some
reason, you want the slave to execute again; to do this the master
needn't be reachable, you just have to do CHANGE MASTER TO
and start the SQL thread (START SLAVE SQL_THREAD
).
You can even use this out of a replication setup, on a standalone,
slave-of-nobody server, to recover after a crash.
Suppose your server has crashed and you have restored a backup.
You want to replay the server's own binlogs (not relay logs, but regular binary
logs), supposedly named `myhost-bin.*'. First make a backup copy of
these binlogs in some safe place, in case you don't exactly follow the
procedure below and accidentally have the server purge the binlogs.
If using MySQL 4.1.1 or newer, do SET GLOBAL RELAY_LOG_PURGE=0
for additional safety.
Then start the server without log-bin
, with a new
(different from before) server ID, with relay-log=myhost-bin
(to make the server believe that these regular binlogs are relay
logs) and skip-slave-start
,
then issue these statements:
mysql> CHANGE MASTER TO -> RELAY_LOG_FILE='myhost-bin.153', -> RELAY_LOG_POS=410, -> MASTER_HOST='some_dummy_string'; mysql> START SLAVE SQL_THREAD; |
Then the server will read and execute its own binlogs, thus achieving
crash recovery.
Once the recovery is finished, run STOP SLAVE
, shutdown the
server, delete `master.info' and `relay-log.info',
and restart the server with its original options.
For the moment, specifying MASTER_HOST
(even with a dummy value) is compulsory
to make the server think it is a slave, and giving the server a new,
different from before, server ID is also compulsory otherwise the
server will see events with its ID and think it is in a circular
replication setup and skip the events, which is unwanted. In the
future we plan to add options to get rid of these small constraints.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |