MySQL第九讲 MySQL集群主从搭建指定数据库同步数据

1、全库同步与部分同步

之前提到，我们目前配置的主从同步是针对全库配置的，而实际环境中，一般并不需要针对全库做备份，而只需要对一些特别重要的库或者表来进行同步。那如何针对库和表做同步配置呢？

首先在Master端：

在my.cnf中，可以通过以下这些属性指定需要针对哪些库或者哪些表记录binlog

#需要同步的二进制数据库名
binlog-do-db=testdemo
#只保留7天的二进制日志，以防磁盘被日志占满(可选)
expire-logs-days = 7
#不备份的数据库
binlog-ignore-db=information_schema
binlog-ignore-db=performation_schema
binlog-ignore-db=sys

然后在Slave端：在my.cnf中，需要配置备份库与主服务的库的对应关系。

#如果salve库名称与master库名相同，使用本配置
replicate-do-db = testdemo
#如果master库名[testdemo]与salve库名[testdemo01]不同，使用以下配置[需要做映射]
#replicate-rewrite-db = testdemo -> testdemo01
#如果不是要全部同步[默认全部同步]，则指定需要同步的表
#replicate-wild-do-table=testdemo.user
#replicate-wild-do-table=testdemo.demotable

配置完成了之后，在show master status指令中，就可以看到Binlog_Do_DB和 Binlog_Ignore_DB两个参数的作用了

重启服务后，再次查看主库

可以看到我们配置的主库需要同步的数据库以及忽略的数据库

再查看从库的状态

另外需要注意一点的是：目前我们的这个MySQL主从集群是单向的，也就是只能从主服务同

步到从服务，而从服务的数据表更是无法同步到主服务的。 所以，在这种架构下，为了保证数据一致，通常会需要保证数据只在主服务上写，而从服务只进行数据读取。这个功能，就是大名鼎鼎的读写分离。但是这里要注意下，mysql主从本身是无法提供读写分离的服务的，需要由业务自己来实现。这也是我们后面要学的ShardingSphere的一个重要功能。

到这里可以看到，在MySQL主从架构中，是需要严格限制从服务的数据写入的，一旦从服务有数据写入，就会造成数据不一致。并且从服务在执行事务期间还很容易造成数据同步失败。

如果需要限制用户写数据，我们可以在从服务中将read_only参数的值设为1( set global read_only=1 ; )。这样就可以限制用户写入数据。

但是这个属性有两个需要注意的地方：

1、read_only=1设置的只读模式，不会影响slave同步复制的功能。所以在MySQL slave库中设定了read_only=1后，通过 "show slave status\G" 命令查看salve状态，可以看到salve仍然会读取master上的日志，并且在slave库中应用日志，保证主从数据库同步一致；

2、read_only=1设置的只读模式，限定的是普通用户进行数据修改的操作，但不会限定具有super权限的用户的数据修改操作。在MySQL中设置read_only=1后，普通的应用用户进行insert、update、delete等会产生数据变化的DML操作时，都会报出数据库处于只读模式不能发生数据变化的错误，但具有super权限的用户，例如在本地或远程通过root用 户登录到数据库，还是可以进行数据变化的DML操作；如果需要限定 super权限的用户写数据，可以设置super_read_only=0。另外 如果要 想连super权限用户的写操作也禁止，就使用"flush tables with read lock;"，这样设置也会阻止主从同步复制！

ok,我们接着测试下上面指定同步数据库的操作，我们在主库上再创建一个数据库，看看从库是否同步主库的数据，另外在从库上再创建一个数据库，查看从库是否会同步新建的数据库。

主库在testdemo数据库新建一个表user,查看从库是否会同步表

mysql> create table user(id int not null, userName varchar(200));
Query OK, 0 rows affected (0.04 sec)

现在查看从库testdemo库的表数据

现在继续在主节点上创建一个新的数据库orders

查看从库是否通不了新建的数据库orders

可以看到主节点新建的orders库是没有同步到从库的。

其他集群方式

我们到这里搭建出了一个一主一从的MySQL主从同步集群，具有了数据同步的基础功能。而在生产环境中，通常会以此为基础，根据业务情况以及负载情况，搭建更大更复杂的集群。

例如为了进一步提高整个集群的读能力，可以扩展出一主多从。而为了减轻主节点进行数据同步的压力，可以继续扩展出多级从的主从集群。为了提高整个集群的高可用能力，可以扩展出多主的集群。我们也可以扩展出互为主从的互主集群甚至是环形的主从集群，实现MySQL多活

部署。搭建互主集群只需要按照上面的方式，在主服务上打开一个slave进程，并且指向

slave节点的binlog当前文件地址和位置。

GTID同步集群

上面我们搭建的集群方式，是基于Binlog日志记录点的方式来搭建的，这也是最为传统的MySQL集群搭建方式。可以看到有一个 Executed_Grid_Set列，暂时还没有用上。实际上，这就是另外一种搭建主从同步的方式，即GTID搭建方式。这种模式是从MySQL5.6版本引入的。

GTID是对一个已经提交事务的编号，并且是全局唯一的。GTID是由UUID和TID组成的。UUID是MySQL实例的唯一标识，TID代表该实例上已经提交的事务数量，随着事务提交数量递增。举个例子：3E11FA47-71CA-11E1-9E33-C80AA9429562:23，冒号前面是UUID，后面是TID。

GTID 工作原理：

主库 master 提交一个事务时会产生 GTID，并且记录在 binlog 日志中
从库 salve I/O 线程读取 master 的 binlog 日志文件，并存储在 slave 的 relay log 中。slave 将 master 的 GTID 这个值，设置到 gtid_next 中，即下一个要读取的 GTID 值。
slave 读取这个 gtid_next，然后对比 slave 自己的 binlog 日志中是否有这个 GTID
如果有这个记录，说明这个 GTID 的事务已经执行过了，可以忽略掉
如果没有这个记录，slave 就会执行该 GTID 事务，并记录到 slave 自己的 binlog 日志中。在读取执行事务前会先检查其他 session 持有该 GTID，确保不被重复执行。
在解析过程中会判断是否有主键，如果没有就用二级索引，如果没有就用全部扫描。

GTID的本质也是基于Binlog来实现主从同步，只是他会基于一个全局的事务ID来标识同步进度。GTID即全局事务ID，全局唯一并且趋势递增，他可以保证为每一个在主节点上提交的事务在复制集群中可以生成一个唯一的ID 。在基于GTID的复制中，首先从服务器会告诉主服务器已经在从服务器执行完了哪些事务的GTID值，然后主库会有把所有没有在从库上执行的事务，发送到从库上进行执行，并且使用GTID的复制可以保证同一个事务只在指定的从库上执行一次，这样可以避免由于偏移量的问题造成数据不一致。他的搭建方式跟我们上面的主从架构整体搭建方式差不多。只是需要在my.cnf中修改一些配

在主节点上：

#开启gtid模式

gtid_mode=on

#强制gtid一致性，开启后对于特定create table不被支持

enforce_gtid_consistency=on

log_bin=on

log-slave-updates=true

binlog_format=row

server_id= 单独设置一个

#relay log

skip_slave_start=1

在从节点上：

gtid_mode=on

enforce_gtid_consistency=on

log-bin=slave-binlog

log-slave-updates=true

server_id= 单独设置一个

#强烈建议，其他格式可能造成数据不一致

binlog_format=row

#relay log

skip_slave_start=1

然后分别重启主服务和从服务，就可以开启GTID同步复制方式。

检查GTID是否开启：

show variables like '%gtid%';

slave连接到master：

CHANGE MASTER TO  
MASTER_HOST='master的IP',    
MASTER_USER='用户名',    
MASTER_PASSWORD='密码',    
MASTER_PORT=端口号,    
# 1 代表采用GTID协议复制
# 0 代表采用老的binlog复制
MASTER_AUTO_POSITION = 1;