概述：Mysql集群的方式可以是很多的，主从，一主多从，多组多从，主从的策略还可以进一步选择和配置。可以说是很灵活了。本文介绍的Replication是异步复制同步方案，分别有基于日志的还有基于GTID的。在docker环境下体验一下。
Replication
Replication是mysql异步复制同步方案，不难理解。异步复制速度快，但是一致性差。对于一些不特别重要的数据可以采用这总方案来同步，比如说日志这些数据。对业务影响不大的数据。
拉取mysql 5.7镜像
docker pull mysql:5.7
AI 代码解读
docker images 查看镜像
实例化两个docker容器
echo "Asia/shanghai" > /home/jorge/docker/mysql-master/timezone
docker run -p 3308:3306 \
--name mysql-master \
-v /home/jorge/docker/mysql-master/conf:/etc/mysql/conf.d \
-v /home/jorge/docker/mysql-master/logs:/logs \
-v /home/jorge/docker/mysql-master/data:/var/lib/mysql \
-v /usr/share/zoneinfo/Asia/Shanghai:/etc/localtime \
-v /home/jorge/docker/mysql-master/timezone:/etc/timezone \
-e MYSQL_ROOT_PASSWORD=123456 \
-d docker.io/mysql:5.7
echo "Asia/shanghai" > /home/jorge/docker/mysql-slave-1/timezone
docker run -p 3309:3306 \
--name mysql-slave-1 \
-v /home/jorge/docker/mysql-slave-1/conf:/etc/mysql/conf.d \
-v /home/jorge/docker/mysql-slave-1/logs:/logs \
-v /home/jorge/docker/mysql-slave-1/data:/var/lib/mysql \
-v /usr/share/zoneinfo/Asia/Shanghai:/etc/localtime \
-v /home/jorge/docker/mysql-slave-1/timezone:/etc/timezone \
-e MYSQL_ROOT_PASSWORD=123456 \
-d docker.io/mysql:5.7
AI 代码解读
docker ps 查看容器实例
方式一：使用日志文件同步数据
创建数据库配置文件
master.cnf 配置文件（/home/jorge/docker/mysql-master/conf/master.cnf）
[mysqld]
server-id=1
log-bin=mysql-bin
AI 代码解读
slave.cnf 配置文件（/home/jorge/docker/mysql-slave-1/conf/master.cnf）
[mysqld]
server_id=2
log-bin=mysql-bin
binlog-format=ROW
#忽略同步的表
binlog_ignore_db=mysql
binlog_ignore_db=information_schema
binlog_ignore_db=performation_schema
binlog_ignore_db=sys
AI 代码解读
进入mysql-master配置用户权限、查看MASTER_LOG_FILE
# 进入mysql-master
docker exec -it mysql-master /bin/bash
#登陆
mysql -uroot -p
AI 代码解读
#创建用户、授权、刷新
mysql> CREATE USER 'jorge-m'@'%' IDENTIFIED BY '123456';
mysql> GRANT REPLICATION SLAVE ON *.* TO 'jorge-m'@'%';
mysql> FLUSH PRIVILEGES;
AI 代码解读
#查看MASTER_LOG_FILE
mysql> show master status;
+----------------------+----------+--------------+------------------+------------------------------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+----------------------+----------+--------------+------------------+------------------------------------------+
| master-binlog.000002 | 1040 | | | ab240285-b4a4-11e8-9104-0242ac110003:1-4 |
+----------------------+----------+--------------+------------------+------------------------------------------+
1 row in set (0.00 sec)
AI 代码解读
进入mysql-slave-1配置从库的master参数
mysql> stop slave;
#省略了 mysql> 方便复制粘贴
#MASTER_HOST为mysql-master的ip。在宿主机执行docker inspect mysql-master可查看
CHANGE MASTER TO
MASTER_HOST='172.17.0.2',
MASTER_USER='jorge-m',
MASTER_PORT=3306,
MASTER_PASSWORD='123456',
MASTER_LOG_FILE='mysql-bin.000002',
MASTER_LOG_POS=0;
mysql> reset slave;
mysql> start slave;
AI 代码解读
#查看slave的启动情况,查看基本参数以及异常信息如下则正常
mysql> show slave status \G
Slave_IO_State: Waiting for master to send event
Master_Host: 172.17.0.2
Master_User: jorge-m
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: master-binlog.000002
Read_Master_Log_Pos: 1040
Relay_Log_File: dfd3ebbbb2f1-relay-bin.000003
Relay_Log_Pos: 1160
Relay_Master_Log_File: master-binlog.000002
......
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
.....
Last_Errno: 0
Last_Error:
......
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 0
Last_SQL_Error:
AI 代码解读
测试
重启容器实例使其加载配置文件
docker restart mysql-master
docker restart mysql-slave-1
AI 代码解读
接下来我们可以直接在主库新建一个数据库
刷新从库之后我们会发现testdb已经被同步到从库了
方式二：GTID配置主从复制
以上是基于日志的主从复制是实现读写分离。这种同步方式很依赖于主库。如果主库宕机或者网络故障等问题出现，可能导致主从库同步丢失，或者多个从库之间数据不一致问题。那么为了解决这个问题mysql5.7.6之后引入了基于事务的主从复制方案。每个事务由唯一的GTID标识。当slave都执行了sql之后，master才持久化到硬盘，否则事务回滚，解决了一致性问题。
配置文件设置打开gtid_mode和enforce_gtid_consistency
master.cnf
[mysqld]
#GTID:
server_id=1
gtid_mode=on
enforce_gtid_consistency=on
#binlog
log_bin=master-binlog
log-slave-updates=1
binlog_format=row
#relay log
skip_slave_start=1
AI 代码解读
slave.cnf
[mysqld]
#GTID:
gtid_mode=on
enforce_gtid_consistency=on
server_id=2
#binlog
log-bin=slave-binlog
log-slave-updates=1
binlog_format=row
#relay log
skip_slave_start=1
AI 代码解读
登陆主库设置
如果主从库有操作没有同步的话要执行以下命令清空gtid_purged，或者dump备份主库到从库之后再设置
#登陆mysql主库后执行
reset master;
#查看gtid_purged和gtid_executed，两个值位为空即可
mysql> show global variables like '%gtid%'\G
AI 代码解读
登陆从库设置
这里配置MASTER_AUTO_POSITION = 1;会根据GTID去获取数据，因此不需要配置 MASTER_LOG_FILE和MASTER_LOG_POS了
mysql> stop slave;
CHANGE MASTER TO
MASTER_HOST='172.17.0.2',
MASTER_USER='jorge-m',
MASTER_PASSWORD='123456',
MASTER_PORT=3306,
MASTER_AUTO_POSITION = 1;
mysql> reset slave;
mysql> reset master;
mysql> start slave;
AI 代码解读
#查看slave的启动情况,查看基本参数以及异常信息如下则正常
mysql> show slave status \G
......
# 我们会发现多了如下的值
Master_UUID: ab240285-b4a4-11e8-9104-0242ac110003
AI 代码解读
总结:
体验过后发现Replication的方式是单向同步的，只能从master写，从slave读。异步复制虽然性能上比较有优势，但是容灾能力真的不强。如果用这种方式来同步日志数据库的话，还可以接受。当然，这样的考虑mysql肯定也是会考虑到的。下一次学习体验下PXC 集群方案（ Percona XtraDB Cluster ）。
