如何对MySQL中的大表进行数据归档

Posted 2023-03-23

pt-archiver原理解析
作为mysql DBA，可以说应该没有不知道pt-archiver了，作为pt-toolkit套件中的重要成员，往往能够轻松帮助DBA解决数据归档的问题。例如线上一个流水表，业务仅仅只需要存放最近3个月的流水数据，三个月前的数据做归档即可，那么pt-archiver就可以轻松帮你完成这件事情，甚至你可以配置成自动任务，无需人工干预。

作为DBA，我们应该知其然更应该知其所以然，这样我们也能够放心地使用pt工具。相信很多DBA都研究过pt-online-schema-change的原理，那么今天我们深入刨一刨pt-archiver的工作原理。
一、原理观察
土人有土办法，我们直接开启general log来观察pt-archiver是如何完成归档的。
命令
pt-archiver --source h=127.0.0.1,u=xucl,p=xuclxucl,P=3306,D=xucl,t=t1 --dest h=127.0.0.1,P=3306,u=xucl,p=xuclxucl,D=xucl_archive,t=t1 --progress 5000 \
--statistics --charset=utf8mb4 --limit=10000 --txn-size 1000 --sleep 30
常用选项
--analyze
指定工具完成数据归档后对表执行'ANALYZE TABLE'操作。指定方法如'--analyze=ds'，s代表源端表，d代表目标端表，也可以单独指定。
--ask-pass
命令行提示密码输入，保护密码安全，前提需安装模块perl-TermReadKey。
--buffer
指定缓冲区数据刷新到选项'--file'指定的文件并且在提交时刷新。
只有当事务提交时禁用自动刷新到'--file'指定的文件和刷新文件到磁盘，这意味着文件是被操作系统块进行刷新，因此在事务进行提交之前有一些数据隐式刷新到磁盘。默认是每一行操作后进行文件刷新到磁盘。
--bulk-delete
指定单个语句删除chunk的方式来批量删除行，会隐式执行选项'--commit-each'。
使用单个DELETE语句删除每个chunk对应的表行，通常的做法是通过主键进行逐行的删除，批量删除在速度上会有很大的提升，但如果有复杂的'WHERE'条件就可能会更慢。
--[no]bulk-delete-limit
默认值：yes
指定添加选项'--bulk-delete'和'--limit'到进行归档的语句中。
--bulk-insert
使用LOAD DATA LOCAL INFILE的方法，通过批量插入chunk的方式来插入行(隐式指定选项'--bulk-delete'和'--commit-each')
而不是通过逐行单独插入的方式进行，它比单行执行INSERT语句插入的速度要快。通过隐式创建临时表来存储需要批量插入的行(chunk)，而不是直接进行批量插入操作，当临时表中完成每个chunk之后再进行统一数据加载。为了保证数据的安全性，该选项会强制使用选项'--bulk-delete'，这样能够有效保证删除是在插入完全成功之后进行的。
--channel
指定当主从复制环境是多源复制时需要进行归档哪个主库的数据，适用于多源复制中多个主库对应一个从库的情形。
--charset，-A
指定连接字符集。
--[no]check-charset
默认值：yes
指定检查确保数据库连接时字符集和表字符集相同。
--[no]check-columns
默认值：yes
指定检查确保选项'--source'指定的源端表和'--dest'指定的目标表具有相同的字段。
不检查字段在表的排序和字段类型，只检查字段是否在源端表和目标表当中都存在，如果有不相同的字段差异，则工具报错退出。如果需要禁用该检查，则指定'--no-check-columns'。
--check-slave-lag
指定主从复制延迟大于选项'--max-lag'指定的值之后暂停归档操作。默认情况下，工具会检查所有的从库，但该选项只作用于指定的从库(通过DSN连接方式)。
--check-interval
默认值：1s
如果同时指定了选项'--check-slave-lag'，则该选项指定的时间为工具发现主从复制延迟时暂停的时间。每进行操作100行时进行一次检查。
--columns，-c
指定需要归档的表字段，如有多个则用','(逗号)隔开。
--commit-each
指定按每次获取和归档的行数进行提交，该选项会禁用选项'--txn-size'。
在每次获取表数据并进行归档之后，在获取下一次数据和选项'--sleep'指定的休眠时间之前，进行事务提交和刷新选项'--file'指定的文件，通过选项'--limit'控制事务的大小。
--host，-h
指定连接的数据库IP地址。
--port，-P
指定连接的数据库Port端口。
--user，-u
指定连接的数据库用户。
--password，-p
指定连接的数据库用户密码。
--socket，-S
指定使用SOCKET文件连接。
--databases，-d
指定连接的数据库
--source
指定需要进行归档操作的表，该选项是必须指定的选项，使用DSN方式表示。
--dest
指定要归档到的目标端表，使用DSN方式表示。
如果该选项没有指定的话，则默认与选项'--source'指定源端表为相同表。

--where
指定通过WHERE条件语句指定需要归档的数据，该选项是必须指定的选项。不需要加上'WHERE'关键字，如果确实不需要WHERE条件进行限制，则指定'--where 1=1'。
--file
指定表数据需要归档到的文件。使用类似MySQL DATE_FORMAT()格式化命名方式。
文件内容与MySQL中SELECT INTO OUTFILE语句使用相同的格式，文件命名选项如下所示：
%Y：年，4位数(Year, numeric, four digits)
%m：月，2位数(Month, numeric (01..12))
%d：日，2位数(Day of the month, numeric (01..31))
%H：小时(Hour (00..23))
%i：分钟(Minutes, numeric (00..59))
%s：秒(Seconds (00..59))
%D：数据库名(Database name)
%t：表名(Table name)
例如：--file '/var/log/archive/%Y-%m-%d-%D.%t'
--output-format
指定选项'--file'文件内容输出的格式。
默认不指定该选项是以制表符进行字段的分隔符，如果指定该选项，则使用','(逗号)作为字段分隔符，使用'"'(双引号)将字段括起。用法示例：'--output-format=dump'。
--for-update
指定为每次归档执行的SELECT语句添加FOR UPDATE子句。--share-lock
指定为每次归档执行的SELECT语句添加LOCK IN SHARE MODE子句。
--header
指定在文件中第一行写入字段名称作为标题。
--ignore
指定为INSERT语句添加IGNORE选项。
--limit
默认值：1
指定每条语句获取表和归档表的行数。
--local
指定不将OPTIMIZE和ANALYZE语句写入binlog。
--max-lag
默认值：1s
指定允许主从复制延迟时长的最大值，单位秒。如果在每次获取行数据之后主从延迟超过指定的值，则归档操作将暂停执行，暂停休眠时间为选项'--check-interval'指定的值。待休眠时间结束之后再次检查主从延迟时长，检查方法是通过从库查询的'Seconds_Behind_Master'值来确定。如果主从复制延迟一直大于该参数指定值或者从库停止复制，则操作将一直等待直到从库重新启动并且延迟小于该参数指定值。
--no-delete
指定不删除已被归档的表数据。
--optimize
指定工具完成数据归档后对表执行'OPTIMIZE TABLE'操作。指定方法如'--analyze=ds'，s代表源端表，d代表目标端表，也可以单独指定。
--primary-key-only
指定只归档主键字段，是选项'--columns=主键'的简写。
如果工具归档的操作是进行DELETE清除时最有效，因为只需读取主键一个字段而无需读取行所有字段。
--progress
指定每多少行打印进度信息，打印当前时间，已用时间以及多少行进行归档。
--purge
指定执行的清除操作而不是归档操作。允许忽略选项'--dest'和'--file'进行操作，如果只是清除操作可以结合选项'--primary-key-only'会更高效。
--quiet，-q
指定工具静默执行，不输出任何的执行信息。
--replace
指定写入选项'--dest'指定目标端表时改写INSERT语句为REPLACE语句。
--retries
默认值：1
指定归档操作遇到死锁或超时的重试次数。当重试次数超过该选项指定的值时，工具将报错退出。
--run-time
指定工具归档操作在退出之前需要运行的时间。允许的时间后缀名为s=秒，m=分，h=小时，d=天，如果没指定，默认为s。
--[no]safe-auto-increment
默认值：yes
指定不使用自增列(AUTO_INCREMENT)最大值对应的行进行归档。
该选项在进行归档清除时会额外添加一条WHERE子句以防止工具删除单列升序字段具有的具有AUTO_INCREMENT属性最大值的数据行，为了在数据库重启之后还能使用到AUTO_INCREMENT对应的值，但这会引起无法归档或清除字段对应最大值的行。
--set-vars
默认：
wait_timeout=10000
innodb_lock_wait_timeout=1
lock_wait_timeout=60
工具归档时指定参数值，如有多个用','(逗号)分隔。如'--set-vars=wait_timeout=5000'。
--skip-foreign-key-checks
指定使用语句SET FOREIGN_KEY_CHECKS = 0禁用外键检查。
--sleep
指定工具在通过SELECT语句获取归档数据需要休眠的时间，默认值是不进行休眠。在休眠之前事务并不会提交，并且选项'--file'指定的文件不会被刷新。如果指定选项'--commit-each'，则在休眠之前会进行事务提交和文件刷新。
--statistics
指定工具收集并打印操作的时间统计信息。
统计信息示例如下：
'
Started at 2008-07-18T07:18:53, ended at 2008-07-18T07:18:53
Source: D=db,t=table
SELECT 4
INSERT 4
DELETE 4
Action Count Time Pct
commit 10 0.1079 88.27
select 5 0.0047 3.87
deleting 4 0.0028 2.29
inserting 4 0.0028 2.28
other 0 0.0040 3.29
--txn-size
默认：1
指定每个事务处理的行数。如果是0则禁用事务功能。
--version
显示工具的版本并退出。
--[no]version-check
默认值：yes
检查Percona Toolkit、MySQL和其他程序的最新版本。
--why-quit
指定工具打印当非因完成归档行数退出的原因。
在执行一个自动归档任务时该选项与选项'--run-time'一起使用非常方便，这样可以确定归档任务是否在指定的时间内完成。如果同时指定了选项'--statistics'，则会打印所有退出的原因。
二、原理解析
根据general log的输出，我们整理出时序表格如下
三、其他说明
咋一看这个过程貌似也没有什么问题，但是，假如在原表扫描出数据，插入到新表的过程中，旧数据发生了变化怎么办？
带着这个疑问，我们进行了源码的跟踪，我们在pt-archiver的6839行打上了断点
然后我分别在几个session窗口做了如下动作
最后pt-archiver输出如下：
# A software update is available:
TIME ELAPSED COUNT
2020-04-08T09:13:21 0 0
2020-04-08T09:13:21 0 1
Started at 2020-04-08T09:13:21, ended at 2020-04-08T09:13:51
Source: A=utf8mb4,D=xucl,P=3306,h=127.0.0.1,p=...,t=t1,u=xucl
Dest: A=utf8mb4,D=xucl_archive,P=3306,h=127.0.0.1,p=...,t=t1,u=xucl
SELECT 1
INSERT 1
DELETE 1
Action Count Time Pct
sleep 1 30.0002 99.89
inserting 1 0.0213 0.07
commit 2 0.0080 0.03
select 2 0.0017 0.01
deleting 1 0.0005 0.00
other 0 0.0008 0.00
很明显，id=3这条记录并没有进行归档（我们这里是改了条件列，实际生产中可能是更改了其他列，造成归档数据不准确）
那么如何来解决这种情况的发生呢？
显然，数据库在数据库中可以通过加排它锁来防止其他程序修改对应的数据，pt-archiver其实早就已经帮我们考虑到了这样的情况，pt-archiver提供了两种选择
--for-update：Adds the FOR UPDATE modifier to SELECT statements
--share-lock：Adds the LOCK IN SHARE MODE modifier to SELECT statements
四、总结
pt-archiver作为归档工具无疑是MySQL DBA日常运维的大利器之一，在使用过程中在知道如何使用的基础上也能够知晓其原理
归档过程中最好能对归档记录进行加锁操作，以免造成归档数据不准确
在主从环境中，归档过程最好控制速度，以免造成主从延迟
尽量控制好chunk的大小，不要过大，造成大事务 参考技术A 使用MySQL的过程，经常会遇到一个问题，比如说某张”log”表，用于保存某种记录，随着时间的不断的累积数据，但是只有最新的一段时间的数据是有用的；这个时候会遇到性能和容量的瓶颈，需要将表中的历史数据进行归档。
下面描述一种典型的做法：
比如说表结构如下：
CREATE TABLE `history` (
`id` int(11) NOT NULL,
`value` text,
`addtime` timestamp default current_timestamp,
PRIMARY KEY (`id`),
index idx_addtime(`addtime`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8

这张表中保存有2012年2013年两年的数据，现在需要将2012年的数据备份归档起来，但是2013年年初的数据还需要被查询，因此不能简单的进行如下的动作：
create table history_tmp like history;
rename table history to history_2012,history_tmp to history;

需要在新表中保留2013年年初的数据，可以参照下面的流程进行：
create table history_tmp like history;
maxid=select max(id) from history;
minid=select id from history where addtime>"2013-01-01 00:00" order by addtime asc limit 1;
last=0;
set autocommit=1;
for(i=minid;i<maxid+1000;i+=1000)

insert into history_tmp select * from history where id>=last and id<i lock in share mode;
last=i;

begin;
lock table history_tmp write,history write;
maxid=select max(id) from history;
insert into history_tmp select * from history where id>=last and id<=maxid;
alter table history rename to history_2012;
alter table history_tmp rename to history;
unlock tables;
commit;

说明:
使用alter table xx rename to xx，而不是rename是因为mysql的一个bug， bug地址 ，直接rename会出现”ERROR 1192 (HY000): Can’t execute the given command because you have active locked tables or an active transaction”错误.
需要使用lock history write来防止新的写入。
这个方式是假设这个表在有插入和查询操作，如果有update、delete操作可以通过类似OSC的算法使用trigger来实现。
不能直接使用insert select where id>minid这种方式，因为这样会导致slave的延迟，而且迟迟不能提交的事务会导致undo log无法purge。本回答被提问者和网友采纳

通过自定义分区器对雪花中的大表进行分区

【中文标题】通过自定义分区器对雪花中的大表进行分区

【英文标题】：Partitioning large table in snowflake through a custom partitioner

【发布时间】：2020-07-08 02:03:27

【问题描述】：

我们有一张雪花大表，里面有超过 550 亿条记录。用户通过提供 YEAR 和 SERIAL_NUMBER 作为谓词从该表中检索数据。检索记录需要大量时间。我们不想启用自动集群，因为这对我们来说变得昂贵。因此，我们提出了以下方法。我想对这种方法提出意见。

我们将表划分为多个分区。例如，如果表名是 TABLE_XYZ。我们正在为每年创建物理表，例如 TABLE_XYZ_2016、TABLE_XYZ_2017、TABLE_XYZ_2018、TABLE_XYS_2019、TABLE_XYZ_2020。最新的年份表经常更改，其他的基本保持不变。我们编写了一个分区器/拆分器，它读取源相似表并按年份拆分记录，并将它们加载到相应的年份表中，按年份和序列号排序。我们还在所有这些表格之上创建了一个视图。这个想法是需要所有年份的人会反对观点，对某一年感兴趣的人会反对物理年表。我们预计这将减少检索数据的时间。但是，如果有新的一年（比如说 2021 年），我们将不得不创建该表并重新定义视图。我还没有找到创建动态视图的方法。

如果这种方法有任何漏洞，请告诉我。

谢谢

【问题讨论】：

我相信，“内置”微分区和集群密钥也会做同样的事情。在日期列上创建集群键后，扫描将修剪那些以前的日期，直到这些以前的日期没有 DML。此外，自动刷新也仅适用于较新的日期。

【参考方案1】：

有一种更简单的方法可以使用集群键实现令人难以置信的性能。请参阅此处的文档：https://docs.snowflake.com/en/user-guide/tables-clustering-keys.html

总之，在 (YEAR, SERIAL_NUMBER) 上创建一个集群键，并且在后台 Snowflake 将根据这些键自动重新集群（排序）数据。最初，这可能会重新排序整个表，但随后，它只会重新排序新添加的值。

我对一个十亿行的表进行了测试，我在其中创建了一个唯一的序列，并在其上放置了一个集群键，通过键执行随机查找，每次获取都以毫秒为单位返回，只需一个 I/O。

Snowflake 在美国也有一个客户，其单个表中的数据超过 PETABYTE（是的，1,000 TB），该表使用相同的技术来实现对最近添加的数据的出色查询性能。

为了帮助调整性能，我建议（如果可能的话）加载 YEAR 格式的数据。 IE。如果您要进行几年的批量加载，请一次加载一年。否则别担心。

然后，您可以删除物理分区和视图，让 Snowflake 保持整个解决方案的清洁并自动更新。

您会发现后台集群在对数据进行排序时会产生初始成本，但随后应该会产生一些成本，而且性能提升值得付出努力。

【讨论】：

嗨，John，我们确实评估了这个选项，但对于我们的用例来说，这是一件代价高昂的事情。我们可能仍会进行自动重新聚类，但这仅适用于最新年份表，因为旧年份数据几乎没有变化

如果您的数据已经“自然聚类”，则重新聚类将不会花费任何成本，因为数据已经被聚类了。关于成本问题。估计替代解决方案的时间和费用。您可能会发现人员成本大大超过了对数据进行聚类的计算成本。

【参考方案2】：

我认为没有任何数据库提供处理不存在的表的视图；）你可以做的是：

（最简单）：创建 10 或 20 个空的“未来”表并将它们添加到您的视图中。它们将是空的，因此不会影响性能

（更难）：创建一个将在年底某处运行的作业并创建新的年度表并重新创建视图

【讨论】：

谢谢，我喜欢这种方法。我试图从程序中做到这一点。这种方法将节省一些处理

【参考方案3】：

如果加载到您的表中的历史记录不变，则重新集群表的成本将在第一个重新集群时最高。随着时间的推移，它应该会变得更便宜，对吧？

如果您出于某种原因不想使用自动重新集群，为什么不做您现在正在做的事情，而是将其放入单个表中？在您按year 和SERIAL_NUMBER 排序的地方运行一系列选择查询并插入到新表中。对我来说，将其拆分为多个表是没有意义的。

【讨论】：

如果我在单个表上执行此操作，随着新数据插入最近一年，集群将再次变坏，对吧？