mysql的复制及备份

概述

MySQL整体来看，其实就有两块：一块是Server层，它主要做的是MySQL功能层面的事情；还有一块是引擎层，负责存储相关的具体事宜。InnoDB引擎特有的日志是redo log，而Server层的日志称为binlog。binlog记录了对MySQL数据库执行更改的所有操作，binlog文件写到一定大小后会切换到下一个（但一个事务的操作肯定在一个文件中，即大事务引发大文件），其大体作用：

mysql复制原理

master在每个事务更新数据完成之前，将该操作记录串行地写入到binlog文件中，也称为二进制文件。slave开启一个I/O Thread，该线程与master建立连接，master则会启动binlog dump 线程并取binlog事件。如果读取的进度已经跟上了mastermysql备份，就进入睡眠状态并等待master产生新的事件。salve的I/O线程将接收到的事件写入到relay log(中继日志)中,且slave连接master的信息及同步进度数据都会保存在master.info文件中（具体内容参考下面复制方式）。slave 中的 SQL Thread会读取relay log（中继日志），并顺序执行该日志中的SQL事件，从而与主数据库中的数据保持一致。 mysql复制模式 Statement（语句模式）: 每一条会修改数据的sql都会记录在binlog中。 Mixed（混合模式）：在Mixed模式下，一般的语句修改使用statment格式保存binlog，如一些函数，statement无法完成主从复制的操作，则采用row格式保存binlog，MySQL会根据执行的每一条具体的sql语句来区分对待记录的日志形式，也就是在Statement和Row之间选择一种。 MySQL主从复制方式

前提：binlog文件是顺序存储结构的。

区别

对sql查询没有什么限制故障转移时重新获取master的日志点信息比较困难（因为偏移点是批量增长的，时间的话有可能一样）。如果指定错误会造成遗漏或者重复，造成主从不一致。 不支持非事务引擎。对执行的sql有一定的限制。可以很方便的进行故障转移，记录master最后事务的GTID值。（按事务分，比较清晰） Mysql复制类型 MySQL 5.5版本之前，一直采用的是这种异步复制的方式。主库的事务执行不会管备库的同步进度，如果备库落后，主库不幸crash，那么就会导致数据丢失.在MySQL在5.5中就顺其自然地引入了半同步复制，主库在应答客户端提交的事务前需要保证至少一个从库接收并写到relay log中。MySQL在5.7.17中引入了一个全新的技术，称之为InnoDB Group Replication。目前官方MySQL 5.7.17基于Group replication的全同步技术已经问世，全同步技术带来了更多的数据一致性保障 异步复制

MySQL默认的复制即是异步的.

主库将事务Binlog事件写入到Binlog文件中主库通知一下Dump线程发送这些新的Binlog主库就会继续处理提交操作(sync binlog, engine Commit)返回客户端（此时不会保证这些Binlog传到任何一个从库节点上）

最大的问题

master和slave事务更新的不同步，当业务并发上来时，slave因为要顺序执行master批量事务，导致很大的延迟。此时，master如果crash掉了，master上已经提交的事务可能没有传到slave上，如果此时，强行将从提升为主，可能导致新主上的数据不完整。

半同步复制

为解决异步复制的不足，MySQL 5.5~5.6可安装semisync_master.so插件，使用after_commit模式的半同步复制

主库将事务Binlog事件写入到Binlog文件中主库通知一下Dump线程发送这些新的Binlog主库就会继续处理提交操作(sync binlog, engine Commit)，并向从库发生Event。dumper线程等待接收slave的ack工作返回客户端

最大的问题

主库将事务在存储引擎层（engine Commit)提交后，主库发生了crash，Slave端还没有读到该事务的events。此时，虽然主库没有返回当前客户端，但事务已经提交，其他客户端会读取到已提交事务。现在强行将从提升为主，那么之前读到的事务就不见了，出现了幻读。

针对上述的问题，5.7.2引入了Loss-less Semi-Synchronous插件，支持after_sync模式的半同步复制

6. 主库将事务Binlog事件写入到Binlog文件中

7. 主库通知一下Dump线程发送这些新的Binlog

8. 主库就会继续处理提交操作(sync binlog)，并向从库发生Event。

9. Receiver线程等待接收slave的ack工作

10. 主库就会继续处理提交操作engine Commit

11. 返回客户端

两者区别

独立出一个Ack Receiver线程 ，专门用于接收slave返回的ack请求，这将之前dump线程的发送和接受工作分为了两个线程来处理。无损复制在write binlog完成后，就传输binlog，但还没有去写commit log，意味着当前这个事物对数据库的修改，其他事物也是不可见的。因此，不会出现幻读，数据丢失风险。

实际使用中还碰到一种情况从库IO线程有延迟时，主库会自动把半同步复制降为异步复制；当从库IO延迟没有时，主库又会把异步复制升级为半同步复制。

全同步复制

又称组复制。基于传统异步复制和半同步复制的缺陷——数据的一致性问题无法保证，官方在5.7.17版本正式推出组复制（MySQL Group Replication，简称MGR）。

MGR依靠分布式一致性Paxos协议（变体），实现了分布式下数据的最终一致性，并且所有以前特点（功能可参考《日志一致性协议Raft》）

高可用：一台机子挂了，其它正常可扩展：可加节点，新加节点会同步老节点数据（必须基于GTID）容错：容忍 f 个故障机所需的服务器数量 n 为：n = 2 * f + 1。 mysql复制常用拓扑结构

复制的体系结构有以下一些基本原则：

每个slave只能有一个master；每个slave只能有一个唯一的服务器ID；每个master可以有很多slave；如果你设置log_slave_updates，slave可以是其它slave的master，从而扩散master的更新。

常见的拓扑结构有：

备份恢复

“复制是备份”是我们经常碰到一个误区，复制不是备份。如果意外发生主库"drop database",备库能否帮我们恢复所有的数据？而我们的备份方案往往是根据恢复需求而来的。

备份方案

在线备份还是离线备份

快照方式

全量备份还是增量备份

- 全量备份：全部备份下来

- 增量备份：上次全量备份后，所发生改变的数据进行备份

互联网复制备份架构选择

满足以下问题：

主要参考

《高性能Mysql》

《MySQL 5.7半同步复制技术》

《MySQL 8 复制（七）——组复制基本原理》

（编辑：海南站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!