amazon-s3 - Amazon Redshift-备份和还原最佳实践？

Question

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

传统方式:使用 CREATE TABLE XYZ_BKP AS SELECT * FROM XYZ 在另一个备份模式中创建备份表。
但是这样做我们丢失了表的 IDENTITY 和其他属性。因此，在恢复期间，如果您尝试直接从备份创建表，您将丢失属性属性，并且您无法更改以添加 IDENTITY 约束。

传统方式备份和不同的恢复方式:这次我们首先使用 DDL 删除并重新创建表，然后尝试从备份执行 INSERT INTO。但它不能将值插入到 IDENTITY 列中。

卸载和复制:我们还尝试了诸如 UNLOAD 之类的 Redshift 实用程序来备份 S3 中的表，然后使用副本进行恢复。它工作正常，但后来我们遇到了其他问题-
一种。在 UNLOAD 提取中未正确提取具有前导零的 DATE 字段。例如:将日期“0001-01-01”提取为“1-01-01”。然后它在 COPY 期间失败，说不是有效日期。在还原 (COPY) 期间，它还会引发其他一些错误，例如非空字段的缺失数据或 int 数据类型的无效值。这意味着 UNLOAD 和 COPY 命令不能同步工作并且值会发生变化。

从快照恢复表:我还没有尝试过，但我知道 AWS 现在支持表还原。但再次为 500 个表单独设置它是一项乏味的工作。您还可以长期保留和跟踪快照。

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

Answer 1

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

传统方式 - 我们更喜欢如果我们需要做一些数据更改并且我们想试运行我们的查询。

传统方式备份和不同的恢复方式 与#1 相同的问题，我们不使用。

卸载和复制 :这是最方便的方法，甚至 IDENTITIES 也可以保留，因此始终是首选方法。

有问题中列出了一些问题，但其中大部分是错误的，或者可以通过提供适当的导出/导入参数来避免。我想提供所有必要的步骤和数据来证明我的观点， dates 中没有问题。和 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或 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

从快照恢复表:这需要我们的“网络/基础设施组”，因此我们避免了，尽管不太确定。其他专家非常欢迎对此发表评论/分享详细信息。

我希望这能回答问题，并为 discuss/summarize/conclude 提供一个起点.欢迎大家加分。