Amazon Redshift-备份和恢复最佳实践?

2024-04-25

我们在 Redshift 中有一组表,其中的列具有 IDENTITY 属性,用于序列生成。在测试阶段,需要进行备份和恢复,这是每个测试周期的重复活动。我们按照以下流程进行备份然后恢复,并遇到以下问题:

  1. 传统方式:使用 CREATE TABLE XYZ_BKP AS SELECT * FROM XYZ 在另一个备份模式中创建了备份表。 但这样做我们丢失了表的 IDENTITY 和其他属性。因此,在恢复过程中,如果您尝试直接从备份创建表,您会丢失属性,并且无法更改添加 IDENTITY 约束。
  2. 传统方式备份和不同的恢复方法:这次我们首先使用 DDL 删除并重新创建表,然后尝试从备份执行 INSERT INTO。但它无法将值插入 IDENTITY 列。
  3. 卸载并复制:我们还尝试了 UNLOAD 等 Redshift 实用程序来备份 S3 中的表,然后使用副本进行恢复。它工作得很好,但随后我们遇到了其他问题 - A。具有前导零的 DATE 字段在 UNLOAD 提取中未正确提取。例如:日期“0001-01-01”提取为“1-01-01”。然后它在复制期间失败,说不是有效日期。在恢复(复制)过程中还会引发其他几个错误,例如非空字段的数据丢失或 int 数据类型的值无效。这意味着 UNLOAD 和 COPY 命令一起不能同步工作并且值会发生变化。
  4. 从快照恢复表:我还没有尝试过这个,但我知道AWS现在支持表恢复。但为 500 张桌子单独设置也是一项乏味的工作。您还可以长期保存和跟踪快照。

如果您能建议在我的场景中备份和恢复的最佳方法或组织遵循的最佳实践,这将非常有帮助。


我想在这里逐条回答,所以会有点长,请原谅;),但在我看来,我觉得最好的选择是Unload to S3 and Copy to table from S3。这里,S3可以替换为EC2.

  1. 传统方式- 如果我们需要进行一些数据替换并且我们希望空运行我们的查询,我们更愿意这样做。
  2. 传统方式备份和不同的恢复方法与#1 相同的问题,我们不使用。
  3. 卸载和复制:这是最方便的方法,甚至 IDENTITIES 也可以保留,因此始终是首选方法。

列出了一些有问题的问题,但大多数问题都是错误的,或者可以通过提供正确的导出/导入参数来避免。我想提供所有必要的步骤和数据来证明我的观点,即不存在任何问题dates and timestamps在装载和卸载过程中。

在这里我做了大部分数据类型来证明我的观点。

create table sales(
salesid integer not null Identity,
commission decimal(8,2),
saledate date,
description varchar(255),
created_at timestamp default sysdate,
updated_at timestamp);

CSV 中的内容(sales-example.txt)

salesid,commission,saledate,description,created_at,updated_at
1|3.55|2018-12-10|Test description|2018-05-17 23:54:51|2018-05-17 23:54:51
2|6.55|2018-01-01|Test description|2018-05-17 23:54:51|2018-05-17 23:54:51
4|7.55|2018-02-10|Test description|2018-05-17 23:54:51|2018-05-17 23:54:51
5|3.55||Test description|2018-05-17 23:54:51|2018-05-17 23:54:51
7|3.50|2018-10-10|Test description|2018-05-17 23:54:51|2018-05-17 23:54:51

复制将导入的命令date, timestamps,以及 ID。

copy sales(salesid,commission,saledate,description,created_at,updated_at) from 's3://****/de***/sales-example.txt' credentials 'aws_access_key_id=************;aws_secret_access_key=***********' IGNOREHEADER  1 EXPLICIT_IDS;

这将复制 5 条记录。我在这里做parallel off获取单个数据CSV来证明这一点,尽管不是必需的并且应该避免。

unload ('select salesid,commission,saledate,description,created_at,updated_at from sales') to 's3://assortdw/development/sales-example-2.txt' credentials 'aws_access_key_id=***********;aws_secret_access_key=***********' parallel off;

下面是我的内容,与导入完全相同,这意味着如果运行Copy命令到任何其他环境说dev or QA或者在某个地方,我会得到与中完全相同的记录Redshift簇。

5|3.55||Test description|2018-05-17 23:54:51|2018-05-17 23:54:51
1|3.55|2018-12-10|Test description|2018-05-17 23:54:51|2018-05-17 23:54:51
7|3.50|2018-10-10|Test description|2018-05-17 23:54:51|2018-05-17 23:54:51
2|6.55|2018-01-01|Test description|2018-05-17 23:54:51|2018-05-17 23:54:51
4|7.55|2018-02-10|Test description|2018-05-17 23:54:51|2018-05-17 23:54:51
  1. 从快照恢复表:这需要我们的“网络/基础设施小组”,因此我们避免这样做,尽管对此不太确定。非常欢迎其他专家对此发表评论/分享详细信息。

我希望这能回答这个问题,并提供一个起点discuss/summarize/conclude。欢迎大家踊跃补充积分。

本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系:hwhale#tublm.com(使用前将#替换为@)

Amazon Redshift-备份和恢复最佳实践? 的相关文章

随机推荐