podman管理容器配置mysql5.7主从复制

1.创建目录结构

mkdir -p /wtdata/mysql-cluster/{mysql-master/{conf,data,log},mysql-slave/{conf,data,log}}

创建了如下目录
/wtdata/mysql-cluster/mysql-master/conf
/wtdata/mysql-cluster/mysql-master/data
/wtdata/mysql-cluster/mysql-master/log

/wtdata/mysql-cluster/mysql-slave/conf
/wtdata/mysql-cluster/mysql-slave/data
/wtdata/mysql-cluster/mysql-slave/log

2.修改配置文件

vim /wtdata/mysql-cluster/mysql-master/conf/my.cnf

[client]
default_character_set=utf8
[mysqld]
collation_server = utf8_general_ci
character_set_server = utf8
## 设置server_id，同一局域网中需要唯一
server_id=101
## 指定不需要同步的数据库名称
binlog-ignore-db=mysql
## 开启二进制日志功能
log-bin=mall-mysql-bin
## 设置二进制日志使用内存大小（事务）
binlog_cache_size=1M
## 设置使用的二进制日志格式（mixed,statement,row）
binlog_format=mixed
## 二进制日志过期清理时间。默认值为0，表示不自动清理。
expire_logs_days=7
## 跳过主从复制中遇到的所有错误或指定类型的错误，避免slave端复制中断。
## 如：1062错误是指一些主键重复，1032错误是因为主从数据库数据不一致
slave_skip_errors=1062

vim /wtdata/mysql-cluster/mysql-slave/conf/my.cnf

[client]
default_character_set=utf8
[mysqld]
collation_server = utf8_general_ci
character_set_server = utf8
## 设置server_id，同一局域网中需要唯一
server_id=102
## 指定不需要同步的数据库名称
binlog-ignore-db=mysql
## 开启二进制日志功能，以备Slave作为其它数据库实例的Master时使用
log-bin=mall-mysql-slave1-bin
## 设置二进制日志使用内存大小（事务）
binlog_cache_size=1M
## 设置使用的二进制日志格式（mixed,statement,row）
binlog_format=mixed
## 二进制日志过期清理时间。默认值为0，表示不自动清理。
expire_logs_days=7
## 跳过主从复制中遇到的所有错误或指定类型的错误，避免slave端复制中断。
## 如：1062错误是指一些主键重复，1032错误是因为主从数据库数据不一致
slave_skip_errors=1062
## relay_log配置中继日志
relay_log=mall-mysql-relay-bin
## log_slave_updates表示slave将复制事件写进自己的二进制日志
log_slave_updates=1
## slave设置为只读（具有super权限的用户除外）
read_only=1

3.启动master和slave配置主从复制

1）拉取镜像

podman pull mysql:5.7

2）配置master

[root@wtdejisuanji log]# podman run -p 3307:3306 --name mysql-master \
-v /wtdata/mysql-cluster/mysql-master/log:/var/log/mysql:Z \
-v /wtdata/mysql-cluster/mysql-master/data:/var/lib/mysql:Z \
-v /wtdata/mysql-cluster/mysql-master/conf:/etc/mysql/mysql.conf.d:Z \
-e MYSQL_ROOT_PASSWORD=root \
-d mysql:5.7


[root@wtdejisuanji log]# podman exec -it mysql-master /bin/bash

bash-4.2# mysql -uroot -proot

mysql> create user 'slave'@'%' identified by '123456';

mysql> grant replication slave,replication client on *.* to 'slave'@'%';

3）配置slave

podman run -p 3308:3306 --name mysql-slave \
-v /wtdata/mysql-cluster/mysql-slave/log:/var/log/mysql:Z \
-v /wtdata/mysql-cluster/mysql-slave/data:/var/lib/mysql:Z \
-v /wtdata/mysql-cluster/mysql-slave/conf:/etc/mysql/mysql.conf.d:Z \
-e MYSQL_ROOT_PASSWORD=root \
-d mysql:5.7

[root@wtdejisuanji log]# podman exec -it mysql-slave /bin/bash
bash-4.2# mysql -uroot -proot
///主从复制命令//

mysql>change master to master_host='宿主机ip', master_user='slave', master_password='123456', master_port=3307, master_log_file='mall-mysql-bin.000001', master_log_pos=617, master_connect_retry=30;

master_host：主数据库的IP地址；

master_port：主数据库的运行端口；

master_user：在主数据库创建的用于同步数据的用户账号；

master_password：在主数据库创建的用于同步数据的用户密码；

master_log_file：指定从数据库要复制数据的日志文件，通过查看主数据的状态，获取File参数；

master_log_pos：指定从数据库从哪个位置开始复制数据，通过查看主数据的状态，获取Position参数；

master_connect_retry：连接失败重试的时间间隔，单位为秒。

mysql>show slave status \G;

此时Slave_IO_Running和Slave_SQL_Running应该都是NO。执行

mysql>start slave;

再查看状态上面的no变成yes

主库建库建表增删改都会同步到从库上

至此，一主一从配置完成。

针对 MySQL 主从复制，修改配置文件后重启的顺序需要谨慎，核心原则是：确保复制不会因主库重启而中断或丢失事件。

在大多数场景下（修改了主库或从库的 `my.cnf`），推荐的安全顺序是：先重启从库，再重启主库。下面是详细的分步指南。

📝 第一步：重启前（重要！记录当前位点）

在操作之前，务必先记录主库和从库当前的二进制日志位点，以防万一需要手动恢复。

查看主库状态（在主库容器内执行）：
```
SHOW MASTER STATUS;
```
记录下 File 和 Position 值。
查看从库状态（在从库容器内执行）：
```
SHOW REPLICA STATUS\G
```
记录下 Master_Log_File、Read_Master_Log_Pos、Relay_Master_Log_File 和 Exec_Master_Log_Pos，同时确认 Slave_IO_Running 和 Slave_SQL_Running 是否为 Yes。

🔄 第二步：执行重启（遵循“先从后主”）

场景 A：主库和从库的配置文件都修改了（或不确定）

按照以下顺序操作，可最大程度避免主库重启后，从库因连接中断而报错堆积：

停止从库的复制线程（在从库容器内）：
```
STOP REPLICA;
```
（此步骤确保从库不会在主库重启期间疯狂重连，产生错误日志）
重启从库容器（在宿主机上）：
```
podman restart mysql-slave
```
等待几秒，确保容器完全启动（可用 podman logs --tail 20 mysql-slave 检查无报错）。
重启主库容器（在宿主机上）：
```
podman restart mysql-master
```
同样检查启动日志，确保主库正常。
启动从库的复制线程（在从库容器内）：
```
START REPLICA;
```

场景 B：只修改了从库的配置文件

从库的重启不会影响主库写入，直接重启从库即可，无需停止复制（但停止再启动更规范）：

（可选）在从库执行 STOP REPLICA;
宿主机执行：podman restart mysql-slave
（可选）在从库执行 START REPLICA;

场景 C：只修改了主库的配置文件

即使从库配置没变，主库重启期间从库 IO 线程会短暂中断。为了避免报错，建议先“断开”从库再操作：

在从库执行 STOP REPLICA;
宿主机执行：podman restart mysql-master
检查主库启动正常后，在从库执行 START REPLICA;

✅ 第三步：重启后验证（关键！）

无论按哪种顺序操作，重启完成后，必须检查复制状态是否恢复正常：

在从库上执行：
```
SHOW REPLICA STATUS\G
```
重点关注以下字段：
- Slave_IO_Running：必须为 Yes
- Slave_SQL_Running：必须为 Yes
- Seconds_Behind_Master：最好是 0（或一个较小的数字，表示正在追赶）
- Last_IO_Errno 和 Last_SQL_Errno：必须为 0（无错误）
在主库上简单插入测试数据，看在从库能否正常同步，进行最终验证。

⚠️ 特别注意

关于 :Z 和 :z：你之前配置挂载时使用的标签（:Z 私有 / :z 共享），不影响重启顺序，只影响 SELinux 权限。但如果重启时因权限问题启动失败，请检查 SELinux 上下文是否正确。
如果“先重启主库”会怎样？如果先重启主库，从库的 IO 线程会立即报错 error reconnecting to master，但通常会在主库恢复后自动重连并继续同步，多数情况下也是安全的。不过，如果主库重启时间较长或二进制日志文件发生轮换，从库可能会因“找不到日志”而彻底卡住，需要重新 CHANGE MASTER，因此 “先从后主”是更稳妥的保守策略。
不要同时重启：不要在宿主机上用 podman restart mysql-master mysql-slave，这会导致两个容器同时关停，难以判断启动顺序和日志状态。

posted on 2026-08-13 01:08 wtsgtc 阅读(8) 评论(0) 收藏举报