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'

CHANGE MASTER TO ändert die Parameter, die der Slave-Server zur Verbindungsherstellung und Kommunikation mit dem Master-Server verwendet. Die Anweisung aktualisiert auch den Inhalt der Dateien master.info und relay-log.info.

MASTER_USER, MASTER_PASSWORD, MASTER_SSL, MASTER_SSL_CA, MASTER_SSL_CAPATH, MASTER_SSL_CERT, MASTER_SSL_KEY und MASTER_SSL_CIPHER vermitteln dem Slave Informationen dazu, wie er Verbindungen mit dem Master herstellen kann.

Die SSL-Optionen (MASTER_SSL, MASTER_SSL_CA, MASTER_SSL_CAPATH, MASTER_SSL_CERT, MASTER_SSL_KEY und MASTER_SSL_CIPHER) können auch auf Slaves geändert werden, die ohne SSL-Unterstützung kompiliert wurden. Sie werden in der Datei master.info gespeichert, aber ignoriert, bis Sie einen Server verwenden, auf dem die SSL-Unterstützung aktiviert ist.

Wenn Sie einen der Parameter nicht angeben, dann behält er in der Regel seinen alten Wert (Ausnahmen entnehmen Sie der nachfolgenden Erläuterung). Wenn sich beispielsweise das Passwort, mit dem die Verbindung zu Ihrem MySQL-Master hergestellt wird, geändert hat, müssen Sie nur die folgenden Anweisungen absetzen, um dem Slave das neue Passwort mitzuteilen:

STOP SLAVE; -- if replication was running
CHANGE MASTER TO MASTER_PASSWORD='new3cret';
START SLAVE; -- if you want to restart replication

Es ist nicht notwendig, Parameter anzugeben, die sich nicht ändern (Host, Port, Benutzer usw.).

MASTER_HOST und MASTER_PORT sind der Hostname (oder die IP-Adresse) des Master-Hosts bzw. sein TCP/IP-Port. Beachten Sie, dass, wenn MASTER_HOST gleich localhost ist, die Portnummer – wie unter MySQL bei anderen Gelegenheiten auch – unter Umständen ignoriert werden kann (dies ist etwa der Fall, wenn Unix-Socketdateien benutzt werden).

Geben Sie MASTER_HOST oder MASTER_PORT an, dann setzt der Slave voraus, dass der Master-Server sich vom vorherigen unterscheidet (und zwar auch dann, wenn Sie einen Host- oder Portwert angeben, der mit dem aktuellen Wert identisch ist). In diesem Fall werden die alten Namens- und Positionswerte der Binärlogdatei auf dem Master-Server als nun ungültig betrachtet, d. h., wenn Sie MASTER_LOG_FILE und MASTER_LOG_POS in der Anweisung nicht angeben, werden stillschweigend MASTER_LOG_FILE='' und MASTER_LOG_POS=4 angehängt.

MASTER_LOG_FILE und MASTER_LOG_POS sind die Koordinaten, bei denen der Slave-I/O-Thread mit dem Lesen vom Master beginnen soll, wenn der Thread beim nächsten Mal startet. Wenn Sie einen dieser Werte angeben, dürfen Sie RELAY_LOG_FILE oder RELAY_LOG_POS nicht angeben. Wenn weder MASTER_LOG_FILE noch MASTER_LOG_POS angegeben werden, verwendet der Slave die letzten Koordinaten des Slave-SQL-Threads, bevor CHANGE MASTER abgesetzt wurde. Hierdurch ist gewährleistet, dass es bei der Replikation auch dann nicht zu Unstetigkeiten kommt, wenn der Slave-SQL-Thread sehr spät mit dem Slave-I/O-Thread verglichen wurde – etwa dann, wenn Sie beispielsweise nur das zu verwendende Passwort ändern wollen.

CHANGE MASTER löscht alle Relay-Logdateien und beginnt eine neue Relay-Logdatei, sofern Sie nicht RELAY_LOG_FILE oder RELAY_LOG_POS angeben. In diesem Fall werden die Relay-Logs behalten, und die globale Variable relay_log_purge wird stillschweigend auf 0 gesetzt.

CHANGE MASTER ist praktisch, wenn es darum geht, einen Slave zu konfigurieren, und Sie hierfür die Momentaufnahme des Masters benötigen und Logdatei und Offset entsprechend aufgezeichnet haben. Nachdem Sie die Momentaufnahme in den Slave geladen haben, können Sie CHANGE MASTER TO MASTER_LOG_FILE='log_name_on_master', MASTER_LOG_POS=log_offset_on_master auf dem Slave ausführen.

Das folgende Beispiel ändert die Koordinaten des Masters und dessen Binärlogdatei. Dies tut man, wenn man den Slave so konfiguriert, dass er den Master repliziert:

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;

Das nächste Beispiel zeigt eine Operation, die weniger häufig benötigt wird. Sie wird verwendet, wenn auf dem Slave Relay-Logs vorhanden sind, die Sie aus irgendeinem Grund erneut ausführen wollen. Zu diesem Zweck muss der Master nicht erreichbar sein. Sie müssen lediglich CHANGE MASTER TO benutzen und den SQL-Thread mit START SLAVE SQL_THREAD starten:

CHANGE MASTER TO
  RELAY_LOG_FILE='slave-relay-bin.006',
  RELAY_LOG_POS=4025;

Sie können die zweite Operation sogar in einer Nicht-Replikations-Konfiguration mit einem eigenständigen Nicht-Slave-Server benutzen, um nach einem Absturz eine Wiederherstellung durchzuführen. Angenommen, Ihr Server ist abgestürzt, und Sie haben eine Sicherung wiederhergestellt. Nun wollen Sie die eigenen Binärlogs des Servers – nicht die Relay-Logs, sondern die regulären Binärlogs – namens (beispielsweise) myhost-bin.* wieder auf den Server aufspielen. Zunächst erstellen Sie ein Backup dieser Binärlogs an einer sicheren Position für den Fall, dass Sie der nachfolgenden Anleitung nicht exakt folgen und der Server deswegen die Binärlogs unbeabsichtigt löscht. Verwenden Sie SET GLOBAL relay_log_purge=0, um die Sicherheit zu erhöhen. Danach starten Sie den Server ohne die Option --log-bin. Stattdessen geben Sie die Optionen --replicate-same-server-id, --relay-log=myhost-bin (damit der Server glaubt, dass es sich bei diesen regulären Logs um Relay-Logs handelt) und --skip-slave-start an. Nach dem Serverstart setzen Sie die folgenden Anweisungen ab:

CHANGE MASTER TO
  RELAY_LOG_FILE='myhost-bin.153',
  RELAY_LOG_POS=410,
  MASTER_HOST='some_dummy_string';
START SLAVE SQL_THREAD;

Der Server liest nun seine eigenen Binärlogs und führt diese aus. Auf diese Weise erfolgt eine Wiederherstellung der Daten. Nach deren Abschluss führen Sie STOP SLAVE aus, fahren den Server herunter, löschen die Dateien master.info und relay-log.info und starten den Server mit den ursprünglichen Optionen neu.

Die Angabe der Option MASTER_HOST (auch mit einem Pseudowert) ist erforderlich, damit der Server annimmt, er sei ein Slave.