MySQL高级讲座篇之：如何利用MySQL的`Replication Filters`进行选择性数据同步？ - 智猿学院-前后端，数据库，人工智能，云计算等领域前沿技术讲座

各位观众老爷们，大家好！我是你们的老朋友，今天咱们聊聊MySQL的Replication Filters，也就是复制过滤器，让大家伙儿也能玩转选择性数据同步，告别“复制粘贴”式的简单粗暴。

开场白：复制的烦恼

想象一下，你的公司壮大了，数据也跟着膨胀。你的数据库也从单枪匹马变成了集群作战。现在你有一主多从的MySQL架构，主库承载所有的读写操作，从库分担读的压力。一开始，你信心满满，觉得复制很简单，一股脑儿把主库的数据都复制到从库。

但是，问题来了！

数据冗余： 从库不需要主库的所有数据，比如一些日志表，测试数据，或者敏感信息。
网络带宽： 复制所有数据占用大量网络带宽，影响其他服务的性能。
存储压力： 从库的存储空间有限，全部复制可能导致存储空间不足。
性能瓶颈： 从库复制大量无用数据，降低查询效率，影响读的性能。

所以，我们需要一种更优雅的方式，只复制我们需要的数据。这就是Replication Filters大显身手的时候了。

Replication Filters：你的数据剪刀手

Replication Filters就像一把精密的剪刀，可以让你选择性地复制数据。你可以指定哪些数据库、哪些表需要复制，哪些不需要复制。这样，从库就能专注地存储和处理有用的数据，提高性能，节省资源。

Replication Filters的类型

MySQL提供了多种Replication Filters，主要分为以下几种：

过滤器类型	作用	适用场景
`binlog_do_db`	指定需要复制的数据库。	适用于只复制特定数据库的场景，例如只复制业务数据库，不复制系统数据库。
`binlog_ignore_db`	指定不需要复制的数据库。	适用于排除特定数据库的场景，例如排除日志数据库，测试数据库。
`replicate_do_db`	（Deprecated）指定需要复制的数据库（在从库设置）。已经不推荐使用，推荐使用`binlog_do_db`在主库设置。	历史遗留问题，不建议使用。
`replicate_ignore_db`	（Deprecated）指定不需要复制的数据库（在从库设置）。已经不推荐使用，推荐使用`binlog_ignore_db`在主库设置。	历史遗留问题，不建议使用。
`replicate_do_table`	指定需要复制的表（需要同时指定数据库）。	适用于只复制特定表，例如只复制订单表，用户表。
`replicate_ignore_table`	指定不需要复制的表（需要同时指定数据库）。	适用于排除特定表，例如排除日志表，统计表。
`replicate_wild_do_table`	使用通配符指定需要复制的表。	适用于批量指定需要复制的表，例如复制所有以`order_`开头的表。
`replicate_wild_ignore_table`	使用通配符指定不需要复制的表。	适用于批量排除特定表，例如排除所有以`log_`开头的表。
`replicate_rewrite_db`	重写数据库名称。	适用于主从库数据库名称不一致的场景。

配置Replication Filters：实战演练

咱们用几个例子来演示如何配置Replication Filters。

例子1：只复制一个数据库

假设我们有一个数据库叫做ecommerce，只包含订单信息、用户信息等核心数据，我们只需要将这个数据库复制到从库。

在主库上配置：

在主库的my.cnf文件中，添加以下配置：
```
[mysqld]
log_bin = mysql-bin
binlog_do_db = ecommerce
```
重启主库MySQL服务。
在从库上配置：

确保从库没有配置其他的复制过滤器，或者使用replicate-ignore-db排除其他数据库。
```
[mysqld]
replicate-ignore-db = mysql
replicate-ignore-db = information_schema
```
重启从库MySQL服务。

启动复制：

在从库上执行以下命令：

CHANGE MASTER TO
    MASTER_HOST='主库IP地址',
    MASTER_USER='复制用户',
    MASTER_PASSWORD='复制密码',
    MASTER_LOG_FILE='主库的binlog文件名',
    MASTER_LOG_POS=主库的binlog位置;

START SLAVE;

现在，从库只会复制ecommerce数据库的数据。

例子2：排除一个数据库

假设我们有一个数据库叫做logs，存储大量的日志信息，我们不需要将这个数据库复制到从库。

在主库上配置：

在主库的my.cnf文件中，添加以下配置：
```
[mysqld]
log_bin = mysql-bin
binlog_ignore_db = logs
```
重启主库MySQL服务。
在从库上配置：

确保从库没有配置其他的复制过滤器，或者使用replicate-do-db指定需要复制的数据库。
```
[mysqld]
# 可以配置多个数据库
replicate-do-db = ecommerce
replicate-do-db = users
```
重启从库MySQL服务。

启动复制：

在从库上执行以下命令：

CHANGE MASTER TO
    MASTER_HOST='主库IP地址',
    MASTER_USER='复制用户',
    MASTER_PASSWORD='复制密码',
    MASTER_LOG_FILE='主库的binlog文件名',
    MASTER_LOG_POS=主库的binlog位置;

START SLAVE;

现在，从库不会复制logs数据库的数据。

例子3：只复制特定表

假设我们只需要复制ecommerce数据库中的orders表和users表。

在主库上配置：

不需要在主库上进行任何配置。
在从库上配置：

在从库的my.cnf文件中，添加以下配置：
```
[mysqld]
replicate-do-table = ecommerce.orders
replicate-do-table = ecommerce.users
```
重启从库MySQL服务。

启动复制：

在从库上执行以下命令：

CHANGE MASTER TO
    MASTER_HOST='主库IP地址',
    MASTER_USER='复制用户',
    MASTER_PASSWORD='复制密码',
    MASTER_LOG_FILE='主库的binlog文件名',
    MASTER_LOG_POS=主库的binlog位置;

START SLAVE;

现在，从库只会复制ecommerce数据库中的orders表和users表的数据。

例子4：使用通配符复制表

假设我们需要复制所有以order_开头的表。

在主库上配置：

不需要在主库上进行任何配置。
在从库上配置：

在从库的my.cnf文件中，添加以下配置：
```
[mysqld]
replicate-wild-do-table = ecommerce.order_%
```
重启从库MySQL服务。

启动复制：

在从库上执行以下命令：

CHANGE MASTER TO
    MASTER_HOST='主库IP地址',
    MASTER_USER='复制用户',
    MASTER_PASSWORD='复制密码',
    MASTER_LOG_FILE='主库的binlog文件名',
    MASTER_LOG_POS=主库的binlog位置;

START SLAVE;

现在，从库只会复制ecommerce数据库中所有以order_开头的表的数据。

Replication Filters的注意事项

配置位置： binlog_do_db和binlog_ignore_db必须在主库上配置，replicate_*类型的过滤器在从库上配置。
优先级： replicate-do-table和replicate-ignore-table的优先级高于replicate-do-db和replicate-ignore-db。如果同时配置了replicate-do-db = db1和replicate-ignore-table = db1.table1，那么table1仍然会被复制。
通配符： 通配符%可以匹配任意字符，_可以匹配单个字符。
重启服务： 修改my.cnf文件后，需要重启MySQL服务才能生效。
安全： 谨慎使用replicate_rewrite_db，避免数据混乱。
Deprecated： 尽量避免使用replicate_do_db和replicate_ignore_db，推荐使用binlog_do_db和binlog_ignore_db。
测试： 在生产环境配置Replication Filters之前，一定要在测试环境进行充分的测试。

高级技巧：动态修改Replication Filters

有时候，我们需要在不重启MySQL服务的情况下，动态修改Replication Filters。MySQL 5.7及以上版本支持动态修改binlog_do_db和binlog_ignore_db。

SET GLOBAL binlog_do_db = 'ecommerce';
SET GLOBAL binlog_ignore_db = 'logs';

但是，需要注意的是，动态修改只对新的连接生效，已经存在的连接仍然使用之前的配置。

Replication Filters的坑

忘记配置： 最常见的错误是忘记配置Replication Filters，导致从库复制了所有数据。
配置错误： 配置错误可能导致从库没有复制需要的数据，或者复制了不需要的数据。
忽略DDL语句： Replication Filters默认不会过滤DDL语句（例如CREATE TABLE，ALTER TABLE），即使你配置了replicate-ignore-table，如果主库执行了CREATE TABLE table1，从库也会执行这个语句。需要使用replicate-ignore-db或者binlog-ignore-db才能完全屏蔽。
GTID： 在使用GTID的情况下，复制过滤器需要更加小心，因为GTID依赖于全局唯一的事务ID，如果过滤了某些事务，可能会导致GTID不连续，影响复制的稳定性。

总结：Replication Filters的价值

Replication Filters是MySQL复制的重要组成部分，可以帮助你：

节省存储空间： 只复制需要的数据，减少从库的存储压力。
提高性能： 减少复制的数据量，提高从库的查询效率。
降低网络带宽： 减少复制的数据量，降低网络带宽的占用。
提高安全性： 避免复制敏感数据，提高数据的安全性。

结束语：复制的艺术

掌握Replication Filters，你就能更好地控制MySQL复制，让数据同步更加高效、安全、灵活。希望今天的讲座对大家有所帮助，让大家在数据复制的道路上少走弯路。咱们下次再见！

发表回复 取消回复

发表回复取消回复