shiran0418的博客

Amazon Redshift 流式摄取的目的是简化将流式数据直接从流式服务摄取到 Amazon Redshift 或 Amazon Redshift Serverless 的过程。官方文档[1]中有详细步骤。用unauthenticated, IAM 的方式均可以进行连接，只不过使用的是不同端口：9092或者9098。

我们可以用这个脚本，将user A的权限寻找出来，并在ddl编辑中替换成B，这样可以直接运行这个view产生的ddl，给B赋予所有A的权限。建议运行时将第一行CREATE OR REPLACE VIEW admin.v_generate_user_grant_revoke_ddl 改为了 public.v_generate_user_grant_revoke_ddl。Redshift内已经有了一个user A，不知道赋予了A什么权限，希望将所有权限都赋予User B。

Redshift这样设置的原因是，Redshift底层是与PostgreSQL 8版本兼容的，根据PostgreSQL官网，这个设置本身就是PostgreSQL对于权限的管理，而不是Redshift这个服务对于权限的特定设置。对于schema1后续创建的future table，也不会默认赋予user1 select权限，需要每次创建了新的table以后手动grant权限。这样schematest1里面新创建的table就也默认对user1有select权限了。

所以超出的长度无法传入 redshift 中.有些数据类型会在导入 redshift 时会被转换成 varchar，这些类型的数据在通过 zero-ETL 传入 redshift 时，如果超过 65535 时都有可能遇到报错。并且0etl处于异常状态的时候，不支持修改这个integration，也就是无法通过修改表增加主键，再把这个表reload一遍。同时根据如下文档，在创建集成后添加筛选条件，Aurora 会重新评估筛选条件，所有受影响的表都需要重新同步。下一篇会更新跨账号配置0etl步骤。

因此我们确定了，因为我们的所有Materialized View创建时都是BACKUP NO, 并且刚好是用了elastic resize方式将dc2集群升级到ra3类型，才导致了升级集群类型之后，MV的消失。接下来我们就继续查看，创建这些Materialized View的DDL, 然后惊喜地发现，创建MV的语句都有parameter BACKUP NO 这样的字样。那么此时再查询MV的DDL，以及文档中的定义，也是可以排查出原因的。然后我们惊讶地发现，我们没删MV呀哈哈哈。

如果我们在使用AWS Redshift时候遇到自己的会话被杀或者中断的情况，需要细致排查或者解释，可以参考如上几项细节解释和测试步骤。

在进行修改前，如果之前没有设置自动执行 vacuum 操作，很长时间也没有进行过手动的vacuum 操作，建议依据参考链接[2]执行vacuum，由于vacuum操作在大数据量又有很多未排序列的情况下，会占用很多资源并且比较费时，文档中建议也可以使用深层复制的方式进行优化，相应对资源的占用会相对较低，并耗时较短。在表比较大的情况下，列修改的耗时也会比较长。在集群的存储空间比较富裕的情况下，我们建议可以考虑在原表的基础上，做一个深层复制[1]创建出一个一样的新表，然后在新表上进行表结构的修改。

也就是说，DMS任务在启动以后，在UTC时间01:27结束了fullload，并完成了在Target Redshift的写入。的指令以后，用DMS User 当前连结的用户session并不会生效，只有在运行了alter的时间之后新建立的session，才会采用新的session timeout设置。“FATAL: terminating connection due to session timeout” 的报错与文档中的4小时空闲会话会导致Redshift断开连接的限制相符。

需要注意的是，根据文档[2], 从单个文件加载数据会迫使 Redshift 执行串行化加载，这比并行加载慢得多。因此，如果我们需要将多个文件加载到单个表，我们应该使用单个COPY命令来执行表，而不是使用多个COPY命令并行执行。根据Best Practice, 为保证集群资源的最佳使用，Copy 加载的数据文件应该被放置到多个大小均匀的文件中。Redshift中没有明确写明性能控制，但是使用Parquet文件格式，会比使用CSV格式等文本文件，卸载速度提高2倍[1].

如果我们的Redshift使用手动WLM，那么我们在定义每个队列所分派的内存的时候，需要手动输入这个队列所用到的内存。当我们使用手动WLM的时候，当Redshift中的query已经用掉了所有的查询槽，那么未分配的内存会由Redshift自行管理。如果我们的Redshift使用自动WLM，那么Redshift会自动管理我们业务运行的每个队列（queue）的并发级别和每个已分派查询的内存分配。我们可以通过增加使用的查询槽数来分配更多内存，例如：set wlm_query_slot_count to 3;

可以通过Redshift Serverless eni flow log中的记录进行排查，比如此eni访问Amazon Web Service服务网段被443端口拒掉，由于443端口是去访问secretmanager的端口，因此从Redshift Serverless服务的安全组中，将outbound rule增加了443端口的开放。Redshift访问secret manager是通过443端口，如果redshift 安全组outbound rule有限制，那么需要打开443.