MySql on 冯威的博客

自研 MySQL 数据迁移工具：比 pt-archiver 快 10 倍的秘密

Fri, 16 Jan 2026 14:00:00 +0800

在上一篇文章《[[使用 pt-archiver 迁移 mysql 数据]]》中，我介绍了使用 Percona Toolkit 工具集中的 pt-archiver 进行历史数据归档的方法。

pt-archiver 功能强大且成熟，但在某些特定场景下，它的性能表现并不尽如人意。

例如，当我尝试将 200 万行历史数据迁移到一个已经包含 500 万行数据的归档表中时，pt-archiver 的速度非常慢。最根本的原因有两个：

1、是因为它在插入数据时，目标表的索引在持续更新，随着表越来越大，索引维护的开销也呈指数级增长。

2、pt-archiver 在批量执行时拼接的 SQL 并非是多值 SQL，而是多条 Insert 语句的拼接。而多值 SQL 的执行效率要远超多条 Insert 语句的拼接。

为了解决这个问题，我借助 AI 的能力编写了一个 Python 工具（data_migrate），通过先删索引-批量插入-重建索引的策略，实现了性能的飞跃。

核心思路

1、迁移前：把原表和目标表上除主键和查询字段相关之外的索引先保存到 json 文件中，然后删除。

2、迁移中：使用 INSERT INTO ... VALUES (...), (...), ... 这种多值 SQL 的方式进行批量写入。因为没有索引的负担，目标表写入速度和原表的删除速度都非常快。

3、迁移后：一次性重建所有索引。MySQL 重建索引是经过优化的（排序后批量构建），比逐行维护快得多。

此外，针对复杂的筛选条件（例如 WHERE id IN (SELECT ...)），引入了快照表机制，避免在循环分页中反复执行昂贵的子查询。

快照表逻辑很简单，就是先将需要过滤的 id 查询出来存到一个临时表中，再通过临时表中的 id 进行过滤。

工具实现

这个工具使用 Python 编写，基于 PyMySQL 驱动。主要包含以下几个模块：

migrator.py: 核心迁移控制器。
index_manager.py: 负责智能地删除和恢复索引。
db_manager.py: 数据库连接池管理。

1、智能索引优化

这是性能提升的关键。在 IndexManager 类中，实现了 drop_indexes 和 restore_indexes 方法。

值得注意的是，我们不能无脑删除所有索引。如果迁移的 WHERE 条件依赖某个索引（例如按 create_time 过滤），删掉它会导致源表查询变慢。因此，我加入了一个简单的逻辑：解析 WHERE 子句，保留查询所需的索引。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49


# data_migrate/tools/data_migrate/index_manager.py 部分代码
def drop_indexes(self, table_name, indexes, keep_columns=None):
 """删除索引并持久化到文件
 :param keep_columns: 需要保留的列名列表（字符串列表），如果索引包含这些列，则不删除
 """
 if not indexes:
 return

 # 持久化索引信息到文件，防止程序中断丢失
 backup_file = f"{table_name}_indexes_backup.json"
 try:
 with open(backup_file, 'w', encoding='utf-8') as f:
 json.dump(indexes, f, ensure_ascii=False, indent=2)
 logger.info(f"索引备份已保存至: {backup_file}")
 except Exception as e:
 logger.error(f"保存索引备份失败: {e}，将跳过索引删除操作以保证安全。")
 return

 # 过滤需要删除的索引
 indexes_to_drop = []
 for idx in indexes:
 should_drop = True
 if keep_columns:
 # 检查索引列是否包含在保留列表中
 # idx['columns'] 是 ["`col1`", "`col2`"] 格式
 for col in idx['columns']:
 clean_col = col.strip('`')
 if clean_col in keep_columns:
 logger.info(f" -> 保留表 {table_name} 的索引 {idx['name']}，因为涉及查询列 {clean_col}")
 should_drop = False
 break
 if should_drop:
 indexes_to_drop.append(idx)

 if not indexes_to_drop:
 logger.info(f"表 {table_name} 没有需要删除的索引（所有索引均被保留或无索引）。")
 return

 logger.info(f"正在删除表 {table_name} 的 {len(indexes_to_drop)} 个索引以加速写入...")
 conn = self.db_manager.get_connection()
 for idx in indexes_to_drop:
 try:
 sql = f"ALTER TABLE `{table_name}` DROP INDEX `{idx['name']}`"
 logger.info(f" -> 删除索引: {idx['name']}")
 with conn.cursor() as cursor:
 cursor.execute(sql)
 conn.commit()
 except Exception as e:
 logger.error(f"删除索引 {idx['name']} 失败: {e}")

2、批量读写与事务控制

为了减少网络交互和事务开销，我使用了 executemany 进行批量插入。

使用 pt-archiver 迁移 mysql 数据

Tue, 13 Jan 2026 16:43:00 +0800

在软件系统中，随着业务增长，有些表数据量会越来越大，为了提升性能，会将表进行拆分。这就需要定时将数据从源表迁移到目标表。

通常使用一个 sql 语句就能实现数据的迁移：

1
2
3
4


insert into t_business_finished 
select * from t_business where state=4;

delete from t_business where state=4;

但这种操作在数据量很大时速度很慢，资源消耗也比较大。

后来发现 pt-archiver 这个工具可以做这个事情。pt-archiver 有下面几个优点：

支持分批（chunk）读取和写入，避免一次性加载大量数据导致内存溢出或锁表。
可以通过 --limit 控制每次处理的行数，配合 --txn-size 控制事务大小。
支持 --sleep ，避免对生产库造成过大的压力。
可以通过 --progress 来查看进度。

下面就简单说下 pt-archiver 是怎么使用的，因为我测试的环境 mysql 是使用 docker 构建的，下面示例中 pt-archiver 也是使用 docker 的方式运行。

1、拉取镜像

1

docker pull percona/percona-toolkit:latest

2、如果是企业内网，不能拉取镜像，就将镜像保存为 tar 文件，赋值到内网服务器 load 即可

1
2
3
4
5


# 外网服务器进行保存
docker save -o percona-toolkit.tar percona/percona-toolkit:latest

# 拷贝到内网后load
docker load -i percona-toolkit.tar

3、执行下面命令就可以进行数据的迁移：

1

docker run -it --rm --network test_net percona/percona-toolkit:latest pt-archiver --source h=172.66.5.7,P=3306,u=root,p=123456,D=test,t=t_user --dest h=172.66.5.7,P=3306,u=root,p=123456,D=test,t=t_user_bak --where "1=1" --limit 10 --progress 10 --txn-size 10 --sleep 1 --no-delete --statistics --why-quit --header

–network：设置和数据库的容器在一个网络中
–source 源表相关配置
- h：数据库的容器 IP
- P：数据库的容器内部端口
- u：数据库用户名
- p：数据库密码
- D：数据库名称
- t：表名
–dest：目标表相关配置
–where：从源表获取数据的 where 条件
–limit：每次获取数据的条数
–progress 10：每处理 10 行就向终端输出一条进度信息
–txn-size 10：每 10 行组成一个事务，提交一次
–sleep 1：每批提交后暂停 1 秒，降低负载。
–no-delete：只复制，不删除源表数据
–statistics：结束后打印总计行数、耗时、吞吐量等汇总
–why-quit：如果提前退出，告知原因
–header：进度信息前打印表头

执行效果如下：

MySQL高可用：InnoDB Cluster 部署详解

Mon, 15 Sep 2025 09:07:00 +0800

最近公众号有人留言：为啥使用 ProxySQL 而不使用 InnoDB Cluster ？

其实使用什么方案，根据实际情况进行权衡利弊即可，如果先部署了 MGR ，想在此基础之上完善高可用，添加 ProxySQL 比较方便。如果新部署一个高可用环境，直接使用 InnoDB Cluster 也可以，InnoDB Cluster 也是依赖 MGR 。

下面将从零开始，来讲解怎么通过 Docker Compose 来部署 MySQL InnoDB Cluster，让你能够快速搭建一套完整的高可用数据库系统。

什么是 MySQL InnoDB Cluster

核心概念

MySQL InnoDB Cluster是 MySQL 官方提供的高可用解决方案，它基于以下三个核心组件：

MySQL Group Replication：提供数据复制和故障检测，这个就是前面文章中提到的 MGR
MySQL Router：提供透明的路由和负载均衡
MySQL Shell：提供集群管理和监控功能

架构优势

自动故障检测和转移
强一致性数据复制
透明的读写分离
简化的管理操作

架构图

开始部署

为了测试方便，在一台服务器上使用 docker compose 部署多个服务节点。

启动 mysql 节点

1、在服务器上创建一个目录 mysql-innodb-cluster ，目录中按照下图进行目录和文件的创建。

2、docker-compose.yml 文件内容如下：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85


version: '3.8'

services:
 mysql1:
 image: mysql:8.0.39
 container_name: mysql1
 hostname: mysql1
 restart: unless-stopped
 environment:
 MYSQL_ROOT_PASSWORD: rootpass123
 TZ: Asia/Shanghai
 networks:
 - mysql-cluster-net
 volumes:
 - ./node1/conf:/etc/mysql/conf.d:ro
 - ./node1/data:/var/lib/mysql
 - ./node1/log:/var/log/mysql
 ports:
 - "3310:3306"

 mysql2:
 image: mysql:8.0.39
 container_name: mysql2
 hostname: mysql2
 restart: unless-stopped
 environment:
 MYSQL_ROOT_PASSWORD: rootpass123
 TZ: Asia/Shanghai
 networks:
 - mysql-cluster-net
 volumes:
 - ./node2/conf:/etc/mysql/conf.d:ro
 - ./node2/data:/var/lib/mysql
 - ./node2/log:/var/log/mysql
 ports:
 - "3311:3306"

 mysql3:
 image: mysql:8.0.39
 container_name: mysql3
 hostname: mysql3
 restart: unless-stopped
 environment:
 MYSQL_ROOT_PASSWORD: rootpass123
 TZ: Asia/Shanghai
 networks:
 - mysql-cluster-net
 volumes:
 - ./node3/conf:/etc/mysql/conf.d:ro
 - ./node3/data:/var/lib/mysql
 - ./node3/log:/var/log/mysql
 ports:
 - "3312:3306"

 mysql-router:
 image: mysql/mysql-router:8.0
 container_name: mysql-router
 restart: unless-stopped
 depends_on:
 - mysql1
 - mysql2
 - mysql3
 networks:
 - mysql-cluster-net
 volumes:
 - ./router/data:/tmp/mysqlrouter
 ports:
 - "6446:6446" # 读写端口 (RW)
 - "6447:6447" # 只读端口 (RO)
 - "6448:6448" # 管理端口 (X Protocol RW)
 - "6449:6449" # 管理端口 (X Protocol RO)
 environment: 
 MYSQL_HOST: mysql1
 MYSQL_PORT: 3306
 MYSQL_USER: clusteradmin
 MYSQL_PASSWORD: clusterpass123
 MYSQL_CREATE_ROUTER_USER: 0
 MYSQL_ROUTER_BOOTSTRAP_EXTRA_OPTIONS: >
 --conf-use-sockets
 --conf-bind-address 0.0.0.0
 --conf-base-port 6446
networks:
 mysql-cluster-net:
 driver: bridge
 name: mysql-cluster-net

router 节点说明：

MySQL高可用：ProxySQL读写分离+MGR

Wed, 03 Sep 2025 16:46:00 +0800

MGR 解决了高可用的问题，但如果数据库访问量大，特别是读多写少的场景，就需要读写分离架构了了，在 MGR 的基础上，前面加上 ProxSQL 就可以实现读写分离。

应用程序只和 ProxySQL 打交道
ProxySQL 做为应用和 MGR 集群中间的一个桥梁，让应用对 MGR 的变化没有感知

组件说明

MGR

mysql-master: 主节点 (Primary)，处理写操作
mysql-slave-1: 从节点 (Secondary)，处理读操作
mysql-slave-2: 从节点 (Secondary)，处理读操作
配置为单主模式 (Single-Primary Mode)
实现自动故障转移和数据同步

ProxySQL

端口 6033: MySQL 协议接口，应用连接端口
端口 6032: 管理接口，用于配置和监控
端口 6080: Web 管理界面 (可选)
提供读写分离、连接池、查询路由功能，可以对 mysql 的每个节点进行健康检查，进行故障转移，发现主节点出现故障，会将新的强求转移到新的主

ProxySQL 安装和配置

在《MySQL高可用-使用Docker部署MGR》中介绍了 MGR 的安装部署，在此基础之上继续来安装 ProxySQL。

1、修改 docker-compose.yml 文件，添加 proxysql 节点。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22


proxysql:
 image: proxysql/proxysql:2.6.1
 container_name: proxysql
 hostname: proxysql
 volumes:
 - proxysql-data:/var/lib/proxysql
 - ./proxysql-config/proxysql.cnf:/etc/proxysql.cnf
 - ./proxysql-init-scripts:/etc/proxysql
 ports:
 - "6033:6033"
 - "6032:6032"
 networks:
 - mysql-mgr-network
 depends_on:
 - mysql-master
 - mysql-slave-1
 - mysql-slave-2
 healthcheck:
 test: ["CMD", "mysql", "-h", "127.0.0.1", "-P", "6032", "-u", "admin", "-padmin", "-e", "SELECT 1"]
 interval: 10s
 timeout: 5s
 retries: 5

/proxysql-config/proxysql.cnf：proxysql 的配置文件
/proxysql-config/proxysql.cnf：proxysql 初始化脚本所在的目录，可以直接配置为 ./proxysql-init-scripts:/docker-entrypoint-initdb.d ，则会在容器启动时执行。上面是将目录中的文件映射到容器内部，后续需要手动执行。

2、volumes 中映射的文件和目录内容，点击查看原文查看。

MySQL高可用-MGR运维常见问题和注意事项

Wed, 13 Aug 2025 09:45:00 +0800

MySQL 的高可用可以选择 MGR 方案，部署 MGR 很简单，可以参考《MySQL高可用-使用Docker部署MGR》，但在运行过程中，如果出现问题，如何快速解决？需要持续学习和实践。

下面我以实际用到的和我搜集到的一些资料来说说 MGR 在运维过程中的常见问题和注意事项。

部署前注意事项

硬件和环境要求

1、网络要求

低延迟网络：MGR 对网络延迟敏感，建议延迟 < 5ms 。因为 MGR 基于 Paxos 变种的共识算法，每提交一次事务至少跨网两次（prepare>ack>commit）。
稳定带宽：确保有足够的带宽支持数据同步，建议 ≥ 1Gbps 。全量 recovery、大事务或 DDL 时会产生突发流量，带宽不足会导致 flow-control 触发，集群整体降速

2、服务器配置

CPU：建议多核 CPU，至少4核以上
内存：充足内存，建议 ≥ 16GB
存储：使用 SSD 存储，确保足够 IOPS，考虑使用 RAID 10 而非 RAID 5/6，以获得更好的写性能
时钟同步：所有节点必须时钟同步（NTP）。MGR 的 GTID、view_change 事件都带时间戳，时间漂移会导致 “member expel” 误判。误判会导致节点是正常的，但会被踢出去。
分离数据和日志：将二进制日志和数据文件放在不同的物理存储上，参数大致如下：

1
2
3
4
5


datadir = /data/mysql
log_bin = /binlog/mysql-bin
binlog_cache_size = 1M 
sync_binlog = 1
innodb_flush_log_at_trx_commit = 1

操作系统优化

1、文件描述符限制

1
2
3


# 文件描述符限制
echo "mysql soft nofile 65536" >> /etc/security/limits.conf
echo "mysql hard nofile 65536" >> /etc/security/limits.conf

MGR + InnoDB 打开的文件数 = 表数量 × 分区 × 3（ibd、frm、ibtmp）+ binlog + relay log。文件描述限制如果比较小，操作系统层面的文件描述符（fd）耗尽，后果是 mysqld 再想去 open() 任何文件（包括新的 ibd、binlog、relay-log、tmp-file、socket 等）时都会得到 EMFILE，导致各种莫名奇妙的错误。

MySQL高可用-使用Docker部署MGR

Tue, 22 Jul 2025 21:57:00 +0800

MySql 的高可用方案很多，有 MHA、MGR、MySQL InnoDB Cluster 等。起初想学习下 MHA，了解后发现 MHA 在 Github 上的仓库已经没有更新了。不过 MHA 的兼容性比较好，有老版本的 MySQL 需要做高可用，还是值得一试的。

本文介绍下 MGR 的部署。

MGR (MySQL Group Replication) 是 MySQL 5.7.17 提出的，既可以很好的保证数据一致性又可以自动切换，具备故障检测功能、支持多节点写入。是以插件的形式提供，可以灵活部署。

MySQL MGR 集群是多个 MysQL Server 节点共同组成的分布式集群，每个 Server 都有完整的副本，它是基于 ROW 格式的二进制日志文件和 GTID 特性来实现的。

MGR 的优点

1、强一致性：基于原生复制及 Paxos 协议的组复制技术（以插件形式提供），确保数据的严格一致性。

2、高容错性：在少数节点故障时仍可正常运行，具备自动故障检测机制。节点间资源冲突采用无锁设计（如先到者优先）处理，避免错误。

3、高扩展性：支持节点动态自动加入与移除。新节点加入后自动同步数据至一致状态；节点移除后，集群自动更新并维护组配置信息。

4、高灵活性：支持单主模式与多主模式。单主模式下自动选举主节点，所有写操作路由至主节点；多主模式下，所有节点均可并发处理写操作。

MGR 的一些限制

1、仅支持 InnoDB 表，并旦每个表一定要有一个主键。

2、必须打开 GTID 特性，二进制日志格式必须设置为 ROW 。

3、MGR 不支持大事务。

4、仅支持 IPv4 网络，组大小限制为最少3个节点、最多9个节点。

5、不支持外键。

6、二进制日志不支持 Binlog Event Checksum 。

7、所有节点 server_id 和 server_uuid 需唯一。

部署前准备

为了方便，mysql 的主节点和从节点在一台虚拟机中进行测试
docker 版本：20.10.0
docker compose 版本：2.26.2
mysql 版本：8.0.39

开始部署

1、采用 docker-compose 的方式进行部署，部署目录 mysql-mgr 的文件结构如下图：

docker-compose.yml：容器编排文件，配置一个主和两个从的 mysql 节点。
mysql-config：此目录中是主和从的 mysql 配置文件
mysql-init-srcipts：此目录中是 mysql 启动时需要创建复制账号以及安装 mgr 插件
start-mgr.sh：三个 mysql 节点启动后，执行该文件进行 mgr 集群的启动。

2、将 mysql-mgr 拷贝到服务器，进入 mysql-mgr 目录执行 docker-compose up -d 。

Docker安装MySql-挂载外部数据和配置

Sun, 20 May 2018 09:18:37 +0800

在上一篇中《在CentOS7中使用Docker安装MySql》中介绍了怎样在Docker中安装Mysql，但存在两个问题：

1、用户密码和字符集等的设置，需要安装完MySql后，进入到MySql中去设置，非常麻烦； 2、配置文件和数据文件都在MySql的容器内，不是很安全。

本文将介绍怎样在创建容器时通过参数的配置来解决上面两个问题。

环境

CentOS：7.4
Docker：1.13.1
MySql：8.0.11

设置环境变量

设置环境变量和镜像的参数，可以来解决第一个问题，环境变量使用-e的方式设置在镜像名称的前面；镜像的参数需要配置在镜像名称的后面

docker run -d -p 4306:3306
-e MYSQL_USER="fengwei"
-e MYSQL_PASSWORD="pwd123"
-e MYSQL_ROOT_PASSWORD="rootpwd123"
--name mysql001
mysql/mysql-server
--character-set-server=utf8
--collation-server=utf8_general_ci

环境变量说明：

-e MYSQL_USER=“fengwei”：添加用户fengwei -e MYSQL_PASSWORD=“pwd123”：设置fengwei的密码伟pwd123 -e MYSQL_ROOT_PASSWORD=“rootpwd123”：设置root的密码伟rootpwd123

镜像参数说明：

–character-set-server=utf8：设置字符集为utf8 –collation-server=utf8_general_ci：设置字符比较规则为utf8_general_ci

使用SQLyog进行测试，用户名和密码使用上面环境变量中添加的用户fengwei和密码pwd123，出现下图的错误

执行命令进入到容器中的MySql中，执行下面的Sql语句

ALTER USER 'fengwei'@'%' IDENTIFIED WITH mysql_native_password BY 'password123';

再用SQLyog测试，连接成功

上面连接不成功的问题也可以添加镜像参数--default-authentication-plugin=mysql_native_password来解决，完整命令如下

docker run -d -p 4306:3306 
-e MYSQL_USER="fengwei" 
-e MYSQL_PASSWORD="pwd123" 
-e MYSQL_ROOT_PASSWORD="rootpwd123" 
--name mysql001 
mysql/mysql-server 
--character-set-server=utf8 
--collation-server=utf8_general_ci 
--default-authentication-plugin=mysql_native_password

数据和配置挂载到宿主机

为了安全性，我们应该将数据和配置放到宿主机中，首先执行下面的命令创建data目录和config目录

mkdir mysqltest
cd mysqltest
mkdir data
mkdir config

执行下面命令进入到config目录中，并在该目录中创建my.cnf配置文件

cd config
touch my.cnf

my.cnf配置文件内容如下

[mysqld]
user=mysql
character-set-server=utf8
default_authentication_plugin=mysql_native_password

[client]
default-character-set=utf8

[mysql]
default-character-set=utf8

执行下面命令创建容器

docker run -d -p 4306:3306 
--restart always 
--privileged=true
--name mysql001
-e MYSQL_USER="fengwei" 
-e MYSQL_PASSWORD="pwd123" 
-e MYSQL_ROOT_PASSWORD="rootpwd123"
-v=/mysqltest/config/my.cnf:/etc/my.cnf 
-v=/mysqltest/data:/var/lib/mysql 
mysql/mysql-server

参数说明

–restart always：开机启动 –privileged=true：提升容器内权限 -v=/mysqltest/config/my.cnf:/etc/my.cnf：映射配置文件 -v=/mysqltest/data:/var/lib/mysql：映射数据目录

在CentOS7中使用Docker安装MySql

Fri, 18 May 2018 22:31:14 +0800

环境

CentOS：7.4
Docker: 1.13.1
MySql: 8.0.11

MySQL服务不能启动，原因竟然是...

Wed, 31 Jan 2018 23:13:02 +0800

老婆最近使用MWeb往部署在Linode中的Wordpress博客中更新女儿的博客，发现图片不能正常上传，出现各种状况：

MWeb闪退
提示图片张数超过限制
一直Loading…

有重度拖延症的我今天在老婆的“强迫”下决定解决此问题。