当前位置:   article > 正文

MySQL第九讲 MySQL集群主从搭建指定数据库同步数据_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是由UUIDTID组成的。UUIDMySQL实例的唯一标识,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:

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

本文内容由网友自发贡献,转载请注明出处:https://www.wpsshop.cn/w/天景科技苑/article/detail/944632
推荐阅读
相关标签
  

闽ICP备14008679号