mysql主从主主与集群

主从复制

主从复制原理

mysql主从主主与集群

在Slave 服务器上执行start slave命令开启主从复制开关，开始进行主从复制。
此时，Slave服务器的IO线程会通过在master上已经授权的复制用户权限请求连接master服务器，并请求从执行binlog日志文件的指定位置（日志文件名和位置就是在配置主从复制服务时执行change master命令指定的）之后开始发送binlog日志内容
Master服务器接收到来自Slave服务器的IO线程的请求后，其上负责复制的IO线程会根据Slave服务器的IO线程请求的信息分批读取指定binlog日志文件指定位置之后的binlog日志信息，然后返回给Slave端的IO线程。返回的信息中除了binlog日志内容外，还有在Master服务器端记录的IO线程。返回的信息中除了binlog中的下一个指定更新位置。
当Slave服务器的IO线程获取到Master服务器上IO线程发送的日志内容、日志文件及位置点后，会将binlog日志内容依次写到Slave端自身的Relay Log（即中继日志）文件（MySQL-relay-bin.xxx）的最末端，并将新的binlog文件名和位置记录到master-info文件中，以便下一次读取master端新binlog日志时能告诉Master服务器从新binlog日志的指定文件及位置开始读取新的binlog日志内容
Slave服务器端的SQL线程会实时检测本地Relay Log 中IO线程新增的日志内容，然后及时把Relay LOG 文件中的内容解析成sql语句，并在自身Slave服务器上按解析SQL语句的位置顺序执行应用这样sql语句，并在relay-log.info中记录当前应用中继日志的文件名和位置点

主从复制模式

异步模式

mysql主从主主与集群

如上图，就是主服务接受到客户端的操作请求，则正常执行然后记录到binlog日志后，就直接返回给客户端结果。在此期间不会考虑binlog日志是否完整传输到从服务器以及是否完整存放到从服务器上的relay日志中。主节点的log dump线程再去发送日志到从服务。这种模式对客户端的响应返回最快，但是一旦主服务(器)宕机，数据就可能会因为没有及时发送给从服务而导致从服务数据丢失。

半同步模式

mysql主从主主与集群

如上图，这种模式下，当主服务写入binlog日志后，就会通知log dump线程发送日志到从服务的I/O线程，等待从服务将日志写入到relay log中，然后返回给主服务一个确认通知，主服务只要接受到一个从服务的确认通知，就会返回给客户端结果，否则需要等待直到超时时间然后切换成异步模式再返回给客户端结果。这样做的目的可以使主从数据库的数据延迟缩小，可以提高数据安全性，确保了事务提交后，binlog至少传输到了一个从节点上，虽然不能保证从节点将此事务更新到db中，但确保了binlog日志已经记录到relay log中。性能上会有一定的降低，客户端响应时间会变长。

全同步模式

此中模式就是在半同步的基础上，等待从服务的I/O线程和SQL线程都执行完毕，将数据更新到从服务器后，返回确认信息后，主服务才返回给客户端成功信息。此中模式完全保证了主从服务的数据一致性，但是相应的响应时间会变长，性能较低。

主从复制方式

传统方式

传统方式即是基于binlog日志的position点来指定日志从什么位置开始执行增量同步，如果这个设置的不对，就会导致主从数据不一致。

GTID 方式

基于GTID的复制是从Mysql5.6开始支持的一种新的复制方式，此方式与传统基于日志的方式存在很大的差异，在基于GTID的复制中，首先从服务器会告诉主服务器已经在从服务器执行完了哪些事务的GTID值，然后主库会有把所有没有在从库上执行的事务，发送到从库上进行执行，并且使用GTID的复制可以保证同一个事务只在指定的从库上执行一次，这样可以避免由于偏移量的问题造成数据不一致。

GTID方式可以很方便的进行故障转移，记录master最后事务的GTID值。比如master：A，slave：B,C。当A挂了后，B执行了所有A传过来的事务。当C连接到B后，在自己的binlog找到最后一次A传过来的GTID。然后C将这个GTID发送给B，B获取到这个GTID，就开始从这个GTID的下一个GTID开始发送事务给C。这种自我寻找复制位置的模式减少事务丢失的可能性以及故障恢复的时间。且slave不会丢失master的任何修改。虽然不支持非事务引擎，故障处理比较复杂，但作为5.6新引入的功能，以取代旧的传统方式。还是推荐使用GTID方式

什么是GTID，也就是全局事务ID，其保证为每一个在主上提交的事务在复制集群中可以生成一个唯一的ID。

binlog格式选择

STATEMENT

基于SQL语句的复制（statement-based replication，SBR），只记录执行的sql，不需要记录每一行数据的变化，减少bin-log日志量，节约IO，提高性能，但是由于记录的执行语句，所以为了让这些语句在slave端也能正确执行，那么他还必须记录每条语句在执行的时候的一些相关信息，也就是上下文信息，且对非确定性时间，无法保证主从复制数据的一致性，比如uuid()。从而导致主从数据一致性，造成复制链路中断。所以一般为了复制都不会使用此格式。

ROW

基于行的复制（row-based replication，RBR)，日志中会记录每一行数据被修改的形式，然后在slave端再对相同的数据进行回放，仅仅只需要记录那一条记录被修改了，修改成什么样了。所以日志内容会非常清楚的记录下每一行数据修改的细节。任何情况都可以被复制，这对复制来说是最安全可靠的，但是所有的执行的语句当记录到日志中的时候，都将以每行记录的修改来记录，这样可能会产生大量的日志内容。对于性能要求不高的，数据量不大的可以采用此日志记录格式。

MIXED

混合模式复制（mixed-based replication,MBR)，就是上面两种格式的混合，由mysql根据语句和操作选择记录日志的方式，将上面两种方式的优点都集合了，所以推荐使用此日志格式。

主从复制优点

在从服务器可以执行查询工作(即我们常说的读功能)，降低主服务器压力;（主库写，从库读，降压）
在从主服务器进行备份，避免备份期间影响主服务器服务;（确保数据安全）
当主服务器出现问题时，可以切换到从服务器。（提升性能）

主从复制缺点

master和slave已经实现同步，即在master上写入新数据，自动同步到slave。而从库只能读不能写，一旦从库有写入数据，就会造成主从数据不一致！
只是提供一种成本较低的数据备份方案加不完美的容灾和负载均衡

主从复制条件

开启Binlog功能
主库要建立账号
从库要配置master.info（CHANGE MASTER to…相当于配置密码文件和Master的相关信息）
start slave 开启复制功能
Mysql复制最好确保master和slave服务器上的Mysql版本相同（如果不能满足版本一致，那么要保证master主节点的版本低于slave从节点的版本）
master和slave两节点间时间需同步
作为复制的所有Mysql节点的server-id都不能相同
binlog文件只记录对数据库有更改的SQL语句（来自主库内容的变更），不记录任何查（select，show）语句

主从复制实践

架构篇——MySQL主从复制(Master-Slave)详解

MySql主主(主从)同步配置详解

show master status 和 show slave status 可以查看复制线程状态，状态详解参考：https://blog.csdn.net/qq_33285112/article/details/78793539

主主复制

主从复制：主库授权从库远程连接，读取binlog日志并更新到本地数据库的过程；主库写数据后，从库会自动同步过来（从库跟着主库变）；
主主复制：主从相互授权连接，读取对方binlog日志并更新到本地数据库的过程；只要对方数据改变，自己就跟着改变；

主主复制注意点

主主复制和主从复制有一些区别，因为多主中都可以对服务器有写权限，所以设计到自增长重复问题，例如：出现的问题（多主自增长ID重复）

首先在A和B两个库上创建test表结构;
停掉A，在B上对数据表test(存在自增长属性的ID字段)执行插入操作，返回插入ID为1;
然后停掉B，在A上对数据表test(存在自增长属性的ID字段)执行插入操作，返回的插入ID也是
然后同时启动A,B，就会出现主键ID重复

解决方法：

在主主同步配置时，需要将两台服务器的auto_increment_increment 设置为 n, auto_increment_offset 分别配置为1 2 ..., 第一台从1开始，第二台就是2，以此类推

集群

官方 mysql cluster

需要用到mysql cluster安装包，在集群中的每一个机器上安装。

有三个关键概念：Sql节点（多个），数据节点（多个），管理节点（一个），数据节点之间采用的是同步复制来保证各节点之间的数据一致性。

同步复制：

Master执行提交语句时，事务被发送到slave，slave开始准备事务的提交。
每个slave都要准备事务，然后向master发送OK(或ABORT)消息，表明事务已经准备好（或者无法准备该事务）。
Master等待所有Slave发送OK或ABORT消息，如果Master收到所有 Slave的OK消息，它就会向所有Slave发送提交消息，告诉Slave提交该事务；如果 Master收到来自任何一个Slave的ABORT消息，它就向所有 Slave发送ABORT消息，告诉Slave去中止事务。
每个Slave等待来自Master的OK或ABORT消息。如果Slave收到提交请求，它们就会提交事务，并向Master发送事务已提交的确认；如果Slave收到取消请求,它们就会撤销所有改变并释放所占有的资源，从而中止事务，然后向Masterv送事务已中止的确认。
Master收到来自所有Slave的确认后，就会报告该事务被提交（或中止），然后继续进行下一个事务处理。
由于同步复制一共需要4次消息传递，故mysql cluster的数据更新速度比单机mysql要慢。所以mysql cluster要求运行在千兆以上的局域网内，节点可以采用双网卡，节点组之间采用直连方式。

mysql主从主主与集群

galera cluster

简介

mysql主从主主与集群

图中有三个实例，组成了一个集群，而这三个节点与普通的主从架构不同，它们都可以作为主节点，三个节点是对等的，这种一般称为multi-master架构，当有客户端要写入或者读取数据时，随便连接哪个实例都是一样的，读到的数据是相同的，写入某一个节点之后，集群自己会将新数据同步到其它节点上面，这种架构不共享任何数据，是一种高冗余架构。

一般的使用方法是，在这个集群上面，再搭建一个中间层，这个中间层的功能包括建立连接、管理连接池，负责使三个实例的负载基本平衡，负责在客户端与实例的连接断开之后重连，也可以负责读写分离（在机器性能不同的情况下可以做这样的优化）等等，使用这个中间层之后，由于这三个实例的架构在客户端方面是透明的，客户端只需要指定这个集群的数据源地址，连接到中间层即可，中间层会负责客户端与服务器实例连接的传递工作，由于这个架构支持多点写入，所以完全避免了主从复制经常出现的数据不一致的问题，从而可以做到主从读写切换的高度优雅，在不影响用户的情况下，离线维护等工作，MySQL的高可用，从此开始，非常完美。

现在已经知道，Galera Cluster是MySQL封装了具有高一致性，支持多点写入的同步通信模块Galera而做的，它是建立在MySQL同步基础之上的，使用Galera Cluster时，应用程序可以直接读、写某个节点的最新数据，并且可以在不影响应用程序读写的情况下，下线某个节点，因为支持多点写入，使得Failover变得非常简单。

所有的Galera Cluster，都是对Galera所提供的接口API做了封装，这些API为上层提供了丰富的状态信息及回调函数，通过这些回调函数，做到了真正的多主集群，多点写入及同步复制，这些API被称作是Write-Set Replication API，简称为wsrep API。

通过这些API，Galera Cluster提供了基于验证的复制，是一种乐观的同步复制机制，一个将要被复制的事务（称为写集），不仅包括被修改的数据库行，还包括了这个事务产生的所有Binlog，每一个节点在复制事务时，都会拿这些写集与正在APPLY队列的写集做比对，如果没有冲突的话，这个事务就可以继续提交，或者是APPLY，这个时候，这个事务就被认为是提交了，然后在数据库层面，还需要继续做事务上的提交操作。

这种方式的复制，也被称为是虚拟同步复制，实际上是一种逻辑上的同步，因为每个节点的写入和提交操作还是独立的，更准确的说是异步的，Galera Cluster是建立在一种乐观复制的基础上的，假设集群中的每个节点都是同步的，那么加上在写入时，都会做验证，那么理论上是不会出现不一致的，当然也不能这么乐观，如果出现不一致了，比如主库（相对）插入成功，而从库则出现主键冲突，那说明此时数据库已经不一致，这种时候Galera Cluster采取的方式是将出现不一致数据的节点踢出集群，其实是自己shutdown了。