Replication and Binary Logging Options and Variables

The next few sections contain information about mysqld options and server variables that are used in replication and for controlling the binary log. Options and variables for use on replication masters and replication slaves are covered separately, as are options and variables relating to binary logging. A set of quick-reference tables providing basic information about these options and variables is also included (in the next section following this one).

Of particular importance is the --server-id option.

Command-Line Format	`--server-id=#`
Option-File Format	`server-id`
Option Sets Variable	Yes, `server_id`
Variable Name	`server_id`
Variable Scope	Global
Dynamic Variable	Yes
	Permitted Values
	Type	`numeric`
	Default	`0`
	Range	`0 .. 4294967295`

This option is common to both master and slave replication servers, and is used in replication to enable master and slave servers to identify themselves uniquely. For additional information, see , "Replication Master Options and Variables", and , "Replication Slave Options and Variables".

On the master and each slave, you must use the --server-id option to establish a unique replication ID in the range from 1 to 2³² - 1. "Unique", means that each ID must be different from every other ID in use by any other replication master or slave. Example: server-id=3.

If you omit --server-id, the default ID is 0, in which case a master refuses connections from all slaves, and a slave refuses to connect to a master. For more information, see , "Setting the Replication Slave Configuration".

server_uuid

Beginning with MariaDB 5.6, the server generates a true UUID in addition to the --server-id supplied by the user. This is available as the global, read-only variable server_uuid.

Version Introduced	5.6.0
Variable Name	`server_uuid`
Variable Scope	Global
Dynamic Variable	No
	Permitted Values
	Type	`string`

When starting, the MariaDB server automatically obtains a UUID as follows:

Attempt to read and use the UUID written in the file data_dir/auto.cnf (where data_dir is the server's data directory); exit on success.
Otherwise, generate a new UUID and save it to this file, creating the file if necessary.

The auto.cnf file has a format similar to that used for my.cnf or my.ini files. In MariaDB 5.6, auto.cnf has only a single [auto] section containing a single server_uuid setting and value; the file's contents appear similar to what is shown here:

[auto]
server_uuid=8a94f357-aab4-11df-86ab-c80aa9429562

Important

The auto.cnf file is automatically generated; you should not attempt to write or modify this file.

Also beginning with MariaDB 5.6, when using MariaDB replication, masters and slaves know one another's UUIDs. The value of a slave's UUID can be seen in the output of SHOW SLAVE HOSTS. Once START SLAVE has been executed (but not before), the value of the master's UUID is available on the slave in the output of SHOW SLAVE STATUS.Note

Issuing a STOP SLAVE or RESET SLAVE statement does not reset the master's UUID as used on the slave.

When starting, the slave I/O thread generates an error and aborts if its master's UUID is equal to its own unless the --replicate-same-server-id option has been set. In addition, the slave I/O thread generates a warning if either of the following is true:

No master having the expected server_uuid exists.
The master's server-uuid has changed, although no CHANGE MASTER TO statement has ever been executed.

Note

The addition of the server_uuid system variable in MariaDB 5.6 does not change the requirement for setting a unique --server-id for each MariaDB server as part of preparing and running MariaDB replication, as described earlier in this section.

Replication and Binary Logging Options and Variables

Retornar