在复制的主机器上是否可以忽略其他不需要增量日志的表

Question

当前高并发复制环境  master机器---slave机器mysql linux之前库不大,数据量不太大.但过几年后,表达400张,数据量巨大.
以前master机器的my.cnf
log-bin = /var/log/mysql/bin.log
binlog-do-db=adb
发现他的增量日志实在过大.因为从机器已经修改为表级别的从机器复制.
现在思考我能否在master机器的my.cnf的那2行配置下面加上
replicate-ignore-table= 其他300多张表. 这样主机器的增量
日志会减少些 .不至于每天20多g. (请注意是 在 复制的主机器上忽略其他不需要增量日志的表
)  

Answer 1

master 不支持 replicate-ignore-table
他只支持:
binlog-do-db
binlog-ignore-db
这2个选项;

Answer 2

楼主可以show master  status(在主上)或show slave status (在从上)可以看到这些参数,就知道为什么了

Answer 3

mysql只支持库级别的忽略。

Answer 4

感谢楼上大力支持.还有一个问题.   偶然发现这古怪的复制问题 
我在从机器配置部分下面
replicate-do-table=adb.TournamentsRiskLevel---------------有时候好 有时候不好
replicate-do-table=adb.TournamentRiskLevelDefine 正常的这个问题是否是 复制从机器对 表名有选择性.  (TournamentsRiskLevel昨天测试时数据是正常的 
但这个表总是有时候 是数据正常的,有时候没有得到数据的)show slave status  
yes
yes  --------------从复制是没有错误的  初步怀疑是 表名的问题??  (从机器其他复制表 发现数据 跟主机器都是实时同步的拉)

Answer 5

从机器上35张表设置 replicate-do-table.  这个表结构如下
CREATE TABLE `TournamentsRiskLevel` (
  `id` int NOT NULL auto_increment,
  `Nameid` bigint default NULL,  
  PRIMARY KEY  (`id`),
  UNIQUE KEY `name` (`Nameid`)
) ENGINE=InnoDB  DEFAULT CHARSET=utf8;从机器slave status 是健康的
为什么其他34张表述据都能及时更新, 但就是TournamentsRiskLevel总是有时候好 有时候数据不能及时更新的 

Answer 6

这个和表名无关,要是觉得没有复制过来,时好时坏的话,就看下日志;replication 是异步的.不是同步的,要是网络好,数据量不大,他们的复制同步时间差很小(可以忽略);反之,还是有延迟的;

Answer 7

不会拉 我等了半小时 那4条记录没有过来. 复制状态是okog-bin = /var/log/mysqld/bin.log
log-bin-index = /var/log/mysqld/log-bin.index
log-error = /var/log/mysqld/error.log----------------检查没有发现有异常的relay-log = /var/log/mysqld/relay.log
relay-log-info-file = /var/log/mysqld/relay-log.info
relay-log-index = /var/log/mysqld/relay-log.index如果复制不通,是好找错误的
现在数据质量问题. 如何定位问题

Answer 8

这4条数据,在主上可以查询的到吗?
可以的话 
把这4条数据手动插入slave的表中;看看有没有记录;
要是有的话表示数据质量没问题了;

Answer 9

把差异的数据找出来,手动在slave执行看看.有什么问题没;楼主有没有 --slave-skip-errors 这个参数;

Answer 10

在从机器my.cnf
skip-slave-start
slave-skip-errors=1062配置了多年了.  (不知道原因拉  如何从上面的查到数据的原因 )

Answer 11

·         错误：1062 SQLSTATE: 23000 (ER_DUP_ENTRY) 消息：键%d的重复条目'%s'。slave-skip-errors=1062 把这个去掉就OK了.应该就是这个问题引起的;

Answer 12

楼上的意思是slave-skip-errors=1062 整行从my.cnf里去掉
不要slave-skip-errors了?

Answer 13

 --slave-skip-errors=[err_code1,err_code2,... | all]通常情况，当出现错误时复制停止，这样给你一个机会手动解决数据中的不一致性问题。该选项告诉从服务器SQL线程当语句返回任何选项值中所列的错误时继续复制。如果你不能完全理解为什么发生错误，则不要使用该选项。如果复制设置和客户程序中没有bug，并且MySQL自身也没有bug，应不会发生停止复制的错误。滥用该选项会使从服务器与主服务器不能保存同步，并且你找不到原因。对于错误代码，你应使用从服务器错误日志中错误消息提供的编号和SHOW SLAVE STATUS的输出。服务器错误代码列于附录B：错误代码和消息。你也可以(但不应)使用不推荐的all值忽略所有错误消息，不考虑所发生的错误。无需而言，如果使用该值，我们不能保证数据的完整性。在这种情况下，如果从服务器的数据与主服务器上的不相近请不要抱怨(或编写bug报告)。已经警告你了。楼主要知道这个参数的意思.手册第6章里有说明;可以去大致的看看;

Answer 14

是否是 在my.cnf
修改为如下slave-skip-errors=all

Answer 15

要是楼主对master-slave 他们数据一致性要求不高的话可以设置成all;
要是对他们的一致性要求高的话 就注释点这句

Answer 16

回忆以前的情况 确实这个表类似情况
现在我在从机器上 slave stop  .change  ,  start 看能否解决这个问题  

Answer 17

binlog-do-db=adb把你的日志不要放在这个库

Answer 18

从机器上 slave stop .change , start   发现还是失败的
现在好麻烦.  这个表到底设什么原因引起的 ,现在怀疑是人为因素的

Answer 19

另外配置了测试机器 主从 1-1  　配置还是一样 ,这个表正常的当前在线这个应用环境如下 
a--             b  --(这个表所在机)       c
master        slave-master           slave现在发现在b 这个表 发生的问题. (昨天相同的配置没有发现这个问题的
今天只不过在b 加个a 的复制表 , 并把过期的bin.log删除就引发这个问题 . 
) 
是否在b 机器上一定要reset slave 下? 加了复制表 ???  

Answer 20

是的  1台主  -->  主从-----> 从机器
            那个表在这里问题     这个机器有5张表复制于b 机器 

Answer 21

楼主有试过把slave-skip-error这个选项注释掉的办法吗?

Answer 22

我的是在线 系统 . 不允许 随意重 start mysql sever
已经 用测试2台机器搭建相同环境,但是测试机器 没有发现这个现象

Answer 23

从bin.log 1.6g 的日志 用脚本反复查找 找到原因

Answer 24

slave-skip-errors=1062
你要生成这个错误,再看看有没有成功,要是没有这个错误的话,肯定是没问题的,这个错误产生,主从数据会不一样

Answer 25

slave-skip-errors=1062我的是在线系统 。如果禁用这个slave-skip-errors=1062，担心从机器会 当机器 的 。从机器理论上不允许随便重新启动的哦所以 不会那样用的哦 我采用的是蚂蚁方法 从巨大日志的查找原因