Question

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

传统方式：使用CREATE TABLE XYZ_BKP AS SELECT * FROM XYZ在另一个备份模式中创建备份表。但这样做我们失去了IDENTITY和表的其他属性。因此，在恢复期间，如果您尝试直接从备份创建表，则会丢失属性属性，并且您无法更改IDENTITY约束。
传统方式备份和不同的还原方法：这次我们首先删除并重新创建具有DDL的表，然后尝试从备份执行INSERT INTO。但它无法将值插入IDENTITY列。
卸载并复制：我们还尝试使用Redload等实用程序（如UNLOAD）在S3中备份表，然后使用副本进行还原。它工作正常，但后来我们面临其他问题 - 一个。具有前导零的DATE字段未在UNLOAD提取中正确提取。例如：日期'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

从快照还原表：这需要我们的“网络/基础结构”组，因此尽管不确定，但还是避免了。 Othe专家非常乐于评论/分享有关此的详细信息。

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

亚马逊Redshift-Backup＆amp;恢复最佳做法？

1 个答案: