mysql中replicate_wild_do_table和replicate_do_db区别

使用replicate_do_db和replicate_ignore_db时有一个隐患,跨库更新时会出错。

如在Master(主)服务器上设置 replicate_do_db=test(my.conf中设置)
use mysql;
update test.table1 set ......
那么Slave(从)服务器上第二句将不会被执行

如Master设置 replicate_ignore_db=mysql
use mysql;
update test.table1 set ......
那么Slave上第二句会被忽略执行

原因是设置replicate_do_db或replicate_ignore_db后,MySQL执行sql前检查的是当前默认数据库,所以跨库更新语句在Slave上会被忽略。

可以在Slave上使用 replicate_wild_do_table 和 replicate_wild_ignore_table 来解决跨库更新的问题,如:
replicate_wild_do_table=test.%

replicate_wild_ignore_table=mysql.%

这样就可以避免出现上述问题了

---------------------华丽丽的分界线------------------------

完整版:

原文: http://www.mysqlperformanceblog.com/2009/05/14/why-mysqls-binlog-do-db-option-is-dangerous/

作者: Baron Schwartz

Why MySQL’s binlog-do-db option is dangerous

为什么 MySQL的 binlog-do-db 选项是危险的.

I see a lot of people filtering replication with binlog-do-db, binlog-ignore-db, replicate-do-db, and replicate-ignore-db. Although there are uses for these, they are dangerous and in my opinion, they are overused. For many cases, there‘s a safer alternative.

我发现很多人通过 binlog-do-db, binlog-ignore-db, replicate-do-db 和 replicate-ignore-db 来过滤复制(某些数据库), 尽管有些使用, 但是,在我看来,他们是危险的,并且他们被滥用了. 对于很多的实例,有更安全的替换方案.

The danger is simple: they don‘t work the way you think they do. Consider the following scenario: you set binlog-ignore-db to "garbage" so data in the garbage database (which doesn‘t exist on the slave) isn‘t replicated. (I‘ll come back to this in a second, so if you already see the problem, don‘t rush to the comment form.)

为什么危险很简单: 他们并不像你想的那样工作. 想象如下的场景: 你设置了 binlog-ignore-db = garbage, 所以 garbage数据库(在slave上不存在这个数据库) 中的数据不会被复制,(待会儿我再讲这个,如果你已经发现问题了,不要急于到评论表单)

Now you do the following:

现在做下面的事情:

$ mysql
mysql> delete from garbage.junk; 
mysql> use garbage;
mysql> update production.users set disabled = 1 where user = "root";

You just broke replication, twice. Once, because your slave is going to execute the first query and there‘s no such table "garbage.junk" on the slave. The second time, silently, because the update to production.users isn‘t replicated, so now the root user isn‘t disabled on the slave.

复制会broke2次, 第一次,因为 slave尝试着去之西你给第一条语句,但是slave上并没有这样的表"garbage.junk" , 第二次, 隐含的, 因为 对 production.users不会被 复制,因为 root帐号并没有在slave上被禁用掉.

Why? Because binlog-ignore-db doesn‘t do what you think. The phrase I used earlier, "data in the garbage database isn‘t replicated," is a fallacy. That‘s not what it does. In fact, it filters out binary logging for statements issued from connections whose default database is "garbage." In other words, filtering is not based on the contents of the query -- it is based on what database you USE.

为什么? 因为 binlog-ignore-db 并不像你想的那样执行, 我之前说的, "在garbage数据库中的数据不会被复制" 是错的, 实际上(数据库)并没有这么做.事实上, 他是通过默认的数据库为“garbage" 的连接, 过滤二进制的(SQL)语句日志的. 换句话说, 过滤不是基于 查询的字符串的, 而实际于你used的数据库.

The other configuration options I mentioned work similarly. The binlog-do-db and binlog-ignore-db statements are particularly dangerous because they keep statements from ever being written to the binary log, which means you can‘t use the binary log for point-in-time recovery of your data from a backup.

其他我提到的配置选项也都类似. binlog-do-db 和 binlog-ignore-db 语句是特别危险的,因为他们将语句写入了二进制日志. 意味着你不能使用二进制日志从备份恢复指定时间的数据.

In a carefully controlled environment, these options can have benefits, but I won‘t talk about that here. (We covered that in our book.)

在严格控制的环境中, 这些选项是很有用的,但是我不会谈论这些(这些包含在我们的书中),

The safer alternative is to configure filters on the slave, with options that actually operate on the tables mentioned in the query itself. These are replicate-wild-* options. For example, the safer way to avoid replicating data in the garbage database is to configure replicate-wild-ignore-table=garbage.%. There are still edge cases where that won‘t work, but it works in more cases and has fewer gotchas.

安全的替换方案是 在 slave上配置过滤, 使用基于查询中真正涉及到的表的选项, 这些是: replicate-wild-* 选项, 例如, 避免复制 garbage数据库中的数据的安全的方案是 配置: replicate-wild-ignore-table=garbage.%. 这样做仍然有一些特殊的情况, 不能正常工作,但可以在更多的情况下正常工作,并且会遇到更少的意外 (gotchas).

If you are confused, you should read the replication rules section of the manual until you know it by heart

如果你有些疑惑了,你应该去读一读手册上的复制规则一节,直到你真正明白为止.

Refer from http://www.mysqlperformanceblog.com/2009/05/14/why-mysqls-binlog-do-db-option-is-dangerous

时间: 2024-10-27 18:34:34

mysql中replicate_wild_do_table和replicate_do_db区别的相关文章

MySQL中varchar与char区别

MySQL中varchar与char区别(转) MySQL中varchar最大长度是多少? 一. varchar存储规则: 4.0版本以下,varchar(20),指的是20字节,如果存放UTF8汉字时,只能存6个(每个汉字3字节) 5.0版本以上,varchar(20),指的是20字符,无论存放的是数字.字母还是UTF8汉字(每个汉字3字节),都可以存放20个,最大大小是65532字节 Mysql4中最大也不过是20个字节,但是Mysql5根据编码不同,存储大小也不同. 二. varchar和

Mysql中FIND_IN_SET()和IN区别简析

来源:http://www.jb51.net/article/125744.htm 测试SQL: CREATE TABLE `test` ( `id` int(8) NOT NULL auto_increment, `name` varchar(255) NOT NULL, `list` varchar(255) NOT NULL, PRIMARY KEY (`id`) ) INSERT INTO `test` VALUES (1, 'name', 'daodao,xiaohu,xiaoqin'

mysql 中delete和trncate区别

mysql中删除表记录delete from和truncate table的用法区别: MySQL中有两种删除表中记录的方法:(1)delete from语句,(2)truncate table语句. delete from语句可以使用where对要删除的记录进行选择.delete语句更灵活.truncate table将删除表中的所有记录. 情况一:清空表中的所有记录,可以使用下面的两种方法: delete from tablename truncate table tablename 其中第

Mysql中varchar和char区别

一.varchar和char的区别: 区别一:定长和变长 char表示定长.长度固定,varchanr表示变长,即长度可变. 即char类型是规定多少字长则必须存储多少字长,超过的长度的字段则只能截取出对应的长度进行存储,相对于要求字长长度不够的字段则用空格补齐. 而varchar类型则是只要在规定字长之内,有多少存多少,无需补齐:超出的部分和char一样,舍去即可.(由perfix来实现) 区别二:存储容量不同 对于char类型来说,最多只能存放的字符个数为255,和编码无关. varchar

mysql中utf8和utf8mb4区别

MySQL在5.5.3之后增加了这个utf8mb4的编码,mb4就是most bytes 4的意思,专门用来兼容四字节的unicode.好在utf8mb4是utf8的超集,除了将编码改为utf8mb4外不需要做其他转换.当然,为了节省空间,一般情况下使用utf8也就够了. 二.内容描述 那上面说了既然utf8能够存下大部分中文汉字,那为什么还要使用utf8mb4呢? 原来mysql支持的 utf8 编码最大字符长度为 3 字节,如果遇到 4 字节的宽字符就会插入异常了.三个字节的 UTF-8 最

mysql 中 myisam innodb 的区别有哪些

MyISAM InnoDB 构成上的区别: 每个MyISAM在磁盘上存储成三个文件.第一个文件的名字以表的名字开始,扩展名指出文件类型. .frm文件存储表定义. 数据文件的扩展名为.MYD (MYData). 索引文件的扩展名是.MYI (MYIndex). 基于磁盘的资源是InnoDB表空间数据文件和它的日志文件,InnoDB 表的大小只受限于操作系统文件的大小,一般为 2GB事务处理上方面: MyISAM类型的表强调的是性能,其执行数度比InnoDB类型更快,但是不提供事务支持 InnoD

mysql中varchar和char区别(思维导图整理)

由于mysql一直是我的弱项(其实各方面我都是很弱的),所以最近在看msyql,正好看到varchar和char区别,所以整理一下,便于以后遗忘. 0.0图片已经说明一切,但是系统说我字数不够,我真能在说两句,首先,非常感谢(http://www.jcodecraeer.com/a/shujuku/2012/1014/435.html)让我了解varchar和char的区别,然后,我身为一名程序员,不怎么会用思维导图,不足之处请见谅.

mysql中char,varchar,text区别总结

具体对这三种类型的说明不做阐述可以查看mysql帮助文档. char的总结:      char最大长度是255字符,注意是字符数和字符集没关系.可以有默认值,尾部有空格会被截断.varchar的总结:      varchar的最大长度65535是指能存储的字节数,其实最多只能存储65532个字节,还有3个字节用于存储长度.注意是字节数这个和字符集有关系.一个汉字字符用utf8占用3字节,用gbk占用2字节.可以有默认值,尾部有空格不会截断.text的总结:      text和varchar

mysql中delete和truncate区别

delete和truncate区别如下: 一.灵活性:delete可以条件删除数据,而truncate只能删除表的所有数据: delete from table_test where ... truncate table table_test 二.效率:delete效率低于truncate,delete是一行一行地删除,truncate会重建表结构, 三.事务:truncate是DDL语句,需要drop权限,因此会隐式提交,不能够rollback:delete是DML语句,可以使用rollbac