#说在前面

PAAS领域中有一个重要的部分，那就是数据库，无论是关系型(如Oracle)还是非关系型(如HBase)，无论是行式数据库(如SqlServer)还是列式数据库(如ClickHouse)，我们在生产环境中是不忍心让这些"数据库爷爷"们孤独的自运行，一定会给它(们)至少找一个"兄弟"，一起为业务系统提供数据交互的承载平台；So，Oracle的RAC、SqlSever的AlwaysOn、Mysql(Mariadb)的主从复制等等类似这样的集群、读写分离机制，都是给数据库安排"葫芦娃"式的兄弟合力共创所提供的解决方案。UP楠哥深知这部分的内容在PAAS领域中占据非常重要的位置，在未来的篇章中给那些已经在IAAS领域的知识体系已有深刻理解同时还想在PAAS中深挖的童鞋们做一些参考，一起来看关于数据库集群方案中的实现要点和效果验证；今天我们先从Mysql(Mariadb)的主从复制开始聊起。Let's go！

 

#Mysql(Mariadb)的主从复制原理概述

Mysql(Mariadb)主从同步是基于从库对主库Binlog文件的增量实现，复制的工作主要是由主库上Master dump线程、从库上的Slave IO线程以及SlaveSQL线程完成。

当在从库上执行START SLAVE 语句来开启复制功能时，会产生一个SlaveIO线程和一个slave SQL线程。slave IO线程负责连接到主库，然后接收主库master dump线程发送过来的Binlog内容，写到本地的Relay-log中。slave SQL线程负责重放relay-log中的内容，将主库的所有修改反映到从库上。

复制的大概过程可以总结为如下3步：

（1）主库将所有的修改以事件的形式记录到binlog中，主库的Master Dump线程负责发送Binlog内容到从库；

（2）从库的SlaveIO线程将接收到的Binlog事件记录到从库本地的Relay-log中；

（3）从库的SlaveSQL线程重放Relay-log中的事件。

 

#Mysql(Mariadb)的主从复制集群模式

Mysql(Mariadb)主从复制架构有一主多从复制架构、多级复制架构等，当然，还有什么双主(Dual Master)复制架构等。

##一主多从复制架构

在Mariadb-Master库读取请求压力很大的情况下，通过配置一主多从复制架构实现读写分离，把对实时性要求不高读方面的数据请求分摊到多个Mariadb-Slave库上，与此同时，可以使用类似LoadBalancer负载机制，从而降低Mariadb-Master库的读压力。另外，在Mariadb-Master库出现异常宕机的情况下，可以把一个Mariadb-Slave库切换为Mariadb-Master库继续提供服务。逻辑图如下：

##多级复制架构

既然有了一主多从复制架构，为何还要再有多级复制架构呢？一直多从复制架构看似解决了很多问题，但其实还有些许瑕疵的。

相比较对比一主多从的架构，多级复制架构只是在一主多从的架构基础之上主库增加了一个Mariadb-Master2的角色，这样的话，Mariadb-Master1只给Mariadb-Master2发送Binlog日志就可以，从而减轻了Mariadb-Master1的压力；此时，Mariadb-Master1再发送Binlog日志给Mariadb-Slave所有从库节点。具体如下：

既然又多了一层，延迟的问题也会如期而至，一定会比一主多从复制架构产生的延迟问题更多。别担心，有一个被称作“BLACKHOLE“的引擎，可以在Mariadb-Master2上选择表引擎为BLACKHOLE来降低多级复制的延迟。写入BLACKHOLE表的数据并不会落到磁盘上，BLACKHOLE表永远都是”空“表，诸如INSERT、UPDATE、DELETE等DML语句操作仅仅在BINLOG中记录事件。

 

##双主复制架构

在双主复制架构中，Mariadb-Master1和Mariadb-Master2互为主从，Client的读&写操作请求都访问主库Mariadb-Master1或Mariadb-Master2。通过双主复制架构可以减轻一主多从架构下Mariadb-Master1库进行维护带来的额外搭建Mariadb-Slave库的工作。

#Binlog格式

这个时候，我们就要看下Binlog包含了哪些格式，具体如下：

（1）Statement：记录每一条更改数据的sql优点：binlog文件较小，节约I/O，性能较高。缺点：不是所有的数据更改都会写入binlog文件中，尤其是使用MySQL中的一些特殊函数（如LOAD_FILE()、UUID()等）和一些不确定的语句操作，从而导致主从数据无法复制的问题。

（2）Row：不记录sql，只记录每行数据的更改细节优点：详细的记录了每一行数据的更改细节，这也意味着不会由于使用一些特殊函数或其他情况导致不能复制的问题。缺点：由于row格式记录了每一行数据的更改细节，会产生大量的binlog日志内容，性能不佳，并且会增大主从同步延迟出现的几率。

（3）Mixed：一般的语句修改使用statment格式保存binlog，如一些函数，statement无法完成主从复制的操作，则采用row格式保存binlog，MySQL会根据执行的每一条具体的sql语句来区分对待记录的日志形式，也就是在Statement和Row之间选择一种。

鉴于以上三种格式，我们到底怎么选才合适呢，UP楠哥通过生产环境实践，建议大家选择Mixed这种格式是最合适的Binlog-format。接下来，我们看，UP楠哥找来了Linux 7.x版本和Linux8.x版本所自带的mariadb软件包安装后所默认的Binlog格式。

第一张图是来自于Linux7.x自带的mariadb版本为5.5.56版本俨然有些老气^-^当然这不是重点，重点是红框框内的STATEMENT，表示默认情况下的Binlog_format。

第二张图是来自于Linux8.x自带的mariadb版本为10.3.17，红框框内的MIXED，表示较新版本的mariadb默认情况下的Binlog_format。

 

#更改binlog-format

刚才UP楠哥也有提到过，通过生产环境实践，建议大家选择Mixed这种格式是最合适的Binlog-format。我们来看下如何更改，具体如下：

更改完成后，执行systemctl restart mariadb，再进行查看会发现格式变成了Mixed。

#Binlog的复制模式

最后再来唠一唠Binlog的复制模式，具体如下：

ü 异步复制（Asynchronous replication）

ü 全同步复制（Fully synchronous replication）

ü 半同步复制（Semisynchronous replication）

ü MGR 组复制（MySQL Group Replication，简称MGR是半同步复制改进版本）在mysql5.7之后的版本能够实现无损复制。

 

#主从复制实现的效果

通过主从复制机制所实现的效果，具体如下：

通过sql语句在Mariadb-Master库创建一个测试数据库，创建后到Mariadb-Slave库执行show databases;会看到有同样的数据库名称存在。

此时看到这里，大家就知道效果了，当然也可以做一些表的创建和数据的插入去验证同步复制的效果，具体详细的我就不再给大家做过多演示。详细的实现步骤，大家可以关注下UP楠哥后期的Online公开课，UP楠哥会在公开课演示实战步骤，后续也会放到实战部分的潮流小文中供大家参考使用！