基于docker-compose的MySQL主从复制集群

最新推荐文章于 2022-11-17 19:54:30 发布

あ-

最新推荐文章于 2022-11-17 19:54:30 发布

阅读量661

点赞数

本文链接：https://blog.csdn.net/qq_38636133/article/details/105753528

版权

前言

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

正文

1 主从复制的方式

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

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

2 主从复制的流程

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

主服务器 将数据的更新记录到 二进制日志（Binary log）中，用于记录二进制日志事件，这一步由 主库线程 完成；
从库将主库的 二进制日志 复制到本地的 中继日志（Relay log），这一步由从库I/O线程完成；
从库读取 中继日志 中的事件，将其重放到数据中，这一步由从库SQL线程完成。

3 主从模式的优点

1）负载均衡

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

2）异地容灾备份

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

3）高可用

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

4）高扩展性

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

scale-up

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

scale-out

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

4 主从模式的缺点

1）成本增加

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

2）数据延迟

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

3）写入更慢

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

5 主从复制的前提条件

主从服务器 操作系统版本 和位数一致。
主数据库和从数据库的版本要一致。
主数据库和从数据库中的数据要一致。
主数据库 开启 二进制日志，主数据库和从数据库的 server_id 在局域网内必须唯一。

6 配置文件

docker --version
Docker version 18.09.0, build 4d60db4
docker-compose --version
docker-compose version 1.25.1, build a82fef07
mysql version
5.7

目录结构如图所示:

6.1 配置docker-compose.yml

version: '3'
services:
mysql-master:
image: mysql:5.7
environment:
- "MYSQL_ROOT_PASSWORD=root"
- "MYSQL_DATABASE=replicas_db"
volumes:
- /home/istorm/mysql_test/master/my.cnf:/etc/mysql/my.cnf
- /home/istorm/mysql_test/master/mysql_data_master:/var/lib/mysql
links:
- mysql-slave1
- mysql-slave2
ports:
- "33065:3306"
restart: always
hostname: mysql-master
container_name: mysql-master

mysql-slave1:
image: mysql:5.7
environment:
- "MYSQL_ROOT_PASSWORD=root"
- "MYSQL_DATABASE=replicas_db"
volumes:
- /home/istorm/mysql_test/slave1/my.cnf:/etc/mysql/my.cnf
- /home/istorm/mysql_test/slave1/mysql_data_slave:/var/lib/mysql
ports:
- "33066:3306"
restart: always
hostname: mysql-slave1
container_name: mysql-slave1

mysql-slave2:
image: mysql:5.7
environment:
- "MYSQL_ROOT_PASSWORD=root"
- "MYSQL_DATABASE=replicas_db"
volumes:
- /home/istorm/mysql_test/slave2/my.cnf:/etc/mysql/my.cnf
- /home/istorm/mysql_test/slave2/mysql_data_slave:/var/lib/mysql
ports:
- "33067:3306"
restart: always
hostname: mysql-slave2
container_name: mysql-slave2

6.2 主数据库配置配置

my.cnf文件

[mysqld]
## 设置server_id，一般设置为IP，注意要唯一
server_id=100 # 三个my.cnf配置文件中的id均不相同
## 复制过滤：也就是指定哪个数据库不用同步（mysql库一般不同步）
binlog-ignore-db=mysql
## 开启二进制日志功能，可以随便取，最好有含义（关键就是这里了）
log-bin=replicas-mysql-bin
## 为每个session分配的内存，在事务过程中用来存储二进制日志的缓存
binlog_cache_size=1M
## 主从复制的格式（mixed,statement,row，默认格式是statement）
binlog_format=mixed
## 二进制日志自动删除/过期的天数。默认值为0，表示不自动删除。
expire_logs_days=7
## 跳过主从复制中遇到的所有错误或指定类型的错误，避免slave端复制中断。
## 如：1062错误是指一些主键重复，1032错误是因为主从数据库数据不一致
slave_skip_errors=1062

6.3 slave1从数据库配置

my.cnf文件

[mysqld]
## 设置server_id，一般设置为IP，注意要唯一
server_id=101
## 复制过滤：也就是指定哪个数据库不用同步（mysql库一般不同步）
binlog-ignore-db=mysql
## 开启二进制日志功能，以备Slave作为其它Slave的Master时使用
log-bin=replicas-mysql-slave1-bin
## 为每个session 分配的内存，在事务过程中用来存储二进制日志的缓存
binlog_cache_size=1M
## 主从复制的格式（mixed,statement,row，默认格式是statement）
binlog_format=mixed
## 二进制日志自动删除/过期的天数。默认值为0，表示不自动删除。
expire_logs_days=7
## 跳过主从复制中遇到的所有错误或指定类型的错误，避免slave端复制中断。
## 如：1062错误是指一些主键重复，1032错误是因为主从数据库数据不一致
slave_skip_errors=1062
## relay_log配置中继日志
relay_log=replicas-mysql-relay-bin
## log_slave_updates表示slave将复制事件写进自己的二进制日志
log_slave_updates=1
## 防止改变数据(除了特殊的线程)
read_only=1

6.4 slave1从数据库配置

my.cnf文件

6.5 slave2从数据库配置

my.cnf文件

[mysqld]
## 设置server_id，一般设置为IP，注意要唯一
server_id=102
## 复制过滤：也就是指定哪个数据库不用同步（mysql库一般不同步）
binlog-ignore-db=mysql
## 开启二进制日志功能，以备Slave作为其它Slave的Master时使用
log-bin=replicas-mysql-slave1-bin
## 为每个session 分配的内存，在事务过程中用来存储二进制日志的缓存
binlog_cache_size=1M
## 主从复制的格式（mixed,statement,row，默认格式是statement）
binlog_format=mixed
## 二进制日志自动删除/过期的天数。默认值为0，表示不自动删除。
expire_logs_days=7
## 跳过主从复制中遇到的所有错误或指定类型的错误，避免slave端复制中断。
## 如：1062错误是指一些主键重复，1032错误是因为主从数据库数据不一致
slave_skip_errors=1062
## relay_log配置中继日志
relay_log=replicas-mysql-relay-bin
## log_slave_updates表示slave将复制事件写进自己的二进制日志
log_slave_updates=1
## 防止改变数据(除了特殊的线程)
read_only=1

6.6 运行docker-compose

在docker-compose.yml文件所在目录下运行

docker-compose up -d

7 配置从数据库

检查从库的起始状态

show master status

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

File: replicas-mysql-bin.000003
Position: 154

从库配置主库信息

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

CHANGE MASTER TO
MASTER_HOST='mysql-master',
MASTER_USER='root',
MASTER_PASSWORD='root',
MASTER_LOG_FILE='replicas-mysql-bin.000003',
MASTER_LOG_POS=154;

重新启动 slave 服务

stop slave
start slave

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

CREATE TABLE IF NOT EXISTS `runoob_tbl`(
`runoob_id` INT UNSIGNED AUTO_INCREMENT,
`runoob_title` VARCHAR(100) NOT NULL,
`runoob_author` VARCHAR(40) NOT NULL,
`submission_date` DATE,
PRIMARY KEY ( `runoob_id` )
)ENGINE=InnoDB DEFAULT CHARSET=utf8;

INSERT INTO runoob_tbl (runoob_title, runoob_author, submission_date) VALUES ("study python", "test1", NOW());
INSERT INTO runoob_tbl (runoob_title, runoob_author, submission_date) VALUES ("study MySQL", "test2", NOW());
INSERT INTO runoob_tbl (runoob_title, runoob_author, submission_date) VALUES ("study JAVA", "test3", '2016-05-06');

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

あ-

关注

0
点赞
踩
5

收藏

觉得还不错? 一键收藏
0
评论
基于docker-compose的MySQL主从复制集群

前言随着应用业务数据不断的增大，应用的响应速度不断下降，在检测过程中我们不难发现大多数的请求都是查询操作。此时，我们可以将数据库扩展成主从复制模式，将读操作和写操作分离开来，多台数据库分摊请求，从而减少单库的访问压力，进而应用得到优化。正文1 主从复制的方式MySQL 5.6开始主从复制有两种方式：基于日志（binlog）和基于GTID（全局事务标示符）...
复制链接

扫一扫