6.8. Replication Startup Options

MySQL 5.0

previous page next page

6.8. Replication Startup Options

This section describes the options that you can use on slave replication servers. You can specify these options either on the command line or in an option file.

On the master and each slave, you must use the option to establish a unique replication ID. For each server, you should pick a unique positive integer in the range from 1 to 232 – 1, and each ID must be different from every other ID. Example:

Options that you can use on the master server for controlling binary logging are described in Section 5.12.3, “The Binary Log”.

Some slave server replication options are handled in a special way, in the sense that each is ignored if a file exists when the slave starts and contains a value for the option. The following options are handled this way:

The file format in MySQL 5.0 includes values corresponding to the SSL options. In addition, the file format includes as its first line the number of lines in the file. (See Section 6.3.4, “Replication Relay and Status Files”.) If you upgrade an older server (before MySQL 4.1.1) to a newer version, the new server upgrades the file to the new format automatically when it starts. However, if you downgrade a newer server to an older version, you should remove the first line manually before starting the older server for the first time.

If no file exists when the slave server starts, it uses the values for those options that are specified in option files or on the command line. This occurs when you start the server as a replication slave for the very first time, or when you have run and then have shut down and restarted the slave.

If the file exists when the slave server starts, the server uses its contents and ignores any options that correspond to the values listed in the file. Thus, if you start the slave server with different values of the startup options that correspond to values in the file, the different values have no effect, because the server continues to use the file. To use different values, you must either restart after removing the file or (preferably) use the statement to reset the values while the slave is running.

Suppose that you specify this option in your file: 

[mysqld]
master-host=

The first time you start the server as a replication slave, it reads and uses that option from the file. The server then records the value in the file. The next time you start the server, it reads the master host value from the file only and ignores the value in the option file. If you modify the file to specify a different master host of , the change still has no effect. You should use instead.

Because the server gives an existing file precedence over the startup options just described, you might prefer not to use startup options for these values at all, and instead specify them by using the statement. See Section 13.6.2.1, “ Syntax”.

This example shows a more extensive use of startup options to configure a slave server: 

[mysqld]
server-id=2
master-host=db-master.mycompany.com
master-port=3306
master-user=pertinax
master-password=freitag
master-connect-retry=60
report-host=db-slave.mycompany.com

The following list describes startup options for controlling replication. Many of these options can be reset while the server is running by using the statement. Others, such as the options, can be set only when the slave server starts.

  • Normally, a slave does not log to its own binary log any updates that are received from a master server. This option tells the slave to log the updates performed by its SQL thread to its own binary log. For this option to have any effect, the slave must also be started with the option to enable binary logging. is used when you want to chain replication servers. For example, you might want to set up replication servers using this arrangement: 

    A -> B -> C

    Here, A serves as the master for the slave B, and B serves as the master for the slave C. For this to work, B must be both a master and a slave. You must start both A and B with to enable binary logging, and B with the option so that updates received from A are logged by B to its binary log.

  • ]

    This option causes a server to print more messages to the error log about what it is doing. With respect to replication, the server generates warnings that it succeeded in reconnecting after a network/connection failure, and informs you as to how each slave thread started. This option is enabled by default; to disable it, use . Aborted connections are not logged to the error log unless the value is greater than 1.

  • The number of seconds that the slave thread sleeps before trying to reconnect to the master in case the master goes down or the connection is lost. The value in the file takes precedence if it can be read. If not set, the default is 60.

  • The hostname or IP number of the master replication server. The value in takes precedence if it can be read. If no master host is specified, the slave thread does not start.

  • The name to use for the file in which the slave records information about the master. The default name is in the data directory.

  • The password of the account that the slave thread uses for authentication when it connects to the master. The value in the file takes precedence if it can be read. If not set, an empty password is assumed.

  • The TCP/IP port number that the master is listening on. The value in the file takes precedence if it can be read. If not set, the compiled-in setting is assumed (normally 3306).

  • The number of times that the slave tries to connect to the master before giving up.

  • , , , , ,

    These options are used for setting up a secure replication connection to the master server using SSL. Their meanings are the same as the corresponding , , , , , options that are described in Section 5.9.7.3, “SSL Command Options”. The values in the file take precedence if they can be read.

  • The username of the account that the slave thread uses for authentication when it connects to the master. This account must have the privilege. The value in the file takes precedence if it can be read. If the master username is not set, the name is assumed.

  • The size at which the server rotates relay log files automatically. For more information, see Section 6.3.4, “Replication Relay and Status Files”.

  • Cause the slave to allow no updates except from slave threads or from users having the privilege. This enables you to ensure that a slave server accepts no updates from clients. As of MySQL 5.0.16, this option does not apply to tables.

  • The name for the relay log. The default name is -relay-bin., where is the name of the slave server host and indicates that relay logs are created in numbered sequence. You can specify the option to create hostname-independent relay log names, or if your relay logs tend to be big (and you don't want to decrease ) and you need to put them in some area different from the data directory, or if you want to increase speed by balancing load between disks.

  • The name to use for the relay log index file. The default name is -relay-bin.index in the data directory, where is the name of the slave server.

  • The name to use for the file in which the slave records information about the relay logs. The default name is in the data directory.

  • Disable or enable automatic purging of relay logs as soon as they are not needed any more. The default value is 1 (enabled). This is a global variable that can be changed dynamically with .

  • This option places an upper limit on the total size in bytes of all relay logs on the slave. A value of 0 means “no limit.” This is useful for a slave server host that has limited disk space. When the limit is reached, the I/O thread stops reading binary log events from the master server until the SQL thread has caught up and deleted some unused relay logs. Note that this limit is not absolute: There are cases where the SQL thread needs more events before it can delete relay logs. In that case, the I/O thread exceeds the limit until it becomes possible for the SQL thread to delete some relay logs, because not doing so would cause a deadlock. You should not set to less than twice the value of (or if is 0). In that case, there is a chance that the I/O thread waits for free space because is exceeded, but the SQL thread has no relay log to purge and is unable to satisfy the I/O thread. This forces the I/O thread to temporarily ignore .

  • Tell the slave to restrict replication to statements where the default database (that is, the one selected by ) is . To specify more than one database, use this option multiple times, once for each database. Note that this does not replicate cross-database statements such as SET foo='bar' while having selected a different database or no database.

    An example of what does not work as you might expect: If the slave is started with and you issue the following statements on the master, the statement is not replicated: 

    USE prices;
UPDATE sales.january SET amount=amount+1000;

    The main reason for this “just check the default database” behavior is that it is difficult from the statement alone to know whether it should be replicated (for example, if you are using multiple-table statements or multiple-table statements that act across multiple databases). It is also faster to check only the default database rather than all databases if there is no need.

    If you need cross-database updates to work, use .% instead. See Section 6.9, “How Servers Evaluate Replication Rules”.

  • Tell the slave thread to restrict replication to the specified table. To specify more than one table, use this option multiple times, once for each table. This works for cross-database updates, in contrast to . See Section 6.9, “How Servers Evaluate Replication Rules”.

  • Tells the slave to not replicate any statement where the default database (that is, the one selected by ) is . To specify more than one database to ignore, use this option multiple times, once for each database. You should not use this option if you are using cross-database updates and you do not want these updates to be replicated. See Section 6.9, “How Servers Evaluate Replication Rules”.

    An example of what does not work as you might expect: If the slave is started with and you issue the following statements on the master, the statement is not replicated: 

    USE prices;
UPDATE sales.january SET amount=amount+1000;

    If you need cross-database updates to work, use .% instead. See Section 6.9, “How Servers Evaluate Replication Rules”.

  • Tells the slave thread to not replicate any statement that updates the specified table, even if any other tables might be updated by the same statement. To specify more than one table to ignore, use this option multiple times, once for each table. This works for cross-database updates, in contrast to . See Section 6.9, “How Servers Evaluate Replication Rules”.

  • ->

    Tells the slave to translate the default database (that is, the one selected by ) to if it was on the master. Only statements involving tables are affected (not statements such as , , and ), and only if is the default database on the master. This does not work for cross-database updates. The database name translation is done before the rules are tested.

    If you use this option on the command line and the ‘’ character is special to your command interpreter, quote the option value. For example: 

    shell> ->"

  • To be used on slave servers. Usually you should use the default setting of 0, to prevent infinite loops caused by circular replication. If set to 1, the slave does not skip events having its own server ID. Normally, this is useful only in rare configurations. Cannot be set to 1 if is used. Note that by default the slave I/O thread does not even write binary log events to the relay log if they have the slave's server id (this optimization helps save disk usage). So if you want to use , be sure to start the slave with this option before you make the slave read its own events that you want the slave SQL thread to execute.

  • Tells the slave thread to restrict replication to statements where any of the updated tables match the specified database and table name patterns. Patterns can contain the ‘’ and ‘’ wildcard characters, which have the same meaning as for the pattern-matching operator. To specify more than one table, use this option multiple times, once for each table. This works for cross-database updates. See Section 6.9, “How Servers Evaluate Replication Rules”.

    Example: replicates only updates that use a table where the database name starts with and the table name starts with .

    If the table name pattern is , it matches any table name and the option also applies to database-level statements (, , and ). For example, if you use , database-level statements are replicated if the database name matches the pattern .

    To include literal wildcard characters in the database or table name patterns, escape them with a backslash. For example, to replicate all tables of a database that is named , but not replicate tables from the database, you should escape the ‘’ and ‘’ characters like this: . If you're using the option on the command line, you might need to double the backslashes or quote the option value, depending on your command interpreter. For example, with the bash shell, you would need to type .

  • Tells the slave thread not to replicate a statement where any table matches the given wildcard pattern. To specify more than one table to ignore, use this option multiple times, once for each table. This works for cross-database updates. See Section 6.9, “How Servers Evaluate Replication Rules”.

    Example: does not replicate updates that use a table where the database name starts with and the table name starts with .

    For information about how matching works, see the description of the option. The rules for including literal wildcard characters in the option value are the same as for as well.

  • The hostname or IP number of the slave to be reported to the master during slave registration. This value appears in the output of on the master server. Leave the value unset if you do not want the slave to register itself with the master. Note that it is not sufficient for the master to simply read the IP number of the slave from the TCP/IP socket after the slave connects. Due to NAT and other routing issues, that IP may not be valid for connecting to the slave from the master or other hosts.

  • The TCP/IP port number for connecting to the slave, to be reported to the master during slave registration. Set this only if the slave is listening on a non-default port or if you have a special tunnel from the master or other clients to the slave. If you are not sure, do not use this option.

  • Tells the slave server not to start the slave threads when the server starts. To start the threads later, use a statement.

  • If this option is set to 1, use compression for the slave/master protocol if both the slave and the master support it.

  • The name of the directory where the slave creates temporary files. This option is by default equal to the value of the system variable. When the slave SQL thread replicates a statement, it extracts the file to be loaded from the relay log into temporary files, and then loads these into the table. If the file loaded on the master is huge, the temporary files on the slave are huge, too. Therefore, it might be advisable to use this option to tell the slave to put temporary files in a directory located in some filesystem that has a lot of available space. In that case, the relay logs are huge as well, so you might also want to use the option to place the relay logs in that filesystem.

    The directory specified by this option should be located in a disk-based filesystem (not a memory-based filesystem) because the temporary files used to replicate must survive machine restarts. The directory also should not be one that is cleared by the operating system during the system startup process.

  • The number of seconds to wait for more data from the master before the slave considers the connection broken, aborts the read, and tries to reconnect. The first retry occurs immediately after the timeout. The interval between retries is controlled by the option.

  • ,,...|all]

    Normally, replication stops when an error occurs on the slave. This gives you the opportunity to resolve the inconsistency in the data manually. This option tells the slave SQL thread to continue replication when a statement returns any of the errors listed in the option value.

    Do not use this option unless you fully understand why you are getting errors. If there are no bugs in your replication setup and client programs, and no bugs in MySQL itself, an error that stops replication should never occur. Indiscriminate use of this option results in slaves becoming hopelessly out of synchrony with the master, with you having no idea why this has occurred.

    For error codes, you should use the numbers provided by the error message in your slave error log and in the output of . Appendix B, Error Codes and Messages, lists server error codes.

    You can also (but should not) use the very non-recommended value of to cause the slave to ignore all error messages and keeps going regardless of what happens. Needless to say, if you use , there are no guarantees regarding the integrity of your data. Please do not complain (or file bug reports) in this case if the slave's data is not anywhere close to what it is on the master. You have been warned.

    Examples: 

    --slave-skip-errors=1062,1053
--slave-skip-errors=all
previous page start next page