历史数据归档选择什么数据库

1地理数据库 (Geodatabase) 存档

2启用存档

3存档过程

4使用历史版本

5使用历史标记

6使用地理数据库历史查看器

7直接使用存档类

8架构更改和存档

9禁用存档

10存档情景

代码参考1链接

代码参考2链接

数据归档应用场景

很多用户在处理数据时都会要求记录 *** 作的过程，也就是记录历史数据。地理数据库归档允许数据随时间变化时对数据进行存储和分析。归档类和地理数据库历史查看器可用做解决此问题的工具，所以数据归档功能也常被称为历史归档。Esri公司从ArcGIS 9.2版本之后就增加了Geodatabase 数据模型的历史库功能。

在国土行业中，用户经常会要求按年、季度、月等时间类型来保留历史，以方便日后进行数据参考或数据分析。随着时间的推移而不断对宗地进行编辑时，可将其保存在归档类中。如果想要查看宗地在某时刻的情况，便可使用地理数据库历史查看器切换到相应的日期和时间。相反，如果想要查看某宗地随时间的变化情况，则可将宗地归档类添加到地图中，并依照其ID号选择相应的宗地。这会显示所选宗地随时间变化的每个制图表达。

1地理数据库 (Geodatabase) 存档

ArcGIS 中的存档 *** 作能够记录和访问对地理数据库中所有数据或数据子集所做的更改。地理数据库存档是一种记录、管理和分析数据更改的机制。

很多组织都需要保留对数据的更改以回答一些常见的问题，例如

某一时刻特定属性的值是多少？

特定要素或特定行是如何随时间变化的？

某一空间区域是如何随时间变化的？

地理数据库存档用于帮助各组织机构通过保存数据更改来回答这些类型的问题。地理数据库存档可保存从启用存档到禁用存档这段期间内所发生的全部更改，明确这一点是十分重要的。

地理数据库归档允许用户连接到历史版本。历史版本表示某一特定历史时刻的数据，它可提供地理数据库的只读信息。用户可通过现有历史标记或特定时刻连接到历史版本。历史标记是用户创建的一个特定时刻，例如，“分区 158 完成”是指 2012 年 7 月 11 日 2:13 PM。

ArcGIS 中提供的工具使用户可以轻松地研究对数据所做的更改。“历史查看器”工具使用户可快速导航到特定历史时刻以显示数据在该时刻是如何显示的。此外，向 ArcMap 中直接添加归档类可使用户执行查询以探究数据如何随时间变化；例如，查看在 2006 年 1 月 1 日到 2007 年 1 月 1 日之间对特定道路所做的编辑。

使用工具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)

二、原理解析

根据general log的输出，我们整理出时序表格如下

三、其他说明

咋一看这个过程貌似也没有什么问题，但是，假如在原表扫描出数据，插入到新表的过程中，旧数据发生了变化怎么办？

带着这个疑问，我们进行了源码的跟踪，我们在pt-archiver的6839行打上了断点

然后我分别在几个session窗口做了如下动作

最后pt-archiver输出如下：

# A software update is available:

TIMEELAPSED 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 TimePct

sleep 130.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的大小，不要过大，造成大事务

---