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方式在windows10上进行搭建（linux同），就使用最简单的一主一从形式，主节点M1，从节点M1S1。

 由于这里已经拉取了最新的MySQL镜像（MySQL版本8.2.0），故后续直接使用此镜像启动多个MySQL服务。

1）分别启动主、从节点

docker run --name M1 -p 3307:3306 -e MYSQL_ROOT_PASSWORD=123456 -d mysql
docker run --name M1S1 -p 3308:3306 -e MYSQL_ROOT_PASSWORD=123456 -d mysql

服务器信息如下：

2）修改主节点的配置文件

对于MySQL的配置文件，不同的版本，其位置可能不同，当前使用的版本MySQL配置文件位置是etc/my.cnf。

由于需要修改文件，而容器内部不能使用vi/vim，故需要把配置文件拷出来，修改内容后再拷贝进去。

拷贝主节点的配置

docker cp M1:/etc/my.cnf m1.cnf

会提示复制成功

在[mysqld]的最后添加以下内容：

server-id=1
log-bin=master.bin

截图如下

 保存后，将其再拷贝都docker容器中

docker cp m1.cnf M1:/etc/my.cnf

3）修改从节点的配置

和主节点一样，进行配置，但不需要开启bin-log日志

拷贝从节点的配置

docker cp M1S1:/etc/my.cnf m1s1.cnf

在[mysqld]的最后添加以下内容：

server-id=2

 保存后，将其再拷贝都docker容器中

docker cp m1s1.cnf M1S1:/etc/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）配置从节点的节点信息

在从节点执行

change master to master_host="172.18.80.1",master_port=3307,master_user="rep",master_password="123456",master_log_file="master.000004",master_log_pos=950;

上面分别指定了主节点的主机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。那么从库在删除时，事务就无法提交。

解决：先停止同步，然后删除从库的所有库，再启动同步。