1、方案调研
公司最近在做集控二期的开发，系统原先的数据库层面是单节点的DB服务， 如果面对大并发，海量数据的存储，显然单机诶单系统架构就会存在严重的问题，因此实现MySQL 的进群，来应对大并发、大量数据存储等问题是势在必行的。
1.1、方案一：读写分离架构方案
1.1.1、说明
我们一般应用对数据库而言都是读多写少，也就是说对数据库读取数据的压力比较大，有一个思路就是采用数据库集群方案，
- 其中一个库是主库，负责写入数据，我们称之为，写库。
- 其他都是从库，负责读取数据，我们称之为，读库。
那么我们对二者之间的要求是
- 读库和写库的数据一致
- 写数据必须写到写库
- 读数据必须到读库
1.1.2、原理图
上图大致阐述了mysql的主从复制原理。即：主从服务器通过I/O线程通讯。二进制日志记录了数据的更新情况，从节点就是通过读取主节点的二进制日志来进行数据复制的。
从该系统架构中，可以看出：
- 数据库从之前的单节点编程多节点提供服务
- 主节点数据，同步到从节点数据
- 应用程序需要连接到2个数据库节点，并且在程序内部实现判断读写操作。
该架构存在2个问题：
-
问题一、应用程序需要连接多个节点，对应程序而言开发变得复杂
-
这个问题，可以通过中间件解决
-
这样，从架构层面来看；
- 应用程序只需要连接到中间件即可，无序连接多个数据库节点
- 应用程序无序区分读写操作，对中间件直接进行读写操作即可
- 在中间件中进行区分读写操作， 读发送给从节点， 写发送到主节点。
-
但是上述架构存在性能瓶颈，中间件这块，因此又有了如下方式去解决
-
但是上述方法又带来了应用系统开发的复杂度。
- 应用系统需要连接多个中间件。
-
解决上述问题的，继续优化架构，可以通过负载均衡来处理，在应用程序和中间件之间增加proxy代理，由代理来完成负载均衡的功能，应用程序只需要接到proxy即可。
- 至此， 主从复制架构的高可用架构才算搭建完成。
-
-
如果再程序内部实现，可使用Spring 的AOP 功能实现。原理图如下：
-
问题二、主从之间的同步，是异步完成的，也就意味着这是弱一致性的。
- 可能会导致，数据库写入主库后，应用程序读取从库获取不到数据，或者可能会丢失数据，对数据安全性要求比较高的应用是不适合的。
- 该问题可以通过PXC集群解决。
-
1.2、方案二：PXC架构
-
前面所说的架构，都是基于MySQL主从的架构，那么在主从架构中弱一致性问题依然没有得到解决，如果需要强一致性需求，显然上述架构是不能应对的，典型的是比如：交易数据。
-
PXC提供了读写强一致性的功能，可以保证数据在任何一个节点写入的同时可以同步到其他节点，也就意味着可以从其他的任何节点进行读取操作，无延时。
-
PXC只是解决了我们强一致性，但是性能相对主从架构较低
- 在写操作的时候， PXC首先要做的是与其他节点的PXC 做同步， 同步完成后才会做事务的提交，因此需要消耗相应的性能和时间。
-
系统架构图如下
1.3、方案三:混合架构方案
在前面我们所说的PXC架构中，虽然可以实现事务的强一致性，但是它是通过牺牲了性能来换取一致性，如果再某些业务场景下，如果没有强一致性需求， 那么使用PXC就不合适了，所哟， 在我们系统的架构中没需要将这两种综合起来， 这样才是一个较为完善的架构。
2、主（master）从（slave）复制原理分析
- master 将数据改变记录到二进制日志（binary log）中， 也即是配置文件 log-bin 指定的文件（这里记录的是二进制日志事件，binary log events）
- slave 将master 的binary log events 拷贝到他的中继日志（relay log）
- slave 重做中继日志中的时间，将改变反应他自己的数据（数据重演）
- 主从配置需要注意的地方：
- 主 DB server 和 从 DB server 数据库的版本一致
- 主 DB server 和 从 DB server数据库数据一致
- 主 DB server 开启二进制日志， 主DB server 和从DB server的server_id 都必须唯一。
2.1、binlog 日志存储形式
在查看二进制日志相关参数内容中， 会发现默认的模式ROW,其实在MySQL中提供了有三种模式
- 基于SQL语句的复制 --
statement-based replication ,SBR- 每一条会修改数据的sql语句会记录到binlog中。
- 优点：并不需要记录每条sql语句和每一行的数据变化，减少了binlog日志量，节约IO,提供性能。
- 缺点：在某些情况下回导致master-slave中的数据不一致（如sleep()函数，last_insert_id()等会出现问题）
- 每一条会修改数据的sql语句会记录到binlog中。
- 基于行的复制 --
row based replication ,RBR- 不记录每条sql语句的上下文信息，仅需记录哪条数据被修改了， 修改成什么样子了。而且不会出现某些特定情况下的存储过程、或function、或trigger的调用和出发无法被正确复制的问题。
- 缺点是 会产生大量的日志，尤其是 alter table的时候日志会暴涨。
- 混合模式复制 --
mixed-based replicaion ,MBR- 以上两种方式混合使用，一般的复制使用STATEMENT模式保存binlog，对于STATEMENT 模式无法复制的操作使用ROW模式保存binlog，MySQL会根据执行的SQL语句选择日志保存方式。
3、主从配置相关SQL语句
#创建同步账户以及授权
create user 'slave01'@'%' identified by 'slave01';
grant replication slave on *.* to 'slave01'@'%';
flush privileges;
# 查看二进制日志相关配置项
show global variables like 'binlog%';
# 查看server相关配置项
show global variables like 'server%';
# 查看master 状态
show master status;
# 查看slave 状态
show slave status;
# 开启slave从库
start slave;
# 关闭从库
stop slave;
# 从库执行的配置master信息的语句
CHANGE MASTER TO
master_host='192.168.1.181',
master_user='slave01',
master_password='slave01',
master_port=3306,
master_log_file='mysql-bin.000002', # 这部分内容通过 show master status 查看
master_log_pos=648; # 这部分内容通过 show master status 查看
