【问题标题】:Amazon Redshift-Backup & Restore best practices?Amazon Redshift-备份和恢复最佳实践?
【发布时间】:2018-07-21 00:30:37
【问题描述】:

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

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

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

【问题讨论】:

    标签: amazon-s3 amazon-redshift


    【解决方案1】:

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

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

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

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

    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
    

    将导入 datetimestamps 以及 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 命令运行到任何其他环境,例如devQA 或某处,我将获得与之前完全相同的记录在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. 从快照恢复表:这需要我们的`networking/infrastructure 组,因此我们避免,尽管不太确定。欢迎其他专家对此发表评论/分享详细信息。

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

    【讨论】:

    • 具有前导零的 DATE 字段未在 UNLOAD 提取中正确提取。例如:将日期“0001-01-01”提取为“1-01-01”。您的回答无法解决此问题。在一个完美的世界中,这些数字不应该存在,但我们无法控制源数据。
    • 200 GB 的数据,UNLOAD 和 COPY 需要多少时间?每小时运行一次是否可行?
    • @nightgaunt 如果1-01-01 在任何用例中都是合法的,to_date 函数会很有帮助,它会产生正确的日期,因为0001-01-01 sql 类似于unload ('select salesid,commission,to_date(saledate,\'YYYY-MM-DD\') as saledate,description,created_at,updated_at from sales') to 's3://********/de***/sales-example.txt' credentials 'aws_access_key_id=******8;aws_secret_access_key=********' parallel off;
    猜你喜欢
    • 2015-02-05
    • 1970-01-01
    • 2012-05-16
    • 1970-01-01
    • 1970-01-01
    • 2021-05-30
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多