mysql复制基础

软件环境：mysql版本5.7，centos7.3

mysq复制是异步的复制，主节点和从节点之间会从在一定的延迟，延迟的大小和几个部分有关（比如业务对数据库的写操作的频率、数据的大小等有关系）；

图1：mysql主从同步结构

1.master上进行数据的写操作（change datas），开启MySQL的Binarylog特性之后（这里我们默认开启）master会把这些操作写入到Binarylog中；
2.在slave上会有两个线程，一个IO thread线程（负责读取master上的Binarylog并存储到slave上的Relaylog中），一个SQL thread线程（负责读取Relaylog中的日志，并在slave中存放这日志，从而达到数据同步的目的）；
3.从上图可以看出，影响主从同步的关键点有：IO thread线程读取Binarylog的速度和SQL线程存放Binarylog的速度；
4.上图中的master上对数据库的操作是可以并行进行的，也就是说我们在master上可以使用多个线程同时进行增删改查这种CRUD操作。我们只有在master上完成了写操作之后，master才会将写操作写入到Binarylog中，而这个写入log的过程是一个线性的过程，也就是说不能并发。
5.而当slave上的IO thread将数据读取并写入到slave上的Relaylog中，SQL thread同过Relaylog来存放数据更改日志的时候，在slave上的SQLthread线程默认也是单线程的。这样的话，就会出现这样一种问题，我们在master上的并发操作，在slave上是线性执行的，这就可能是造成主从延时的一个主要原因。

无延迟的集群架构（pxc），是一个多写的集群，向多个MySQL中写数据。

QPS：Queries Per Second意思是“每秒查询率”，是一台服务器每秒能够相应的查询次数，是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准。
TPS：是TransactionsPerSecond的缩写，也就是事务数/秒。它是软件测试结果的测量单位。一个事务是指一个客户机向服务器发送请求然后服务器做出反应的过程。客户机在发送请求时开始计时，收到服务器响应后结束计时，以此来计算使用的时间和完成的事务个数，

理解如下： 1、Tps即每秒处理事务数，包括了 1）用户请求服务器 2）服务器自己的内部处理 3）服务器返回给用户
这三个过程，每秒能够完成N个这三个过程，Tps也就是3；

当然，这样的延迟是比较小的，通常意义上是ns或者ms级别的。

基于主从复制的数据同步架构由于异步的原因存在一定的延时，但是可以通过一些优化的手段降低这种延时对用户的影响。

mysql复制是基于binarylog的复制

参考：
二进制日志是什么？查看《高可用MySQL.pdf》

Binlog日志格式：

• statement：存储sql语句，日志量少；
• Row：存储event数据，日志量大，不能直接进行读取，可能造成延时；
• Mixed：介于Row和Statement之间，对于不确定的操作使用Row记录；

mysql的复制可以是整个库的复制，也可以是对某个数据库的复制。

Mysql 的复制类型

• 基于二进制日志的复制
• 基于事物的复制（使用GTID），后面我们会继续讨论基于事物的复制

问题讨论

我们知道基于日志的复制是MySQL5.5之前支持的唯一的复制方式，这种复制要求我们在进行主从同步复制的时候必须能够明确的知道当前从上的数据所对应的主上的日志文件（File）和日志点（Position）。特别是在一主多从的情况下，如果主宕机，要进行主从切换的时候，必须从多个从中选取一个主来，此时如何使其他从和这个新的主进行同步，就是我们面对的一个重要问题。因为我们无法清楚的知道新的主所对应的从上数据的日志文件（file）和日志点（Position）到底是哪一个。

为了解决上述的问题，MySQL在5.6之后推出了一个基于事物的复制方法，基于事物的复制使用GTID这个概念，GTID表示全局唯一标识符。这种方式的实现原理简单来说就是，每一个在master上所提交的事物都有一个全局唯一的标识，当从上需要同步的时候，就可以容易的知道那些事物已经执行。对数据的完整性就能得到保障。

MySQL的半同步复制

半同步复制其实是一种软件上的约定的同步，其实还是一种异步复制过程。可能造成延迟。