Mysql配置Replication主从复制-实现读写分离

概述：Mysql集群的方式可以是很多的，主从，一主多从，多组多从，主从的策略还可以进一步选择和配置。可以说是很灵活了。本文介绍的Replication是异步复制同步方案，分别有基于日志的还有基于GTID的。在docker环境下体验一下。

Replication

Replication是mysql异步复制同步方案，不难理解。异步复制速度快，但是一致性差。对于一些不特别重要的数据可以采用这总方案来同步，比如说日志这些数据。对业务影响不大的数据。

拉取mysql 5.7镜像

docker pull mysql:5.7

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

docker ps 查看容器实例

方式一：使用日志文件同步数据

创建数据库配置文件

master.cnf 配置文件（/home/jorge/docker/mysql-master/conf/master.cnf）

[mysqld]
server-id=1
log-bin=mysql-bin

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

进入mysql-master配置用户权限、查看MASTER_LOG_FILE

# 进入mysql-master
docker exec -it mysql-master /bin/bash
#登陆
mysql -uroot -p

#创建用户、授权、刷新
mysql> CREATE USER 'jorge-m'@'%' IDENTIFIED BY '123456';
mysql> GRANT REPLICATION SLAVE ON *.* TO 'jorge-m'@'%';
mysql> FLUSH PRIVILEGES;

#查看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)

进入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;

#查看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: 

测试

重启容器实例使其加载配置文件

docker restart mysql-master
docker restart mysql-slave-1

接下来我们可以直接在主库新建一个数据库

刷新从库之后我们会发现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

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

登陆主库设置

如果主从库有操作没有同步的话要执行以下命令清空gtid_purged，或者dump备份主库到从库之后再设置

#登陆mysql主库后执行
reset master;
#查看gtid_purged和gtid_executed，两个值位为空即可
mysql> show global variables like '%gtid%'\G

登陆从库设置

这里配置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;

#查看slave的启动情况,查看基本参数以及异常信息如下则正常
mysql> show slave status \G
......
# 我们会发现多了如下的值
Master_UUID: ab240285-b4a4-11e8-9104-0242ac110003

总结:

体验过后发现Replication的方式是单向同步的，只能从master写，从slave读。异步复制虽然性能上比较有优势，但是容灾能力真的不强。如果用这种方式来同步日志数据库的话，还可以接受。当然，这样的考虑mysql肯定也是会考虑到的。下一次学习体验下PXC 集群方案（ Percona XtraDB Cluster ）。