返回顶部
首页 > 资讯 > 数据库 >警惕!replicate_do_db 有坑!
  • 550
分享到

警惕!replicate_do_db 有坑!

2024-04-02 19:04:59 550人浏览 安东尼
摘要

写在前面:笔者采用传统方式搭建的主从环境,主库更新记录后,从库不能将数据同步过去,在从库查看主从复制状态,Read_Master_Log_Pos 和 Exec_Master_Log_Pos 一致,I/O、s

写在前面:
笔者采用传统方式搭建的主从环境,主库更新记录后,从库不能将数据同步过去,在从库查看主从复制状态,Read_Master_Log_Pos 和 Exec_Master_Log_Pos 一致,I/O、sql线程都正常,没有主从延迟发生,没有人为的设置延迟更新参数,主库binlog和从库relay log都有相应的更新记录,从库错误日志没有任何复制相关的error信息。如果你和笔者是同样的情况,那么你可能和笔者一样,遇到了复制过滤规则的 "坑"

环境:
Mysql5.6(mysql5.7,MySQL8没有亲自测过)

场景复现:

Master配置:
[mysqld]
datadir = /home/data/mysql3306/
port = 3306
server_id = 1
binlog_fORMat = row
log_bin = /home/data/mysql3306/binlog

SLave配置:
[mysqld]
datadir = /home/data/mysql3306/
port = 3306
binlog_format = row
server_id=2
relay_log = /home/data/mysql3306/relaylog
replicate_do_db=edusoho_e,statis

Master授权复制连接用户:
mysql> grant replication slave on *.*to repliter@'192.168.32.2' identified by PASSWord ' *6BB4837EB74329105EE4568DDA7DC67ED2CA2AD9';
Query OK, 0 rows affected (0.01 sec)


mysql> flush logs;
Query OK, 0 rows affected (0.03 sec)

mysql> show master status;
+---------------+----------+--------------+------------------+-------------------+
| File          | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+---------------+----------+--------------+------------------+-------------------+
| binlog.000004 |      120 |              |                  |                   |
+---------------+----------+--------------+------------------+-------------------+
1 row in set (0.00 sec)

Slave开启数据复制:
CHANGE MASTER TO MASTER_HOST='192.168.32.3',MASTER_USER='repliter',MASTER_PASSWORD='123456',MASTER_PORT=3306,MASTER_LOG_FILE='binlog.000004',MASTER_LOG_POS=120;
Query OK, 0 rows affected, 2 warnings (0.05 sec)

mysql> start slave;
Query OK, 0 rows affected (0.03 sec)

mysql> show slave status\G;
*************************** 1. row ***************************
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB: edusoho_e,statis

主从复制状态正常!

Master变更了数据:
mysql> create database edusoho_e;
Query OK, 1 row affected (0.00 sec)

mysql> use edusoho_e;
Database changed

CREATE TABLE `t1` (
`id` INT(11) UNSIGNED NOT NULL AUTO_INCREMENT,
`xname` VARCHAR(20) NOT NULL DEFAULT '',
`address` CHAR(20) NOT NULL DEFAULT '',
`sex` TINYINT(1) NOT NULL DEFAULT '1',
`hobby` VARCHAR(30) NOT NULL DEFAULT '',
`age` TINYINT(2) DEFAULT '18',
PRIMARY KEY (`id`),
KEY `idx_name` (`xname`)
) ENGINE=INNODB DEFAULT CHARSET=utf8;

mysql> INSERT INTO `edusoho_e`.`t1` (`xname`, `address`, `hobby`) VALUES ('edusoho_e', 'ldl', 'dba');
Query OK, 1 row affected (0.01 sec)

mysql> show master status;
+---------------+----------+--------------+------------------+-------------------+
| File          | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+---------------+----------+--------------+------------------+-------------------+
| binlog.000004 |      882 |              |                  |                   |
+---------------+----------+--------------+------------------+-------------------+
1 row in set (0.00 sec)

Master的binlog日志是正常的

然而你在Slave主机上看不到新建的表及其数据
Slave:
mysql> show databases;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| mysql              |
| performance_schema |
| test               |
+--------------------+
4 rows in set (0.00 sec)

查看主从复制状态:
mysql> show slave status\G;
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 192.168.32.3
Master_User: repliter
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: binlog.000004
Read_Master_Log_Pos: 882
Relay_Log_File: relaylog.000002
Relay_Log_Pos: 1042
Relay_Master_Log_File: binlog.000004
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB: edusoho_e,statis
Exec_Master_Log_Pos: 882
Seconds_Behind_Master: 0
SQL_Delay: 0

你会发现 I/O、SQL 线程正常;Read_Master_Log_Pos 和 Exec_Master_Log_Pos 值相同;Seconds_Behind_Master 值为0,说明没有主从延迟发生;SQL_Delay 值为0,说明没有主观设置延迟插入;虽然设置了主从过滤规则,但也只是复制该库的,难道是Slave的relay log出了问题,没有记录Master的日志?

到Slave去分析relay log日志,会发现也是有相应的Master的日志的
[root@slave mysql3306]# mysqlbinlog -v --base64-output=decode relaylog.000002
;
;
;
DELIMITER ;
# at 4
#190530  9:32:17 server id 2  end_log_pos 120 CRC32 0x35d47ba3  Start: binlog v 4, server v 5.6.16-log created 190530  9:32:17
# at 120
#700101  8:00:00 server id 1  end_log_pos 0 CRC32 0x0166516e    Rotate to binlog.000004  pos: 120
# at 164
#190530  9:29:02 server id 1  end_log_pos 0 CRC32 0xfea4f75a    Start: binlog v 4, server v 5.6.16-log created 190530  9:29:02
# at 280
#190530  9:35:18 server id 1  end_log_pos 229 CRC32 0x6b0d2047  Query   thread_id=2 exec_time=0 error_code=0
SET TIMESTAMP=1559180118;
SET @@session.pseudo_thread_id=2;
SET @@session.foreign_key_checks=1, @@session.sql_auto_is_null=0, @@session.unique_checks=1, @@session.autocommit=1;
SET @@session.sql_mode=1073741824;
SET @@session.auto_increment_increment=1, @@session.auto_increment_offset=1;
;
SET @@session.character_set_client=33,@@session.collation_connection=33,@@session.collation_server=33;
SET @@session.lc_time_names=0;
SET @@session.collation_database=DEFAULT;
create database edusoho_e
;
# at 389
#190530  9:35:31 server id 1  end_log_pos 653 CRC32 0x1268f754  Query   thread_id=2 exec_time=0 error_code=0
use `edusoho_e`;
SET TIMESTAMP=1559180131;
CREATE TABLE `t1` (
`id` INT(11) UNSIGNED NOT NULL AUTO_INCREMENT,
`xname` VARCHAR(20) NOT NULL DEFAULT '',
`address` CHAR(20) NOT NULL DEFAULT '',
`sex` TINYINT(1) NOT NULL DEFAULT '1',
`hobby` VARCHAR(30) NOT NULL DEFAULT '',
`age` TINYINT(2) DEFAULT '18',
PRIMARY KEY (`id`),
KEY `idx_name` (`xname`)
) ENGINE=INNODB DEFAULT CHARSET=utf8
;
# at 813
#190530  9:35:41 server id 1  end_log_pos 730 CRC32 0x20610ab1  Query   thread_id=2 exec_time=0 error_code=0
SET TIMESTAMP=1559180141;
BEGIN
;
# at 890
#190530  9:35:41 server id 1  end_log_pos 791 CRC32 0xc2edbad8  Table_map: `edusoho_e`.`t1` mapped to number 540
# at 951
#190530  9:35:41 server id 1  end_log_pos 851 CRC32 0xaa57d74f  Write_rows: table id 540 flags: STMT_END_F
### INSERT INTO `edusoho_e`.`t1`
### SET
###   @1=1
###   @2='edusoho_e'
###   @3='ldl'
###   @4=1
###   @5='dba'
###   @6=18
# at 1011
#190530  9:35:41 server id 1  end_log_pos 882 CRC32 0x7de64644  Xid = 1350
COMMIT;
DELIMITER ;
# End of log file
ROLLBACK ;
;
;

查看Slave的错误日志,也没有看到任何复制error相关的信息

那么问题来了,这可能是遭遇了BUG! 笔者也忘记了,是某位大佬说过,还是在某博客中看到过,如果Slave配置了replicate_do_db 过滤规则,如果写成了如下形式:
replicate_do_db=edusoho_e,statis 可能会遭遇BUG,需要分开来写
replicate_do_db=edusoho_e
replicate_do_db=statis

重启Slave以验证猜想

Master:
mysql> flush logs;
Query OK, 0 rows affected (0.44 sec)

mysql> show master status;
+---------------+----------+--------------+------------------+-------------------+
| File          | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+---------------+----------+--------------+------------------+-------------------+
| binlog.000005 |      120 |              |                  |                   |
+---------------+----------+--------------+------------------+-------------------+
1 row in set (0.00 sec)

SET @@session.sql_log_bin=0;

DROP DATABASE `edusoho_e`;

mysql> create database edusoho_e;
Query OK, 1 row affected (0.00 sec)

mysql> use edusoho_e;
Database changed

CREATE TABLE `t1` (
`id` INT(11) UNSIGNED NOT NULL AUTO_INCREMENT,
`xname` VARCHAR(20) NOT NULL DEFAULT '',
`address` CHAR(20) NOT NULL DEFAULT '',
`sex` TINYINT(1) NOT NULL DEFAULT '1',
`hobby` VARCHAR(30) NOT NULL DEFAULT '',
`age` TINYINT(2) DEFAULT '18',
PRIMARY KEY (`id`),
KEY `idx_name` (`xname`)
) ENGINE=INNODB DEFAULT CHARSET=utf8;

mysql> INSERT INTO `edusoho_e`.`t1` (`xname`, `address`, `hobby`) VALUES ('edusoho_e', 'ldl', 'dba');
Query OK, 1 row affected (0.01 sec)

Slave:
mysql> show databases;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| edusoho_e          |
| mysql              |
| performance_schema |
| test               |
+--------------------+
5 rows in set (0.00 sec)

mysql> select * from edusoho_e.t1;
+----+-----------+---------+-----+-------+------+
| id | xname     | address | sex | hobby | age  |
+----+-----------+---------+-----+-------+------+
|  1 | edusoho_e | ldl     |   1 | dba   |   18 |
+----+-----------+---------+-----+-------+------+
1 row in set (0.00 sec)

你会发现新建的表和数据都同步过去了,说明确实是 replicate_do_db 过滤规则的 "坑"

您可能感兴趣的文档:

--结束END--

本文标题: 警惕!replicate_do_db 有坑!

本文链接: https://lsjlt.com/news/39450.html(转载时请注明来源链接)

有问题或投稿请发送至: 邮箱/279061341@qq.com    QQ/279061341

猜你喜欢
  • 警惕!replicate_do_db 有坑!
    写在前面:笔者采用传统方式搭建的主从环境,主库更新记录后,从库不能将数据同步过去,在从库查看主从复制状态,Read_Master_Log_Pos 和 Exec_Master_Log_Pos 一致,I/O、S...
    99+
    2024-04-02
  • 关于replicate_do_db和replicate_ignore_db的坑
    介绍 MySQL5.7官方文档关于相关参数的介绍:https://dev.mysql.com/doc/refman/5.7/en/change-replication-filter.html 在5.7版本支...
    99+
    2024-04-02
  • 警惕阿里云服务器返利骗局
    阿里云是中国最大的云计算服务提供商,但最近出现了一些关于阿里云服务器返利骗局的报道。本文将深入剖析这些骗局的特点、危害,并提供一些防范措施,帮助用户避免受骗。 一、返利骗局的基本特点简单的高回报承诺 阿里云服务器返利骗局通常会承诺给用户提供...
    99+
    2024-01-25
    阿里 骗局 服务器
  • Meta 标签错误:警惕并避免 SEO 灾难
    常见的 Meta 标签错误 重复的 Meta 标签:每个网页都应拥有唯一的标题和描述 Meta 标签。重复的标签会混淆搜索引擎,损害排名。 过长的标题:标题 Meta 标签的长度必须在 50-60 个字符以内。较长的标题会被截断,从而失...
    99+
    2024-04-02
  • 阿里云服务器诈骗警惕网络安全风险
    随着互联网的不断发展,云计算服务已成为许多企业和个人的重要选择。然而,随着云计算的普及,网络诈骗的手段也变得更加复杂和隐蔽,其中以阿里云服务器诈骗尤为突出。本文将对阿里云服务器诈骗进行详细介绍,提醒读者警惕网络安全风险。 一、阿里云服务器诈...
    99+
    2023-11-23
    阿里 网络安全 风险
  • Spring中使用事务嵌套时需要警惕的问题分享
    目录前言问题描述问题结果原因追溯解决之道事务的传播机制总结前言 最近项目上有一个使用事务相对复杂的业务场景报错了。在绝大多数情况下,都是风平浪静,没有问题。其实内在暗流涌动,在有些异...
    99+
    2023-05-17
    Spring事务嵌套使用 Spring事务嵌套
  • CMS安全隐患重重:警惕黑客攻击的各种手段
    内容管理系统(CMS)是一种软件,允许用户创建、管理和修改网站内容。CMS的不断发展和使用为黑客提供了更多机会来攻击网站。黑客利用漏洞牟利的手段包括SQL注入、跨站脚本、木马后门、缓冲区溢出、配置缺陷等。 SQL注入 SQL注入是最常见的...
    99+
    2024-02-12
    CMS安全 SQL注入 跨站脚本 木马后门 缓冲区溢出 配置缺陷
  • 大脑无特权:警惕免疫系统带来的精神健康问题
    一场突如其来的新冠病毒疫情,结结实实地给我们上了一堂全球防疫的科普大课。关心疫情进展、了解感染防控、操心疫苗进度,几乎让每个人都快成为半个防疫专家。不久前,英国政府发出的“群体免疫”的措施,引发全球的轩然大波。这件事情也给所有人提了一个醒:...
    99+
    2023-06-05
  • 大家请警惕这件事!手机户外使用免费的充电桩,会导致信息外泄
    大家请警惕这件事!手机户外使用免费的充电桩,会导致信息外泄大家好,这里是技能小酱,不知道大家有没有使用过免费的充电桩为自己的手机进行充电,像这种免费为消费者提供手机充电的充电桩,大部分都会出现在电影院,购物商场等公共场所,但是大家最好少使用...
    99+
    2023-06-05
  • 阿里云服务器返利骗局案例详解警惕网络陷阱,保护个人信息安全
    近年来,随着互联网的快速发展,网络诈骗手段日益复杂,各种返利、折扣、优惠等活动层出不穷。在这些活动中,有些甚至打着知名企业的旗号,如阿里云服务器,进行返利骗局,诱骗消费者上当受骗。本文将对阿里云服务器返利骗局案例进行详细说明,提醒大家警惕网...
    99+
    2023-11-12
    阿里 骗局 信息安全
  • sql server2012有什么坑
    小编给大家分享一下sql server2012有什么坑,相信大部分人都还不怎么了解,因此分享这篇文章给大家参考一下,希望大家阅读完这篇文章后大有收获,下面让我们一起去了解一下吧!   以前,sq...
    99+
    2024-04-02
  • 告警:没有现有的数据库
    metastat: wy2db: there are no existing databases····没有做数据库镜像,请教后得知没什么大问题 ...
    99+
    2024-04-02
  • 有哪些C++模板坑
    这篇文章主要介绍“有哪些C++模板坑”,在日常操作中,相信很多人在有哪些C++模板坑问题上存在疑惑,小编查阅了各式资料,整理出简单好用的操作方法,希望对大家解答”有哪些C++模板坑”的疑惑有所帮助!接下来,请跟着小编一起来学习吧!问题复现头...
    99+
    2023-06-16
  • Spring事务有哪些坑
    这篇文章主要讲解了“Spring事务有哪些坑”,文中的讲解内容简单清晰,易于学习与理解,下面请大家跟着小编的思路慢慢深入,一起来研究和学习“Spring事务有哪些坑”吧!一、Spring事务管理的几种方式:Spring事务在具体使用方式上可...
    99+
    2023-06-15
  • Java CPP的坑有哪些
    这篇文章主要讲解了“Java CPP的坑有哪些”,文中的讲解内容简单清晰,易于学习与理解,下面请大家跟着小编的思路慢慢深入,一起来研究和学习“Java CPP的坑有哪些”吧!1.分清楚System.load与System.loadLibra...
    99+
    2023-06-04
  • 使用Python坑有哪些
    本篇内容介绍了“使用Python坑有哪些”的有关知识,在实际案例的操作过程中,不少人都会遇到这样的困境,接下来就让小编带领大家学习一下如何处理这些情况吧!希望大家仔细阅读,能够学有所成!缩进,符号和空格不正确写代码时大家会使用缩进、对齐、空...
    99+
    2023-06-02
  • BigDecimal遇到的坑有哪些
    这篇文章主要介绍“BigDecimal遇到的坑有哪些”,在日常操作中,相信很多人在BigDecimal遇到的坑有哪些问题上存在疑惑,小编查阅了各式资料,整理出简单好用的操作方法,希望对大家解答”BigDec...
    99+
    2024-04-02
  • 关于C++的坑有哪些
    这篇文章主要讲解了“关于C++的坑有哪些”,文中的讲解内容简单清晰,易于学习与理解,下面请大家跟着小编的思路慢慢深入,一起来研究和学习“关于C++的坑有哪些”吧!1. string的字符串拼接,导致coredump该问题的核心点在于第9行,...
    99+
    2023-06-16
  • 编写Java的坑有哪些
    本篇内容主要讲解“编写Java的坑有哪些”,感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷,实用性强。下面就让小编来带大家学习“编写Java的坑有哪些”吧!1、对象比较方法JDK 1.7 提供的 Objects.equals 方法,非常...
    99+
    2023-06-16
  • win10安装pytorch——前面有坑
      嗯!花费了不少时间才把pytorch安装成功。主要原因就是: 清华和中科大的Anaconda国内镜像源关闭了 activate.bat 不是内部或外部命令(这个真实奇怪)   可以去Anaconda官网下载windows的最新的...
    99+
    2023-01-31
    pytorch
软考高级职称资格查询
编程网,编程工程师的家园,是目前国内优秀的开源技术社区之一,形成了由开源软件库、代码分享、资讯、协作翻译、讨论区和博客等几大频道内容,为IT开发者提供了一个发现、使用、并交流开源技术的平台。
  • 官方手机版

  • 微信公众号

  • 商务合作