一.主要概述MySQL数据库归档历史数据主要可以分为三种方式:一.创建编写SP、设置Event;二.通过dump导入导出;三.通过pt-archiver工具进行归档。第一种方式往往受限于同实例要求,往往被大家舍弃。第二种,性能相对较好,但是归档表较多时运维也是比较头疼的事。所以很多DBA往往采用第三种方式--pt-archiver。pt-archiver是Percona-Toolkit工具集中的一
简介:mysql 日志slow log和 error log归档,发现还挺麻烦的。因为如果是大文件的话,比如大于200g,如果直接copy的话,就会把IO打满,影响mysql的生产业务。一 、安全清理mysql 日志文件脚本首先处理掉大的日志文件,因为logrotate轮转时是先copy,然后再清理日志文件,会打满磁盘IO。1、把日志文件slow log和error log重命名;2、然后进入my
应用场景在mysql数据库运维过程中,总会碰到一些比较棘手的事情,历史数据归档绝对算的上一个。由于一些历史原因,有些业务表当初被设计成单表,而且没有分区,业务跑了一段时间,发现越来越慢了。一排查,发现这些单表的数据太多了,导致查询效率变低,这个时候,需要将一些业务用不到的历史数据归档,减少表的数据量,提升查询效率。可是要丝滑的将这些历史数据进行归档,可不是一件容易的事情。注意是丝滑,不能停业务,不
目录 文章目录目录1. 引言2. 工具说明2.1 使用方式2.2 选项说明3. 工作流程4. 实例4.1 表归档到表(逐行进行)4.2 表归档到表(批量进行)4.2.1 归档到当前实例,并删除数据4.2.2 归档到远程实例,不删除数据4.3 仅清除表数据4.4 表自增字段处理5. 总结 1. 引言2. 工具说明2.1 使用方式2.2 选项说明选项说明–analyze指定工具执行完成后对表的优化,如
转载 2023-08-02 18:07:24
107阅读
mysql中某张表数据量很大时,和客户沟通可以进行归档(将XX天之前的数据备份后删除)。可以使用此文档。 目录 一、PT工具安装 二、使用说明 三、file和purge使用: 四、其他参数 五、脚本例子 一、PT工具安装 #下载: #wget https://downloads.percona.com/downloads/per
背景:在很多业务场景中,每过一段时间就需要对大表进行归档操作以保障系统对性能稳定,但是这种操作往往会留下很多表空间碎片,所以每隔一段时间也需要对表空间进行清理。mysql中optimize table 是比较常用的清理磁盘命令,但是这个命令对缓存区有大小要求,如果一次归档过多数据,往往耗时久还非常有可能无法成功。所以只剩下了alter table这个命令,但是这个命令也非常慢:因为原理是先复制表在
归档对于DBA来说是一个非常严肃的话题,但是对于开发来说可能就没有那么的重视,最近我接到开发经理的需求说要归档两个月以前的短信日志;在开发和开发经理看来,短信下发了就下发了,超过60天的数据已经处于完全无用状态,属于可丢弃数据; 需求到我这里,我给了两个方案,1、做一个归档数据库,2、文本形式归档其中做归档数据库肯定是比较复杂的,原因有:1、考虑整个平台的通用性,可定要慎重的选型数据库2
归档日志:bin-log。删库恢复的解决方案!主从复制的解决方案! bin-log基本信息Binlog在MySQL的Server层实现(引擎共用)Binlog为逻辑日志,记录的是一条语句的原始逻辑Binlog不限大小,追加写入,不会覆盖以前的日志如果,我们误删了数据库,可以使用binlog进行归档!要使用binlog归档,首先我们得记录binlog,因此
转载 2023-08-08 11:38:48
83阅读
由于线上的MySQL实时表数据量太大,即使建了索引查询速度也不理想,上周下班前经理让我对线上MySQL的七张源数据层面的实时表进行归档,现表仅保留近三天的数据,三天之前的数据全部归档到历史表中一、基本思想考虑到按照时间进行归档,因此MySQL按时间创建分区表,并且动态维护每张历史表的分区,将三天前的数据插入到历史表中,根据时间的不同会落到不同的分区中;校验数据量在没有丢失的情况下删除原表数据并记录
转载 2023-06-29 10:29:44
394阅读
一、引言前段时间,在优雅的使用pt-archiver进行数据归档一文中介绍了pt-archiver的使用方法,也将pt-archiver部署到了生产环境,这时候问题来了~生产环境需要做归档的任务有十几个,如果要知道每个归档任务成功与否、跑了多长时间、归档了多少数据,就得手工逐个查看日志,非常枯燥的重复劳动,那是否有办法可以统一管理呢?于是用python倒腾了一个小工具—mysql_archiver
# MySQL归档:将数据存档起来 随着互联网和数字化技术的飞速发展,数据量的增长速度越来越快。对于数据库管理员来说,如何有效地管理数据库中的海量数据成为了一项重要的任务。MySQL归档是一种常用的数据管理方法,它可以帮助数据库管理员将不常用的数据存档起来,从而减少数据库的负担,提高查询性能。 ## MySQL归档的原理 MySQL归档的原理很简单:将不常用的数据从数据库表中移动到归档表中,
原创 5月前
12阅读
归档,在 MySQL 中,是一个相对高频的操作。它通常涉及以下两个动作:迁移。将数据从业务实例迁移到归档实例。删除。从业务实例中删除已迁移的数据。在处理类似需求时,都是开发童鞋提单给 DBA,由 DBA 来处理。于是,很多开发童鞋就好奇,DBA 都是怎么执行归档操作的?归档条件没有索引会缩表吗?安全吗,会不会数据删了,却又没归档成功?针对这些疑问,下面介绍 MySQL 中的数据归档神器 - pt-
转载 2023-08-29 17:44:25
237阅读
MySQL必备工具第九位: mk-archiver随着列表体积的日益增大,查询指令生效时间也每况愈“长”。响应时间不理想的干扰因素当然很多,但如果我们已经对各个角度实施了优化,那么最后仍然制约性能表现的瓶颈所在就是列表的规模了。将庞大列表中的各行内容进行归档操作能够有效缩短查询指令的响应时间。除非列表内容并不重要,否则大家千万不能贸然删除其中的内容行。归档也需要技巧,因为首先数据不能缺失、列表也不
导读MySQL 8.0.17开始支持的redo log归档能干嘛用呢,好吃吗今天,MySQL 8.0.17发布了,看了下release note,发现果真如之前预期的那样,恢复了redo log归档(redo log archiving)功能。之所以说是“恢复”,那是因为在InnoDB非常古老的版本(MySQL 4.0.6之前的版本)才存在,之后就取消了,当时还支持redo log mi
一.主要概述MySQL数据库归档历史数据主要可以分为三种方式:一.创建编写SP、设置Event;二.通过dump导入导出;三.通过pt-archiver工具进行归档。第一种方式往往受限于同实例要求,往往被大家舍弃。第二种,性能相对较好,但是归档表较多时运维也是比较头疼的事。所以很多DBA往往采用第三种方式--pt-archiver。pt-archiver是Percona-Toolkit工具集中的一
归档模式在归档模式下时,当LGWR后台进程的写操作从一个重做日志组切换到另一个重做日志组之后,归档写后台进程(ARCH/ARCn)就会将原来的重做日志文件的信息复制到归档日志文件中。可以把归档日志文件堪称是重做日志文件的克隆;要使归档的操作自动化,首先必须将数据库设置为归档模式,其次要启动归档后台进程(ARCn),还要有足够的硬盘空间以存储持续产生的归档日志文件;将数据库设置为归档模式意味:1)当
SQL Server 数据归档方案 目的本文旨在从数据库管理方面,提供将SQL Server大数据表归档的解决方案。可以作为新业务上线时进行方案设计的参考。 归档方案选型方案一:方案介绍BCP导出数据到本地目录目录后,遍历目录文件BCP导入到临时表,再循环删除源表数据。通过Insert into … Left Join …通过主键关联临时表和归档表排除存在的数据。(或通过200
MySQL 常用 OLTP 业务环境,一般会使用比较好的硬件资源来提供对外服务。现在 MySQL 数据对外提供的数据动不动好几个 T 也是正常的。在很多业务中,数据有较强的生命周期,在线一段时间后,可能就是失去业务意义,如:某个业务下线业务数据超过服务周期,例如某个业务只需要近 3 个月的数据业务操作的日志类型的数据进行归档分库分表的数据库需要合并到同一个地方,提供统计查询及分析能力定期的备份归档
使用MySQL的过程,经常会遇到一个问题,比如说某张”log”表,用于保存某种记录,随着时间的不断的累积数据,但是只有最新的一段时间的数据是有用的;这个时候会遇到性能和容量的瓶颈,需要将表中的历史数据进行归档。下面描述一种典型的做法:比如说表结构如下: CREATE TABLE `history` ( `id` int(11) NOT NULL, `value` text, `add
转载 2023-07-07 19:38:20
147阅读
前言随着业务量的增长,存储在 MySQL 中的数据日益剧增达到千万及上亿数据量,这就导致跟其 Join 的表的 SQL 变得很慢,对应用接口的 response time 也变长了,影响了用户体验。一般常见增长量巨大的表都是一些记录、日志类型数据,只需要保留 2 到 3 月。此时需要对表做数据清理实现瘦身。那么这么大的数据如何进行删除,而不影响数据库的正常使用呢?如何进行删除?都有哪些方案?根据前
  • 1
  • 2
  • 3
  • 4
  • 5