View a markdown version of this page

Amazon Redshift 中的行为更改 - Amazon Redshift
即将发生的行为更改最近的行为更改

2026 年 6 月 30 日之后，Amazon Redshift 不再支持使用 Python UDF。我们将分阶段开始执行。有关 Python 生命周期终止和迁移选项详情的更多信息，请参阅 2025 年 6 月 30 日发布的博客文章。

Amazon Redshift 中的行为更改

随着 Amazon Redshift 不断发展和改进，为了增强性能、提高安全性和改善用户体验，我们引入了一些行为更改。此页面包含全面的资源，让您可以随时了解这些关键更新，采取必要措施，并避免对工作负载造成中断。

即将发生的行为更改

以下描述了即将发生的行为更改。

Amazon Redshift Serverless 和 Amazon Redshift RG 实例上手动快照的增强计费模式于 2026 年 6 月 8 日生效

从 2026 年 6 月 8 日起，Amazon Redshift 宣布对 Amazon Redshift Serverless 和 Amazon Redshift RG 实例上的手动快照采用增强计费模式。通过此增强功能，现在可以根据您账户中所有活跃手动快照中存储的唯一数据块数，来对手动快照进行计量。出现在多个快照中的共享数据块仅计数一次，按您所在区域的现有手动快照费率计费。

如果您在 Amazon Redshift Serverless 工作组或 Amazon Redshift RG 集群上使用手动快照，则可能会受到此影响。这样可以降低维护多个快照的客户的手动快照成本。

无需采取行动。增强计费模式同时自动适用于现有和新的手动快照。

有关快照定价的更多信息，请参阅 Amazon Redshift 定价。

从补丁 202 开始，Lake Formation 表上的 Iceberg DELETE 需要 DELETE 权限

从 Amazon Redshift 补丁 202 开始，对 Lake Formation（LF）托管表执行 Iceberg DELETE 操作需要 DELETE Lake Formation 权限。UPDATE 和 MERGE 操作要求同时具有 INSERT 和 DELETE 权限。所有 Iceberg DML 操作都需要 ALTER 权限。

如果您对由 AWS Lake Formation 管理的 Iceberg 表执行 DELETE、UPDATE 或 MERGE 操作，则可能会受到此影响。

以前，仅具有 INSERT 权限（而没有 DELETE 权限）的主体可以对 LF 管理的 Iceberg 表执行删除操作。从补丁 202 开始，DELETE 操作需要 DELETE Lake Formation 权限。在显式授予 DELETE 权限之前，仅依赖 INSERT 权限来执行删除操作的主体将收到权限错误。S3 表类数据存储服务不受此更改的影响。

要在此更改后继续执行 DELETE 操作，请查看您对 Iceberg 表授予的 Lake Formation 权限，并确保执行删除操作的主体已获得 DELETE Lake Formation 权限。您可以使用 AWS Lake Formation 控制台或 aws lakeformation list-permissions AWS CLI 命令验证现有授权。

如果您需要暂时恢复到之前的行为，请联系 AWS Support 以在集群上禁用此更改，而无需部署代码。

有关补丁版本的更多信息，请参阅 Amazon Redshift 的集群版本。

从补丁 202 开始，Amazon Redshift Serverless 在快照还原时保留零 ETL 和 S3 事件集成

从 Amazon Redshift 补丁 202 开始，当您将 Amazon Redshift Serverless 命名空间从快照或恢复点还原到相同的无服务器命名空间时，将自动保留与该命名空间和快照/恢复点关联的零 ETL 和 S3 事件集成。无需执行其它操作。

如果您将快照或恢复点还原到配置了零 ETL 或 S3 事件集成的 Amazon Redshift Serverless 命名空间，则您可能会受到此影响。

以前，将快照或恢复点还原到无服务器命名空间，会将关联的零 ETL 和 S3 事件集成标记为失败，需要您在还原完成后手动重新创建它们。从补丁 202 开始，默认情况下会保留这些集成，并在还原完成后恢复运行。

仅当还原到相同的无服务器命名空间时，此功能才适用于 Amazon Redshift Serverless。将快照还原到其它命名空间不会保留集成。预调配集群上的快照还原不会保留零 ETL 或 S3 事件集成。

要选择退出在还原期间保留集成，请在 AWS Management Console中取消选中还原页面上的保留集成框。如果您使用的是 AWS CLI，请在调用 restore-from-snapshot 或 restore-from-recovery-point API 操作时设置 --no-maintain-integration 参数。当您选择退出时，集成将在还原后进入 FAILED 状态。然后，您可以删除失败的集成并重新创建它们。

有关补丁版本的更多信息，请参阅 Amazon Redshift 的集群版本。

2026 年 9 月 30 日终止对 Amazon Redshift ODBC 1.x 驱动程序的支持

从 2026 年 9 月 30 日起，Amazon Redshift 将停止对 ODBC 1.x 驱动程序的支持。根据客户反馈，我们已将最初的支持终止日期从 2026 年 6 月 30 日延长至 2026 年 9 月 30 日，以便为迁移提供更多时间。这同时适用于 Amazon Redshift 预置集群和无服务器工作组。

如果您使用任何版本的 ODBC 1.x 驱动程序连接到 Amazon Redshift，则可能会受到影响。要验证您使用的是否为 ODBC 1.x 驱动程序，请运行以下查询：

SELECT *
FROM SYS_CONNECTION_LOG
WHERE 
(driver_version ilike 'Amazon Redshift ODBC Driver 1%'
OR driver_version ilike 'Redshift ODBC Driver 01%'
OR driver_version ilike 'Redshift ODBC Driver 1,%'
)
OR
(application_name ilike 'Amazon Redshift ODBC Driver 1%');

要继续获得 Amazon Redshift ODBC 驱动程序连接的技术支持，请在 2026 年 9 月 29 日之前迁移到最新的 Amazon Redshift ODBC 2.x 驱动程序。

在生产环境中迁移到 ODBC 2.x 驱动程序之前，我们建议进行全面的概念验证，以验证新驱动程序满足您的所有功能要求。

我们建议使用最新版本的 Amazon Redshift ODBC 2.x 驱动程序，并设置 ApplicationName 属性，以便在连接到 Amazon Redshift 时标识您的应用程序。

标量 Python UDF 将在 2026 年 6 月 30 日之后终止支持

Amazon Redshift 将在 2026 年 6 月 30 日之后终止对 Python UDF 的支持。作为替代方案，我们建议您使用 Lambda UDF。

与 Python UDF 相比，Lambda UDF 具有以下优点：

  • Lambda UDF 可以从 UDF 逻辑内部连接到外部服务和 API。

  • Lambda UDF 使用 Lambda 计算资源。计算密集型或内存密集型 Lambda UDF 不会影响 Amazon Redshift 的查询性能或资源并发性。

  • Lambda UDF 支持运行 Python 代码。Lambda UDF 支持多个 Python 运行时，具体取决于特定的使用案例。有关更多信息，请参阅《AWS Lambda 开发人员指南》中的使用 Python 构建。

  • 您可以将自定义代码执行隔离在单独的服务边界中。这可简化维护、监控、预算制定和权限管理。

有关创建和使用 Lambda UDF 的信息，请参阅《Amazon Redshift 数据库开发人员指南》中的标量 Lambda UDF。有关将现有 Python UDF 转换为 Lambda UDF 的信息，请参阅博客文章。

2026 年 2 月 27 日之后的实体化视图（MV）自动 REFRESH 行为更改

从 2026 年 2 月 27 日起，Amazon Redshift 实体化视图的自动 REFRESH 查询将作为用户查询而不是后台自主进程执行。因此，自动 REFRESH 查询现在的运行优先级与其它用户查询相同。

与之前的行为相比，此更改提高了启用自动 REFRESH 功能的实体化视图的新鲜度，有助于它们更及时地了解对基表的最新更改。

注意：MV 自动 REFRESH 行为更改功能仅适用于补丁版本 P198 及更高版本的当前跟踪版本上的 Amazon Redshift 预置集群。它目前在无服务器上处于禁用状态。

2026 年 2 月 16 日之后，Amazon Redshift 将不支持通过数据共享访问使用者信息的函数

从 2026 年 2 月 16 日起，Amazon Redshift 将不再支持使用 user_is_member_of 以及通过数据共享访问使用者用户、角色或组信息的相关函数。

传输层安全性协议（TLS）最低版本变更自 2026 年 7 月 30 日起生效

自 2026 年 7 月 30 日起，Amazon Redshift 将强制使用最低的传输层安全性协议（TLS）版本 1.2。使用 TLS 版本 1.0 或 1.1 的传入连接将遭到拒绝。这同时适用于 Amazon Redshift 预置集群和无服务器工作组。未使用 TLS 的 Amazon Redshift 数据仓库将不受此变更的影响。

如果您使用 TLS 版本 1.0 或 1.1 连接到 Amazon Redshift，此更新可能会影响您。

要验证您当前使用的 TLS 版本，您可以：

对于 Amazon Redshift 预置：检查 STL_CONNECTION_LOG 系统表中的 sslversion 列 [1]。

对于 Amazon Redshift Serverless 工作组：检查 SYS_CONNECTION_LOG 系统表中的 ssl_version 列 [2]。

要在此更改后保持对 Amazon Redshift 数据仓库的不间断访问，请按照以下所列步骤操作：

  1. 更新您的客户端以支持 TLS 1.2 或更高版本

  2. 安装支持 TLS 1.2+ 的最新驱动程序版本

如果可能，我们建议使用最新版本的 Amazon Redshift 驱动程序 [3]。

[1] https://docs.aws.amazon.com/redshift/latest/dg/r_STL_CONNECTION_LOG.html

[2] https://docs.aws.amazon.com/redshift/latest/dg/SYS_CONNECTION_LOG.html

[3] https://docs.aws.amazon.com/redshift/latest/mgmt/configuring-connections.html

2025 年 10 月 30 日之后，Amazon Redshift 将不支持创建新的标量 Python UDF

2025 年 10 月 30 日之后，Amazon Redshift 将不再支持创建新的 Python UDF。现有的 Python UDF 将继续正常运行。我们强烈建议您在该日期之前将现有的 Python UDF 迁移至 Lambda UDF。

与 Python UDF 相比，Lambda UDF 具有以下优点：

  • Lambda UDF 可以从 UDF 逻辑内部连接到外部服务和 API。

  • Lambda UDF 使用 Lambda 计算资源。计算密集型或内存密集型 Lambda UDF 不会影响 Amazon Redshift 的查询性能或资源并发性。

  • Lambda UDF 支持运行 Python 代码。Lambda UDF 支持多个 Python 运行时，具体取决于特定的使用案例。有关更多信息，请参阅《AWS Lambda 开发人员指南》中的使用 Python 构建。

  • 您可以将自定义代码执行隔离在单独的服务边界中。这可简化维护、监控、预算制定和权限管理。

有关创建和使用 Lambda UDF 的信息，请参阅《Amazon Redshift 数据库开发人员指南》中的标量 Lambda UDF。有关将现有 Python UDF 转换为 Lambda UDF 的信息，请参阅博客文章。

最近的行为更改

2025 年 8 月 26 日之后，Amazon Redshift 使用最新的 IANA 时区数据库

从 2025 年 8 月 26 日起，Amazon Redshift 通过采用最新的 IANA 时区数据库补丁来计算时区。此更改会更改某些时区和时段的日期和时间转换的运作方式。此更新会影响显式时区转换，例如使用 CONVERT_TIMEZONE 函数或 TIMEZONE 和 AT TIME ZONE 命令执行的转换，以及在类型强制转换操作期间发生的隐式转换，特别是 TIMESTAMP 和 TIMESTAMPTZ 格式之间的转换。

以下是时区和时段组合的更新列表：

  • 现在，在 2038 年后，时区可以正确地遵守夏令时（DST）。以前，在 2038 年后，没有时区遵循夏令时。

  • 对于 America/Toronto 时区以及与之关联的时区，在 1947-1950 年，夏令时在当地时间凌晨 2 点而不是午夜进行切换。

  • Amazon Redshift 现在可以正确反映在所有时区标准化之前时段的本地平均时间（LMT）。这个时段是特定于时区的，大多数时区在 19 世纪中叶之前都转向了标准化。

  • EET、CET、WET 和 MET 现在被视为正常时区而不是缩写。

  • Amazon Redshift 中不再存在以下时区名称：

    • Asia/Riyadh87

    • Asia/Riyadh88

    • Asia/Riyadh89

    • Mideast/Riyadh87

    • Mideast/Riyadh88

    • Mideast/Riyadh89

    • US/Pacific-New

有关 IANA 时区数据库的更多信息，请参阅 IANA 时区数据库网站上的 Time Zone Database。

Amazon Redshift Serverless RPU 更改将于 2025 年 8 月 15 日之后生效

从 2025 年 8 月 15 日起，Amazon Redshift Serverless 基本 Redshift 处理器（RPU）的 AWS 账户配额为 3200 个 RPU 或前六个月最大累计基本 RPU 的 1.5 倍（以较大值为准）。

数据库审计日志记录更改在 2025 年 8 月 10 日之后生效

从 2025 年 8 月 10 日起，Amazon Redshift 将对数据库审计日志记录进行更改，这需要您采取行动。Amazon Redshift 会将有关数据库中连接和用户活动的信息记录到 Amazon S3 存储桶和 CloudWatch。2025 年 8 月 10 日之后，对于具有用于指定 Redshift IAM USER 的存储桶策略的 Amazon S3 存储桶，Amazon Redshift 将停止数据库审计日志记录。我们建议更新您的策略，以便在 S3 存储桶策略中改用 Redshift SERVICE-PRINCIPAL 来实现审计日志记录。有关审计日志记录的信息，请参阅 Amazon Redshift 审计日志记录的存储桶权限。

为避免任何日志记录中断，请在 2025 年 8 月 10 日之前查看并更新您的 S3 存储桶策略，以便向关联区域中的 Redshift 服务主体授予访问权限。有关数据库审计日志记录的信息，请参阅 Amazon S3 中的日志文件。

如有疑问或疑虑，请通过以下链接联系 AWS 支持人员：AWS Support。

无服务器工作组的虚拟私有云端点更改将于 2025 年 6 月 27 日之后生效

从 2025 年 6 月 27 日起，Amazon Redshift 更改虚拟私有云端点（VPCE）对无服务器工作组的支持。在此日期之前，Amazon Redshift 在工作组创建期间将端点部署到单个可用区（AZ），并随着时间推移将 VPCE 支持扩展到多达三个可用区。在此日期之后，Amazon Redshift 将在工作组创建期间指定的多达三个可用区中部署 VPCE。

有关更多信息，请参阅 使用 Amazon Redshift Serverless 时的注意事项。

如有疑问或疑虑，请通过以下链接联系 AWS 支持人员：AWS Support。

查询监控更改于 2025 年 5 月 2 日之后生效

自 2025 年 5 月 2 日起，我们将不再为现有和新创建的 Redshift Serverless 工作组提供查询限制选项卡中的查询 CPU 时间 (max_query_cpu_time) 和查询 CPU 使用率 (max_query_cpu_percentage) 指标。在此日期之后，我们将自动移除所有 Redshift Serverless 工作组中基于这些指标的所有查询限制。

查询限制旨在捕获失控的查询。但是，在查询的生命周期中，查询 CPU 时间 (max_query_cpu_time) 和查询 CPU 使用率 (max_query_cpu_percentage) 可能会有所不同，因此不是用于捕获失控查询的持续有效的方法。要捕获失控的查询，我们建议您利用可提供一致且切实可行的信息的查询监控指标。一些示例包括：

  • 查询执行时间 (max_query_execution_time)：确保查询在预期的时间范围内完成。

  • 返回行数 (max_scan_row_count)：监控正在处理的数据的规模。

  • 查询队列时间 (max_query_queue_time)：识别需要花费时间排队的查询。

有关支持的指标的完整列表，请参阅查询 Amazon Redshift Serverless 的监控指标。

在 2025 年 1 月 10 日之后生效的安全更改

安全性一直是 Amazon Web Services（AWS）的重中之重。为此，我们通过引入增强的安全默认值来进一步加强 Amazon Redshift 环境的安全状况，这些默认值有助于您在无需额外设置的情况下遵守数据安全的最佳实践，并降低潜在错误配置的风险。为避免任何潜在的中断，请在生效日期之前查看预置集群和无服务器工作组的创建配置、脚本和工具，以进行必要的更改，使其与新的默认设置保持一致。

默认情况下禁用公共访问权限

2025 年 1 月 10 日之后，默认情况下，对于所有新创建的预置集群以及从快照还原的集群禁用公共可访问性。在此版本中，默认情况下，只允许从同一虚拟私有云（VPC）内的客户端应用程序连接到集群。要从其它 VPC 中的应用程序访问数据仓库，请配置跨 VPC 访问。此更改将反映在 CreateCluster 和 RestoreFromClusterSnapshot API 操作以及相应的 SDK 和 AWS CLI 命令中。如果您通过 Amazon Redshift 控制台创建预置集群，则默认情况下，该集群已禁用公共访问权限。

如果您仍然需要公共访问权限，将需要在运行 CreateCluster 或 RestoreFromClusterSnapshot API 操作时覆盖默认值并将 PubliclyAccessible 参数设置为 true。对于可公共访问的集群，建议您必须使用安全组或网络访问控制列表（ACL）来限制访问权限。有关更多信息，请参阅VPC 安全组和为 Amazon Redshift 集群或 Amazon Redshift Serverless 工作组配置安全组通信设置。

默认加密

2025 年 1 月 10 日之后，Amazon Redshift 将通过启用加密来作为所有新创建的 Amazon Redshift 预置集群的默认设置，进一步增强数据和集群的安全性。这不适用于从快照还原的集群。

进行此更改后，当使用 AWS Management Console、AWS CLI 或 API 创建预置集群而不指定 KMS 密钥时，解密集群的功能将不再可用。集群将自动使用 AWS 拥有的密钥进行加密。

如果您使用自动脚本创建未加密的集群，或利用与未加密集群的数据共享，则此更新可能会对您产生影响。为确保无缝过渡，请更新用于创建未加密集群的脚本。此外，如果您定期创建新的未加密使用者集群并将其用于数据共享，请检查您的配置以确保生产者和使用者集群都经过加密，从而防止中断数据共享活动。有关更多信息，请参阅 Amazon Redshift 数据库加密。

强制执行 SSL 连接

2025 年 1 月 10 日之后，Amazon Redshift 将默认对连接到新创建的预置和还原集群的客户端强制执行 SSL 连接。此默认更改也将适用于无服务器工作组。

通过此更改，将为所有新创建或还原的集群引入一个名为 default.redshift-2.0 的新默认参数组，而 require_ssl 参数默认设置为 true。在没有指定的参数组的情况下创建的任何新集群都将自动利用 default.redshift-2.0 参数组。通过 Amazon Redshift 控制台创建集群时，将自动选择新的 default.redshift-2.0 参数组。此更改还将反映在 CreateCluster 和 RestoreFromClusterSnapshot API 操作以及相应的 SDK 和 AWS CLI 命令中。如果您使用现有或自定义参数组，Amazon Redshift 将继续使用在参数组中指定的 require_ssl 值。您可以根据需要，继续选择更改自定义参数组中的 require_ssl 值。

对于 Amazon Redshift Serverless 用户，config-parameters 中的默认值 require_ssl 将更改为 true。任何创建将 require_ssl 设置为 false 的新工作组的请求都将被拒绝。创建工作组后，您可以将 require_ssl 值更改为 false。有关更多信息，请参阅 配置连接的安全选项。

请注意，如果您的特定用例需要，您仍然可以修改集群或工作组设置以更改默认行为。