使用Xtrabackup对MySQL做主从复制
使用Xtrabackup对MySQL做主从复制
脑洞老湿_ 发表于3个月前
使用Xtrabackup对MySQL做主从复制
  • 发表于 3个月前
  • 阅读 0
  • 收藏 0
  • 点赞 0
  • 评论 0

腾讯云 新注册用户 域名抢购1元起>>>   

使用Xtrabackup对MySQL做主从复制

xtrabackup

mysqldump对于导出10G以下的数据库或几个表,还是适用的,而且更快捷。一旦数据量达到100-500G,无论是对原库的压力还是导出的性能,mysqldump就力不从心了。Percona-Xtrabackup备份工具,是实现MySQL在线热备工作的不二选择,可进行全量、增量、单表备份和还原。(但当数据量更大时,可能需要考虑分库分表,或使用 LVM 快照来加快备份速度了)。
2.2版本xtrabackup能对InnoDB和XtraDB存储引擎的数据库非阻塞地备份,innobackupex通过perl封装了一层xtrabackup,对MyISAM的备份通过加表读锁的方式实现。2.3版本xtrabackup命令直接支持MyISAM引擎。

优势:

  1. 无需停止数据库进行InnoDB热备
  2. 增量备份MySQL
  3. 流压缩到传输到其它服务器
  4. 能比较容易地创建主从同步
  5. 备份MySQL时不会增大服务器负载

replication

为什么要做主从复制? 我想这是要在实施以前要想清楚的问题。是为了实现读写分离,减轻主库负载或数据分析? 为了数据安全,做备份恢复?主从切换做高可用?
大部分场景下,以上三个问号一主一从都能够解决,而且任何生产环境都建议你至少要有一个从库,假如你的读操作压力特别大,甚至要做一主多从,还可以不同的slave扮演不同的角色,例如使用不同的索引,或者不同的存储引擎,或使用一个小内存server做slave只用于备份。(当然slave太多也会对master的负载和网络带宽造成压力,此时可以考虑级联复制,即 A->B->C )。
还有需要考虑的是,一主一从,一旦做了主从切换,不通过其它HA(High Available,是双机集群系统简称,指高可用性集群,是保证业务连续性的有效解决方案,一般有两个或两个以上的节点,且分为活动节点及备用节点。)手段干预的话,业务访问的还是原IP,而且原主库很容易就作废了。于是“主-主”复制就产生了,凭借各自不同的server-id,可以避免“A的变化同步到B,B应用变化又同步到A”这样循环复制的问题。但建议是,主主复制,其中一个主库强制设置为只读,主从切换后架构依然是可用的。
复制过程是slave主动向master拉取,而不是master去推的,所以理想情况下做搭建主从时不需要master做出任何改变甚至停服,slave失败也不影响主库。

复制类型:

  • 基于语句的复制:STATEMENT
  1. 在主服务器上执行的SQL语句,在从服务器上执行同样的语句,有可能会由于SQL执行上下文环境不同而是数据不一致,例如调用NOW()函数。MySQL在5.7.7以前默认采用基于语句的复制,在 5.7.7 及以后版本默认改用 row-based(基于行的)。 基于行的复制:ROW
  2. 把改变的内容复制过去,而不是把命令在从服务器上执行一遍。从mysql5.0开始支持,能够严格保证数据完全一致,但此时用mysqlbinlog去分析日志就没啥意义。因为任何一条update语句,都会把涉及到的行数据全部set值,所以binlog文件会比较大。(遇到的一个坑是,迁移时,从库改正了字段默认值定义,但数据在主库更改后,即使产生的新数据默认值是正确的,但基于行的复制依然用不正确的值字段全部更新了)
  3. 混合类型的复制: MIXED 默认采用基于语句的复制,一旦发现基于语句的无法精确的复制时,就会采用基于行的复制。

> mysql系统库mysql库里面表的日志记录格式需要说明:在通过如INSERT、UPDATE、DELETE、TRUNCATE等方式直接修改数据的语句,使用binlog_format指定的方式记录,但使用GRANT、ALTER、CREATE、RENAME等改动的mysql库里数据的,会强制使用statement-based方式记录binlog。
可以在线修改二进制日志类型,如SET SESSION binlog_format=MIXED;,需要SUPER权限。
复制类型还可以分为:异步复制和半同步复制。 通常没说明指的都是异步,即主库执行完Commit后,在主库写入Binlog日志后即可成功返回客户端,无需等等Binlog日志传送给从库,一旦主库宕机,有可能会丢失日志。而半同步复制,是等待其中一个从库也接收到Binlog事务并成功写入Relay Log之后,才返回Commit操作成功给客户端;如此半同步就保证了事务成功提交后至少有两份日志记录,一份在主库Binlog上,另一份在从库的Relay Log上,从而进一步保证数据完整性;半同步复制很大程度取决于主从网络RTT(往返时延),以插件 semisync_master/semisync_slave 形式存在。

原理:

  • master将改变记录到二进制日志(binary log)中(这些记录叫做二进制日志事件,binary log events);
  • slave将master的binary log events拷贝到它的中继日志(relay log);
  • slave重做中继日志中的事件,将改变反映它自己的数据。

mark

  • 该过程的第一部分就是master记录二进制日志。在每个事务更新数据完成之前,master在二进制日志记录这些改变。MySQL将事务串行的写入二进制日志,即使事务中的语句都是交叉执行的。在事件写入二进制日志完成后,master通知存储引擎提交事务。
  • 下一步将master的binary log拷贝到它自己的中继日志。首先,slave开始一个工作线程——I/O线程。I/O线程在master上打开一个普通的连接,请求从指定日志文件的指定位置之后的日志内容,然后开始binlog dump process。Binlog dump process从master的二进制日志中读取事件,如果已经跟上master,它会睡眠并等待master产生新的事件。I/O线程将这些事件写入中继日志。
  • SQL slave thread(SQL从线程)处理该过程的最后一步。SQL线程从中继日志读取事件,并重放其中的事件而更新slave的数据,使其与master中的数据一致。只要该线程与I/O线程保持一致,中继日志通常会位于OS的缓存中,所以中继日志的开销很小。

> 此外,在master中也有一个工作线程:和其它MySQL的连接一样,slave在master中打开一个连接也会使得master开始一个线程。
复制过程有一个很重要的限制——复制在slave上是串行化的,也就是说master上的并行更新操作不能在slave上并行操作。

其他

  • mysql 5.7开始加入了多源复制,这个特性对同时有很多个mysql实例是很有用的,阿里云RDS(迁移)实现了类似的方式。
  • 从MySQL 5.6.2开始,mysql binlog支持checksum校验,并且5.6.6默认启用(CRC32 ),这对自己模拟实现mysql复制的场景有影响。

> CRC32(Cyclic Redundancy Check)校验实用程序库在数据存储和数据通讯领域,为了保证数据的正确,就不得不采用检错的手段。在诸多检错手段中,CRC是最著名的一种。CRC的全称是循环冗余校验。

共有 人打赏支持
粉丝 2
博文 72
码字总数 84309
×
脑洞老湿_
如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
* 金额(元)
¥1 ¥5 ¥10 ¥20 其他金额
打赏人
留言
* 支付类型
微信扫码支付
打赏金额:
已支付成功
打赏金额: