MySQL传统复制与GTID复制原理及操作详解
复制是单向的,只能从master复制到slave上,延时基本上是毫秒级别的。
一组复制结构中可以有多个slave,对于master一
MySQL复制在业界里有叫:mysql同步,ab复制等。专业名称就是叫:复制。 复制是单向的,只能从master复制到slave上,延时基本上是毫秒级别的。 一组复制结构中可以有多个slave,对于master一般场景推荐只有一个。 master用户写入数据,生成event记到binary log中slave接收master上传来的binlog,然后按顺序应用,重现master上的用户操作。 记录最小的单位是一个event,日志前4个字节是一个magic number,接下来19个字节记录formatt desc event:FDE MySQL5.6增加了GTID复制 1、classic主从配置 核心配置 [mysqld] log-bin server-id gtid_mode=off #禁掉gtid grantreplication slave on *.* to 'repl'@'%' identified by 'repl4slave'; flushprivileges; 添加一个新的从库,获取主库上一个带binlog及pos偏移量的备份 在从库上恢复后执行 >changemaster to master_host='192.168.199.117', master_user='slave', master_port=7000, master_password='slavepass', master_log_file='mysql-bin.000008', master_log_pos=896; 启动slave,并查看状态 >start slave; >show slave status\G; 如果遇到错误,可以跳过: stop slave; set globalsql_slave_skip_counter=1; start slave; show slave status\G; 2、复制配置 一个事务对应一个唯一ID,一个GTID在一个服务器上只会执行一次,GTID是用来替代以前classic的复制方法,mysql5.62支持,mysql5.6.10后完善 优点: 相对于行复制来讲数据安全性更高,故障切换更简单 配置GTID [mysqld] #GTID: gtid_mode=on enforce-gtid-consistency=on #binlog log-bin=mysql-bin log-slave-updates=1 GTID添加从库有两种方法: 1、如果master所有的binlog还在,安装slave后,直接changemaster 到master 原理是直接获取master所有的gtid并执行 优点是简单 缺点是如果binlog太多mssql复制,数据完全同步需要的时间较长,并且需要master一开始就启用了GTID 总结:适用于master也是新建不久的情况 2、通过master或者其它slave的备份搭建新的slave. 原理:获取master的数据和这些数据对应的GTID范围,然后通过在slave设置@@GLOBAL.GTID_PURGED从而跳过备份包含的GTID 优点是可以避免第一种方法中的不足 缺点操作相对复杂 总结:适用于拥有较大数据集的情况 GTID添加从库: 1、用mysqldump工具 在备份的时候需要指定--master-data 导出的语句中包括:set @@GLOBAL.GTID_PURGED='c8d960f1-83ca-11e5-a8eb-000c29ea831c:1-745497';恢复时,需要先在slave上执行一个reset master,再执行change master to 2、用percona xtrabackup工具 xtrabackup_binlog_info包含了GTID在信息 做从库恢复后,需要手工设置: set @@GLOBAL.GTID_PURGED='c8d960f1-83ca-11e5-a8eb-000c29ea831c:1-745497'; 恢复后,执行 >change master to master_host='192.168.199.117', master_user='slave', master_port=7000, master_password='slavepass', master_auto_position=1; 错误跳过 stop slave; setgtid_next='xxxxxxxx:N'; begin; commit; setgtid_next='automatic'; start slave; GTID的限制: 不支持非事务引擎(从库报错,stopslave; start slave; 忽略) 不支持create table … select 语句复制(主库直接报错) 不允许在一个SQL同时更新一个事务引擎和非事务引擎的表 在一个复制组中,必须要求统一开启CTID或是关闭GTID 开启DTID需要重启(5.7中可能不需要) 开启DTID后,就不在使用原来的传统的复制方式 对于createtemporary table 和drop temporary table语句不支持 不支持sql_slave_skip_counter MySQL复制默认是异步复制,Master将事件写入binlog,但并不知道Slave是否或何时已经接收且已处理。在异步复制的机制的情况下,如果Master宕机,事务在Master上已提交,但很可能这些事务没有传到任何的Slave上。假设有Master->Salve故障转移的机制,此时Slave也可能会丢失事务。 官方半同步复制的概念: 1.当Slave主机连接到Master时,能够查看其是否处于半同步复制的机制。 2.当Master上开启半同步复制的功能时,至少应该有一个Slave开启其功能。此时,一个线程在Master上提交事务将受到阻塞,直到得知一个已开启半同步复制功能的Slave已收到此事务的所有事件,或等待超时。 3.当一个事务的事件都已写入其relay-log中且已刷新到磁盘上,Slave才会告知已收到。 4.如果等待超时,也就是Master没被告知已收到,此时Master会自动转换为异步复制的机制。当至少一个半同步的Slave赶上了,Master与其Slave自动转换为半同步复制的机制。 5.半同步复制的功能要在Master,Slave都开启,半同步复制才会起作用;否则,只开启一边,它依然为异步复制。 同步(社区增强半同步),异步,半同步复制的比较: 同步复制:Master提交事务,直到事务在所有的Slave都已提交,此时才会返回客户端,事务执行完毕。缺点:完成一个事务可能会有很大的延迟。 异步复制:当Slave准备好才会向Master请求binlog。缺点:不能保证一些事件都能够被所有的Slave所接收。 半同步复制:半同步复制工作的机制处于同步和异步之间,Master的事务提交阻塞,只要一个Slave已收到该事务的事件且已记录。它不会等待所有的Slave都告知已收到,且它只是接收,并不用等其完全执行且提交。 半同步,开启后严重影响性能 解决主库不关心日志是否被从库读到 半同步配置,在master和slave上都配置 master [mysqld] rpl_semi_sync_master_enabled=1 rp;_semi_sync_master_timeout=1000#1s slave [mysqld] rpl_semi_sync_slave_enabled=1 复制参数 近期技术活动 今年8月18-19号,由极客邦InfoQ、听云联合主办,运维帮协办的2016APMCon中国应用性能管理大会将在北京正式拉开帷幕,大会邀请了来自LinkedIn、支付宝、腾讯、京东、网易、新浪、天猫、1号店等公司的技术负责人,共同探讨APM相关的性能优化、技术方案以及架构细节,为更多的行业从业者传递应用架构优化和创新内容。点击阅读原文,了解详情。 输入ywb优惠码,可以优惠500RMB 输入ywb优惠码,可以优惠500RMB (编辑:拼字网 - 核心网) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |