Documentation Home
MySQL 8.0 Reference Manual
Related Documentation Download this Manual
PDF (US Ltr) - 44.6Mb
PDF (A4) - 44.7Mb
PDF (RPM) - 40.5Mb
HTML Download (TGZ) - 10.5Mb
HTML Download (Zip) - 10.5Mb
HTML Download (RPM) - 9.1Mb
Man Pages (TGZ) - 205.6Kb
Man Pages (Zip) - 308.9Kb
Info (Gzip) - 3.9Mb
Info (Zip) - 3.9Mb
Excerpts from this Manual

17.1.6.3 Replication Slave Options and Variables

This section explains the server options and system variables that apply to slave replication servers and contains the following:

Specify the options either on the command line or in an option file. Many of the options can be set while the server is running by using the CHANGE MASTER TO statement. Specify system variable values using SET.

Server ID.  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 232 − 1. Unique means that each ID must be different from every other ID in use by any other replication master or slave. Example my.cnf file:

[mysqld]
server-id=3
Startup Options for Replication Slaves

This section explains startup options for controlling replication slave servers. Many of these options can be set while the server is running by using the CHANGE MASTER TO statement. Others, such as the --replicate-* options, can be set only when the slave server starts. Replication-related system variables are discussed later in this section.

  • --log-slave-updates

    Property Value
    Command-Line Format --log-slave-updates
    System Variable log_slave_updates
    Scope Global
    Dynamic No
    SET_VAR Hint Applies No
    Type Boolean
    Default Value (>= 8.0.3) ON
    Default Value (<= 8.0.2) OFF

    This option makes a slave write updates that are received from a master server and performed by the slave's SQL thread to the slave's own binary log. Binary logging, which is controlled by the --log-bin option and is enabled by default, must also be enabled on the slave for updates to be logged. --log-slave-updates is enabled by default, unless you specify --skip-log-bin to disable binary logging, in which case MySQL also disables slave update logging by default. If you need to disable slave update logging when binary logging is enabled, specify --skip-log-slave-updates.

    --log-slave-updates enables replication servers to be chained. 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. With binary logging and the --log-slave-updates option enabled, which are the default settings, updates received from A are logged by B to its binary log, and can therefore be passed on to C.

  • --master-info-file=file_name

    Property Value
    Command-Line Format --master-info-file=file_name
    Type File name
    Default Value master.info

    The name for the master info log, if --master-info-repository=FILE is set. The default name is master.info in the data directory. --master-info-repository=FILE is now deprecated. For information about the master info log, see Section 17.2.4.2, “Slave Status Logs”.

  • --master-retry-count=count

    Property Value
    Command-Line Format --master-retry-count=#
    Deprecated Yes
    Type Integer
    Default Value 86400
    Minimum Value 0
    Maximum Value (64-bit platforms) 18446744073709551615
    Maximum Value (32-bit platforms) 4294967295

    The number of times that the slave tries to reconnect to the master before giving up. The default value is 86400 times. A value of 0 means infinite, and the slave attempts to connect forever. Reconnection attempts are triggered when the slave reaches its connection timeout (specified by the --slave-net-timeout option) without receiving data or a heartbeat signal from the master. Reconnection is attempted at intervals set by the MASTER_CONNECT_RETRY option of the CHANGE MASTER TO statement (which defaults to every 60 seconds).

    This option is deprecated and will be removed in a future MySQL release. Use the MASTER_RETRY_COUNT option of the CHANGE MASTER TO statement instead.

  • --max-relay-log-size=size

    Property Value
    Command-Line Format --max-relay-log-size=#
    System Variable max_relay_log_size
    Scope Global
    Dynamic Yes
    SET_VAR Hint Applies No
    Type Integer
    Default Value 0
    Minimum Value 0
    Maximum Value 1073741824

    The size at which the server rotates relay log files automatically. If this value is nonzero, the relay log is rotated automatically when its size exceeds this value. If this value is zero (the default), the size at which relay log rotation occurs is determined by the value of max_binlog_size. For more information, see Section 17.2.4.1, “The Slave Relay Log”.

  • --relay-log=file_name

    Property Value
    Command-Line Format --relay-log=file_name
    System Variable relay_log
    Scope Global
    Dynamic No
    SET_VAR Hint Applies No
    Type File name

    The base name for the relay log. The server creates relay log files in sequence by adding a numeric suffix to the base name.

    For the default replication channel, the default base name for relay logs is host_name-relay-bin, using the name of the host machine. For non-default replication channels, the default base name for relay logs is host_name-relay-bin-channel, where channel is the name of the replication channel recorded in this relay log.

    The default location for relay log files is the data directory. You can use the --relay-log option to specify an alternative location, by adding a leading absolute path name to the base name to specify a different directory.

    The relay log and relay log index on a replication server cannot be given the same names as the binary log and binary log index, whose names are specified by the --log-bin and --log-bin-index options. The server issues an error message and does not start if the binary log and relay log file base names would be the same.

    Due to the manner in which MySQL parses server options, if you specify this option, you must supply a value; the default base name is used only if the option is not actually specified. If you use the --relay-log option without specifying a value, unexpected behavior is likely to result; this behavior depends on the other options used, the order in which they are specified, and whether they are specified on the command line or in an option file. For more information about how MySQL handles server options, see Section 4.2.4, “Specifying Program Options”.

    If you specify this option, the value specified is also used as the base name for the relay log index file. You can override this behavior by specifying a different relay log index file base name using the --relay-log-index option.

    When the server reads an entry from the index file, it checks whether the entry contains a relative path. If it does, the relative part of the path is replaced with the absolute path set using the --relay-log option. An absolute path remains unchanged; in such a case, the index must be edited manually to enable the new path or paths to be used. Previously, manual intervention was required whenever relocating the binary log or relay log files. (Bug #11745230, Bug #12133)

    You may find the --relay-log option useful in performing the following tasks:

    • Creating relay logs whose names are independent of host names.

    • If you need to put the relay logs in some area other than the data directory because your relay logs tend to be very large and you do not want to decrease max_relay_log_size.

    • To increase speed by using load-balancing between disks.

    You can obtain the relay log file name (and path) from the relay_log_basename system variable.

  • --relay-log-index=file_name

    Property Value
    Command-Line Format --relay-log-index=file_name
    System Variable relay_log_index
    Scope Global
    Dynamic No
    SET_VAR Hint Applies No
    Type File name

    The name for the index file for the relay log. If you do not specify the --relay-log-index option, but the --relay-log option is specified, its value is used as the default base name for the relay log index file. If the --relay-log option is also not specified, then for the default replication channel, the default name is host_name-relay-bin.index, using the name of the host machine. For non-default replication channels, the default name is host_name-relay-bin-channel.index, where channel is the name of the replication channel recorded in this relay log index.

    The default location for relay log files is the data directory, or any other location that was specified using the --relay-log option. You can use the --relay-log-index option to specify an alternative location, by adding a leading absolute path name to the base name to specify a different directory.

    The relay log and relay log index on a replication server cannot be given the same names as the binary log and binary log index, whose names are specified by the --log-bin and --log-bin-index options. The server issues an error message and does not start if the binary log and relay log file base names would be the same.

    Due to the manner in which MySQL parses server options, if you specify this option, you must supply a value; the default base name is used only if the option is not actually specified. If you use the --relay-log-index option without specifying a value, unexpected behavior is likely to result; this behavior depends on the other options used, the order in which they are specified, and whether they are specified on the command line or in an option file. For more information about how MySQL handles server options, see Section 4.2.4, “Specifying Program Options”.

  • --relay-log-info-file=file_name

    Property Value
    Command-Line Format --relay-log-info-file=file_name
    Type File name
    Default Value relay-log.info

    The name for the relay log info file, if --relay-log-info-repository is set to FILE. The default name is relay-log.info in the data directory. --relay-log-info-repository=FILE is now deprecated. For information about the relay log info log, see Section 17.2.4.2, “Slave Status Logs”.

  • --relay-log-purge={0|1}

    Property Value
    Command-Line Format --relay-log-purge
    System Variable relay_log_purge
    Scope Global
    Dynamic Yes
    SET_VAR Hint Applies No
    Type Boolean
    Default Value TRUE

    Disable or enable automatic purging of relay logs as soon as they are no longer needed. The default value is 1 (enabled). This is a global variable that can be changed dynamically with SET GLOBAL relay_log_purge = N. Disabling purging of relay logs when using the --relay-log-recovery option risks data consistency and is therefore not crash-safe.

  • --relay-log-recovery={0|1}

    Property Value
    Command-Line Format --relay-log-recovery
    Type Boolean
    Default Value FALSE

    Enables automatic relay log recovery immediately following server startup. The recovery process creates a new relay log file, initializes the SQL thread position to this new relay log, and initializes the I/O thread to the SQL thread position. Reading of the relay log from the master then continues. This should be used following a crash on the replication slave to ensure that no possibly corrupted relay logs are processed. The default value is 0 (disabled).

    To provide a crash-safe slave, this option must be enabled (set to 1), --relay-log-info-repository must be set to TABLE, and relay-log-purge must be enabled. Enabling the --relay-log-recovery option when relay-log-purge is disabled risks reading the relay log from files that were not purged, leading to data inconsistency, and is therefore not crash-safe. See Making replication resilient to unexpected halts, for more information.

    When using a multithreaded slave (in other words slave_parallel_workers is greater than 0), inconsistencies such as gaps can occur in the sequence of transactions that have been executed from the relay log. Enabling the --relay-log-recovery option when there are inconsistencies causes an error and the option has no effect. The solution in this situation is to issue START SLAVE UNTIL SQL_AFTER_MTS_GAPS, which brings the server to a more consistent state, then issue RESET SLAVE to remove the relay logs. See Section 17.4.1.34, “Replication and Transaction Inconsistencies” for more information.

  • --relay-log-space-limit=size

    Property Value
    Command-Line Format --relay-log-space-limit=#
    System Variable relay_log_space_limit
    Scope Global
    Dynamic No
    SET_VAR Hint Applies No
    Type Integer
    Default Value 0
    Minimum Value 0
    Maximum Value (64-bit platforms) 18446744073709551615
    Maximum Value (32-bit platforms) 4294967295

    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 --relay-log-space-limit to less than twice the value of --max-relay-log-size (or --max-binlog-size if --max-relay-log-size is 0). In that case, there is a chance that the I/O thread waits for free space because --relay-log-space-limit 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 ignore --relay-log-space-limit temporarily.

  • --replicate-do-db=db_name

    Property Value
    Command-Line Format --replicate-do-db=name
    Type String

    Creates a replication filter using the name of a database. Such filters can also be created using CHANGE REPLICATION FILTER REPLICATE_DO_DB.

    This option supports channel specific replication filters, enabling multi-source replication slaves to use specific filters for different sources. To configure a channel specific replication filter on a channel named channel_1 use --replicate-do-db:channel_1:db_name. In this case, the first colon is interpreted as a separator and subsequent colons are literal colons. See Section 17.2.5.4, “Replication Channel Based Filters” for more information.

    Note

    Global replication filters cannot be used on a MySQL server instance that is configured for Group Replication, because filtering transactions on some servers would make the group unable to reach agreement on a consistent state. Channel specific replication filters can be used on replication channels that are not directly involved with Group Replication, such as where a group member also acts as a replication slave to a master that is outside the group. They cannot be used on the group_replication_applier or group_replication_recovery channels.

    The precise effect of this replication filter depends on whether statement-based or row-based replication is in use.

    Statement-based replication.  Tell the slave SQL thread to restrict replication to statements where the default database (that is, the one selected by USE) is db_name. To specify more than one database, use this option multiple times, once for each database; however, doing so does not replicate cross-database statements such as UPDATE some_db.some_table SET foo='bar' while a different database (or no database) is selected.

    Warning

    To specify multiple databases you must use multiple instances of this option. Because database names can contain commas, if you supply a comma separated list then the list is treated as the name of a single database.

    An example of what does not work as you might expect when using statement-based replication: If the slave is started with --replicate-do-db=sales and you issue the following statements on the master, the UPDATE statement is not replicated:

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

    The main reason for this check just 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 DELETE statements or multiple-table UPDATE 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.

    Row-based replication.  Tells the slave SQL thread to restrict replication to database db_name. Only tables belonging to db_name are changed; the current database has no effect on this. Suppose that the slave is started with --replicate-do-db=sales and row-based replication is in effect, and then the following statements are run on the master:

    USE prices;
    UPDATE sales.february SET amount=amount+100;

    The february table in the sales database on the slave is changed in accordance with the UPDATE statement; this occurs whether or not the USE statement was issued. However, issuing the following statements on the master has no effect on the slave when using row-based replication and --replicate-do-db=sales:

    USE prices;
    UPDATE prices.march SET amount=amount-25;

    Even if the statement USE prices were changed to USE sales, the UPDATE statement's effects would still not be replicated.

    Another important difference in how --replicate-do-db is handled in statement-based replication as opposed to row-based replication occurs with regard to statements that refer to multiple databases. Suppose that the slave is started with --replicate-do-db=db1, and the following statements are executed on the master:

    USE db1;
    UPDATE db1.table1 SET col1 = 10, db2.table2 SET col2 = 20;

    If you are using statement-based replication, then both tables are updated on the slave. However, when using row-based replication, only table1 is affected on the slave; since table2 is in a different database, table2 on the slave is not changed by the UPDATE. Now suppose that, instead of the USE db1 statement, a USE db4 statement had been used:

    USE db4;
    UPDATE db1.table1 SET col1 = 10, db2.table2 SET col2 = 20;

    In this case, the UPDATE statement would have no effect on the slave when using statement-based replication. However, if you are using row-based replication, the UPDATE would change table1 on the slave, but not table2—in other words, only tables in the database named by --replicate-do-db are changed, and the choice of default database has no effect on this behavior.

    If you need cross-database updates to work, use --replicate-wild-do-table=db_name.% instead. See Section 17.2.5, “How Servers Evaluate Replication Filtering Rules”.

    Note

    This option affects replication in the same manner that --binlog-do-db affects binary logging, and the effects of the replication format on how --replicate-do-db affects replication behavior are the same as those of the logging format on the behavior of --binlog-do-db.

    This option has no effect on BEGIN, COMMIT, or ROLLBACK statements.

  • --replicate-ignore-db=db_name

    Property Value
    Command-Line Format --replicate-ignore-db=name
    Type String

    Creates a replication filter using the name of a database. Such filters can also be created using CHANGE REPLICATION FILTER REPLICATE_IGNORE_DB.

    This option supports channel specific replication filters, enabling multi-source replication slaves to use specific filters for different sources. To configure a channel specific replication filter on a channel named channel_1 use --replicate-ignore-db:channel_1:db_name. In this case, the first colon is interpreted as a separator and subsequent colons are literal colons. See Section 17.2.5.4, “Replication Channel Based Filters” for more information.

    Note

    Global replication filters cannot be used on a MySQL server instance that is configured for Group Replication, because filtering transactions on some servers would make the group unable to reach agreement on a consistent state. Channel specific replication filters can be used on replication channels that are not directly involved with Group Replication, such as where a group member also acts as a replication slave to a master that is outside the group. They cannot be used on the group_replication_applier or group_replication_recovery channels.

    To specify more than one database to ignore, use this option multiple times, once for each database. Because database names can contain commas, if you supply a comma separated list then the list will be treated as the name of a single database.

    As with --replicate-do-db, the precise effect of this filtering depends on whether statement-based or row-based replication is in use, and are described in the next several paragraphs.

    Statement-based replication.  Tells the slave SQL thread not to replicate any statement where the default database (that is, the one selected by USE) is db_name.

    Row-based replication.  Tells the slave SQL thread not to update any tables in the database db_name. The default database has no effect.

    When using statement-based replication, the following example does not work as you might expect. Suppose that the slave is started with --replicate-ignore-db=sales and you issue the following statements on the master:

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

    The UPDATE statement is replicated in such a case because --replicate-ignore-db applies only to the default database (determined by the USE statement). Because the sales database was specified explicitly in the statement, the statement has not been filtered. However, when using row-based replication, the UPDATE statement's effects are not propagated to the slave, and the slave's copy of the sales.january table is unchanged; in this instance, --replicate-ignore-db=sales causes all changes made to tables in the master's copy of the sales database to be ignored by the slave.

    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 17.2.5, “How Servers Evaluate Replication Filtering Rules”.

    If you need cross-database updates to work, use --replicate-wild-ignore-table=db_name.% instead. See Section 17.2.5, “How Servers Evaluate Replication Filtering Rules”.

    Note

    This option affects replication in the same manner that --binlog-ignore-db affects binary logging, and the effects of the replication format on how --replicate-ignore-db affects replication behavior are the same as those of the logging format on the behavior of --binlog-ignore-db.

    This option has no effect on BEGIN, COMMIT, or ROLLBACK statements.

  • --replicate-do-table=db_name.tbl_name

    Property Value
    Command-Line Format --replicate-do-table=name
    Type String

    Creates a replication filter by telling the slave SQL thread to restrict replication to a given table. To specify more than one table, use this option multiple times, once for each table. This works for both cross-database updates and default database updates, in contrast to --replicate-do-db. See Section 17.2.5, “How Servers Evaluate Replication Filtering Rules”. You can also create such a filter by issuing a CHANGE REPLICATION FILTER REPLICATE_DO_TABLE statement.

    This option supports channel specific replication filters, enabling multi-source replication slaves to use specific filters for different sources. To configure a channel specific replication filter on a channel named channel_1 use --replicate-do-table:channel_1:db_name.tbl_name. In this case, the first colon is interpreted as a separator and subsequent colons are literal colons. See Section 17.2.5.4, “Replication Channel Based Filters” for more information.

    Note

    Global replication filters cannot be used on a MySQL server instance that is configured for Group Replication, because filtering transactions on some servers would make the group unable to reach agreement on a consistent state. Channel specific replication filters can be used on replication channels that are not directly involved with Group Replication, such as where a group member also acts as a replication slave to a master that is outside the group. They cannot be used on the group_replication_applier or group_replication_recovery channels.

    This option affects only statements that apply to tables. It does not affect statements that apply only to other database objects, such as stored routines. To filter statements operating on stored routines, use one or more of the --replicate-*-db options.

  • --replicate-ignore-table=db_name.tbl_name

    Property Value
    Command-Line Format --replicate-ignore-table=name
    Type String

    Creates a replication filter by telling the slave SQL thread not to 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 --replicate-ignore-db. See Section 17.2.5, “How Servers Evaluate Replication Filtering Rules”. You can also create such a filter by issuing a CHANGE REPLICATION FILTER REPLICATE_IGNORE_TABLE statement.

    This option supports channel specific replication filters, enabling multi-source replication slaves to use specific filters for different sources. To configure a channel specific replication filter on a channel named channel_1 use --replicate-ignore-table:channel_1:db_name.tbl_name. In this case, the first colon is interpreted as a separator and subsequent colons are literal colons. See Section 17.2.5.4, “Replication Channel Based Filters” for more information.

    Note

    Global replication filters cannot be used on a MySQL server instance that is configured for Group Replication, because filtering transactions on some servers would make the group unable to reach agreement on a consistent state. Channel specific replication filters can be used on replication channels that are not directly involved with Group Replication, such as where a group member also acts as a replication slave to a master that is outside the group. They cannot be used on the group_replication_applier or group_replication_recovery channels.

    This option affects only statements that apply to tables. It does not affect statements that apply only to other database objects, such as stored routines. To filter statements operating on stored routines, use one or more of the --replicate-*-db options.

  • --replicate-rewrite-db=from_name->to_name

    Property Value
    Command-Line Format --replicate-rewrite-db=old_name->new_name
    Type String

    Tells the slave to create a replication filter that translates the default database (that is, the one selected by USE) to to_name if it was from_name on the master. Only statements involving tables are affected (not statements such as CREATE DATABASE, DROP DATABASE, and ALTER DATABASE), and only if from_name is the default database on the master. To specify multiple rewrites, use this option multiple times. The server uses the first one with a from_name value that matches. The database name translation is done before the --replicate-* rules are tested. You can also create such a filter by issuing a CHANGE REPLICATION FILTER REPLICATE_REWRITE_DB statement.

    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> mysqld --replicate-rewrite-db="olddb->newdb"

    This option supports channel specific replication filters, enabling multi-source replication slaves to use specific filters for different sources. Specify the channel name followed by a colon, followed by the filter specification. The first colon is interpreted as a separator, and any subsequent colons are interpreted as literal colons. For example, to configure a channel specific replication filter on a channel named channel_1, use:

    shell> mysqld --replicate-rewrite-db=channel_1:db_name1->db_name2

    If you use a colon but do not specify a channel name, the option configures the replication filter for the default replication channel. See Section 17.2.5.4, “Replication Channel Based Filters” for more information.

    Note

    Global replication filters cannot be used on a MySQL server instance that is configured for Group Replication, because filtering transactions on some servers would make the group unable to reach agreement on a consistent state. Channel specific replication filters can be used on replication channels that are not directly involved with Group Replication, such as where a group member also acts as a replication slave to a master that is outside the group. They cannot be used on the group_replication_applier or group_replication_recovery channels.

    Statements in which table names are qualified with database names when using this option do not work with table-level replication filtering options such as --replicate-do-table. Suppose we have a database named a on the master, one named b on the slave, each containing a table t, and have started the master with --replicate-rewrite-db='a->b'. At a later point in time, we execute DELETE FROM a.t. In this case, no relevant filtering rule works, for the reasons shown here:

    1. --replicate-do-table=a.t does not work because the slave has table t in database b.

    2. --replicate-do-table=b.t does not match the original statement and so is ignored.

    3. --replicate-do-table=*.t is handled identically to --replicate-do-table=a.t, and thus does not work, either.

    Similarly, the --replication-rewrite-db option does not work with cross-database updates.

  • --replicate-same-server-id

    Property Value
    Command-Line Format --replicate-same-server-id
    Type Boolean
    Default Value FALSE

    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. The option cannot be set to 1 when --log-slave-updates is enabled, which is the default.

    By default, the slave I/O thread does not write binary log events to the relay log if they have the slave's server ID (this optimization helps save disk usage). If you want to use --replicate-same-server-id, 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.

  • --replicate-wild-do-table=db_name.tbl_name

    Property Value
    Command-Line Format --replicate-wild-do-table=name
    Type String

    Creates a replication filter by telling 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 LIKE 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 17.2.5, “How Servers Evaluate Replication Filtering Rules”. You can also create such a filter by issuing a CHANGE REPLICATION FILTER REPLICATE_WILD_DO_TABLE statement.

    This option supports channel specific replication filters, enabling multi-source replication slaves to use specific filters for different sources. To configure a channel specific replication filter on a channel named channel_1 use --replicate-wild-do-table:channel_1:db_name.tbl_name. In this case, the first colon is interpreted as a separator and subsequent colons are literal colons. See Section 17.2.5.4, “Replication Channel Based Filters” for more information.

    Note

    Global replication filters cannot be used on a MySQL server instance that is configured for Group Replication, because filtering transactions on some servers would make the group unable to reach agreement on a consistent state. Channel specific replication filters can be used on replication channels that are not directly involved with Group Replication, such as where a group member also acts as a replication slave to a master that is outside the group. They cannot be used on the group_replication_applier or group_replication_recovery channels.

    This option applies to tables, views, and triggers. It does not apply to stored procedures and functions, or events. To filter statements operating on the latter objects, use one or more of the --replicate-*-db options.

    As an example, --replicate-wild-do-table=foo%.bar% replicates only updates that use a table where the database name starts with foo and the table name starts with bar.

    If the table name pattern is %, it matches any table name and the option also applies to database-level statements (CREATE DATABASE, DROP DATABASE, and ALTER DATABASE). For example, if you use --replicate-wild-do-table=foo%.%, database-level statements are replicated if the database name matches the pattern foo%.

    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 my_own%db, but not replicate tables from the my1ownAABCdb database, you should escape the _ and % characters like this: --replicate-wild-do-table=my\_own\%db. If you use 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 --replicate-wild-do-table=my\\_own\\%db.

  • --replicate-wild-ignore-table=db_name.tbl_name

    Property Value
    Command-Line Format --replicate-wild-ignore-table=name
    Type String

    Creates a replication filter which keeps the slave thread from replicating a statement in which 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 17.2.5, “How Servers Evaluate Replication Filtering Rules”. You can also create such a filter by issuing a CHANGE REPLICATION FILTER REPLICATE_WILD_IGNORE_TABLE statement.

    This option supports channel specific replication filters, enabling multi-source replication slaves to use specific filters for different sources. To configure a channel specific replication filter on a channel named channel_1 use --replicate-wild-ignore:channel_1:db_name.tbl_name. In this case, the first colon is interpreted as a separator and subsequent colons are literal colons. See Section 17.2.5.4, “Replication Channel Based Filters” for more information.

    Note

    Global replication filters cannot be used on a MySQL server instance that is configured for Group Replication, because filtering transactions on some servers would make the group unable to reach agreement on a consistent state. Channel specific replication filters can be used on replication channels that are not directly involved with Group Replication, such as where a group member also acts as a replication slave to a master that is outside the group. They cannot be used on the group_replication_applier or group_replication_recovery channels.

    As an example, --replicate-wild-ignore-table=foo%.bar% does not replicate updates that use a table where the database name starts with foo and the table name starts with bar. For information about how matching works, see the description of the --replicate-wild-do-table option. The rules for including literal wildcard characters in the option value are the same as for --replicate-wild-ignore-table as well.

  • --report-host=host_name

    Property Value
    Command-Line Format --report-host=host_name
    System Variable report_host
    Scope Global
    Dynamic No
    SET_VAR Hint Applies No
    Type String

    The host name or IP address of the slave to be reported to the master during slave registration. This value appears in the output of SHOW SLAVE HOSTS on the master server. Leave the value unset if you do not want the slave to register itself with the master.

    Note

    It is not sufficient for the master to simply read the IP address 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.

  • --report-password=password

    Property Value
    Command-Line Format --report-password=name
    System Variable report_password
    Scope Global
    Dynamic No
    SET_VAR Hint Applies No
    Type String

    The account password of the slave to be reported to the master during slave registration. This value appears in the output of SHOW SLAVE HOSTS on the master server if the master was started with --show-slave-auth-info.

    Although the name of this option might imply otherwise, --report-password is not connected to the MySQL user privilege system and so is not necessarily (or even likely to be) the same as the password for the MySQL replication user account.

  • --report-port=slave_port_num

    Property Value
    Command-Line Format --report-port=#
    System Variable report_port
    Scope Global
    Dynamic No
    SET_VAR Hint Applies No
    Type Integer
    Default Value [slave_port]
    Minimum Value 0
    Maximum Value 65535

    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 nondefault 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.

    The default value for this option is the port number actually used by the slave (Bug #13333431). This is also the default value displayed by SHOW SLAVE HOSTS.

  • --report-user=user_name

    Property Value
    Command-Line Format --report-user=name
    System Variable report_user
    Scope Global
    Dynamic No
    SET_VAR Hint Applies No
    Type String

    The account user name of the slave to be reported to the master during slave registration. This value appears in the output of SHOW SLAVE HOSTS on the master server if the master was started with --show-slave-auth-info.

    Although the name of this option might imply otherwise, --report-user is not connected to the MySQL user privilege system and so is not necessarily (or even likely to be) the same as the name of the MySQL replication user account.

  • --slave-checkpoint-group=#

    Property Value
    Command-Line Format --slave-checkpoint-group=#
    Type Integer
    Default Value 512
    Minimum Value 32
    Maximum Value 524280
    Block Size 8

    Sets the maximum number of transactions that can be processed by a multithreaded slave before a checkpoint operation is called to update its status as shown by SHOW SLAVE STATUS. Setting this option has no effect on slaves for which multithreading is not enabled.

    Note

    Multithreaded slaves are not currently supported by NDB Cluster, which silently ignores the setting for this option. See Section 22.6.3, “Known Issues in NDB Cluster Replication”, for more information.

    This option works in combination with the --slave-checkpoint-period option in such a way that, when either limit is exceeded, the checkpoint is executed and the counters tracking both the number of transactions and the time elapsed since the last checkpoint are reset.

    The minimum allowed value for this option is 32, unless the server was built using -DWITH_DEBUG, in which case the minimum value is 1. The effective value is always a multiple of 8; you can set it to a value that is not such a multiple, but the server rounds it down to the next lower multiple of 8 before storing the value. (Exception: No such rounding is performed by the debug server.) Regardless of how the server was built, the default value is 512, and the maximum allowed value is 524280.

  • --slave-checkpoint-period=#

    Property Value
    Command-Line Format --slave-checkpoint-period=#
    Type Integer
    Default Value 300
    Minimum Value 1
    Maximum Value 4G

    Sets the maximum time (in milliseconds) that is allowed to pass before a checkpoint operation is called to update the status of a multithreaded slave as shown by SHOW SLAVE STATUS. Setting this option has no effect on slaves for which multithreading is not enabled.

    Note

    Multithreaded slaves are not currently supported by NDB Cluster, which silently ignores the setting for this option. See Section 22.6.3, “Known Issues in NDB Cluster Replication”, for more information.

    This option works in combination with the --slave-checkpoint-group option in such a way that, when either limit is exceeded, the checkpoint is executed and the counters tracking both the number of transactions and the time elapsed since the last checkpoint are reset.

    The minimum allowed value for this option is 1, unless the server was built using -DWITH_DEBUG, in which case the minimum value is 0. Regardless of how the server was built, the default value is 300, and the maximum possible value is 4294967296 (4GB).

  • --slave-parallel-workers

    Property Value
    Command-Line Format --slave-parallel-workers=#
    Type Integer
    Default Value 0
    Minimum Value 0
    Maximum Value 1024

    Enables multithreading on the slave and sets the number of slave applier threads for executing replication transactions in parallel. When the value is a number greater than 0, the slave is a multithreaded slave with the specified number of applier threads, plus a coordinator thread to manage them. If you are using multiple replication channels, each channel has this number of threads.

    Retrying of transactions is supported when multithreading is enabled on a slave. When slave_preserve_commit_order=1, transactions on a slave are externalized on the slave in the same order as they appear in the slave's relay log. The way in which transactions are distributed among applier threads is configured by --slave-parallel-type.

    To disable parallel execution, set this option to 0, which gives the slave a single applier thread and no coordinator thread. With this setting, the --slave-parallel-type and slave_preserve_commit_order options have no effect and are ignored.

    Note

    Multithreaded slaves are not currently supported by NDB Cluster, which silently ignores the setting for this option. See Section 22.6.3, “Known Issues in NDB Cluster Replication”, for more information.

  • --slave-pending-jobs-size-max=#

    Property Value
    Command-Line Format --slave-pending-jobs-size-max=#
    Type Integer
    Default Value (>= 8.0.12) 128M
    Default Value (<= 8.0.11) 16M
    Minimum Value 1024
    Maximum Value 16EiB
    Block Size 1024

    For multithreaded slaves, this option sets the maximum amount of memory (in bytes) available to slave worker queues holding events not yet applied. Setting this option has no effect on slaves for which multithreading is not enabled.

    The minimum possible value for this option is 1024 bytes; the default is 128MB. The maximum possible value is 18446744073709551615 (16 exbibytes). Values that are not exact multiples of 1024 bytes are rounded down to the next lower multiple of 1024 bytes prior to being stored.

    The value of this variable is a soft limit and can be set to match the normal workload. If an unusually large event exceeds this size, the transaction is held until all the slave workers have empty queues, and then processed. All subsequent transactions are held until the large transaction has been completed.

  • --skip-slave-start

    Property Value
    Command-Line Format --skip-slave-start
    Type Boolean
    Default Value FALSE

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

  • --slave_compressed_protocol={0|1}

    Property Value
    Command-Line Format --slave-compressed-protocol
    System Variable slave_compressed_protocol
    Scope Global
    Dynamic Yes
    SET_VAR Hint Applies No
    Type Boolean
    Default Value OFF

    If this option is set to 1, use compression for the slave/master protocol if both the slave and the master support it. The default is 0 (no compression).

  • --slave-load-tmpdir=dir_name

    Property Value
    Command-Line Format --slave-load-tmpdir=dir_name
    System Variable slave_load_tmpdir
    Scope Global
    Dynamic No
    SET_VAR Hint Applies No
    Type Directory name
    Default Value /tmp

    The name of the directory where the slave creates temporary files. This option is by default equal to the value of the tmpdir system variable. When the slave SQL thread replicates a LOAD DATA INFILE 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 file system 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 --relay-log option to place the relay logs in that file system.

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

  • slave-max-allowed-packet=bytes

    Property Value
    Command-Line Format --slave-max-allowed-packet=#
    Type Integer
    Default Value 1073741824
    Minimum Value 1024
    Maximum Value 1073741824

    This option sets the maximum packet size in bytes that the slave SQL and I/O threads can handle. It is possible for a replication master to write binary log events longer than its max_allowed_packet setting once the event header is added. The setting for slave_max_allowed_packet must be larger than the max_allowed_packet setting on the master, so that large updates using row-based replication do not cause replication to fail.

    The corresponding server variable slave_max_allowed_packet always has a value that is a positive integer multiple of 1024; if you set it to some value that is not such a multiple, the value is automatically rounded down to the next highest multiple of 1024. (For example, if you start the server with --slave-max-allowed-packet=10000, the value used is 9216; setting 0 as the value causes 1024 to be used.) A truncation warning is issued in such cases.

    The maximum (and default) value is 1073741824 (1 GB); the minimum is 1024.

  • --slave-net-timeout=seconds

    Property Value
    Command-Line Format --slave-net-timeout=#
    System Variable slave_net_timeout
    Scope Global
    Dynamic Yes
    SET_VAR Hint Applies No
    Type Integer
    Default Value 60
    Minimum Value 1

    The number of seconds to wait for more data or a heartbeat signal from the master before the slave considers the connection broken, aborts the read, and tries to reconnect. The default value is 60 seconds (one minute). The first retry occurs immediately after the timeout. The interval between retries is controlled by the MASTER_CONNECT_RETRY option for the CHANGE MASTER TO statement, and the number of reconnection attempts is limited by the MASTER_RETRY_COUNT option for the CHANGE MASTER TO statement.

    The heartbeat interval, which stops the connection timeout occurring in the absence of data if the connection is still good, is controlled by the MASTER_HEARTBEAT_PERIOD option for the CHANGE MASTER TO statement. The heartbeat interval defaults to half the value of --slave-net-timeout, and it is recorded in the master info log and shown in the replication_connection_configuration Performance Schema table. Note that a change to the value or default setting of --slave-net-timeout does not automatically change the heartbeat interval, whether that has been set explicitly or is using a previously calculated default. If the connection timeout is changed, you must also issue CHANGE MASTER TO to adjust the heartbeat interval to an appropriate value so that it occurs before the connection timeout.

  • --slave-parallel-type=type

    Property Value
    Command-Line Format --slave-parallel-type=type
    Type Enumeration
    Default Value DATABASE
    Valid Values

    DATABASE

    LOGICAL_CLOCK

    When using a multithreaded slave (slave_parallel_workers is greater than 0), this option specifies the policy used to decide which transactions are allowed to execute in parallel on the slave. The option has no effect on slaves for which multithreading is not enabled. The possible values are:

    • LOGICAL_CLOCK: Transactions that are part of the same binary log group commit on a master are applied in parallel on a slave. The dependencies between transactions are tracked based on their timestamps to provide additional parallelization where possible. When this value is set, the binlog_transaction_dependency_tracking system variable can be used on the master to specify that write sets are used for parallelization in place of timestamps, if a write set is available for the transaction and gives improved results compared to timestamps.

    • DATABASE: Transactions that update different databases are applied in parallel. This value is only appropriate if data is partitioned into multiple databases which are being updated independently and concurrently on the master. There must be no cross-database constraints, as such constraints may be violated on the slave.

    When slave_preserve_commit_order=1 is set, you can only use LOGICAL_CLOCK.

    If your replication topology uses multiple levels of slaves, LOGICAL_CLOCK may achieve less parallelization for each level the slave is away from the master. You can reduce this effect by using binlog_transaction_dependency_tracking on the master to specify that write sets are used instead of timestamps for parallelization where possible.

  • slave-rows-search-algorithms=list

    Property Value
    Command-Line Format --slave-rows-search-algorithms=list
    Type Set
    Default Value (>= 8.0.2) INDEX_SCAN,HASH_SCAN
    Default Value (<= 8.0.1) TABLE_SCAN,INDEX_SCAN
    Valid Values

    TABLE_SCAN,INDEX_SCAN

    INDEX_SCAN,HASH_SCAN

    TABLE_SCAN,HASH_SCAN

    TABLE_SCAN,INDEX_SCAN,HASH_SCAN (equivalent to INDEX_SCAN,HASH_SCAN)

    When preparing batches of rows for row-based logging and replication, this option controls how the rows are searched for matches—that is, whether or not hashing is used for searches using a primary or unique key, some other key, or no key at all. The option sets the initial value for the slave_rows_search_algorithms system variable.

    Specify a comma-separated list of any 2 (or all 3) values from the list INDEX_SCAN, TABLE_SCAN, HASH_SCAN. The list need not be quoted, but must contain no spaces, whether or not quotes are used. Possible combinations (lists) and their effects are shown in the following table:

    Index used / option value INDEX_SCAN,HASH_SCAN or INDEX_SCAN,TABLE_SCAN,HASH_SCAN INDEX_SCAN,TABLE_SCAN TABLE_SCAN,HASH_SCAN
    Primary key or unique key Index scan Index scan Hash scan over index
    (Other) Key Hash scan over index Index scan Hash scan over index
    No index Hash scan Table scan Hash scan

    The order in which the algorithms are specified in the list does not make any difference in the order in which they are displayed by a SELECT or SHOW VARIABLES statement (which is the same as that used in the table just shown previously).

    • The default value is INDEX_SCAN,HASH_SCAN. With this setting, hashing is used for any searches that do not use a primary or unique key. Specifying INDEX_SCAN,TABLE_SCAN,HASH_SCAN has the same effect as specifying INDEX_SCAN,HASH_SCAN.

    • To force hashing for all searches, set this option to TABLE_SCAN,HASH_SCAN.

    • To remove hashing, set this option to TABLE_SCAN,INDEX_SCAN. With this setting, all searches that can use indexes do use them, and searches without any indexes use table scans.

    It is possible to specify single values for this option, but this is not optimal, because setting a single value limits searches to using only that algorithm. In particular, setting INDEX_SCAN alone is not recommended, as in that case searches are unable to find rows at all if no index is present.

    Note

    There is only a performance advantage for INDEX_SCAN and HASH_SCAN if the row events are big enough. The size of row events is configured using the binlog_row_event_max_size system variable. For example, suppose a DELETE statement which deletes 25,000 rows generates large Delete_row_event events. In this case if slave_rows_search_algorithms is set to INDEX_SCAN or HASH_SCAN there is a performance improvement. However, if there are 25,000 DELETE statements and each is represented by a separate event then setting slave_rows_search_algorithms to INDEX_SCAN or HASH_SCAN provides no performance improvement while executing these separate events.

  • --slave-skip-errors=[err_code1,err_code2,...|all|ddl_exist_errors]

    Property Value
    Command-Line Format --slave-skip-errors=name
    System Variable slave_skip_errors
    Scope Global
    Dynamic No
    SET_VAR Hint Applies No
    Type String
    Default Value OFF
    Valid Values

    OFF

    [list of error codes]

    all

    ddl_exist_errors

    Normally, replication stops when an error occurs on the slave, which gives you the opportunity to resolve the inconsistency in the data manually. This option causes 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 SHOW SLAVE STATUS. Appendix B, Errors, Error Codes, and Common Problems, lists server error codes.

    The shorthand value ddl_exist_errors is equivalent to the error code list 1007,1008,1050,1051,1054,1060,1061,1068,1094,1146.

    You can also (but should not) use the very nonrecommended value of all to cause the slave to ignore all error messages and keeps going regardless of what happens. Needless to say, if you use all, 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
    --slave-skip-errors=ddl_exist_errors
  • --slave-sql-verify-checksum={0|1}

    Property Value
    Command-Line Format --slave-sql-verify-checksum=value
    Type Boolean
    Default Value 1
    Valid Values

    0

    1

    When this option is enabled, the slave examines checksums read from the relay log, in the event of a mismatch, the slave stops with an error.

The following options are used internally by the MySQL test suite for replication testing and debugging. They are not intended for use in a production setting.

  • --abort-slave-event-count

    Property Value
    Command-Line Format --abort-slave-event-count=#
    Type Integer
    Default Value 0
    Minimum Value 0

    When this option is set to some positive integer value other than 0 (the default) it affects replication behavior as follows: After the slave SQL thread has started, value log events are permitted to be executed; after that, the slave SQL thread does not receive any more events, just as if the network connection from the master were cut. The slave thread continues to run, and the output from SHOW SLAVE STATUS displays Yes in both the Slave_IO_Running and the Slave_SQL_Running columns, but no further events are read from the relay log.

  • --disconnect-slave-event-count

    Property Value
    Command-Line Format --disconnect-slave-event-count=#
    Type Integer
    Default Value 0
Options for Logging Slave Status to Tables

Replication slave status information is logged to an InnoDB table in the mysql database. Before MySQL 8.0, this information could alternatively be logged to a file in the data directory, but the use of that format is now deprecated. Writing of the master info log and the relay log info log can be configured separately using the two server options listed here:

  • --master-info-repository={TABLE|FILE}

    Property Value
    Command-Line Format --master-info-repository=FILE|TABLE
    Type String
    Default Value (>= 8.0.2) TABLE
    Default Value (<= 8.0.1) FILE
    Valid Values

    FILE

    TABLE

    This option determines whether the slave server logs master status and connection information to an InnoDB table in the mysql database, or to a file in the data directory.

    The default setting is TABLE. As an InnoDB table, the master info log is named mysql.slave_master_info. The TABLE setting is required when multiple replication channels are configured.

    The FILE setting is deprecated, and will be removed in a future release. As a file, the master info log is named master.info by default, and you can change this name using the --master-info-file option.

    The setting for the location of this slave status log has a direct influence on the effect had by the setting of the sync_master_info system variable. You can only change the setting when no replication threads are executing.

  • --relay-log-info-repository={TABLE|FILE}

    Property Value
    Command-Line Format --relay-log-info-repository=FILE|TABLE
    Type String
    Default Value (>= 8.0.2) TABLE
    Default Value (<= 8.0.1) FILE
    Valid Values

    FILE

    TABLE

    This option determines whether the slave server logs its position in the relay logs to an InnoDB table in the mysql database, or to a file in the data directory.

    The default setting is TABLE. As an InnoDB table, the relay log info log is named mysql.slave_relay_log_info. The TABLE setting is required when multiple replication channels are configured. The TABLE setting for the relay log info log is also required to make replication resilient to unexpected halts, for which the --relay-log-recovery option must also be enabled. See Making replication resilient to unexpected halts for more information.

    The FILE setting is deprecated, and will be removed in a future release. As a file, the relay log info log is named relay-log.info by default, and you can change this name using the --relay-log-info-file option.

    The setting for the location of this slave status log has a direct influence on the effect had by the setting of the sync_relay_log_info system variable. You can only change the setting when no replication threads are executing.

The slave status log tables and their contents are considered local to a given MySQL Server. They are not replicated, and changes to them are not written to the binary log.

For more information, see Section 17.2.4, “Replication Relay and Status Logs”.

System Variables Used on Replication Slaves

The following list describes system variables for controlling replication slave servers. They can be set at server startup and some of them can be changed at runtime using SET. Server options used with replication slaves are listed earlier in this section.

  • init_slave

    Property Value
    Command-Line Format --init-slave=name
    System Variable init_slave
    Scope Global
    Dynamic Yes
    SET_VAR Hint Applies No
    Type String

    This variable is similar to init_connect, but is a string to be executed by a slave server each time the SQL thread starts. The format of the string is the same as for the init_connect variable. The setting of this variable takes effect for subsequent START SLAVE statements.

    Note

    The SQL thread sends an acknowledgment to the client before it executes init_slave. Therefore, it is not guaranteed that init_slave has been executed when START SLAVE returns. See Section 13.4.2.6, “START SLAVE Syntax”, for more information.

  • log_slow_slave_statements

    Property Value
    System Variable log_slow_slave_statements
    Scope Global
    Dynamic Yes
    SET_VAR Hint Applies No
    Type Boolean
    Default Value OFF

    When the slow query log is enabled, this variable enables logging for queries that have taken more than long_query_time seconds to execute on the slave. Setting this variable has no immediate effect. The state of the variable applies on all subsequent START SLAVE statements.

    Note that all statements logged in row format in the master will not be logged in the slave's slow log, even if log_slow_slave_statements is enabled.

  • master_info_repository

    Property Value
    Command-Line Format --master-info-repository=FILE|TABLE
    System Variable master_info_repository
    Scope Global
    Dynamic Yes
    SET_VAR Hint Applies No
    Type String
    Default Value (>= 8.0.2) TABLE
    Default Value (<= 8.0.1) FILE
    Valid Values

    FILE

    TABLE

    The setting of this variable determines whether the slave server logs master status and connection information to an InnoDB table in the mysql database, or to a file in the data directory.

    The default setting is TABLE. As an InnoDB table, the master info log is named mysql.slave_master_info. The TABLE setting is required when multiple replication channels are configured.

    The FILE setting is deprecated, and will be removed in a future release. As a file, the master info log is named master.info by default, and you can change this name using the --master-info-file option.

    The setting for the location of this slave status log has a direct influence on the effect had by the setting of the sync_master_info system variable. You can only change the setting when no replication threads are executing.

  • max_relay_log_size

    Property Value
    Command-Line Format --max-relay-log-size=#
    System Variable max_relay_log_size
    Scope Global
    Dynamic Yes
    SET_VAR Hint Applies No
    Type Integer
    Default Value 0
    Minimum Value 0
    Maximum Value 1073741824

    If a write by a replication slave to its relay log causes the current log file size to exceed the value of this variable, the slave rotates the relay logs (closes the current file and opens the next one). If max_relay_log_size is 0, the server uses max_binlog_size for both the binary log and the relay log. If max_relay_log_size is greater than 0, it constrains the size of the relay log, which enables you to have different sizes for the two logs. You must set max_relay_log_size to between 4096 bytes and 1GB (inclusive), or to 0. The default value is 0. See Section 17.2.2, “Replication Implementation Details”.

  • relay_log

    Property Value
    Command-Line Format --relay-log=file_name
    System Variable relay_log
    Scope Global
    Dynamic No
    SET_VAR Hint Applies No
    Type File name

    The base name for relay log files, with no paths and no file extension. For the default replication channel, the default base name for relay logs is host_name-relay-bin. For non-default replication channels, the default base name for relay logs is host_name-relay-bin-channel, where channel is the name of the replication channel recorded in this relay log.

  • relay_log_basename

    Property Value
    System Variable relay_log_basename
    Scope Global
    Dynamic No
    SET_VAR Hint Applies No
    Type File name
    Default Value datadir + '/' + hostname + '-relay-bin'

    Holds the name and complete path to the relay log file.

  • relay_log_index

    Property Value
    Command-Line Format --relay-log-index
    System Variable relay_log_index
    Scope Global
    Dynamic No
    SET_VAR Hint Applies No
    Type File name
    Default Value *host_name*-relay-bin.index

    The name of the relay log index file for the default replication channel. The default name is host_name-relay-bin.index.

  • relay_log_info_file

    Property Value
    Command-Line Format --relay-log-info-file=file_name
    System Variable relay_log_info_file
    Scope Global
    Dynamic No
    SET_VAR Hint Applies No
    Type File name
    Default Value relay-log.info

    The name of the relay log info log, when relay_log_info_repository=FILE is set. The default name is relay-log.info in the data directory. relay_log_info_repository=FILE is now deprecated.

  • relay_log_info_repository

    Property Value
    System Variable relay_log_info_repository
    Scope Global
    Dynamic Yes
    SET_VAR Hint Applies No
    Type String
    Default Value (>= 8.0.2) TABLE
    Default Value (<= 8.0.1) FILE
    Valid Values

    FILE

    TABLE

    The setting of this variable determines whether the slave server logs its position in the relay logs to an InnoDB table in the mysql database, or to a file in the data directory.

    The default setting is TABLE. As an InnoDB table, the relay log info log is named mysql.slave_relay_log_info. The TABLE setting is required when multiple replication channels are configured. The TABLE setting for the relay log info log is also required to make replication resilient to unexpected halts, for which the --relay-log-recovery option must also be enabled. See Making replication resilient to unexpected halts for more information.

    The FILE setting is deprecated, and will be removed in a future release. As a file, the relay log info log is named relay-log.info by default, and you can change this name using the --relay-log-info-file option.

    The setting for the location of this slave status log has a direct influence on the effect had by the setting of the sync_relay_log_info system variable. You can only change the setting when no replication threads are executing.

  • relay_log_purge

    Property Value
    Command-Line Format --relay-log-purge
    System Variable relay_log_purge
    Scope Global
    Dynamic Yes
    SET_VAR Hint Applies No
    Type Boolean
    Default Value TRUE

    Disables or enables automatic purging of relay log files as soon as they are not needed any more. The default value is 1 (ON).

  • relay_log_recovery

    Property Value
    Command-Line Format --relay-log-recovery
    System Variable relay_log_recovery
    Scope Global
    Dynamic No
    SET_VAR Hint Applies No
    Type Boolean
    Default Value FALSE

    Enables automatic relay log recovery immediately following server startup. The recovery process creates a new relay log file, initializes the SQL thread position to this new relay log, and initializes the I/O thread to the SQL thread position. Reading of the relay log from the master then continues. This global variable is read-only; its value can be changed by starting the slave with the --relay-log-recovery option, which should be used following a crash on the replication slave to ensure that no possibly corrupted relay logs are processed, and must be used in order to guarantee a crash-safe slave. The default value is 0 (disabled).

    This variable also interacts with relay-log-purge, which controls purging of logs when they are no longer needed. Enabling the --relay-log-recovery option when relay-log-purge is disabled risks reading the relay log from files that were not purged, leading to data inconsistency, and is therefore not crash-safe.

    When relay_log_recovery is enabled and the slave has stopped due to errors encountered while running in multithreaded mode, you can use START SLAVE UNTIL SQL_AFTER_MTS_GAPS to ensure that all gaps are processed before switching back to single-threaded mode or executing a CHANGE MASTER TO statement.

  • relay_log_space_limit

    Property Value
    Command-Line Format --relay-log-space-limit=#
    System Variable relay_log_space_limit
    Scope Global
    Dynamic No
    SET_VAR Hint Applies No
    Type Integer
    Default Value 0
    Minimum Value 0
    Maximum Value (64-bit platforms) 18446744073709551615
    Maximum Value (32-bit platforms) 4294967295

    The maximum amount of space to use for all relay logs.

  • report_host

    Property Value
    Command-Line Format --report-host=host_name
    System Variable report_host
    Scope Global
    Dynamic No
    SET_VAR Hint Applies No
    Type String

    The value of the --report-host option.

  • report_password

    Property Value
    Command-Line Format --report-password=name
    System Variable report_password
    Scope Global
    Dynamic No
    SET_VAR Hint Applies No
    Type String

    The value of the --report-password option. Not the same as the password used for the MySQL replication user account.

  • report_port

    Property Value
    Command-Line Format --report-port=#
    System Variable report_port
    Scope Global
    Dynamic No
    SET_VAR Hint Applies No
    Type Integer
    Default Value [slave_port]
    Minimum Value 0
    Maximum Value 65535

    The value of the --report-port option.

  • report_user

    Property Value
    Command-Line Format --report-user=name
    System Variable report_user
    Scope Global
    Dynamic No
    SET_VAR Hint Applies No
    Type String

    The value of the --report-user option. Not the same as the name for the MySQL replication user account.

  • rpl_read_size

    Property Value
    Command-Line Format --rpl-read-size=#
    Introduced 8.0.11
    System Variable rpl_read_size
    Scope Global
    Dynamic Yes
    SET_VAR Hint Applies No
    Type Integer
    Default Value 8192
    Minimum Value 8192
    Maximum Value 4294967295

    The rpl_read_size system variable controls the minimum amount of data in bytes that is read from the binary log files and relay log files. If heavy disk I/O activity for these files is impeding performance for the database, increasing the read size might reduce file reads and I/O stalls when the file data is not currently cached by the operating system.

    The minimum and default value for rpl_read_size is 8192 bytes. The value must be a multiple of 4KB. Note that a buffer the size of this value is allocated for each thread that reads from the binary log and relay log files, including dump threads on masters and coordinator threads on slaves. Setting a large value might therefore have an impact on memory consumption for servers.

  • rpl_semi_sync_slave_enabled

    Property Value
    System Variable rpl_semi_sync_slave_enabled
    Scope Global
    Dynamic Yes
    SET_VAR Hint Applies No
    Type Boolean
    Default Value OFF

    Controls whether semisynchronous replication is enabled on the slave. To enable or disable the plugin, set this variable to ON or OFF (or 1 or 0), respectively. The default is OFF.

    This variable is available only if the slave-side semisynchronous replication plugin is installed.

  • rpl_semi_sync_slave_trace_level

    Property Value
    System Variable rpl_semi_sync_slave_trace_level
    Scope Global
    Dynamic Yes
    SET_VAR Hint Applies No
    Type Integer
    Default Value 32

    The semisynchronous replication debug trace level on the slave. See rpl_semi_sync_master_trace_level for the permissible values.

    This variable is available only if the slave-side semisynchronous replication plugin is installed.

  • rpl_stop_slave_timeout

    Property Value
    Command-Line Format --rpl-stop-slave-timeout=seconds
    System Variable rpl_stop_slave_timeout
    Scope Global
    Dynamic Yes
    SET_VAR Hint Applies No
    Type Integer
    Default Value 31536000
    Minimum Value 2
    Maximum Value 31536000

    You can control the length of time (in seconds) that STOP SLAVE waits before timing out by setting this variable. This can be used to avoid deadlocks between STOP SLAVE and other slave SQL statements using different client connections to the slave.

    The maximum and default value of rpl_stop_slave_timeout is 31536000 seconds (1 year). The minimum is 2 seconds. Changes to this variable take effect for subsequent STOP SLAVE statements.

    This variable affects only the client that issues a STOP SLAVE statement. When the timeout is reached, the issuing client returns an error message stating that the command execution is incomplete. The client then stops waiting for the slave threads to stop, but the slave threads continue to try to stop, and the STOP SLAVE instruction remains in effect. Once the slave threads are no longer busy, the STOP SLAVE statement is executed and the slave stops.

  • slave_checkpoint_group

    Property Value
    Command-Line Format --slave-checkpoint-group=#
    System Variable slave_checkpoint_group=#
    Scope Global
    Dynamic Yes
    SET_VAR Hint Applies No
    Type Integer
    Default Value 512
    Minimum Value 32
    Maximum Value 524280
    Block Size 8

    Sets the maximum number of transactions that can be processed by a multithreaded slave before a checkpoint operation is called to update its status as shown by SHOW SLAVE STATUS. Setting this variable has no effect on slaves for which multithreading is not enabled. Setting this variable has no immediate effect. The state of the variable applies on all subsequent START SLAVE commands.

    Note

    Multithreaded slaves are not currently supported by NDB Cluster, which silently ignores the setting for this variable. See Section 22.6.3, “Known Issues in NDB Cluster Replication”, for more information.

    This variable works in combination with the slave_checkpoint_period system variable in such a way that, when either limit is exceeded, the checkpoint is executed and the counters tracking both the number of transactions and the time elapsed since the last checkpoint are reset.

    The minimum allowed value for this variable is 32, unless the server was built using -DWITH_DEBUG, in which case the minimum value is 1. The effective value is always a multiple of 8; you can set it to a value that is not such a multiple, but the server rounds it down to the next lower multiple of 8 before storing the value. (Exception: No such rounding is performed by the debug server.) Regardless of how the server was built, the default value is 512, and the maximum allowed value is 524280.

  • slave_checkpoint_period

    Property Value
    Command-Line Format --slave-checkpoint-period=#
    System Variable slave_checkpoint_period=#
    Scope Global
    Dynamic Yes
    SET_VAR Hint Applies No
    Type Integer
    Default Value 300
    Minimum Value 1
    Maximum Value 4G

    Sets the maximum time (in milliseconds) that is allowed to pass before a checkpoint operation is called to update the status of a multithreaded slave as shown by SHOW SLAVE STATUS. Setting this variable has no effect on slaves for which multithreading is not enabled. Setting this variable takes effect for all replication channels immediately, including running channels.

    Note

    Multithreaded slaves are not currently supported by NDB Cluster, which silently ignores the setting for this variable. See Section 22.6.3, “Known Issues in NDB Cluster Replication”, for more information.

    This variable works in combination with the slave_checkpoint_group system variable in such a way that, when either limit is exceeded, the checkpoint is executed and the counters tracking both the number of transactions and the time elapsed since the last checkpoint are reset.

    The minimum allowed value for this variable is 1, unless the server was built using -DWITH_DEBUG, in which case the minimum value is 0. Regardless of how the server was built, the default value is 300, and the maximum possible value is 4294967296 (4GB).

  • slave_compressed_protocol

    Property Value
    Command-Line Format --slave-compressed-protocol
    System Variable slave_compressed_protocol
    Scope Global
    Dynamic Yes
    SET_VAR Hint Applies No
    Type Boolean
    Default Value OFF

    Whether to use compression of the slave/master protocol if both the slave and the master support it. Changes to this variable take effect on subsequent connection attempts; this includes after issuing a START SLAVE statement, as well as reconnections made by a running I/O thread (for example after issuing a CHANGE MASTER TO MASTER_RETRY_COUNT statement).

  • slave_exec_mode

    Property Value
    Command-Line Format --slave-exec-mode=mode
    System Variable slave_exec_mode
    Scope Global
    Dynamic Yes
    SET_VAR Hint Applies No
    Type Enumeration
    Default Value

    IDEMPOTENT (NDB)

    STRICT (Other)

    Valid Values

    IDEMPOTENT

    STRICT

    Controls how a slave thread resolves conflicts and errors during replication. IDEMPOTENT mode causes suppression of duplicate-key and no-key-found errors; STRICT means no such suppression takes place.

    IDEMPOTENT mode is intended for use in multi-master replication, circular replication, and some other special replication scenarios for NDB Cluster Replication. (See Section 22.6.10, “NDB Cluster Replication: Multi-Master and Circular Replication”, and Section 22.6.11, “NDB Cluster Replication Conflict Resolution”, for more information.) NDB Cluster ignores any value explicitly set for slave_exec_mode, and always treats it as IDEMPOTENT.

    In MySQL Server 8.0, STRICT mode is the default value.

    Setting this variable takes immediate effect for all replication channels, including running channels.

    For storage engines other than NDB, IDEMPOTENT mode should be used only when you are absolutely sure that duplicate-key errors and key-not-found errors can safely be ignored. It is meant to be used in fail-over scenarios for NDB Cluster where multi-master replication or circular replication is employed, and is not recommended for use in other cases.

  • slave_load_tmpdir

    Property Value
    Command-Line Format --slave-load-tmpdir=dir_name
    System Variable slave_load_tmpdir
    Scope Global
    Dynamic No
    SET_VAR Hint Applies No
    Type Directory name
    Default Value /tmp

    The name of the directory where the slave creates temporary files for replicating LOAD DATA INFILE statements. Setting this variable takes effect for all replication channels immediately, including running channels.

  • slave_max_allowed_packet

    Property Value
    System Variable slave_max_allowed_packet
    Scope Global
    Dynamic Yes
    SET_VAR Hint Applies No
    Type Integer
    Default Value 1073741824
    Minimum Value 1024
    Maximum Value 1073741824

    This option sets the maximum packet size in bytes that the slave SQL and I/O threads can handle. Setting this variable takes effect for all replication channels immediately, including running channels. It is possible for a replication master to write binary log events longer than its max_allowed_packet setting once the event header is added. The setting for slave_max_allowed_packet must be larger than the max_allowed_packet setting on the master, so that large updates using row-based replication do not cause replication to fail.

    This global variable always has a value that is a positive integer multiple of 1024; if you set it to some value that is not, the value is rounded down to the next highest multiple of 1024 for it is stored or used; setting slave_max_allowed_packet to 0 causes 1024 to be used. (A truncation warning is issued in all such cases.) The default and maximum value is 1073741824 (1 GB); the minimum is 1024.

    slave_max_allowed_packet can also be set at startup, using the --slave-max-allowed-packet option.

  • slave_net_timeout

    Property Value
    Command-Line Format --slave-net-timeout=#
    System Variable slave_net_timeout
    Scope Global
    Dynamic Yes
    SET_VAR Hint Applies No
    Type Integer
    Default Value 60
    Minimum Value 1

    The number of seconds to wait for more data or a heartbeat signal from the master before the slave considers the connection broken, aborts the read, and tries to reconnect. Setting this variable has no immediate effect. The state of the variable applies on all subsequent START SLAVE commands.

    The default value is 60 seconds (one minute). The first retry occurs immediately after the timeout. The interval between retries is controlled by the MASTER_CONNECT_RETRY option for the CHANGE MASTER TO statement, and the number of reconnection attempts is limited by the MASTER_RETRY_COUNT option for the CHANGE MASTER TO statement.

    The heartbeat interval, which stops the connection timeout occurring in the absence of data if the connection is still good, is controlled by the MASTER_HEARTBEAT_PERIOD option for the CHANGE MASTER TO statement. The heartbeat interval defaults to half the value of slave_net_timeout, and it is recorded in the master info log and shown in the replication_connection_configuration Performance Schema table. Note that a change to the value or default setting of slave_net_timeout does not automatically change the heartbeat interval, whether that has been set explicitly or is using a previously calculated default. If the connection timeout is changed, you must also issue CHANGE MASTER TO to adjust the heartbeat interval to an appropriate value so that it occurs before the connection timeout.

  • slave_parallel_type=type

    Property Value
    Command-Line Format --slave-parallel-type=type
    Type Enumeration
    Default Value DATABASE
    Valid Values

    DATABASE

    LOGICAL_CLOCK

    When using a multithreaded slave (slave_parallel_workers is greater than 0), this variable specifies the policy used to decide which transactions are allowed to execute in parallel on the slave. The variable has no effect on slaves for which multithreading is not enabled. The possible values are:

    • LOGICAL_CLOCK: Transactions that are part of the same binary log group commit on a master are applied in parallel on a slave. The dependencies between transactions are tracked based on their timestamps to provide additional parallelization where possible. When this value is set, the binlog_transaction_dependency_tracking system variable can be used on the master to specify that write sets are used for parallelization in place of timestamps, if a write set is available for the transaction and gives improved results compared to timestamps.

    • DATABASE: Transactions that update different databases are applied in parallel. This value is only appropriate if data is partitioned into multiple databases which are being updated independently and concurrently on the master. There must be no cross-database constraints, as such constraints may be violated on the slave.

    When slave_preserve_commit_order=1 is set, you can only use LOGICAL_CLOCK.

    If your replication topology uses multiple levels of slaves, LOGICAL_CLOCK may achieve less parallelization for each level the slave is away from the master. You can reduce this effect by using binlog_transaction_dependency_tracking on the master to specify that write sets are used instead of timestamps for parallelization where possible.

  • slave_parallel_workers

    Property Value
    Command-Line Format --slave-parallel-workers=#
    System Variable slave_parallel_workers
    Scope Global
    Dynamic Yes
    SET_VAR Hint Applies No
    Type Integer
    Default Value 0
    Minimum Value 0
    Maximum Value 1024

    Enables multithreading on the slave and sets the number of slave applier threads for executing replication transactions in parallel. When the value is a number greater than 0, the slave is a multithreaded slave with the specified number of applier threads, plus a coordinator thread to manage them. If you are using multiple replication channels, each channel has this number of threads.

    Note

    Multithreaded slaves are not currently supported by NDB Cluster, which silently ignores the setting for this variable. See Section 22.6.3, “Known Issues in NDB Cluster Replication”, for more information.

    Retrying of transactions is supported when multithreading is enabled on a slave. When slave_preserve_commit_order=1, transactions on a slave are externalized on the slave in the same order as they appear in the slave's relay log. The way in which transactions are distributed among applier threads is configured by --slave-parallel-type.

    To disable parallel execution, set this option to 0, which gives the slave a single applier thread and no coordinator thread. With this setting, the --slave-parallel-type and slave_preserve_commit_order options have no effect and are ignored.

    Setting slave_parallel_workers has no immediate effect. The state of the variable applies on all subsequent START SLAVE statements.

  • slave_pending_jobs_size_max

    Property Value
    Command-Line Format --slave-pending-jobs-size-max=#
    System Variable slave_pending_jobs_size_max
    Scope Global
    Dynamic Yes
    SET_VAR Hint Applies No
    Type Integer
    Default Value (>= 8.0.12) 128M
    Default Value (<= 8.0.11) 16M
    Minimum Value 1024
    Maximum Value 16EiB
    Block Size 1024

    For multithreaded slaves, this variable sets the maximum amount of memory (in bytes) available to slave worker queues holding events not yet applied. Setting this variable has no effect on slaves for which multithreading is not enabled. Setting this variable has no immediate effect. The state of the variable applies on all subsequent START SLAVE commands.

    The minimum possible value for this variable is 1024 bytes; the default is 128MB. The maximum possible value is 18446744073709551615 (16 exbibytes). Values that are not exact multiples of 1024 bytes are rounded down to the next lower multiple of 1024 bytes prior to being stored.

    The value of this variable is a soft limit and can be set to match the normal workload. If an unusually large event exceeds this size, the transaction is held until all the slave workers have empty queues, and then processed. All subsequent transactions are held until the large transaction has been completed.

  • slave_preserve_commit_order

    Property Value
    Command-Line Format --slave-preserve-commit-order=value
    System Variable slave_preserve_commit_order
    Scope Global
    Dynamic Yes
    SET_VAR Hint Applies No
    Type Boolean
    Default Value 0
    Valid Values

    0

    1

    For multithreaded slaves, the setting 1 for this variable ensures that transactions are externalized on the slave in the same order as they appear in the slave's relay log, and prevents gaps in the sequence of transactions that have been executed from the relay log. This variable has no effect on slaves for which multithreading is not enabled.

    slave_preserve_commit_order=1 requires that --log-bin and --log-slave-updates are enabled on the slave, and --slave-parallel-type is set to LOGICAL_CLOCK.

    With slave_preserve_commit_order enabled, the executing thread waits until all previous transactions are committed before committing. While the slave thread is waiting for other workers to commit their transactions it reports its status as Waiting for preceding transaction to commit. With this mode, a multithreaded slave never enters a state that the master was not in. This supports the use of replication for read scale-out. See Section 17.3.5, “Using Replication for Scale-Out”.

    Before changing this variable, all replication threads (for all replication channels if you are using multiple replication channels) must be stopped. If slave_preserve_commit_order=0 is set, the transactions that the slave applies in parallel may commit out of order. Therefore, checking for the most recently executed transaction does not guarantee that all previous transactions from the master have been executed on the slave. There is a chance of gaps in the sequence of transactions that have been executed from the slave's relay log. This has implications for logging and recovery when using a multithreaded slave. Note that the setting slave_preserve_commit_order=1 prevents gaps, but does not prevent gap-free low-watermark positions (where Exec_master_log_pos is behind the position up to which transactions have been executed). See Section 17.4.1.34, “Replication and Transaction Inconsistencies” for more information.

  • slave_rows_search_algorithms

    Property Value
    System Variable slave_rows_search_algorithms=list
    Scope Global
    Dynamic Yes
    SET_VAR Hint Applies No
    Type Set
    Default Value (>= 8.0.2) INDEX_SCAN,HASH_SCAN
    Default Value (<= 8.0.1) TABLE_SCAN,INDEX_SCAN
    Valid Values

    TABLE_SCAN,INDEX_SCAN

    INDEX_SCAN,HASH_SCAN

    TABLE_SCAN,HASH_SCAN

    TABLE_SCAN,INDEX_SCAN,HASH_SCAN (equivalent to INDEX_SCAN,HASH_SCAN)

    When preparing batches of rows for row-based logging and replication, this variable controls how the rows are searched for matches—that is, whether or not hashing is used for searches using a primary or unique key, some other key, or using no key at all. Setting this variable takes effect for all replication channels immediately, including running channels. The initial setting for the system variable can be specified using the --slave-rows-search-algorithms option.

    Specify a comma-separated list of any 2 (or all 3) values from the list INDEX_SCAN, TABLE_SCAN, HASH_SCAN. The value is expected as a string, so the value must be quoted. In addition, the value must not contain any spaces. Possible combinations (lists) and their effects are shown in the following table:

    Index used / option value INDEX_SCAN,HASH_SCAN or INDEX_SCAN,TABLE_SCAN,HASH_SCAN INDEX_SCAN,TABLE_SCAN TABLE_SCAN,HASH_SCAN
    Primary key or unique key Index scan Index scan Hash scan over index
    (Other) Key Hash scan over index Index scan Hash scan over index
    No index Hash scan Table scan Hash scan

    The order in which the algorithms are specified in the list does not make any difference in the order in which they are displayed by a SELECT or SHOW VARIABLES statement (which is the same as that used in the table just shown previously).

    • The default value is INDEX_SCAN,HASH_SCAN. With this setting, hashing is used for any searches that do not use a primary or unique key. Specifying INDEX_SCAN,TABLE_SCAN,HASH_SCAN has the same effect as specifying INDEX_SCAN,HASH_SCAN.

    • To force hashing for all searches, set this option to TABLE_SCAN,HASH_SCAN.

    • To remove hashing, set this option to TABLE_SCAN,INDEX_SCAN. With this setting, all searches that can use indexes do use them, and searches without any indexes use table scans.

    It is possible to specify single values for this option, but this is not optimal, because setting a single value limits searches to using only that algorithm. In particular, setting INDEX_SCAN alone is not recommended, as in that case searches are unable to find rows at all if no index is present.

    Note

    There is only a performance advantage for INDEX_SCAN and HASH_SCAN if the row events are big enough. The size of row events is configured using --binlog-row-event-max-size. For example, suppose a DELETE statement which deletes 25,000 rows generates large Delete_row_event events. In this case if slave_rows_search_algorithms is set to INDEX_SCAN or HASH_SCAN there is a performance improvement. However, if there are 25,000 DELETE statements and each is represented by a separate event then setting slave_rows_search_algorithms to INDEX_SCAN or HASH_SCAN provides no performance improvement while executing these separate events.

  • slave_skip_errors

    Property Value
    Command-Line Format --slave-skip-errors=name
    System Variable slave_skip_errors
    Scope Global
    Dynamic No
    SET_VAR Hint Applies No
    Type String
    Default Value OFF
    Valid Values

    OFF

    [list of error codes]

    all

    ddl_exist_errors

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

  • slave_sql_verify_checksum

    Property Value
    System Variable slave_sql_verify_checksum
    Scope Global
    Dynamic Yes
    SET_VAR Hint Applies No
    Type Boolean
    Default Value 1
    Valid Values

    0

    1

    Cause the slave SQL thread to verify data using the checksums read from the relay log. In the event of a mismatch, the slave stops with an error. Setting this variable takes effect for all replication channels immediately, including running channels.

    Note

    The slave I/O thread always reads checksums if possible when accepting events from over the network.

  • slave_transaction_retries

    Property Value
    Command-Line Format --slave-transaction-retries=#
    System Variable slave_transaction_retries
    Scope Global
    Dynamic Yes
    SET_VAR Hint Applies No
    Type Integer
    Default Value 10
    Minimum Value 0
    Maximum Value (64-bit platforms) 18446744073709551615
    Maximum Value (32-bit platforms) 4294967295

    Sets the maximum number of times for replication slave SQL threads on a single-threaded or multithreaded slave to automatically retry failed transactions before stopping. Setting this variable takes effect for all replication channels immediately, including running channels. The default value is 10. Setting the variable to 0 disables automatic retrying of transactions.

    If a replication slave SQL thread fails to execute a transaction because of an InnoDB deadlock or because the transaction's execution time exceeded InnoDB's innodb_lock_wait_timeout or NDB's TransactionDeadlockDetectionTimeout or TransactionInactiveTimeout, it automatically retries slave_transaction_retries times before stopping with an error. Transactions with a non-temporary error are not retried.

    The Performance Schema table replication_applier_status shows the number of retries that took place on each replication channel, in the COUNT_TRANSACTIONS_RETRIES column. The Performance Schema table replication_applier_status_by_worker shows detailed information on transaction retries by individual applier threads on a single-threaded or multithreaded replication slave, and identifies the errors that caused the last transaction and the transaction currently in progress to be reattempted.

  • slave_type_conversions

    Property Value
    Command-Line Format --slave-type-conversions=set
    System Variable slave_type_conversions
    Scope Global
    Dynamic No
    SET_VAR Hint Applies No
    Type Set
    Default Value
    Valid Values

    ALL_LOSSY

    ALL_NON_LOSSY

    ALL_SIGNED

    ALL_UNSIGNED

    Controls the type conversion mode in effect on the slave when using row-based replication. Its value is a comma-delimited set of zero or more elements from the list: ALL_LOSSY, ALL_NON_LOSSY, ALL_SIGNED, ALL_UNSIGNED. Set this variable to an empty string to disallow type conversions between the master and the slave. Setting this variable takes effect for all replication channels immediately, including running channels.

    For additional information on type conversion modes applicable to attribute promotion and demotion in row-based replication, see Row-based replication: attribute promotion and demotion.

  • sql_slave_skip_counter

    Property Value
    System Variable sql_slave_skip_counter
    Scope Global
    Dynamic Yes
    SET_VAR Hint Applies No
    Type Integer

    The number of events from the master that a slave server should skip. Setting the option has no immediate effect. The variable applies to the next START SLAVE statement; the next START SLAVE statement also changes the value back to 0. When this variable is set to a nonzero value and there are multiple replication channels configured, the START SLAVE statement can only be used with the FOR CHANNEL channel clause.

    This option is incompatible with GTID-based replication, and must not be set to a nonzero value when --gtid-mode=ON. If you need to skip transactions when employing GTIDs, use gtid_executed from the master instead. See Injecting empty transactions, for information about how to do this.

    Important

    If skipping the number of events specified by setting this variable would cause the slave to begin in the middle of an event group, the slave continues to skip until it finds the beginning of the next event group and begins from that point. For more information, see Section 13.4.2.5, “SET GLOBAL sql_slave_skip_counter Syntax”.

  • sync_master_info

    Property Value
    Command-Line Format --sync-master-info=#
    System Variable sync_master_info
    Scope Global
    Dynamic Yes
    SET_VAR Hint Applies No
    Type Integer
    Default Value 10000
    Minimum Value 0
    Maximum Value (64-bit platforms) 18446744073709551615
    Maximum Value (32-bit platforms) 4294967295

    The effects of this variable on a replication slave depend on whether the slave's master_info_repository is set to FILE or TABLE, as explained in the following paragraphs.

    master_info_repository = FILE.  If the value of sync_master_info is greater than 0, the slave synchronizes its master.info file to disk (using fdatasync()) after every sync_master_info events. If it is 0, the MySQL server performs no synchronization of the master.info file to disk; instead, the server relies on the operating system to flush its contents periodically as with any other file.

    master_info_repository = TABLE.  If the value of sync_master_info is greater than 0, the slave updates its master info repository table after every sync_master_info events. If it is 0, the table is never updated.

    The default value for sync_master_info is 10000. Setting this variable takes effect for all replication channels immediately, including running channels.

  • sync_relay_log

    Property Value
    Command-Line Format --sync-relay-log=#
    System Variable sync_relay_log
    Scope Global
    Dynamic Yes
    SET_VAR Hint Applies No
    Type Integer
    Default Value 10000
    Minimum Value 0
    Maximum Value (64-bit platforms) 18446744073709551615
    Maximum Value (32-bit platforms) 4294967295

    If the value of this variable is greater than 0, the MySQL server synchronizes its relay log to disk (using fdatasync()) after every sync_relay_log events are written to the relay log. Setting this variable takes effect for all replication channels immediately, including running channels.

    Setting sync_relay_log to 0 causes no synchronization to be done to disk; in this case, the server relies on the operating system to flush the relay log's contents from time to time as for any other file.

    A value of 1 is the safest choice because in the event of a crash you lose at most one event from the relay log. However, it is also the slowest choice (unless the disk has a battery-backed cache, which makes synchronization very fast).

  • sync_relay_log_info

    Property Value
    Command-Line Format --sync-relay-log-info=#
    System Variable sync_relay_log_info
    Scope Global
    Dynamic Yes
    SET_VAR Hint Applies No
    Type Integer
    Default Value 10000
    Minimum Value 0
    Maximum Value (64-bit platforms) 18446744073709551615
    Maximum Value (32-bit platforms) 4294967295

    The default value for sync_relay_log_info is 10000. Setting this variable takes effect for all replication channels immediately, including running channels.

    The effects of this variable on the replication slave depend on the server's relay_log_info_repository setting (FILE or TABLE). If the setting is TABLE, the effects of the variable also depend on whether the storage engine used by the relay log info table is transactional (such as InnoDB) or not transactional (MyISAM). The effects of these factors on the behavior of the server for sync_relay_log_info values of zero and greater than zero are as follows:

    sync_relay_log_info = 0
    • If relay_log_info_repository is set to FILE, the MySQL server performs no synchronization of the relay-log.info file to disk; instead, the server relies on the operating system to flush its contents periodically as with any other file.

    • If relay_log_info_repository is set to TABLE, and the storage engine for that table is transactional, the table is updated after each transaction. (The sync_relay_log_info setting is effectively ignored in this case.)

    • If relay_log_info_repository is set to TABLE, and the storage engine for that table is not transactional, the table is never updated.

    sync_relay_log_info = N > 0
    • If relay_log_info_repository is set to FILE, the slave synchronizes its relay-log.info file to disk (using fdatasync()) after every N transactions.

    • If relay_log_info_repository is set to TABLE, and the storage engine for that table is transactional, the table is updated after each transaction. (The sync_relay_log_info setting is effectively ignored in this case.)

    • If relay_log_info_repository is set to TABLE, and the storage engine for that table is not transactional, the table is updated after every N events.


User Comments
User comments in this section are, as the name implies, provided by MySQL users. The MySQL documentation team is not responsible for, nor do they endorse, any of the information provided here.
  Posted by Charles Darwin on February 17, 2012
I had a problem when I just changed the server name. I got the known error:

[ERROR] Failed to open the relay log './zeus-relay-bin.000009' (relay_log_pos 251)
120216 17:11:31 [ERROR] Could not find target log during relay log initialization

When I changed the name from zeus to perseo.

My solution was to delete the files with old server name, I mean zeus-relay-* and delete relay-log.info.

It just worked for me.
  Posted by andrew lorien on April 28, 2014
MySQL Enterprise Monitor (supported by a few tech blogs) has an "Slave Detection Of Network Outages Too High" advisor, which suggests that you "decrease slave_net_timeout so the outages -- and associated connection retries -- are detected and resolved faster. The default for this parameter is 3600 seconds (1 hour), which is too high for many environments."

However, in our reasonably high traffic environment (each master has three slaves on a very low-latency network, a 1G compressed binlog takes about a week to rotate), setting this value to 30 seconds caused recurring replication problems. The slaves started and stopped replicating with the message "Waiting to reconnect after a failed master event read." stop slave - start slave did not fix them (in fact we believe it made the problem worse). Removing the slave_net_timeout value from mysql.ini fixed replication immediately.
Sign Up Login You must be logged in to post a comment.