MySQL 版本 5.5.14
根据文档默认情况下，slave 会不是将从主服务器收到的任何更新记录到其二进制日志中。
以下是我在从属设备上的配置：
# egrep 'bin|slave' /etc/my.cnf
relay-log=mysqld-relay-bin
log-bin = /var/log/mysql/mysql-bin
binlog-format=MIXED
sync_binlog = 1
log-bin-trust-function-creators = 1
mysql> show global variables like 'log_slave%';
+-------------------+-------+
| Variable_name | Value |
+-------------------+-------+
| log_slave_updates | OFF |
+-------------------+-------+
1 row in set (0.01 sec)
mysql> select @@log_slave_updates;
+---------------------+
| @@log_slave_updates |
+---------------------+
| 0 |
+---------------------+
1 row in set (0.00 sec)
但从属服务器仍然将一些更改记录到它的二进制日志中，让我们看看文件大小：
-rw-rw---- 1 mysql mysql 37M Apr 1 01:00 /var/log/mysql/mysql-bin.001256
-rw-rw---- 1 mysql mysql 25M Apr 2 01:00 /var/log/mysql/mysql-bin.001257
-rw-rw---- 1 mysql mysql 46M Apr 3 01:00 /var/log/mysql/mysql-bin.001258
-rw-rw---- 1 mysql mysql 115M Apr 4 01:00 /var/log/mysql/mysql-bin.001259
-rw-rw---- 1 mysql mysql 105M Apr 4 18:54 /var/log/mysql/mysql-bin.001260
以及使用以下方式读取这些二进制文件时的示例查询mysqlbinlog公用事业：
#120404 19:08:57 server id 3 end_log_pos 110324763 Query thread_id=382435 exec_time=0 error_code=0
SET TIMESTAMP=1333541337/*!*/;
INSERT INTO norep_SplitValues VALUES ( NAME_CONST('cur_string',_utf8'118212' COLLATE 'utf8_general_ci'))
/*!*/;
# at 110324763
我错过了什么？
回复@RolandoMySQLDBA：
如果复制带来了这一点，那么相同的查询必须存在于中继日志中。请查找具有相同 TIMESTAMP (1333541337) 的 INSERT 查询的中继日志。
中继日志中不存在具有相同 TIMESTAMP 的查询。
如果在中继日志中找不到，则查看 Infobright 是否正在发布 INSERT 查询。在这种情况下，INSERT 应该记录在从属服务器的二进制日志中。
更深入地探讨二进制日志，我看到几乎所有的查询都是 CREATE/INSERT/UPDATE/DROP“临时”表，如下所示：
# at 123873315
#120405 0:42:04 server id 3 end_log_pos 123873618 Query thread_id=395373 exec_time=0 error_code=0
SET TIMESTAMP=1333561324/*!*/;
SET @@session.pseudo_thread_id=395373/*!*/;
CREATE TEMPORARY TABLE `norep_tmpcampaign` (
`campaignid` INTEGER(11) NOT NULL DEFAULT '0' ,
`status` INTEGER(11) NOT NULL DEFAULT '0' ,
`updated` DATETIME,
KEY `campaignid` (`campaignid`)
)ENGINE=MEMORY
/*!*/;
# at 123873618
#120405 0:42:04 server id 3 end_log_pos 123873755 Query thread_id=395373 exec_time=0 error_code=0
SET TIMESTAMP=1333561324/*!*/;
DROP TABLE IF EXISTS `norep_tmpcampaign1` /* generated by server */
这里的“临时”是指计算完成后删除它们。我还告诉从属服务器不要复制任何与norep_通配符模式匹配的语句：
replicate-wild-ignore-table=%.norep_%
但是二进制日志中有一个异常表：
# at 123828094
#120405 0:37:21 server id 3 end_log_pos 123828495 Query thread_id=395209 exec_time=0 error_code=0
SET TIMESTAMP=1333561041/*!*/;
INSERT INTO sessions (SessionId, ApplicationName, Created, Expires, LockDate, LockId, Timeout, Locked, SessionItems, Fla
gs) Values('pgv2exo4y4vo4ccz44vwznu0', '/', '2012-04-05 00:37:21', '2012-04-05 00:57:21', '2012-04-05 00:37:21', 0, 20,
0, 'AwAAAP////8IdXNlcm5hbWUGdXNlcmlkCHBlcm1pdGlkAgAAAAQAAAAGAAAAAQABAAEA', 0)
/*!*/;
描述：
mysql> desc reportingdb.sessions;
+-----------------+------------------+------+-----+---------------------+-------+
| Field | Type | Null | Key | Default | Extra |
+-----------------+------------------+------+-----+---------------------+-------+
| SessionId | varchar(64) | NO | PRI | | |
| ApplicationName | varchar(255) | NO | | | |
| Created | timestamp | NO | | 0000-00-00 00:00:00 | |
| Expires | timestamp | NO | | 0000-00-00 00:00:00 | |
| LockDate | timestamp | NO | | 0000-00-00 00:00:00 | |
| LockId | int(11) unsigned | NO | | NULL | |
| Timeout | int(11) unsigned | NO | | NULL | |
| Locked | bit(1) | NO | | NULL | |
| SessionItems | varchar(255) | YES | | NULL | |
| Flags | int(11) | NO | | NULL | |
+-----------------+------------------+------+-----+---------------------+-------+
我确信所有这些查询都是由 MySQL 发布的，不是 Infobright：
$ mysql-ib -u root -p
Enter password:
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 48971
Server version: 5.1.40 build number (revision)=IB_4.0.5_r15240_15370(ice) (static)
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
mysql> select * from information_schema.tables where table_name='sessions';
Empty set (0.02 sec)
我一直在尝试在主服务器上对测试表进行一些 INSERT/UPDATE 查询，它被复制到中继日志，而不是从属设备上的二进制日志：
# at 311664029
#120405 0:15:23 server id 1 end_log_pos 311664006 Query thread_id=10458250 exec_time=0 error_code=0
use testuser/*!*/;
SET TIMESTAMP=1333559723/*!*/;
update users set email2='[email protected]' where id=22
/*!*/;
注意server id中继日志中，服务器 ID 是 master（1），并且在二进制日志，服务器 ID 是从属的（在本例中为 3）。
回复@RolandoMySQLDBA: 2012 年 4 月 5 日星期四 10:06:00 ICT
CREATE DATABASE quantatest;请立即在主服务器上运行CREATE DATABASE quantatest;。如果在从服务器的二进制日志中显示，请告诉我。
正如我上面所说的：
我一直在尝试在主服务器上对测试表进行一些 INSERT/UPDATE 查询，它被复制到中继日志，不是二进制日志
您可以猜测，IO 线程将其复制到中继日志，而不是二进制日志。
#120405 10:07:25 server id 1 end_log_pos 347573819 Query thread_id=10480775 exec_time=0 error_code=0
SET TIMESTAMP=1333595245/*!*/;
/*!\C latin1 *//*!*/;
SET @@session.character_set_client=8,@@session.collation_connection=8,@@session.collation_server=8/*!*/;
create database quantatest
/*!*/;
问题可能必须改为：为什么禁用后，某些更新查询仍然会记录到从属二进制日志中--log-slave-updates？它们来自哪里？
最后几点如下：
/*!*/;
# at 27492197
#120405 10:12:45 server id 3 end_log_pos 27492370 Query thread_id=410353 exec_time=0 error_code=0
SET TIMESTAMP=1333595565/*!*/;
CREATE TEMPORARY TABLE norep_SplitValues (
value VARCHAR(1000) NOT NULL
) ENGINE=MEMORY
/*!*/;
# at 27492370
#120405 10:12:45 server id 3 end_log_pos 27492445 Query thread_id=410353 exec_time=0 error_code=0
SET TIMESTAMP=1333595565/*!*/;
BEGIN
/*!*/;
# at 27492445
#120405 10:12:45 server id 3 end_log_pos 27492619 Query thread_id=410353 exec_time=0 error_code=0
SET TIMESTAMP=1333595565/*!*/;
INSERT INTO norep_SplitValues VALUES ( NAME_CONST('cur_string',_utf8'119577' COLLATE 'utf8_general_ci'))
/*!*/;
# at 27492619
#120405 10:12:45 server id 3 end_log_pos 27492695 Query thread_id=410353 exec_time=0 error_code=0
SET TIMESTAMP=1333595565/*!*/;
COMMIT
/*!*/;
# at 27492918
#120405 10:12:46 server id 3 end_log_pos 27493115 Query thread_id=410353 exec_time=0 error_code=0
SET TIMESTAMP=1333595566/*!*/;
SELECT `reportingdb`.`selfserving_get_locationad`(_utf8'3' COLLATE 'utf8_general_ci',_utf8'' COLLATE 'utf8_general_ci')
/*!*/;
# at 27493199
#120405 10:12:46 server id 3 end_log_pos 27493353 Query thread_id=410353 exec_time=0 error_code=0
SET TIMESTAMP=1333595566/*!*/;
/*!\C utf8 *//*!*/;
SET @@session.character_set_client=33,@@session.collation_connection=33,@@session.collation_server=8/*!*/;
DROP TEMPORARY TABLE IF EXISTS `norep_SplitValues` /* generated by server */
/*!*/;
答案1
对我来说，server-id 值显示一切正常。
每个语句都与该语句所源自的服务器的 server-id 相关联（这就是 mysql 服务器知道不要从自身复制语句的方式，除非您使用特定设置）。即使通过复制，此关联也会保留。
您可以看到，主服务器（服务器 ID 1）中的语句仅被复制、存储在中继日志中，然后在从服务器上执行，而不会写入从服务器二进制日志。您看到的与服务器 ID 3（从服务器）相关的语句必须在从服务器数据库上本地执行。这就是它们被写入二进制日志的原因。log-slave-updates 不会排除本地写入的查询。
您应该查看从属数据库上的流量：一定有东西正在连接并执行这些查询。如果您在进程列表中看不到任何内容（没有持久连接），您可以尝试打开常规日志或使用 tcpdump 等捕获 mysql 流量。
另外：您说您希望从属服务器上的 binlog 用于增量备份。如果您有意从从属 binlog 中排除复制流量，这听起来似乎您实际上无法使用这些 binlog 进行时间点备份/恢复。您将丢失所有复制流量。所以也许您毕竟应该使用 log-slave-updates？不确定。
-担
答案2
在你的问题中，你说 Slave 上的二进制日志有
#120404 19:08:57 server id 3 end_log_pos 110324763 Query thread_id=382435 exec_time=0 error_code=0
SET TIMESTAMP=1333541337/*!*/;
INSERT INTO norep_SplitValues VALUES ( NAME_CONST('cur_string',_utf8'118212' COLLATE 'utf8_general_ci'))
/*!*/;
# at 110324763
如果复制带来了这一点，那么相同的查询必须存在于中继日志中。请查找具有相同 TIMESTAMP (1333541337) 的 INSERT 查询的中继日志。
如果在中继日志中找不到，则查看 Infobright 是否正在发布 INSERT 查询。在这种情况下，INSERT 应该记录在从属服务器的二进制日志中。
更新时间 2012-04-04 14:49 EDT
这是一个实验。在 Master 上运行以下查询：
CREATE DATABASE quantatest;
该语句在主服务器上执行后必须进入从服务器上的中继日志正常情况下，该语句不应该出现在已经禁用的Slave的二进制日志中log-slave-updates。
根据您的问题，如果您已log-slave-updates禁用，您说这个查询将出现在 Slave 的二进制日志中。
CREATE DATABASE quantatest;请立即在主服务器上运行CREATE DATABASE quantatest;。如果在从服务器的二进制日志中显示，请告诉我。