Docker Compose搭建MySQL主从复制集群

前言

随着应用业务数据不断的增大，应用的响应速度不断下降，在检测过程中我们不难发现大多数的请求都是查询操作。此时，我们可以将数据库扩展成主从复制模式，将读操作和写操作分离开来，多台数据库分摊请求，从而减少单库的访问压力，进而应用得到优化。

正文

主从复制的方式

开始主从复制有两种方式：基于日志（ ）和基于（全局事务标示符）。

本文只涉及基于日志 的主从配置。

主从复制的流程

同步操作通过 个线程实现，其基本步骤如下：

主服务器将数据的更新记录到二进制日志（ ）中，用于记录二进制日志事件，这一步由主库线程完成；

从库将主库的二进制日志复制到本地的中继日志（ ），这一步由从库线程完成；

从库读取中继日志中的事件，将其重放到数据中，这一步由从库线程完成。

主从模式的优点

1. 负载均衡

通常情况下，会使用主服务器对数据进行更新、删除和新建等操作，而将查询工作落到从库头上。

2. 异地容灾备份

可以将主服务器上的数据同步到异地从服务器上，极大地提高了数据安全性。

3. 高可用

数据库的复制功能实现了主服务器与从服务器间的数据同步，一旦主服务器出了故障，从服务器立即担当起主服务器的角色，保障系统持续稳定运作。

4. 高扩展性

主从复制模式支持 种扩展方式:

scale-up

向上扩展或者纵向扩展，主要是提供比现在服务器性能更好的服务器，比如增加和内存以及磁盘阵列等，因为有多台服务器，所以可扩展性比单台更大。

scale-out

向外扩展或者横向扩展，是指增加服务器数量的扩展，这样主要能分散各个服务器的压力。

主从模式的缺点

1. 成本增加

搭建主从肯定会增加成本，毕竟一台服务器和两台服务器的成本完全不同，另外由于主从必须要开启二进制日志，所以也会造成额外的性能消耗。

2. 数据延迟

从库从主库复制数据肯定是会有一定的数据延迟的。所以当刚插入就出现查询的情况，可能查询不出来。当然如果是插入者自己查询，那么可以直接从主库中查询出来，当然这个也是需要用代码来控制的。

3. 写入更慢

主从复制主要是针对读远大于写或者对数据备份实时性要求较高的系统中。因为主服务器在写中需要更多操作，而且只有一台可以写入的主库，所以写入的压力并不能被分散。

主从复制的前提条件

主从服务器操作系统版本和位数一致。

主数据库和从数据库的版本要一致。

主数据库和从数据库中的数据要一致。

主数据库开启二进制日志，主数据库和从数据库的 在局域网内必须唯一。

具体配置

1. 环境准备

2. 配置docker-compose.yml

docker-compose.yml

3. 主数据库配置

3.1. 配置Dockerfile

Dockerfile

3.2. 配置my.cnf文件

my.cnf

4. 从数据库配置

4.1. 配置Dockerfile

Dockerfile

4.2. 配置my.cnf文件

5. 创建容器

进入 目录，运行 启动命令。

如图所示，主数据库和从数据库的容器创建成功。

分别配置主数据库和从数据库的连接信息如下：

主数据库

从数据库

6. 配置从数据库

检查从库的起始状态

如图所示，从数据库处于未同步复制状态。

检查主库的状态

记录主数据库的文件名称和数据同步起始位置。

File: replicas-mysql-bin.000003

Position: 154

从库配置主库信息

在从数据库上运行主数据库的相关配置 进行主从关联

重新启动 服务

进一步检查从数据库的状态信息，两者已经进行数据同步关联。

7. 创建目标表

在主数据库中创建一张测试数据表

主数据库和从数据库的 数据处于同步状态，主从复制集群搭建完成。

MySQL的复制类型

基于语句的复制

主服务器上面执行的语句在从服务器上面再执行一遍，在 版本以后支持。

问题：时间上可能不完全同步造成偏差，执行语句的用户也可能是不同一个用户。

基于行的复制

把主服务器上面改变后的内容直接复制过去，而不关心到底改变该内容是由哪条语句引发的，在 版本以后引入。

问题：比如一个工资表中有一万个用户，我们把每个用户的工资+1000，那么基于行的复制则要复制一万行的内容，由此造成的开销比较大，而基于语句的复制仅仅一条语句就可以了。

混合类型的复制

默认使用基于语句的复制，当基于语句的复制会引发问题的时候就会使用基于行的复制， 会自动进行选择。

欢迎关注公众号： 零壹技术栈

本帐号将持续分享后端技术干货，包括虚拟机基础，多线程编程，高性能框架，异步、缓存和消息中间件，分布式和微服务，架构学习和进阶等学习资料和文章。