MySQL 日志表改造为分区表

文章目录

    • 前言
    • [1. 分区表改造方法](#1. 分区表改造方法)
    • [2. 操作步骤](#2. 操作步骤)
      • [2.1 调整主键](#2.1 调整主键)
      • [2.2 无锁变更](#2.2 无锁变更)
      • [2.3 回滚策略](#2.3 回滚策略)
    • [3. 分区表维护](#3. 分区表维护)
      • [3.1 创建分区](#3.1 创建分区)
      • [3.2 删除分区](#3.2 删除分区)
      • [3.3 分区表查询](#3.3 分区表查询)
    • 后记

前言

业务有一张日志表,只需要保留 3 个月的数据,仅 3 月的数据就占用 80G 的存储空间,如果不定期清理那么磁盘容纳不下,但是每次清理的时候,使用 DELETE 删除非常慢,还会产生大量的 Binlog 日志,而且删除后会产生大量的空间碎片,回收需要重建表,期间还会造成临时空间增长(Online DDL 排序需要使用临时空间)需要先扩磁盘,等待空间收缩后再缩容,非常麻烦。

了解到这张表几乎不会查询,只会在某种特殊情况下才会查询,所以非常适合使用分区表。所以就提出将普通表改造成分区表的方案,本文将介绍整个过程,如果业务也有相似的场景,可以作为参考。

1. 分区表改造方法

分区表改造,需要全程锁表,业务表示无法给出窗口时间,所以需要借助 OnlineDDL 工具,通过无锁变更的方式来改造。这里使用的工具是 gh-ost 它的原理大致如下:

官方图解 (https://github.com/github/gh-ost)

主要执行过程:

  1. 检查是否有外键触发器及主键信息;
  2. 检查是否主库或从库,是否开启 log_slave_updates 以及 binlog 信息;
  3. 检查 gho 和 ghc 结尾的临时表是否存在;
  4. 创建 ghc 结尾的表,存数据迁移的信息,以及 binlog 信息等;
  5. 初始化 stream 的连接,添加 binlog 的监听;
  6. 根据 alter 语句创建 gho 结尾的幽灵表;
  7. 开启迁移数据,按照主键把源表数据写入到 gho 结尾的表上,以及 binlog apply;
  8. 进入 cut-over 阶段,锁住主库的源表,等待 binlog 应用完毕,然后替换 gh-ost 表为源表;
  9. 清理 ghc 表,删除 socket 文件。

cut-over 即表 rename 阶段,gh-ost 利用了 MySQL 的一个特性,原子性的 rename 请求,在所有被 blocked 的请求中,rename 优先级永远是最高的。gh-ost 基于此设计了该方案:一个连接对原表加锁,另启一个连接尝试 rename 操作,此时会被阻塞住,当释放 lock 的时候,rename 会首先被执行,其他被阻塞的请求会继续应用到新表。

2. 操作步骤

下方为脱敏后的表结构,目前已有 80G 的数据,业务依赖 created_at 作为保留日期参考字段,目前有 4~8 月的数据。

sql 复制代码
CREATE TABLE `xxxx_log` (
  `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT COMMENT 'id',
  `user_id` bigint(20) NOT NULL COMMENT '用户id',
  `user_name` varchar(60) DEFAULT NULL COMMENT '用户名',
  `user_ip` varchar(60) NOT NULL COMMENT '用户ip',
  `service_ip` varchar(60) NOT NULL COMMENT '服务端ip',
  `url` varchar(500) NOT NULL COMMENT '访问url',
  `req_method` varchar(60) DEFAULT NULL COMMENT '请求类型',
  `access_time` bigint(20) DEFAULT NULL COMMENT '请求时间',
  `service_id` varchar(60) DEFAULT NULL COMMENT '服务id',
  `parameter` varchar(500) DEFAULT NULL COMMENT '请求参数',
  `created_at` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
  `updated_at` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间',
  `api_id` bigint(20) DEFAULT NULL COMMENT '资源ID',
  `request_result` varchar(200) DEFAULT NULL COMMENT '请求结果',
  `response_param` text COMMENT '响应出参'
  PRIMARY KEY (`id`),
  KEY `idx_user_id` (`user_id`) USING BTREE,
  KEY `idx_created_at` (`created_at`) USING BTREE,
  KEY `idx_service_id` (`service_id`) USING BTREE,
  KEY `idx_server_id` (`server_id`) USING BTREE
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='请求日志表';

2.1 调整主键

调整主键,该操作不会锁表,不会影响用户写入,但是会造成一定负载,建议业务低峰执行:

sql 复制代码
ALTER TABLE xxxx_log DROP PRIMARY KEY, ADD PRIMARY KEY (id, created_at), ALGORITHM=INPLACE, LOCK=NONE;

2.2 无锁变更

gh-ost 的使用方法参加之前的文档:

无锁变更工具使用说明:MySQL gh-ost DDL 变更工具

分区表执行的 DDL 语句如下:

sql 复制代码
ALTER TABLE xxxx_log
PARTITION BY RANGE(to_days(created_at)) (
    PARTITION p2024_01 VALUES LESS THAN (to_days('2024-02-01')),
    PARTITION p2024_02 VALUES LESS THAN (to_days('2024-03-01')),
    PARTITION p2024_03 VALUES LESS THAN (to_days('2024-04-01')),
    PARTITION p2024_04 VALUES LESS THAN (to_days('2024-05-01')),
    PARTITION p2024_05 VALUES LESS THAN (to_days('2024-06-01')),
    PARTITION p2024_06 VALUES LESS THAN (to_days('2024-07-01')),
    PARTITION p2024_07 VALUES LESS THAN (to_days('2024-08-01')),
    PARTITION p2024_08 VALUES LESS THAN (to_days('2024-09-01')),
    PARTITION p2024_09 VALUES LESS THAN (to_days('2024-10-01')),
    PARTITION p2024_10 VALUES LESS THAN (to_days('2024-11-01')),   
    PARTITION p2024_11 VALUES LESS THAN (to_days('2024-12-01')),     
    PARTITION p2024_12 VALUES LESS THAN (to_days('2025-01-01')) 
);

执行完后,该表就被改造为分区表。

2.3 回滚策略

调整主键,由于 id 本身就是唯一的,所以对业务来说没有影响,不需要回滚。

调整分区表,从刚才的原理介绍可以了解到,整个过程只会增加负载,在 copy 数据到影子表的过程中,切换后还可以选择保留原表,测试无误后删除,随时可以再 rname 回去。

3. 分区表维护

3.1 创建分区

需要提前创建好分区,否则插入数据会失败,调整分区表的语句,已经创建了 2024 年整年的分区,所以到 2025 年之前,需要提前创建好 2025 年的分区,这个业务负责人和 DBA 都需要注意,否则会造成故障,分区要提前创建。

sql 复制代码
-- 创建 2025 年的分区 SQL 语句。
ALTER TABLE xxxx_log ADD PARTITION (
  PARTITION p2025_01 VALUES LESS THAN (to_days('2025-02-01')),
  PARTITION p2025_02 VALUES LESS THAN (to_days('2025-03-01')),
  PARTITION p2025_03 VALUES LESS THAN (to_days('2025-04-01')),
  PARTITION p2025_04 VALUES LESS THAN (to_days('2025-05-01')),
  PARTITION p2025_05 VALUES LESS THAN (to_days('2025-06-01')),
  PARTITION p2025_06 VALUES LESS THAN (to_days('2025-07-01')),
  PARTITION p2025_07 VALUES LESS THAN (to_days('2025-08-01')),
  PARTITION p2025_08 VALUES LESS THAN (to_days('2025-09-01')),
  PARTITION p2025_09 VALUES LESS THAN (to_days('2025-10-01')),
  PARTITION p2025_10 VALUES LESS THAN (to_days('2025-11-01')),
  PARTITION p2025_11 VALUES LESS THAN (to_days('2025-12-01')),
  PARTITION p2025_12 VALUES LESS THAN (to_days('2026-01-01'))
);

3.2 删除分区

清理数据,了解业务只需要保留 3 个月的数据,那么可以直接 drop 分区清理数据,比如清理 2024 年第一季度的数据。

sql 复制代码
ALTER TABLE xxxx_log DROP PARTITION p2024_01, p2024_02, p2024_03;

3.3 分区表查询

分区表查询的方式和普通表没有差别,不过建议查询时带上分区字段,否则查询要扫描所有的分区,会比较慢。当然也可以直接选择在某个分区里面查询。

sql 复制代码
-- 在 p2024_04 查询最大和最小的 created_at
SELECT max(created_at), min(created_at) FROM xxxx_log PARTITION (p2024_04);

后记

这类日志表类型的表,需要定期清理和归档,且业务平时也不会查询,历史数据都是静态的,分区表的特性就比较友好。改造为分区表后可大幅提升可维护性。

相关推荐
齐 飞4 分钟前
MongoDB笔记01-概念与安装
前端·数据库·笔记·后端·mongodb
云空4 分钟前
《Python 与 SQLite:强大的数据库组合》
数据库·python·sqlite
暮毅9 分钟前
10.Node.js连接MongoDb
数据库·mongodb·node.js
wowocpp12 分钟前
ubuntu 22.04 server 格式化 磁盘 为 ext4 并 自动挂载 LTS
服务器·数据库·ubuntu
成富34 分钟前
文本转SQL(Text-to-SQL),场景介绍与 Spring AI 实现
数据库·人工智能·sql·spring·oracle
songqq2735 分钟前
SQL题:使用hive查询各类型专利top 10申请人,以及对应的专利申请数
数据库·sql
计算机学长felix39 分钟前
基于SpringBoot的“校园交友网站”的设计与实现(源码+数据库+文档+PPT)
数据库·spring boot·毕业设计·交友
小码的头发丝、1 小时前
Django中ListView 和 DetailView类的区别
数据库·python·django
小兜全糖(xdqt)2 小时前
mysql数据同步到sql server
mysql·adb
Karoku0662 小时前
【企业级分布式系统】Zabbix监控系统与部署安装
运维·服务器·数据库·redis·mysql·zabbix