153 lines
5.6 KiB
Markdown
153 lines
5.6 KiB
Markdown
title: MySQL超大表删除数据
|
||
tags: []
|
||
categories: []
|
||
date: 2023-09-12 16:10:34
|
||
---
|
||
# 背景
|
||
|
||
笔者在公司负责公司的OpenAPI应用，估产生了调用审计的需求。对于存储这些AccessLog，虽然业界有很合适的架构和理论，奈何我司已成本优先，且作为toB的项目，调用量并不算特别大，每天也就2G左右的AccessLog产生。业务特征又导致整个订单的周期非常长，最少要保存1年以上的记录，以备排查问题所用（扯皮甩锅）。所以使用了大磁盘的MySQL直接存储。其表结构如下：
|
||
|
||
```sql
|
||
CREATE TABLE `access_log` (
|
||
`id` bigint(20) unsigned NOT NULL AUTO_INCREMENT COMMENT '主键',
|
||
`gmt_create` bigint(20) NOT NULL COMMENT '创建时间',
|
||
`trace_id` varchar(50) DEFAULT NULL COMMENT 'traceId',
|
||
`api_name` varchar(50) DEFAULT NULL COMMENT 'api名称',
|
||
`api_context` longtext COMMENT '调用正文',
|
||
`api_result` longtext COMMENT '返回正文',
|
||
`is_success` tinyint(4) DEFAULT NULL COMMENT '是否成功',
|
||
`time_consuming` bigint(20) DEFAULT NULL COMMENT '消耗时间(毫秒)',
|
||
PRIMARY KEY (`id`),
|
||
KEY `idx_trace_id` (`trace_id`),
|
||
KEY `idx_gmt_create` (`gmt_create`,`api_name`),
|
||
KEY `idx_api_name` (`api_name`,`gmt_create`,`is_success`)
|
||
) ENGINE=InnoDB COMMENT='流量入口-api记录'
|
||
```
|
||
|
||
而随着业务发展，需要接入的系统也越来越多，甚至有定时任务需要轮询接口，导致日志量暴增。达到了日均40G的地步。单表最大数据量在600G
|
||
|
||
> 在此期间，使用了各种手段优化写入量。忽略某些超高频又不影响业务的API。只记录某些接口错误调用的日志等等。
|
||
|
||
至于为什么不采用以月为后缀的动态表，涉及到我司DB管控问题。该方案一直无法通过。
|
||
|
||
问题拖到现在，涉及两张表：accessLog 600G， errorLog 200G。存储已经达到了物理机的上限，扩容就需要进行数据库迁移，最少需要一周时间提前做数据迁移。
|
||
|
||
# 要求
|
||
|
||
**现状：**
|
||
|
||
1. 两张超大表：accessLog 600G， errorLog 200G。
|
||
2. 近两周暴增了400G的占用
|
||
3. 整个机器的存储空间已经达到91%。剩余90G左右空间。
|
||
|
||
**要求：**
|
||
|
||
1. 线上做到写入无影响。
|
||
2. 数据库不能因此宕机。
|
||
|
||
# 技术方案
|
||
|
||
因为涉及的表过大，操作必须谨慎，不能产生临时表，表重建等隐形操作。
|
||
|
||
|
||
**流程如下：**
|
||
|
||
1. 清理errorLog表，只留存3天数据
|
||
2. 检查实际空间占用，确定重建表的空间安全
|
||
3. 重建该表，将可用空间提升到200G左右
|
||
4. 归档accessLog表
|
||
5. 清理其超高频的API日志
|
||
6. 按照日期保留3个月的日志
|
||
7. 检查实际空间占用，确定重建时空间安全。
|
||
8. 说服DBA，同意基于日期的动态表方案。
|
||
|
||
|
||
## 清理数据
|
||
|
||
清理数据相对简单，只需要加上主键排序+limit即可
|
||
|
||
```sql
|
||
delete from table_name where *** order by id limit 10000;
|
||
```
|
||
|
||
但是在清理过程中需要注意binlog文件大小，因为binlog一般配置了按天保存文件，可能导致binlog打满磁盘的情况。
|
||
|
||
**查看binlog文件大小**
|
||
|
||
```sql
|
||
show binary logs;
|
||
|
||
|
||
| Log_name | File_size|
|
||
| mysql-bin.003312 | 15178497 |
|
||
| mysql-bin.003313 | 3841846 |
|
||
| mysql-bin.003314 | 12789083 |
|
||
| mysql-bin.003315 | 9800029 |
|
||
```
|
||
|
||
**查看正在写入的Binlog文件**
|
||
|
||
```sql
|
||
show master status;
|
||
|
||
|
||
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
|
||
| mysql-bin.003315 | 10479164 | | | **** |
|
||
```
|
||
|
||
执行过程中，需要暂停一段时间执行，方便binlog切换等操作，否则可能导致实例一直繁忙状态无法生成新的binlog文件
|
||
|
||
**清理历史binlog文件**
|
||
|
||
```sql
|
||
PURGE MASTER LOGS TO 'mysql-bin.003315';
|
||
|
||
--- 清理 mysql-bin.003315 之前的文件，并不会清理当前文件。
|
||
```
|
||
|
||
清理完成后可以再次查看binlog文件
|
||
|
||
## 检查实际空间大小
|
||
|
||
因为MySQL的物理删除本质上也是逻辑删除，所以空间并不会被释放，需要检查实际的空间占用，保证重建表时，空间在安全范围内。
|
||
|
||
```sql
|
||
SELECT CONCAT(table_schema, '.', table_name) AS 'Table Name',
|
||
CONCAT(ROUND(table_rows / 1000000, 4), 'M') AS 'Number of Rows',
|
||
CONCAT(ROUND(data_length / (1024 * 1024 * 1024), 4), 'G') AS 'Data Size',
|
||
CONCAT(ROUND(index_length / (1024 * 1024 * 1024), 4), 'G') AS 'Index Size',
|
||
CONCAT(ROUND((data_length + index_length) / (1024 * 1024 * 1024), 4), 'G')
|
||
AS 'Total',
|
||
CONCAT(ROUND((data_free) / (1024 * 1024 * 1024), 4), 'G')
|
||
AS 'Free Size'
|
||
FROM information_schema.TABLES
|
||
WHERE table_schema LIKE 'database_name';
|
||
```
|
||
|
||
替换掉database_name为数据库名称，则可以看到表有效数据的占用大小，可释放空间大小等等。
|
||
|
||
如`Total`>数据库剩余空间，则重建就是安全的。
|
||
|
||
## 重建表
|
||
|
||
重建表使用一下语句：
|
||
|
||
```sql
|
||
OPTIMIZE TABLE `table_name`;
|
||
```
|
||
|
||
该命令会重建表，重建过程可以可以参考 [13 为什么表数据删掉一半，表文件大小不变？](http://learn.lianglianglee.com/%e4%b8%93%e6%a0%8f/MySQL%e5%ae%9e%e6%88%9845%e8%ae%b2/13%20%20%e4%b8%ba%e4%bb%80%e4%b9%88%e8%a1%a8%e6%95%b0%e6%8d%ae%e5%88%a0%e6%8e%89%e4%b8%80%e5%8d%8a%ef%bc%8c%e8%a1%a8%e6%96%87%e4%bb%b6%e5%a4%a7%e5%b0%8f%e4%b8%8d%e5%8f%98%ef%bc%9f.md)
|
||
|
||
# 结果
|
||
|
||
**清理数据过程中**
|
||
|
||
* 180 IOPS左右浮动
|
||
* CPU在20%左右
|
||
* 磁盘空间无明显增长
|
||
|
||
**重建过程中**
|
||
|
||
* 6000左右的 IOPS，完全吃满了磁盘性能
|
||
* CPU 40%左右浮动
|
||
* 磁盘初始新增20GB，后续断崖式下降 |