Command-Line Format | –server-id=# | |
Option-File Format | server-id | |
Option Sets Variable | Yes, server_id | |
Variable Name | server_id | |
Variable Scope | Global | |
Dynamic Variable | Yes | |
Permitted Values | ||
Type | numeric | |
Default | 0 | |
Range | 0 .. 4294967295 |
该选项对复制主、从服务器都是共有的,并在复制中使用以使主机和从机服务器能唯一识别自身。更多信息,参见16.1.3.2节,“复制主选项和变量”,16.1.3.3节,“复制从选项和变量”。
在主机和每个从机上,你必须使用–server-id选项来建立一个在1到232-1范围内的唯一的复制ID。“唯一”意味着每个ID必须不同于其它任何复制主或从使用的ID。例如:server-id=3。
如果你省略–server-id,默认ID为0,在这种情况下,主机拒绝来自所有从机的连接,并且从机拒绝连接到主机。更多信息,参见16.1.1.2节,“设置复制从配置”。
Command-Line Format | –auto-increment-increment[=#] | |
Option-File Format | auto_increment_increment | |
Option Sets Variable | ||
Variable Name | auto_increment_increment | |
Variable Scope | Global, Session | |
Dynamic Variable | Yes | |
Permitted Values | ||
Type | numeric | |
Default | 1 | |
Range | 1 .. 65535 |
auto_increment_increment和auto_increment_offset设计用于主主复制使用,可以用来控制AUTO_INCREMENT列的操作。这两个变量都有全局和会话值,每个都可以指定1到65,535之间的整数值。尝试设置这两个变量的值为0会导致被替代为设置其值为1。尝试设置这两个变量的值为大于65535或小于0的整数会导致被替代为设置其值为65,535。试图设置auto_increment_increment或auto_increment_offset的值为一个非整数值产生一个错误,变量的实际值保持不变。
注意
auto_increment_increment只支持用于NDB表。(auto_increment_increment is supported for use with NDB tables only.) (官方手册原文翻译,此处疑为手册原文有误)
这两个变量像下面那样影响AUTO_INCREMENT列的行为:
auto_increment_increment控制连续列值之间的间隔。例如:
mysql> SHOW VARIABLES LIKE ‘auto_inc%’;
+--------------------------+-------+
| Variable_name | Value |
+--------------------------+-------+
| auto_increment_increment | 1 |
| auto_increment_offset | 1 |
+--------------------------+-------+
2 rows in set (0.00 sec)
mysql> CREATE TABLE autoinc1
-> (col INT NOT NULL AUTO_INCREMENT PRIMARY KEY);
Query OK, 0 rows affected (0.04 sec)
mysql> SET @@auto_increment_increment=10;
Query OK, 0 rows affected (0.00 sec)
mysql> SHOW VARIABLES LIKE ‘auto_inc%’;
+--------------------------+-------+
| Variable_name | Value |
+--------------------------+-------+
| auto_increment_increment | 10 |
| auto_increment_offset | 1 |
+--------------------------+-------+
2 rows in set (0.01 sec)
mysql> INSERT INTO autoinc1 VALUES (NULL), (NULL), (NULL), (NULL);
Query OK, 4 rows affected (0.00 sec)
Records: 4 Duplicates: 0 Warnings: 0
mysql> SELECT col FROM autoinc1;
+-----+
| col |
+-----+
| 1 |
| 11 |
| 21 |
| 31 |
+-----+
4 rows in set (0.00 sec)
auto_increment_offset确定AUTO_INCREMENT列值的起点。考虑以下假设,这些语句像auto_increment_increment的描述中给出的例子一样在同一个会话期间执行:
mysql> SET @@auto_increment_offset=5;
Query OK, 0 rows affected (0.00 sec)
mysql> SHOW VARIABLES LIKE ‘auto_inc%’;
+--------------------------+-------+
| Variable_name | Value |
+--------------------------+-------+
| auto_increment_increment | 10 |
| auto_increment_offset | 5 |
+--------------------------+-------+
2 rows in set (0.00 sec)
mysql> CREATE TABLE autoinc2
-> (col INT NOT NULL AUTO_INCREMENT PRIMARY KEY);
Query OK, 0 rows affected (0.06 sec)
mysql> INSERT INTO autoinc2 VALUES (NULL), (NULL), (NULL), (NULL);
Query OK, 4 rows affected (0.00 sec)
Records: 4 Duplicates: 0 Warnings: 0
mysql> SELECT col FROM autoinc2;
+-----+
| col |
+-----+
| 5 |
| 15 |
| 25 |
| 35 |
+-----+
4 rows in set (0.02 sec)
如果auto_increment_offset的值比auto_increment_increment的更大auto_increment_offset值将被忽略。
如果这些变量中的一个或两个改变,然后新行插入到一个包含一个AUTO_INCREMENT列的表,结果可能有悖常理,这是由于AUTO_INCREMENT值计算时不考虑任何目前已在列中出现的值,而且下一个插入的值至少是这一序列值中比现有AUTO_INCREMENT列中的最大值更大的值。换言之,序列是像这样计算的:
auto_increment_offset + N × auto_increment_increment
其中N是一个序列 [1,2,3,...]中的正整数。例如:
mysql> SHOW VARIABLES LIKE ‘auto_inc%’;
+--------------------------+-------+
| Variable_name | Value |
+--------------------------+-------+
| auto_increment_increment | 10 |
| auto_increment_offset | 5 |
+--------------------------+-------+
2 rows in set (0.00 sec)
mysql> SELECT col FROM autoinc1;
+-----+
| col |
+-----+
| 1 |
| 11 |
| 21 |
| 31 |
+-----+
4 rows in set (0.00 sec)
mysql> INSERT INTO autoinc1 VALUES (NULL), (NULL), (NULL), (NULL);
Query OK, 4 rows affected (0.00 sec)
Records: 4 Duplicates: 0 Warnings: 0
mysql> SELECT col FROM autoinc1;
+-----+
| col |
+-----+
| 1 |
| 11 |
| 21 |
| 31 |
| 35 |
| 45 |
| 55 |
| 65 |
+-----+
8 rows in set (0.00 sec)
所示的auto_increment_increment和auto_increment_offset值为生成5+ N×10的序列,即[5,15,25,35,45,...]。在INSERT之前col列出现的最大值是31,在AUTO_INCREMENT序列中下一个可用值是35,所以col插入的值从那一点开始,其结果如SELECT查询所示。
将这两个变量的影响局限于一个单一的表是不可能的,因此它们无法代替一些其它的数据库管理系统提供的序列;这些变量控制MySQL服务器上的所有表中的所有AUTO_INCREMENT列的行为。如果任一变量的全局值被设置,其影响一直存在,直到全局值被更改或被设置会话值覆盖,或直到mysqld重新启动。如果设置了局部值,新的值会影响在会话期间被当前用户插入新行的所有表的AUTO_INCREMENT列,除非在该会话期间改变了其值。
auto_increment_increment的默认值是1。参见16.4.1.1节,“复制与AUTO_INCREMENT”。
Command-Line Format | –auto-increment-offset[=#] | |
Option-File Format | auto_increment_offset | |
Option Sets Variable | ||
Variable Name | auto_increment_offset | |
Variable Scope | Global, Session | |
Dynamic Variable | Yes | |
Permitted Values | ||
Type | numeric | |
Default | 1 | |
Range | 1 .. 65535 |
这个变量的默认值为1。详情参见auto_increment_increment的描述。
注意
auto_increment_offset只支持用于NDB表。(auto_increment_offset is supported for use with NDB tables only.) (官方手册原文翻译,此处疑为手册原文有误)
Version Introduced | 5.5.26 | |
Variable Name | slave_max_allowed_packet | |
Variable Scope | Global | |
Dynamic Variable | Yes | |
Permitted Values | ||
Type | numeric | |
Default | 1073741824 | |
Range | 1024 .. 1073741824 |
在MySQL5.5.26中及以后,这个变量设置从SQL和I / O线程的最大数据包大小,因此,使用基于行的复制的大更新不会因为更新超过max_allowed_packet导致复制失败。
这个全局变量值总是1024的正整数倍数,如果你把它设置为一些其它值,存储或使用的值向下舍入到下一个最大的1024的倍数;设置slave_max_allowed_packet为0导致使用1024。 (在所有这些情况下,发出截断警告。)默认和最大值是1073741824(1 GB),最小值为1024。
也可以在启动时使用–slave-max-allowed-packet选项设置slave_max_allowed_packet。
Version Introduced | 5.5.26 | |
Command-Line Format | –slave-max-allowed-packet=# | |
Option-File Format | slave-max-allowed-packet | |
Option Sets Variable | ||
Permitted Values | ||
Type | numeric | |
Default | 1073741824 | |
Range | 1024 .. 1073741824 |
在MySQL5.5.26中及以后,这个变量设置从SQL和I / O线程的最大数据包大小,因此,使用基于行的复制的大更新不会因为更新超过max_allowed_packet导致复制失败。(Bug #12400221, BUG#60926)
相应的服务器变量slave_max_allowed_packet总是1024的正整数倍数;如果你把它设置为不是这样一个倍数的一些值,值会自动向下调整到下一个最大的1024的倍数。 (例如,如果你用–slave-max-allowed-packet=10000启动服务器,使用的值是9216;设置值为0导致使用1024)在这种情况下发出一个截断警告。
最大(默认)值为1073741824(1 GB),最小值为1024。
Command-Line Format | –abort-slave-event-count=# | |
Option-File Format | abort-slave-event-count | |
Permitted Values | ||
Type | numeric | |
Default | 0 | |
Min Value | 0 |
当这个选项被设置为除0(默认)以外的正整数value时,它对复制行为的影响如下:从机的SQL线程开始后, value个日志事件被允许执行;之后,slave的SQL线程不接收任何更多的事件,就如同来自主机的网络连接被切断一样。从机线程继续运行,并且SHOW SLAVE STATUS的输出Slave_IO_Running与Slave_SQL_Running列均显示yes,但不从中继日志读取更多的事件。
该选项被MySQL测试套件为复制测试和调试在内部使用。它不是为了用于生产环境中。
Command-Line Format | –disconnect-slave-event-count=# | |
Option-File Format | disconnect-slave-event-count | |
Permitted Values | ||
Type | numeric | |
Default | 0 |
该选项被MySQL测试套件为复制测试和调试在内部使用。
Command-Line Format | –log-slave-updates | |
Option-File Format | log-slave-updates | |
Option Sets Variable | Yes, log_slave_updates | |
Variable Name | log_slave_updates | |
Variable Scope | Global | |
Dynamic Variable | No | |
Permitted Values | ||
Type | boolean | |
Default | FALSE |
通常情况下,从机不记录自主机服务器收到的任何更新到自己的二进制日志。这个选项告诉从机记录其SQL线程执行的更新到自己的二进制日志。要使此选项有效果,还必须用- log-bin选项启动从机以启用二进制日志。在MySQL5.5之前,当使用–log-slave-updates选项但不使用–log-bin选项启动服务器时,服务器将无法启动,将失败并报错 (and would fail with an error),在MySQL5.5中,只产生一个警告。(bug#44663)–log-slave-updates用于当你想要链式复制服务器时。例如,你可能想使用这样的安排建立复制服务器:
A -> B -> C
在这里,A作为B从机的主机,且B作为C从机的主机。要使它们起作用,B必须同时是主机与从机。您必须用–log-bin启动A和B以启用二进制日志,并且B使用–log-slave-updates选项以便自A收到的更新被B记录到它的二进制日志。
Command-Line Format | –log-slow-slave-statements | |
Option-File Format | log-slow-slave-statements | |
Permitted Values | ||
Type | boolean | |
Default | off |
当启用慢查询日志时,该选项允许记录从机上执行消耗超过long_query_time秒的查询。
Command-Line Format | –log-warnings[=#] | |
-W [#] | ||
Option-File Format | log-warnings | |
Option Sets Variable | Yes, log_warnings | |
Variable Name | log_warnings | |
Variable Scope | Global, Session | |
Dynamic Variable | Yes | |
Disabled by | skip-log-warnings | |
Permitted Values | ||
Platform Bit Size | 64 | |
Type | numeric | |
Default | 1 | |
Range | 0 .. 18446744073709547520 |
该选项会导致服务器向错误日志打印更多关于它正在做什么的消息。对于复制而言,服务器产生警告:它在网络/连接失败后重新连接成功,并告知你各个从线程如何启动。该选项默认启用;要禁用它,使用–skip-log-warnings。如果该值大于1,中止(abort)连接被写入到错误日志,并且新的连接尝试的拒绝访问错误被写入。参见C.5.2.11节,“通信错误与中止连接”。
请注意此选项的影响不仅限于复制。它产生涵盖一系列服务器活动的警告。(It produces warnings across a spectrum of server activities.)
Command-Line Format | –master-info-file=file_name | |
Option-File Format | master-info-file=file_name | |
Permitted Values | ||
Type | file name | |
Default | master.info |
从机记录关于主机的信息的文件使用的名称。默认名称是master.info,在数据目录中。有关该文件格式的信息,参见16.2.2.2节,“从机状态日志”。
Command-Line Format | –master-retry-count=# | |
Option-File Format | master-retry-count | |
Deprecated | 5.6.1 | |
Permitted Values | ||
Platform Bit Size | 32 | |
Type | numeric | |
Default | 86400 | |
Range | 0 .. 4294967295 | |
Permitted Values | ||
Platform Bit Size | 64 | |
Type | numeric | |
Default | 86400 | |
Range | 0 .. 18446744073709551615 |
从机放弃前尝试连接主机的次数。重连在由CHANGE MASTER TO语句的MASTER_CONNECT_RETRY选项(默认60)设定的时间间隔尝试。(Reconnects are attempted at intervals set by the MASTER_CONNECT_RETRY option of the CHANGE MASTER TO statement (default 60).)当从机读取的数据依据–slave-net-timeout选项超时时重新连接被触发。(Reconnects are triggered when data reads by the slave time out according to the –slave-net-timeout option.)默认值是86400。值为0意味着“无限”;从机永远试图连接。
服务器自动切换中继日志文件的大小。更多信息,参见16.2.2节,“复制中继和状态日志”。默认大小为1GB。
导致从机不允许除了复制线程或具有SUPER权限的用户以外的更新。在从服务器上,这可以有效确保从机只接受来自它的主服务器,而不是来自客户端的更新。此变量不适用于TEMPORARY表。
Command-Line Format | –relay-log=name | |
Option-File Format | relay-log | |
Permitted Values | ||
Type | file name |
中继日志的基本名称(basename)。默认的基本名称是host_name-relay-bin。除非给定的基本名称以绝对路径名开头来指定不同的目录,服务器写入文件到数据目录中。服务器通过添加一个数字后缀到基本名称来创建中继日志文件序列。
由于MySQL解析服务器选项的方式的原因,如果指定该选项,你必须提供一个值,默认的基本名称只有当该选项实际上并没有指定时被使用。如果你使用不指定值的–relay-log选项,有可能导致意外的行为;这种行为取决于使用的其他选项,他们被指定的顺序,是否是在命令行或在选项文件指定。 关于MySQL如何处理服务器选项的更多信息,参见4.2.3节,“指定程序选项”。
如果你指定该选项,指定的值也被用作中继日志索引文件的基本名称。你可以通过使用–relay-log-index选项指定一个不同的中继日志索引文件基本名称覆盖这种行为。
从MySQL 5.5.20开始,当服务器从索引文件读取一个条目,它会检查条目是否包含一个相对路径。如果确实如此,路径的相对部分被使用–relay-log选项设置的绝对路径取代。绝对路径保持不变;在这种情况下,必须手动编辑该索引以启用新的路径,或将要使用的路径。在MySQL 5.5.20之前,迁移二进制日志或中继日志文件时需要人工干预。 (bug#11745230,bug#12133)
您可能会发现执行以下任务时–relay-log选项有用:
n 创建其名称独立于主机名的中继日志。
n 如果由于你的中继日志可能非常大,且你不想降低max_relay_log_size,你需要把中继日志放在除数据目录以外的一些地方。
n 使用磁盘间负载平衡,以增加速度。
Command-Line Format | –relay-log-index=name | |
Option-File Format | relay-log-index | |
Option Sets Variable | Yes, relay_log_index | |
Variable Name | relay-log-index | |
Variable Scope | Global, Session | |
Dynamic Variable | No | |
Permitted Values | ||
Type | file name |
中继日志索引文件使用的名称。默认名称是host_name-relay-bin.index位于数据目录中,其中host_name是从服务器的名称。
由于MySQL解析服务器选项的方式,如果指定该选项,你必须提供一个值,默认的基本名称只有当该选项实际上并没有指定时被使用。如果你使用不指定值的–relay-log-index选项,有可能导致意外的行为;这种行为取决于使用的其他选项,他们被指定的顺序,是否在命令行或在选项文件指定。 关于MySQL如何处理服务器选项的更多信息,参见4.2.3节,“指定程序选项”。
如果你指定该选项,指定的值也被用作中继日志文件的基本名称。你可以通过使用–relay-log选项指定一个不同的中继日志文件基本名称覆盖这种行为。
Command-Line Format | –relay-log-info-file=file_name | |
Option-File Format | relay-log-info-file | |
Option Sets Variable | Yes, relay_log_info_file | |
Permitted Values | ||
Type | file name | |
Default | relay-log.info |
从机记录中继日志的有关信息使用的文件的名称。默认名称是relay-log.info,在数据目录中。有关该文件格式的信息,参见16.2.2.2节,“从机状态日志”。
禁用或启用一旦不再需要中继日志时的自动清除(Disable or enable automatic purging of relay logs as soon as they are no longer needed)。默认值是1(启用)。这是一个可以用SET GLOBAL relay_log_purge= N动态改变的全局变量。
Command-Line Format | –relay-log-recovery | |
Option-File Format | relay-log-recovery | |
Option Sets Variable | Yes, relay_log_recovery | |
Permitted Values | ||
Type | boolean | |
Default | FALSE |
启用紧接着服务器启动后的自动中继日志恢复,这意味着复制从机丢弃所有未处理的中继日志并从复制主机取回它们。复制从机的崩溃后它应该被使用,以确保没有可能损坏的中继日志被处理。默认值是0(禁用)。
该选项设置在从机上的所有中继日志的总大小字节数上限。值为0意味着“没有限制”。服务器主机的磁盘空间有限时这是有用的。当达到限制时,I / O线程停止从主服务器读取二进制日志事件,直到SQL线程已经赶上并删除了一些未使用的中继日志。请注意,该限制不是绝对的:在有些情况下,SQL线程需要更多的事件,才可以删除中继日志。在这种情况下,I / O线程超过该限制,直到情况变为SQL线程有可能删除中继日志,因为不这样做会导致死锁。你不应该设置–relay-log-space-limit为少于–max-relay-log-size的值的两倍(或 –max-binlog-size,如果–max-relay-log-size为0的话 )。在这种情况下,有一定几率I / O线程因为–relay-log-space-limit超出限制等待空闲空间,但SQL线程没有中继日志去清除而无法满足I / O线程。这将强制I / O线程暂时忽略–relay-log-space-limit。
Command-Line Format | –replicate-do-db=name | |
Option-File Format | replicate-do-db | |
Permitted Values | ||
Type | string |
这个选项的效果取决于是否正在使用基于语句或基于行的复制。
基于语句的复制:告诉从机的SQL线程限制为复制默认数据库(即,USE选择的那一个)是db_name的语句(restrict replication to statements where the default database (that is, the one selected by USE) is db_name.)。要指定多个数据库,多次使用这个选项,为每个数据库一次;这样做并不能在不同的数据库(或没有数据库)被选中时复制跨数据库的语句,例如UPDATE some_db.some_table SET foo =’bar’。
警告
要指定多个数据库你必须使用多个该选项。因为数据库名称可以包含逗号,如果你提供了一个逗号分隔的列表,它将被视为一个单一的数据库的名称。
使用基于语句的复制时,一个不像你可能期望的那样运行的例子:如果用–replicate-do-db=sales启动从机且你在主机上发出下面的语句,该UPDATE语句不会被复制:
USE prices;
UPDATE sales.january SET amount=amount+1000;
这个“只检查默认数据库”行为的主要原因是,单独由语句很难知道它是否应该被复制(例如,如果您使用跨多个数据库的多表DELETE语句或多表UPDATE语句)。如果并没有必要,只检查默认数据库而不是所有的数据库也更快。
基于行的复制:告诉slave的SQL线程限制复制db_name数据库(restrict replication to database db_name.)。只有属于db_name的表被修改。当前数据库对它没有影响。假设从机用–replicate-do-db=sales启动且基于行的复制起效,然后主机上运行了下面的语句:
USE prices;
UPDATE sales.february SET amount=amount+100;
从机上的sales数据库february表按照UPDATE语句被改变,无论USE语句是否发出,这种情况都发生。然而,当使用基于行的复制与–replicate-do-db=sales时,在主机发出下面的语句,在从机上没有效果:
USE prices;
UPDATE prices.march SET amount=amount-25;
即使语句USE prices改为USE sales,该UPDATE语句的影响依旧不会被复制。
另一个重要的在基于语句的复制中不同于基于行的复制–replicate-do-db是如何处理的,发生于引用多个数据库的语句。(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.)假设从机用–replicate-do-db=db1启动,在主服务器上执行下面的语句:
USE db1;
UPDATE db1.table1 SET col1 = 10, db2.table2 SET col2 = 20;
如果你正使用基于语句复制,那么从机上的两个表都被更新。然而,当使用基于行的复制时,从机上只有table1受影响;因为table2在不同的数据库,从机上的table2不被UPDATE所改变。现在假设,一个USE db4语句被使用,而不是USE db1语句:
USE db4;
UPDATE db1.table1 SET col1 = 10, db2.table2 SET col2 = 20;
在这种情况下,使用基于语句的复制时该UPDATE语句在从机上不起效果。然而,如果你使用基于行的复制,更新会改变从机上的table1,但table2不会,换句话说,仅有–replicate-do-db指定名称的数据库中的表被改变,在此种行为下,默认数据库的选择没有影响。
如果你需要跨数据库更新起效,使用–replicate-wild-do-table=db_name.%代替。参见16.2.3节“服务器如何判断复制过滤规则”。
注意
该选项会像–binlog-do-db影响二进制日志记录一样影响复制日志,–replicate-do-db如何影响复制行为对复制日志格式的影响与–binlog-do-db的行为对日志格式的影响相同(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.)。
该选项不影响BEGIN,COMMIT或ROLLBACK语句。
Command-Line Format | –replicate-ignore-db=name | |
Option-File Format | replicate-ignore-db | |
Permitted Values | ||
Type | string |
和–replicate-do-db一样,该选项的影响依赖于基于语句的还是基于行的复制正在使用。
基于语句的复制:告诉从机的SQL线程不复制任何默认数据库(即,USE选择的那一个)是db_name的语句。
基于行的复制 :告诉从机的SQL线程不要更新数据库db_name中的的任何表。默认的数据库没有任何效果。
当使用基于语句复制时,下面的例子不像你可能想象的那样工作。假设从机用–replicate-ignore-db=sales启动,并且你在主机上发出以下语句:
USE prices;
UPDATE sales.january SET amount=amount+1000;
在这种情况下, UPDATE语句被复制,因为–replicate-ignore-db仅应用于默认数据库(由USE语句确定)。因为sales数据库是在语句中明确指定的,该语句并没有被过滤。然而,当使用基于行的复制时,UPDATE语句的效果不传递到从机,从机的sales.january表副本是不变的;在这种情况下–replicate-ignore-db=sales导致所有对主机的sales数据库副本的更改被从机忽略。
要指定多个数据库被忽略,多次使用这个选项,为每个数据库一次。因为数据库名称可以包含逗号,如果你提供了一个逗号分隔的列表,该列表将被视为一个单一的数据库的名称。
如果你正使用跨数据库的更新且你不想这些更新被复制,你不应该使用这个选项。参见16.2.3节,“服务器如何判断复制过滤规则”。
如果你需要跨数据库的更新起效,使用–replicate-wild-ignore-table=db_name.%代替。参见16.2.3节,“服务器如何判断复制过滤规则”。
注意
该选项会像–binlog-ignore-db影响二进制日志记录一样影响复制日志,–replicate-ignore-db如何影响复制行为对复制日志格式的影响与–binlog-ignore-db的行为对日志格式的影响相同(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.)。
该选项不影响BEGIN,COMMIT或ROLLBACK语句。
Command-Line Format | –replicate-do-table=name | |
Option-File Format | replicate-do-table | |
Permitted Values | ||
Type | string |
告诉从机的SQL线程限制为复制指定的表(Tells the slave SQL thread to restrict replication to the specified table.)。要指定多个表,多次使用该选项,为每个表一次。与– replicate-do-db对比,它对跨数据库更新和默认数据库更新都有效。参见16.2.3节,“服务器如判断复制过滤规则”。
该选项只影响用于表的语句。它不会影响仅用于其它数据库对象的语句,例如存储过程。若要筛选操作存储程过程(operating on stored routines)的语句,使用一个或更多–replicate-*-db选项。
Command-Line Format | –replicate-ignore-table=name | |
Option-File Format | replicate-ignore-table | |
Permitted Values | ||
Type | string |
告诉从机的SQL线程不要复制更新指定表的任何语句,即使任何其它表可能被相同的语句更新。要指定多个表忽略,多次使用此选项,为每个表一次。相比于–replicate-ignore-db,它对跨数据库更新有效。参见16.2.3节,“服务器如何判断复制过滤规则”。
该选项只影响用于表的语句。它不会影响仅用于其它数据库对象的语句,例如存储过程。若要筛选操作存储程过程的语句,使用一个或更多–replicate-*-db选项。
Command-Line Format | –replicate-rewrite-db=old_name->new_name | |
Option-File Format | replicate-rewrite-db | |
Permitted Values | ||
Type | string |
告诉从机如果在主机上默认数据库(即,USE选择的那一个)是from_name则转换为to_name。只有涉及表的语句受影响(不包括类似CREATE DATABASE,DROP DATABASE和ALTER DATABASE语句),并且只有在主机上from_name是默认数据库时。这并不适用于跨数据库更新。要指定多个重写,多次使用该选项。服务器使用第一个from_name值匹配的。数据库名称转换在–replicate-*规则测试之前完成。
如果你在命令行中使用这个选项,且“>”字符对你的命令解释器而言是特殊的,把选项值括起来。例如:
shell> mysqld –replicate-rewrite-db=”olddb->newdb”
Command-Line Format | –replicate-same-server-id | |
Option-File Format | replicate-same-server-id | |
Permitted Values | ||
Type | boolean | |
Default | FALSE |
在从服务器上使用。通常你应该使用默认的设置0,以防止圆形复制所造成的无限循环。如果设置为1,从机不跳过有它自己的服务器ID的事件。通常,这只有在极少数的配置环境有用。如果使用了–log-slave-updates不能设置为1。默认情况下,如果二进制日志事件有从机的服务器ID,从机I / O线程不把它们写入到中继日志(这个优化有助于节省磁盘使用)。如果你想使用–replicate-same-server-id,请确认在你使从机读取它自己的事件,即你希望从机SQL线程执行的,之前,使用该选项启动从机(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)。
Command-Line Format | –replicate-wild-do-table=name | |
Option-File Format | replicate-wild-do-table | |
Permitted Values | ||
Type | string |
告诉从机线程限制为复制任何被更新的表的表名匹配指定的数据库和表名的模式的语句。(Tells the slave thread to restrict replication to statements where any of the updated tables match the specified database and table name patterns.)模式可以包含“%”和“_”通配符,它与LIKE模式匹配操作符(LIKE pattern-matching operator)具有相同的含义。要指定一个以上的表,请多次使用该选项,为每个表一次。这适用于跨数据库更新。参见16.2.3节,“服务器如何判断复制过滤规则”。
此选项适用于表,视图和触发器。它并不适用于存储过程和函数,或者事件。要过滤后者的对象上的操作语句,使用–replicate-*-db选项中的一个或多个。
示例:–replicate-wild-do-table=foo%.bar%只复制使用一个其数据库名以foo开头表名以bar开头的表的更新。
如果表名模式是%,它匹配任何表名称且该选项也适用于数据库级的语句(CREATE DATABASE,DROP DATABASE和ALTER DATABASE)。例如,如果你使用–replicate-wild-do-table=foo%.%,如果数据库名称相匹配foo%的模式,数据库级的语句被复制。
要在数据库或表名的模式包含文字通配符,用一个反斜杠转义它们。例如,要复制的是名为my_own%db的数据库中的所有表,但不复制my1ownAABCdb数据库中的表,你应该像这样转义“_”和“%”字符:–replicate-wild-do-table=my\_own\%db。如果你在命令行中使用该选项,依据你的命令解释器,你可能需要增加一倍的反斜杠或括起选项值。例如,在bash shell中,你将需要输入–replicate-wild-do-table=my\\_own\\%db。
Command-Line Format | –replicate-wild-ignore-table=name | |
Option-File Format | replicate-wild-ignore-table | |
Permitted Values | ||
Type | string |
告诉从机线程不复制任何表名匹配给定的通配符模式的语句。要指定一个以上的表被忽略,多次使用此选项,为每个表一次。它适用于跨数据库更新。参见第16.2.3节,“服务器如何判断复制过滤规则”。
例如:–replicate-wild-ignore-table=foo%.bar%不复制使用一个表,且其中数据库名以foo开头和表名以bar开头的更新。
关于匹配如何工作的信息,请参阅–replicate-wild-do-table选项的描述。选项的值中包含的文字通配符的规则与–replicate-wild-ignore-table是一样的。
Command-Line Format | –report-host=host_name | |
Option-File Format | report-host | |
Option Sets Variable | Yes, report_host | |
Variable Name | report-host | |
Variable Scope | Global | |
Dynamic Variable | No | |
Permitted Values | ||
Type | string |
在从机注册时被报告给主机的从机的主机名或IP地址。该值出现在主机上SHOW SLAVE HOSTS的输出中。如果你不希望从机向主机注册它自己,保留该值为未设置的状态。注意,主机简单地在从机连接后从TCP/ IP套接字读取从机的IP地址是不够的。由于NAT和其它路由方面的问题,该IP可能无法有效地从主机(master)或其它主机(host)连接。
Command-Line Format | –report-password=name | |
Option-File Format | report-password | |
Option Sets Variable | Yes, report_password | |
Variable Name | report-password | |
Variable Scope | Global | |
Dynamic Variable | No | |
Permitted Values | ||
Type | string |
在从机注册时被报告给主机的从机的账户密码。如果给定了–show-slave-auth-info选项,该值出现在主机上SHOW SLAVE HOSTS的输出中。
虽然这个选项的名称可能有所暗示,–report-password和MySQL的用户权限系统没有联系,因此它不必要和(甚至有可能是)MySQL的复制用户帐户的密码一样。
Command-Line Format | –report-port=# | |
Option-File Format | report-port | |
Option Sets Variable | Yes, report_port | |
Variable Name | report-port | |
Variable Scope | Global | |
Dynamic Variable | No | |
Permitted Values (>= 5.5.23) | ||
Type | numeric | |
Default | 0 |
在从机注册时被报告给主机的用于连接从机的TCP/IP端口号。只有从机上监听非默认端口,或者你有一个特殊的从主机或其它客户端到从机隧道时才设置它。如果你不确定,请不要使用此选项。
在MySQL5.5.23之前,该选项的默认值是3306。在MySQL5.5.23和更高版本中,显示的值是被从机实际使用的端口号(Bug#13333431)。这个改变也影响SHOW SLAVE HOSTS显示的默认值。
Command-Line Format | –report-user=name | |
Option-File Format | report-user | |
Option Sets Variable | Yes, report_user | |
Variable Name | report-user | |
Variable Scope | Global | |
Dynamic Variable | No | |
Permitted Values | ||
Type | string |
在从机注册时被报告给主机的从机的账户用户名。如果给定了–show-slave-auth-info选项,该值出现在主机上SHOW SLAVE HOSTS的输出中。
虽然这个选项的名称可能有所暗示,–report-user和MySQL的用户权限系统没有联系,因此它不必要和(甚至有可能是)MySQL的复制用户帐户的用户名一样。
Command-Line Format | –show-slave-auth-info | |
Option-File Format | show-slave-auth-info | |
Permitted Values | ||
Type | boolean | |
Default | FALSE |
在主机上SHOW SLAVE HOSTS的输出中为使用–report-user和–report-password选项启动的从机显示从机的用户名和密码。
Command-Line Format | –skip-slave-start | |
Option-File Format | skip-slave-start | |
Permitted Values | ||
Type | boolean | |
Default | FALSE |
告诉从机,在服务器启动时不启动从线程。要稍后启动线程,使用START SLAVE语句。
Command-Line Format | –slave_compressed_protocol | |
Option-File Format | slave_compressed_protocol | |
Option Sets Variable | ||
Variable Name | slave_compressed_protocol | |
Variable Scope | Global | |
Dynamic Variable | Yes | |
Permitted Values | ||
Type | boolean | |
Default | OFF |
如果该选项被设置为1,如果主机和从机都支持,为主/从通讯协议(slave/master protocol)使用压缩。默认值是0(不压缩)。
Command-Line Format | –slave-load-tmpdir=path | |
Option-File Format | slave-load-tmpdir | |
Option Sets Variable | Yes, slave_load_tmpdir | |
Variable Name | slave_load_tmpdir | |
Variable Scope | Global | |
Dynamic Variable | No | |
Permitted Values | ||
Type | file name | |
Default | /tmp |
从机创建临时文件的目录的名称。该选项在默认情况下,等于tmpdir系统变量的值。当从机的SQL线程复制LOAD DATA INFILE语句时,它从中继日志提取被加载的文件到临时文件,然后将它加载到表中。如果在主机上加载的文件是巨大的,从机上的临时文件也是巨大的。因此,使用这个选项告诉从机把临时文件放在某个位于有很多可用空间的文件系统的目录中可能是明智的做法。在这种情况下,中继日志也是巨大的,所以你可能也想使用–relay-log选项,将中继日志放在该文件系统。
该选项指定的目录应位于基于磁盘的文件系统(而不是基于内存的文件系统),因为用于复制LOAD DATA INFILE的临时文件必须在机器重新启动后依旧存在。该目录也不应该是一个由操作系统在系统启动过程中被清除的目录。
Command-Line Format | –slave-net-timeout=# | |
Option-File Format | slave-net-timeout | |
Option Sets Variable | Yes, slave_net_timeout | |
Variable Name | slave_net_timeout | |
Variable Scope | Global | |
Dynamic Variable | Yes | |
Permitted Values | ||
Type | numeric | |
Default | 3600 | |
Min Value | 1 |
在从机认为连接中断,中止读,并尝试重新连接之前等待来自主机的更多的数据的秒数。第一次重试在超时之后立即发生。重试之间的间隔由CHANGE MASTER TO语句的MASTER_CONNECT_RETRY选项控制,并且尝试重新连接的次数被–master-retry-count选项限制。默认值是3600秒(1小时)。
Command-Line Format | –slave-skip-errors=name | |
Option-File Format | slave-skip-errors | |
Option Sets Variable | Yes, slave_skip_errors | |
Variable Name | slave_skip_errors | |
Variable Scope | Global | |
Dynamic Variable | No | |
Permitted Values | ||
Type | string | |
Default | OFF | |
Valid Values | [list of error codes] all ddl_exist_errors |
通常情况下,从机上发生错误时复制停止。这给你机会来手动解决数据中的不一致。这个选项告诉从机的SQL线程,当语句返回任何选项值中列出的错误时继续复制。
除非你完全了解为什么你得到错误,不要使用该选项。如果在复制配置和客户端程序中没有错误,且MySQL本身没有错误,停止复制的错误永远不应该发生。不分青红皂白地使用该选项,导致从机变得无可救药地和主机不同步,并且你不知道为什么发生这种情况。
寻找错误代码,你应该使用从错误日志中和SHOW SLAVE STATUS的输出的错误信息中提供的号码。附录C:错误、错误代码及常见问题,列出了服务器错误代码。
您也可以(但不应该)使用非常不推荐的值all导致从机忽略所有的错误信息,不管发生什么都不断进行。不用说,如果你使用all,无法保证你的数据完整性。在这种情况下,如果从机的数据和主机上的数据没有任何相似之处请不要抱怨(或提交错误报告)。你已经被警告过了。
对于MySQL Cluster NDB7.2.6和更高版本中的MySQL Cluster复制,支持一个额外的速记值ddl_exists_errors,用于增强MySQL Cluster NDB7.2和更高版本实现的故障转移机制。这个值相当于错误代码列表1007,1008,4050,1051,1054,1060,1061,1068,1094,1146。该值仅被包含MySQL Cluster NDB7.2 发行版的mysqld支持。 (Bug#11762277,Bug#54854)更多信息,请参见第17.6.8节,“MySQL Cluster的复制故障转移实现”。
例子:
–slave-skip-errors=1062,1053
–slave-skip-errors=all
–slave-skip-errors=ddl_exist_errors
Command-Line Format | –init-slave=name | |
Option-File Format | init_slave | |
Option Sets Variable | Yes, init_slave | |
Variable Name | init_slave | |
Variable Scope | Global | |
Dynamic Variable | Yes | |
Permitted Values | ||
Type | string |
这个变量类似于init_connect,但是是从机SQL线程每次启动时要执行的字符串。字符串的格式与init_connect变量是相同的。
注意
SQL线程在执行init_slave之前发送确认到客户端。因此,不能保证START SLAVE返回时init_slave已经执行了。参见13.4.2.5节,“START SLAVE语法”,以获取更多信息。
Command-Line Format | –relay-log-index | |
Option-File Format | relay_log_index | |
Option Sets Variable | Yes, relay_log_index | |
Variable Name | relay_log_index | |
Variable Scope | Global | |
Dynamic Variable | No | |
Permitted Values | ||
Type | string | |
Default | *host_name*-relay-bin.index |
中继日志索引文件的名称。默认的名称是host_name-relay-bin.index,位于数据目录中,其中host_name是从机的名称。
Command-Line Format | –relay-log-info-file=file_name | |
Option-File Format | relay_log_info_file | |
Option Sets Variable | Yes, relay_log_info_file | |
Variable Name | relay_log_info_file | |
Variable Scope | Global | |
Dynamic Variable | No | |
Permitted Values | ||
Type | string | |
Default | relay-log. |
从机记录有关中继日志的信息的文件的名称。默认的名称是relay-log.info,位于数据目录中。
Command-Line Format | –relay-log-recovery | |
Option-File Format | relay_log_recovery | |
Option Sets Variable | Yes, relay_log_recovery | |
Variable Name | relay_log_recovery | |
Variable Scope | Global | |
Dynamic Variable | No | |
Permitted Values | ||
Type | boolean | |
Default | FALSE |
复制服务器启动后,立即启用自动中继日志恢复,这意味着复制从机丢弃所有未处理的中继日志并从复制主机获取。这应该在复制从机崩溃之后使用,以确保没有可能的已损坏的中继日志被处理。默认值是0(禁用)。这个全局变量可以动态改变,或者用–relay-log-recovery选项启动从机。
这个变量未使用,并在MySQL5.6中删除。
Command-Line Format | –slave_compressed_protocol | |
Option-File Format | slave_compressed_protocol | |
Option Sets Variable | ||
Variable Name | slave_compressed_protocol | |
Variable Scope | Global | |
Dynamic Variable | Yes | |
Permitted Values | ||
Type | boolean | |
Default | OFF |
如果从机和主机都支持,是否使用主/从通讯协议的压缩。
Command-Line Format | –slave-exec-mode=mode | |
Option-File Format | slave_exec_mode | |
Option Sets Variable | Yes, slave_exec_mode | |
Variable Name | slave_exec_mode | |
Variable Scope | Global | |
Dynamic Variable | Yes | |
Permitted Values | ||
Type | enumeration | |
Default | STRICT (ALL) | |
Default | IDEMPOTENT (NDB) | |
Valid Values | IDEMPOTENT STRICT |
控制复制冲突解决和错误检查采用的是IDEMPOTENT还是STRICT模式。IDEMPOTENT模式导致重复键和没找到键(no-key-found)的错误被抑制。这种模式可以用于多主复制,圆形的复制,以及其它一些特殊的复制方案。STRICT模式是默认值,并且它适用于大多数情况。
注意
MySQL Cluster忽略任何slave_exec_mode显式设置的值,并始终将其视为IDEMPOTENT。
Command-Line Format | –slave-load-tmpdir=path | |
Option-File Format | slave-load-tmpdir | |
Option Sets Variable | Yes, slave_load_tmpdir | |
Variable Name | slave_load_tmpdir | |
Variable Scope | Global | |
Dynamic Variable | No | |
Permitted Values | ||
Type | file name | |
Default | /tmp |
从机复制LOAD DATA INFILE语句时创建临时文件的目录的名称。
Command-Line Format | –slave-net-timeout=# | |
Option-File Format | slave-net-timeout | |
Option Sets Variable | Yes, slave_net_timeout | |
Variable Name | slave_net_timeout | |
Variable Scope | Global | |
Dynamic Variable | Yes | |
Permitted Values | ||
Type | numeric | |
Default | 3600 | |
Min Value | 1 |
中止读取之前等待来自主机/从机连接的更多数据的秒数。
Command-Line Format | –slave-skip-errors=name | |
Option-File Format | slave-skip-errors | |
Option Sets Variable | Yes, slave_skip_errors | |
Variable Name | slave_skip_errors | |
Variable Scope | Global | |
Dynamic Variable | No | |
Permitted Values | ||
Type | string | |
Default | OFF | |
Valid Values | [list of error codes] all ddl_exist_errors |
通常情况下,从机上发生错误时复制停止。这给你机会来手动解决数据中的不一致。这个变量告诉从机的SQL线程,当语句返回任何选项值中列出的错误时继续复制。
Command-Line Format | –slave_transaction_retries=# | |
Option-File Format | slave_transaction_retries | |
Option Sets Variable | ||
Variable Name | slave_transaction_retries | |
Variable Scope | Global | |
Dynamic Variable | Yes | |
Permitted Values | ||
Platform Bit Size | 32 | |
Type | numeric | |
Default | 10 | |
Range | 0 .. 4294967295 | |
Permitted Values | ||
Platform Bit Size | 64 | |
Type | numeric | |
Default | 10 | |
Range | 0 .. 18446744073709547520 |
如果复制从SQL线程因为InnoDB死锁或因为事务的执行时间超过InnoDB的innodb_lock_wait_timeout或NDBCLUSTER的TransactionDeadlockDetectionTimeout或TransactionInactiveTimeout而执行事务失败,在报错停止前(before stopping with an error),它会自动重试slave_transaction_retries次。默认值是10。
Version Introduced | 5.5.3 | |
Command-Line Format | –slave_type_conversions=set | |
Option-File Format | slave_type_conversions | |
Option Sets Variable | ||
Variable Name | slave_type_conversions | |
Variable Scope | Global | |
Dynamic Variable | No | |
Permitted Values | ||
Type | set | |
Default | ||
Valid Values | ALL_LOSSY ALL_NON_LOSSY ALL_LOSSY,ALL_NON_LOSSY |
控制使用基于行的复制时,在从机上生效的类型转换模式,也包括MySQL Cluster的复制。它的值是零个或多个以逗号分隔的以下列表中元素的集合:ALL_LOSSY,ALL_NON_LOSSY。设置这个变量为一个空字符串来禁止主机和从机之间的类型转换。更改需要重新启动从机以生效。
其他关于基于行的复制中的用于属性提升和降级的类型转换模式的信息,请参阅“基于行的复制:属性升级和降级。
此变量,在MySQL5.5.3中被添加。
Variable Name | sql_slave_skip_counter | |
Variable Scope | Global | |
Dynamic Variable | Yes | |
Permitted Values | ||
Type | numeric |
从机应该跳过的来自主机的事件数量。
重要
如果通过设置此变量指定的跳过事件数量会导致从机从事件组的中间开始,从机将继续跳过,直到它找到下一个事件的开始并从那一点开始。更多信息,参见13.4.2.4节,“SET GLOBAL sql_slave_skip_counter语法”。
Command-Line Format | –sync-master-info=# |
Option-File Format | sync_master_info |
Option Sets Variable | Yes, sync_master_info |
Variable Name | sync_master_info |
Variable Scope | Global |
Dynamic Variable | Yes |
如果这个变量的值大于0时,复制从机每sync_master_info事件后,同步它的master.info文件到硬盘上(使用fdatasync())。sync_relay_log_info的默认值是0(推荐在大多数情况下使用),MySQL服务器不会强制进行任何同步到磁盘;在这种情况下,和任何其他文件一样,服务器依赖于操作系统不时刷写master.info文件中的内容。
Command-Line Format | –sync-relay-log=# |
Option-File Format | sync_relay_log |
Option Sets Variable | Yes, sync_relay_log |
Variable Name | sync_relay_log |
Variable Scope | Global |
Dynamic Variable | Yes |
如果这个变量的值大于0,MySQL服务器每sync_relay_log次写入中继日志操作后同步中继日志到硬盘上(使用fdatasync())。如果启用了自动提交,每一个语句有一次写入到中继日志操作,否则,每个事务一次写操作。sync_relay_log的默认值是0,它不同步到磁盘——在这种情况下,和任何其它文件一样,服务器依赖于操作系统不时刷新中继日志的内容。值为1是最安全的选择,因为在发生崩溃时,你至多失去中继日志中的一个语句或事务。然而,它也是最慢的选择(除非磁盘有电池后备的高速缓存,它使得同步速度非常快)。
Command-Line Format | –sync-relay-log-info=# |
Option-File Format | sync_relay_log_info |
Option Sets Variable | Yes, sync_relay_log_info |
Variable Name | sync_relay_log_info |
Variable Scope | Global |
Dynamic Variable | Yes |
如果这个变量的值大于0,复制从机每sync_relay_log_info事务后同步它的relay-log.info文件到磁盘上(使用fdatasync())。 值为1通常是最好的选择。sync_relay_log_info的默认值是0,MySQL服务器不强制进行任何同步到磁盘——在这种情况下,任何其他文件一样,服务器依赖于操作系统不时刷写relay-log.info文件的内容。
Command-Line Format | –binlog-row-event-max-size=# |
Option-File Format | binlog-row-event-max-size |
指定一个基于行的二进制日志事件的最大大小(以字节为单位)。如果可能,行分组为小于这个尺寸的事件。该值应该是256的倍数。默认值是1024。参见16.1.2节,“复制格式”。
Command-Line Format | –log-bin | |
Option-File Format | log-bin | |
Variable Name | log_bin | |
Variable Scope | Global | |
Dynamic Variable | No | |
Permitted Values | ||
Type | file name | |
Default | OFF |
启用二进制日志。服务器记录所有改变数据的语句到二进制日志,它用于备份和复制。参见5.2.4节,“二进制日志”。
如果给定选项的值,那么它是日志序列的基本名称。服务器通过在基本名称后添加一个数字后缀顺序地创建二进制日志文件。建议您指定一个基本名称(原因参见第C.5.8节,“MySQL中已知的问题”)。否则,MySQL使用host_name-bin作为基本名称。
在MySQL5.5.20和更高版本中,当服务器读取索引文件中的条目时,它会检查条目是否包含相对路径,如果是,它的路径中的相对路径部分使用- – log-bin选项设置的绝对路径替换。绝对路径保持不变,在这种情况下,必须手动编辑索引以启用新路径或要使用的路径。在MySQL5.5.20之前,迁移二进制日志或中继日志文件时需要手动干预。 (Bug#11745230,Bug#12133)
设置该选项会导致log_bin系统变量设置为ON(1),而不是变为基本名称。这是一个已知的问题,更多信息,参见Bug#19614。
Command-Line Format | –log-bin-index=name | |
Option-File Format | log-bin-index | |
Permitted Values | ||
Type | file name | |
Default | OFF |
二进制日志文件名称的索引文件。参见5.2.4节,“二进制日志”。如果你省略了文件名,且你没有通过– log-bin指定一个,MySQL使用host_name-bin.index作为文件名。
Command-Line Format | –log-bin-trust-function-creators | |
Option-File Format | log-bin-trust-function-creators | |
Option Sets Variable | ||
Variable Name | log_bin_trust_function_creators | |
Variable Scope | Global | |
Dynamic Variable | Yes | |
Permitted Values | ||
Type | boolean | |
Default | FALSE |
此选项设置相应的log_bin_trust_function_creators系统变量。如果没有给出参数,该选项将变量设置为1。 log_bin_trust_function_creators影响MySQL如何实施对存储函数和触发器创建的限制。参见19.7节,“存储程序的二进制日志记录”。
Version Introduced | 5.5.15-ndb-7.2.1 | |
Command-Line Format | –log-bin-use-v1-row-events[={0|1}] | |
Option-File Format | log-bin-use-v1-row-events | |
Option Sets Variable | ||
Variable Name | log-bin-use-v1-row-events | |
Variable Scope | Global | |
Dynamic Variable | No | |
Permitted Values | ||
Type | boolean | |
Default | 1 | |
Permitted Values | ||
Type | boolean | |
Default | 1 | |
Permitted Values | ||
Type | boolean | |
Default | 0 |
从MySQL Cluster NDB7.2.1开始,默认使用第2版的二进制日志行事件;然而,第2版的事件不能被以前的MySQL Cluster发行版读取。设置–log-bin-use-v1-row-events为1导致mysqld使用版本1记录事件写入二进制日志,它是唯一的在以前的发行版中使用的二进制日志事件的版本,从而产生可以被旧的从机读取的二进制日志。
该选项所使用的值,可以从只读的系统变量log_bin_use_v1_row_events得到。
–log-bin-use-v1-row-events主要用于(–log-bin-use-v1-row-events is chiefly of interest when….)使用需要第2版的二进制日志行事件的NDB$ EPOCH_TRANS()作为冲突检测函数建立复制冲突检测与解决时。因此,这个选项和–ndb-log-transaction-id是不兼容的。
注意
在MySQL Cluster NDB7.0.27和MySQL Cluster NDB7.1.6和更高版本的MySQL Cluster NDB7.0和7.1发行版中,第2版的二进制日志行事件也是可用的。然而,在MySQL Cluster NDB7.2.1之前,版本1的事件是默认的(所以在这些版本中该选项的默认值是1)。规划升级使用MySQL Cluster复制的环境时,你应该记住它。
主干MySQL Server 5.5发行版本不支持–log-bin-use-v1-row-events。
要了解更多信息,参见第17.6.11节,“MySQL Cluster复制冲突的解决”。
Command-Line Format | –log-short-format | |
Option-File Format | log-short-format | |
Permitted Values | ||
Type | boolean | |
Default | FALSE |
如果它被激活,记录较少的信息到二进制日志和慢查询日志。
Command-Line Format | –binlog-do-db=name | |
Option-File Format | binlog-do-db | |
Permitted Values | ||
Type | string |
该选项会以–replicate-do-db影响复制的类似方式影响二进制日志。
该选项的影响取决于在使用基于语句的还是基于行的记录格式,与–replicate-do-db的影响取决于在使用基于语句还是基于行的复制一样。你应该记住,用来记录指定语句的格式不一定与binlog_format的值所表示的是一样的。例如,DDL语句,例如CREATE TABLE和ALTER TABLE,不考虑当前有效的记录格式,始终以语句的方式记录,所以下面的–binlog-do-db的基于语句的规则总是适用于确定语句是否被记录下来。
基于语句的记录:只有那些默认数据库(也就是USE选择的那个)是db_name的语句被写入二进制日志。要指定一个以上的数据库,多次使用此选项,为每个数据库一次;然而,这样做并不会导致选择不同的数据库(或无数据库)被选中时跨数据库的语句,例如UPDATE some_db.some_table SET foo =’bar’被记录。
警告
要指定多个数据库,你必须使用这个选项的多个实例。如果你提供了一个逗号分隔的列表,由于数据库名称可以包含逗号,该列表将被视为一个单一的数据库的名称。
使用基于语句的记录时一个不像你可能期望的那样运行例子:如果服务器用–binlog-do-db=sales选项启动,并且你发出下面的语句,UPDATE语句没有被记录:
USE prices;
UPDATE sales.january SET amount=amount+1000;
这种“只检查默认数据库”行为主要的原因是只从语句很难知道它是否应该被复制(例如,如果您使用跨多个数据库的多表DELETE语句或多表UPDATE语句)。如果没有必要,只检查默认数据库,而不是所有的数据库,也更快。
另一种可能不是不言自明的情况发生于,尽管设置选项时没有指定一个给定的数据库,但它被复制。如果服务器用–binlog-do-db=sales选项启动,尽管设置–binlog-do-db时不包括prices,下面的UPDATE语句被记录:
USE sales;
UPDATE prices.discounts SET percentage = percentage + 10;
因为发出UPDATE语句时sales是默认的数据库,于是更新被记录了。
基于行的记录:日志记录被限制在(Logging is restricted to)数据库db_name上。只有对属于DB_NAME的表的修改被记录;默认的数据库在这种情况下没有影响。假定服务器用–binlog-do-db=sales选项启动并且基于行的记录正在起效,然后下面的语句被执行:
USE prices;
UPDATE sales.february SET amount=amount+100;
按照UPDATE语句对在sales数据库中february表的修改被记录;不管是否发出USE语句这种情况均发生。然而,当使用基于行的记录格式与–binlog-do-db=sales,下面的UPDATE所做的更改不记录:
USE prices;
UPDATE prices.march SET amount=amount-25;
即使USE prices语句改为USE sales,UPDATE语句的影响依旧不被写入到二进制日志中。
另一个–binlog-do-db为基于语句的记录的处理,相对于基于行的记录的重要区别发生与涉及多个数据库的语句。假定服务器用–binlog-do-db=db1启动,并且下面的语句被执行:
USE db1;
UPDATE db1.table1 SET col1 = 10, db2.table2 SET col2 = 20;
如果你使用的是基于语句的记录,这两个表的更新被写入到二进制日志中。然而,当使用基于行的格式记录时,只有对table1的修改被记录;table2在不同的数据库,所以它不被UPDATE改变(so it is not changed by the UPDATE)。现在假设,USE db4语句被使用,而不是USE db1语句:
USE db4;
UPDATE db1.table1 SET col1 = 10, db2.table2 SET col2 = 20;
在这种情况下,当使用基于语句的记录时, UPDATE语句不被写入二进制日志中。然而,当使用基于行的记录时,对table1的修改被记录,但不包括table2——换句话说,只有对–binlog-do-db指定名称的数据库中的表的修改被记录,默认数据库的选择对该行为没有影响。
Command-Line Format | –binlog-ignore-db=name | |
Option-File Format | binlog-ignore-db | |
Permitted Values | ||
Type | string |
该选项以类似于–replicate-ignore-db影响复制的方式影响二进制日志的记录。
该选项的影响取决于正在使用基于语句的还是基于行的记录格式,与–replicate-ignore-db的影响取决于正在使用基于语句还是基于行的复制一样。你应该记住,用来记录指定语句的格式不一定与binlog_format的值所指示的一样。例如, DDL语句,例如CREATE TABLE和ALTER TABLE,不考虑正在起效的记录格式,始终记录为语句,所以下面–binlog-ignore-db的基于语句的规则总是适用于确定该语句是否应该被记录下来。
基于语句的记录:告诉服务器不要记录默认数据库(也就是USE选择的那个)是db_name的语句。
基于行的格式:告诉服务器不记录对在数据库db_name中的任何表的更新。当前的数据库对此没有影响。
当使用基于语句的记录时,下面的例子不像你可能期望的那样运行。假设服务器用–binlog-ignore-db=sales选项启动,并且你发出下面的语句:
USE prices;
UPDATE sales.january SET amount=amount+1000;
在这种情况下,因为–binlog-ignore-db仅适用于默认数据库(由USE语句决定),UPDATE语句被记录。因为sales数据库是在语句中明确地指定的,所以该语句没有被过滤。然而,当使用基于行的记录时,UPDATE语句的影响不写入二进制日志,这意味着没有对sales.january表的改变被记录;在这种情况下,–binlog-ignore-db=sales导致所有对主机上的sales数据库的副本的表所做的更改在二进制日志记录中被忽略。
要指定一个以上的数据库忽略,多次使用该选项,为每个数据库一次。如果你提供了一个逗号分隔的列表,因为数据库名称可以包含逗号,该列表将被视为一个单一的数据库的名称。
如果你使用跨库更新,并且你不希望这些更新被记录,你不应该使用这个选项。
Command-Line Format | –max-binlog-dump-events=# | |
Option-File Format | max-binlog-dump-events | |
Permitted Values | ||
Type | numeric | |
Default | 0 |
该选项被MySQL测试套件内部使用,用于测试和调试复制。
Command-Line Format | –sporadic-binlog-dump-fail | |
Option-File Format | sporadic-binlog-dump-fail | |
Permitted Values | ||
Type | boolean | |
Default | FALSE |
该选项被MySQL测试套件内部使用,用于测试和调试复制。
Command-Line Format | –binlog_cache_size=# | |
Option-File Format | binlog_cache_size | |
Option Sets Variable | Yes, binlog_cache_size | |
Variable Name | binlog_cache_size | |
Variable Scope | Global | |
Dynamic Variable | Yes | |
Permitted Values | ||
Platform Bit Size | 32 | |
Type | numeric | |
Default | 32768 | |
Range | 4096 .. 4294967295 | |
Permitted Values | ||
Platform Bit Size | 64 | |
Type | numeric | |
Default | 32768 | |
Range | 4096 .. 18446744073709547520 |
在一个事务中暂存对二进制日志的更改的缓存大小。如果服务器支持任何事务性存储引擎并且服务器启用了二进制日志(– log-bin选项),给每个客户端分配一个二进制日志高速缓存。如果你经常使用的大事务,你可以增加这个缓存的大小,以获得更好的性能。Binlog_cache_use和Binlog_cache_disk_use状态变量对调整这个变量的大小可能是有用的。参见5.2.4节,“二进制日志”。
在MySQL5.5.3中,一个单独的二进制日志高速缓存(二进制日志语句高速缓存)为非事务性语句被引入,在MySQL5.5.3到5.5.8中,该变量设置这两个高速缓存的大小。这意味着,在这些MySQL版本中,这些缓存的总内存使用是binlog_cache_size设置的值两倍。
从MySQL5.5.9开始,binlog_cache_size只设置事务缓存的大小,语句高速缓存的大小由binlog_stmt_cache_size系统变量管理。
Version Introduced | 5.5.2 | |
Command-Line Format | –binlog_direct_non_transactional_updates[=value] | |
Option-File Format | binlog_direct_non_transactional_updates | |
Option Sets Variable | ||
Variable Name | binlog_direct_non_transactional_updates | |
Variable Scope | Global, Session | |
Dynamic Variable | Yes | |
Permitted Values | ||
Type | boolean | |
Default | OFF |
由于并发的问题,当一个事务同时包含对事务性和非事务性表的更新,从机可能会变得不一致。 MySQL会尝试通过将非事务性语句写入到事务缓存来保存这些语句中的因果关系,该缓存在提交时刷写。然而,属于一个事务的对非事务性表的修改立即被其它连接可见,由于这些变化可能不会立即写入到二进制日志中,这时,问题出现了。
从MySQL5.5.2开始,binlog_direct_non_transactional_updates变量为这个问题提供了一个可能的解决方法。默认情况下,这个变量是禁用的。启用binlog_direct_non_transactional_updates导致对非事务性表的更新直接被写入到二进制日志中,而不是事务缓存。
binlog_direct_non_transactional_updates仅适用于使用基于语句的二进制日志记录格式复制的语句;也就是说,只有当binlog_format的值为STATEMENT时,或当binlog_format是MIXED且一个给定的语句使用基于语句的格式被复制时,它是有效的。二进制日志的格式是ROW时,或者是binlog_format设置为MIXED且一个给定的语句使用基于行的格式复制时,这个变量没有效果。
重要
启用此变量之前,你必须确认的是,事务性和非事务性表之间没有依赖;一个这样的依赖的例子是语句INSERT INTO myisam_table SELECT * FROM innodb_table。否则,这样的语句可能会导致从机偏离主机。
从MySQL5.5.5开始,二进制日志的格式是ROW或MIXED时,这个变量没有效果。 (Bug#51291)
Command-Line Format | –binlog-format=format | |
Option-File Format | binlog-format=format | |
Option Sets Variable | Yes, binlog_format | |
Variable Name | binlog_format | |
Variable Scope | Global, Session | |
Dynamic Variable | Yes | |
Permitted Values | ||
Type | enumeration | |
Default | STATEMENT | |
Valid Values | ROW STATEMENT MIXED |
该变量设置二进制日志的记录格式,可以是STATEMENT,ROW,或MIXED中的任何一个。参见16.1.2节,“复制格式”。 binlog_format在启动时由–binlog-format选项设置,或在运行时由binlog_format系统变量设置。
注意
虽然你可以在运行时更改日志记录格式,但是不建议你在复制正在进行中时改变它。这部分是由于以下事实:从机不遵从主机的binlog_format设置;一个给定的MySQL服务器,只可以改变自己的日志格式。
在MySQL 5.5中(包括MySQL Cluster NDB 7.2.1及以后版本),默认的格式为STATEMENT。
你必须具有SUPER权限来设置全局或会话的binlog_format值。
管理更改此变量生效的时刻和效果持续多久时间的规则,与其它MySQL服务器系统变量是相同的。参见13.7.4节,“SET语法”,以获取更多信息。
指定MIXED时,除了只有基于行的复制是保证得到正确的结果的情况,使用基于语句的复制。例如,这种情况发生于,当语句包含用户定义函数(UDF)或UUID()函数时。这个规则的一个例外是,MIXED始终为存储函数和触发器使用基于行的复制。
也有例外情况,此时你不能在运行时切换复制格式:
■来自存储函数或触发器中。
■如果会话当前是基于行的复制模式,且有打开的临时表。
■自MySQL 5.5.3开始,在一个事务中。 (Bug#47863)
在这些情况下试图切换格式,结果导致报错。
注意
在MySQL Cluster NDB 7.2.1之前,当NDBCLUSTER存储引擎是启用的时,也不可能在运行时改变二进制日志记录的格式。在MySQL Cluster NDB 7.2.1或更高版本,这个限制去掉了。
二进制日志的格式会影响以下服务器选项的行为:
■–replicate-do-db
■–replicate-ignore-db
■–binlog-do-db
■–binlog-ignore-db
这些影响在各个选项的描述中详细讨论了。
Version Introduced | 5.5.9 | |
Command-Line Format | –binlog_stmt_cache_size=# | |
Option-File Format | binlog_stmt_cache_size | |
Option Sets Variable | ||
Variable Name | binlog_stmt_cache_size | |
Variable Scope | Global | |
Dynamic Variable | Yes | |
Permitted Values | ||
Platform Bit Size | 32 | |
Type | numeric | |
Default | 32768 | |
Range | 4096 .. 4294967295 | |
Permitted Values | ||
Platform Bit Size | 64 | |
Type | numeric | |
Default | 32768 | |
Range | 4096 .. 18446744073709547520 |
从MySQL5.5.9开始,这个变量决定了二进制日志用来保存在一个事务期间发出的非事务性语句的缓存的大小。在MySQL5.5.3和之后,如果服务器支持任何事务性存储引擎,且服务器启用了二进制日志(– log-bin选项),每个客户端分配单独的二进制日志事务和语句高速缓存。如果你经常在事务过程中使用大非事务性语句,你可以增加这个高速缓存的大小,以获得更高的性能。Binlog_stmt_cache_use和Binlog_stmt_cache_disk_use状态变量,对调整这个变量的大小可能是有用的。参见5.2.4节,“二进制日志”。
在MySQL5.5.3到5.5.8中,两个高速缓存的大小都使用binlog_cache_size的设置。这意味着,在这些MySQL版本中,这些缓存使用的总内存是binlog_cache_size设置的值的两倍。从MySQL5.5.9开始,binlog_cache_size只设置事务缓存的大小。
Version Introduced | 5.5.15-ndb-7.2.1 | |
Command-Line Format | –log-bin-use-v1-row-events[={0|1}] | |
Option-File Format | log_bin_use_v1_row_events | |
Option Sets Variable | ||
Variable Name | log_bin_use_v1_row_events | |
Variable Scope | Global | |
Dynamic Variable | No | |
Permitted Values | ||
Type | boolean | |
Default | 1 | |
Permitted Values | ||
Type | boolean | |
Default | 1 | |
Permitted Values | ||
Type | boolean | |
Default | 0 |
显示从MySQL Cluster NDB7.2.1开始可用的第2版二进制日志记录方式是否在使用。值为1表明服务器使用版本1的事件记录方式(在以前的版本中使用的二进制日志事件的唯一版本)写入二进制日志,从而产生一个可以被旧的从机读取的二进制日志。 0表示在使用第2版的二进制事件日志方式。
这个变量是只读的。要在二进制日志的版本1和版本2二进制事件之间进行切换,须要使用–log-bin-use-v1-row-events选项重新启动mysqld。
除了MySQL Claster复制执行升级时,–log-bin-use-v1-row-events主要用于(–log-bin-use-v1-row-events is chiefly of interest when….)使用需要第2版的二进制日志行事件的NDB$ EPOCH_TRANS()作为冲突检测函数建立复制冲突检测与解决时。因此,这个选项和–ndb-log-transaction-id是不兼容的。
注意
MySQL Cluster NDB7.2.1和更高版本中默认使用第2版的二进制日志行事件(所以在这些版本中这个变量的的默认值变化为0)。规划升级使用MySQL Cluster复制的环境时,你应该记住它。
主干MySQL Server 5.5发行版本不支持这个变量。
要了解更多信息,参见第17.6.11节,“MySQL Cluster复制冲突的解决”。
Command-Line Format | –max_binlog_cache_size=# | |
Option-File Format | max_binlog_cache_size | |
Option Sets Variable | ||
Variable Name | max_binlog_cache_size | |
Variable Scope | Global | |
Dynamic Variable | Yes | |
Permitted Values | ||
Type | numeric | |
Default | 18446744073709547520 | |
Range | 4096 .. 18446744073709547520 |
如果一个事务需要比这个数量更多字节的内存,服务器产生一个Multi-statement transaction required more than ‘max_binlog_cache_size’ bytes of storage错误。最小值是4096。最大值和默认值在32位平台上是4GB,在64位平台上是16EB(艾字节)。
注意
在MySQL5.5.28之前,64位的Windows平台截断这个变量存储的值到4G,即使当它被设置为更大的值时(Bug#13961678)。
在MySQL5.5.3中,为非事务性语句引入了一个单独的二进制日志高速缓存(二进制日志语句高速缓存),并且在MySQL5.5.3到5.5.8,该变量设置这两个高速缓存的上限。这意味着,在这些MySQL版本中,这些缓存的有效的最大值是max_binlog_cache_size所设置的值的两倍。
从MySQL5.5.9开始,max_binlog_cache_size只设置事务高速缓存的大小,语句高速缓存的上限是由max_binlog_stmt_cache_size系统变量管理。
也是从MySQL5.5.9开始,max_binlog_cache_size系统变量的会话可见性匹配binlog_cache_size系统变量的:在MySQL5.5.8和更早的版本中,对max_binlog_cache_size的改变立即生效,在MySQL5.5.9和更高版本,对max_binlog_cache_size的改变只对更改该值后开始的新的会话生效。
Command-Line Format | –max_binlog_size=# | |
Option-File Format | max_binlog_size | |
Option Sets Variable | Yes, max_binlog_size | |
Variable Name | max_binlog_size | |
Variable Scope | Global | |
Dynamic Variable | Yes | |
Permitted Values | ||
Type | numeric | |
Default | 1073741824 | |
Range | 4096 .. 1073741824 |
如果一次对二进制日志的写入导致当前日志文件的大小超过了这个变量的值,服务器将切换二进制日志(关闭当前文件并打开下一个)。最小值是4096字节。最大值和默认值是1GB。
一个事务写入到二进制日志的一块中,所以它永远不会分割到数个二进制日志之间。因此,如果你有大的事务,你可能会看到二进制日志文件大于max_binlog_size。
如果max_relay_log_size是0, max_binlog_size的值也适用于中继日志。
Version Introduced | 5.5.9 | |
Command-Line Format | –max_binlog_stmt_cache_size=# | |
Option-File Format | max_binlog_stmt_cache_size | |
Option Sets Variable | ||
Variable Name | max_binlog_stmt_cache_size | |
Variable Scope | Global | |
Dynamic Variable | Yes | |
Permitted Values | ||
Type | numeric | |
Default | 18446744073709547520 | |
Range | 4096 .. 18446744073709547520 |
如果一个事务中的非事务语句需要比这个数量更多字节的内存,服务器产生一个错误。最小值是4096。最大值和默认值在32位平台上是4GB,在64位平台上是16EB(艾字节)。
注意
在MySQL5.5.28之前,64位的Windows平台截断这个变量存储的值到4G,即使当它被设置为更大的值时(Bug#13961678)。
在MySQL5.5.3中,为非事务性语句引入了一个单独的二进制日志高速缓存(二进制日志语句高速缓存),并且在MySQL5.5.3到5.5.8,该变量(此处怀疑原文档有误)设置这两个高速缓存的上限。这意味着,在这些MySQL版本中,这些缓存的有效的最大值是max_binlog_cache_size所设置的值的两倍。
从MySQL5.5.9开始,max_binlog_stmt_cache_size只设置语句高速缓存的大小,事务高速缓存的上限是由max_binlog _cache_size系统变量单独管理。
Command-Line Format | –sync-binlog=# | |
Option-File Format | sync_binlog | |
Option Sets Variable | Yes, sync_binlog | |
Variable Name | sync_binlog | |
Variable Scope | Global | |
Dynamic Variable | Yes | |
Permitted Values | ||
Platform Bit Size | 32 | |
Type | numeric | |
Default | 0 | |
Range | 0 .. 4294967295 | |
Permitted Values | ||
Platform Bit Size | 64 | |
Type | numeric | |
Default | 0 | |
Range | 0 .. 18446744073709547520 |
如果这个变量的值大于0,MySQL服务器每sync_binlog次写入操作到二进制日志后同步二进制日志到磁盘(使用fdatasync())。如果启用了自动提交,每条语句一次写入操作到二进制日志,否则每个事务一次写操作。sync_binlog的默认值是0,这表示不同步到磁盘,在这种情况下,和其它文件一样,服务器依赖于操作系统不时刷写二进制日志的内容。值为1是最安全的选择,因为在发生崩溃时,你至多自二进制日志中丢失一个语句或事务。然而,它也是最慢的选择(除非磁盘有电池后备的高速缓存,它使得同步非常快)。