MySQL集群搭建，你会吗
对于目前的应用来说，一般很少使用单机MySQL服务，都会采用主从复制或集群方式，那么如何搭建呢？
1.集群
1.1概述
所谓集群，就是多台服务器之间共享数据，从而实现系统的高可用。节点之间的数据是实时同步的，采用的是同步复制机制。除了有多个主节点外，这些主节点还有多个从节点，当在主节点上进行写操作时，这些写操作会立即被复制到其他节点。因此，所有节点上的数据都是同步的，可以保持一致性。
其特点是高可伸缩性和高可用性，但其缺点也不言而喻，可能会出现数据不一致情况，也会耗费大量的资源。
2.主从复制
2.1什么是主从复制
有一个主数据库（Master）和一个或多个从数据库（Slave）。主数据库负责处理事务操作（INSERT、UPDATE、DELETE），并将这些操作的日志（binlog）传送给从数据库。从数据库通过解析主数据库的日志并执行相同的操作，在从库上实现数据的同步。其作用是可以实现读写分离（主节点负责读和写，从节点只负责读），也可以在发生故障时进行数据的恢复（从数据库相当于是主数据库的备份）
2.2主从复制的形式
其形式有以下几种：
2.3主从复制的原理
在MySQL主从复制中，主要有3个线程，master 1个（binlog dump thread）、slave 2个（I/O thread 、SQL thread）。其执行过程如下：
第一步：在主库中，如果有数据更新，则主库会将数据的事务操作DML记录到二进制日志binary log中（在配置文件中log-bin指定的文件就是日志文件）。
第二步：从库会监听主库的binary log日志文件变化，当发生数据变化后，会将主库的日志文件拷贝到它的中继日志（relay log）中，放在末端。I/O线程会不断的去请求主库的bin-log日志，并将日志写入到relay log中，此时主库会生成一个log dump线程，用来给从库I/O线程传输bin-log日志文件。而且会将读取到的Master端的bin-log的文件名和位置记录到master-info文件中，以便在下一次读取的时候能够清楚的告诉Master “我需要从某个bin- log的哪个位置开始往后的日志内容，请发给我”。
第三步：从库会更新relay log文件中的操作，将数据的改变在从库中进行数据重演（即SQL线程执行操作，将日志文件中的记录变为数据操作行为再次执行，以达到主从数据最终一致性的目的）。
2.4搭建主从复制架构（一主一从）
这里使用使用docker方式在Linux上进行搭建，就使用最简单的一主一从形式，主节点M1，从节点M1S1。
由于这里已经拉取了最新的MySQL镜像（MySQL版本8.0.23），故后续直接使用此镜像启动多个MySQL服务。
docker pull daocloud.io/library/mysql:latest
1）分别启动主、从节点(8457e9155715是下载的镜像的id)
docker run -d --name M1 -p 3307:3306 -e MYSQL_ROOT_PASSWORD=123456 8457e9155715 docker run -d --name M1S1 -p 3308:3306 -e MYSQL_ROOT_PASSWORD=123456 8457e9155715
服务器信息如下：
| 节点名称 | ip | 端口 | 说明 |
| M1 | 172.18.80.1 | 3307 | 主节点 |
| M1S1 | 172.18.80.1 | 3308 | 从节点 |
2）修改主节点的配置文件
对于MySQL的配置文件，不同的版本，其位置可能不同，当前使用的版本MySQL配置文件位置是etc/mysql/my.cnf。
由于需要修改文件，而容器内部不能使用vi/vim，故需要把配置文件拷出来，修改内容后再拷贝进去。
拷贝主节点的配置
docker cp M1:/etc/mysql/my.cnf M1.cnf
会提示复制成功
在[mysqld]的最后添加以下内容：
server-id=1 log-bin=master.bin
截图如下
保存后，将其再拷贝都docker容器中
docker cp M1.cnf M1:/etc/mysql/my.cnf
3）修改从节点的配置
和主节点一样，进行配置，但不需要开启bin-log日志
拷贝从节点的配置
docker cp M1S1:/etc/mysql/my.cnf m1s1.cnf
在[mysqld]的最后添加以下内容：
server-id=2
保存后，将其再拷贝都docker容器中
docker cp m1s1.cnf M1S1:/etc/mysql/my.cnf
4）重启MySQL服务
docker restart M1 M1S1
重启后两个数据库均可连接成功
5）在主节点中创建一个用户，用于数据的同步（这里直接使用navicat连接后操作）
create user 'rep'@'%' identified by '123456'; grant replication slave on *.* to 'rep'@'%'; flush privileges;
6）查询主节点的节点信息
show master status;
查询结果如下，其中file指的是主节点的日志文件名称，position就是偏移量，这两个字段值在每次重启服务后会变。
7）配置从节点的节点信息
首先在从节点使用rep用户登录主节点（这一步不可省略）
mysql -u rep -h 172.18.80.1 -P 3307 -p
然后再使用root登录从节点，执行
change master to master_host="172.18.80.1",master_port=3307,master_user="rep",master_password="123456",master_log_file="master.000001",master_log_pos=853;
上面分别指定了主节点的主机ip，端口号，数据同步的用户名，密码，日志文件名称及日志偏移量。这里的主机ip不能使用127.0.0.1，原因是不同的docker容器网络默认不互通。
8）启动从节点的数据同步
在从节点执行下面命令来开启同步
start slave;
9）查看主从同步状态
在从节点执行，不能直接在navicat中执行，需要在MySQL命令行执行
show slave status \G;
看到下面两个都是yes则说明配置主成功，如果未成功，请参考下一小节进行问题的排查和解决
10）配置成功后，还需要测试。在M1中新建数据库或表或添加数据，发现数据都会同步，自此主从同步搭建完成
注：主从搭建完成，所有的写操作请在主节点上进行，从节点只负责读。也就是所谓的读写分离。数据同步是单向的，只会从主库同步到从库，不会反向同步。
2.5主从搭建可能出现的问题
1）Slave_IO_Running是Connecting而不是Yes
原因：这种情况主要就是从节点配置节点信息时参数不正确，也会有错误信息。
解决：这时先停止同步，然后参考上一小节第7步，将其修改为正确的。再开启同步后查询同步状态
stop slave; 停止 start slave; 开启
2）1）Slave_IO_Running是No而不是Yes
原因：从节点server-id 没有配置成功（我当时就改了文件但忘了拷贝进去）
解决：修改从节点的server-id并拷贝到从节点中，再重启从节点的服务。
3）Slave_SQL_Running是No而不是Yes
原因：这种情况通常时主从服务数据不一致造成的，导致从节点在执行同步SQL时遇到事务问题一直处于阻塞状态。比如在主库有个表是t_user，而在从库却叫sys_user。那么从库在删除时，事务就无法提交。
解决：先停止同步，然后删除从库的所有库，再启动同步。
