AWS本月结束了对RDS上PostgreSQL 13的标准支持。客户如果想继续使用受支持的数据库（AWS积极鼓励这样做），需要升级到PostgreSQL 14或更高版本。
这个决定是合理的，因为PostgreSQL 13在去年底已达到社区生命周期终点。
PostgreSQL 14于2021年发布，默认采用更安全的密码认证方案（SCRAM-SHA-256）。然而，这恰好会导致AWS Glue（他们的托管ETL服务）出现故障，因为该服务无法处理这种认证方案。如果你按照AWS自己的安全指导升级RDS数据库，AWS自己的数据管道工具会响应"Authentication type 10 is not supported"错误并停止工作。
鉴于这两个服务通常都部署在大多数公司称为"生产环境"的环境中，这种情况相当糟糕！
废弃支持并没有创造这个问题，它只是移除了避免一个已经存在五年问题的能力，除非你承担额外的维护负担或支付扩展支持费用。
技术问题的核心在于：当你迁移到RDS上更新版本的PostgreSQL时，Glue的连接测试基础设施使用的内部驱动程序早于新认证支持。"测试连接"按钮——你在将设置应用于生产数据之前点击以验证设置是否工作的按钮——根本无法正常工作。AWS支持论坛上的社区专家三年前就承认"测试器正在等待驱动程序升级"，并向用户保证爬虫使用自己的驱动程序，应该能正常工作。但同一线程中的用户报告说爬虫也会失败。在RDS PostgreSQL上运行Glue是数据工程的基础模式，不是边缘案例——这是AWS让其陷入失修状态的一条成熟路径。
这种不兼容性自2021年PostgreSQL 14发布以来就已为人所知。PG13的废弃时间表也是提前宣布的。RDS和Glue两个团队都应该跟踪行业发展动态。但显然，两者都没有关注彼此的动向。
对这种情况发生原因的善意解读也是正确的：AWS拥有数万名工程师，组织成数百个半自主的服务团队。RDS团队按照RDS生命周期推出废弃计划，Glue团队按照Glue路线图维护驱动程序依赖关系，而没有人明确负责他们之间的差距。客户在生产环境中发现不兼容性，通常是在不方便的时间。
这不是阴谋，因为AWS缺乏实施阴谋所需的内部凝聚力。这也不是精心构建的收入增强机制，因为与它产生的客户不满相比，扩展支持收入几乎肯定是AWS资产负债表上的舍入误差。相反，这只是组织复杂性在发挥其固有作用。这就像你公司内部工具无法互相通信的原因一样；AWS只是在一个规模上这样做，其影响范围是别人的生产数据库。跨越多个碰巧共享母公司的数十亿美元业务边界的集成测试确实很困难。没有人醒来后决定破坏Glue。它从工厂就是这样的。
我想明确表示我真的相信这一点，因为我即将描述的替代方案与意图无关。
善意解读的问题在于它无关紧要
如果你在凌晨2点盯着环境中损坏的管道，原因是学术性的。你需要修复。AWS提供了三种解决方案，但都很糟糕。你可以将数据库的密码加密降级到较旧、不太安全的标准：即你刚刚按照AWS自己的建议升级离开的那个标准。你可以自带JDBC驱动程序，这会禁用连接测试，并可能不支持你想要的所有功能。或者你可以将ETL工作流重写为Python shell作业。
每个出口都意味着放弃托管服务的整个价值主张——这可能就是你陷入这种困境的原因——或者撤销你刚被告知要做的安全改进。
对于为了避免这个特定问题而继续使用PG13的客户，扩展支持现在会自动运行，除非你在集群创建时选择退出——这是一个容易错过的细节。前两年每个vCPU小时收费0.10美元，第三年翻倍。一个16-vCPU多可用区实例仅扩展支持费用一年就接近30,000美元。这不是敲诈。但这是账单上出现的数字，来自一家同时控制修复问题时间表的公司，而且所有客户响应选项都很糟糕。
AWS不需要进行敲诈。他们只需要足够大，使结果与敲诈无法区分。
这种模式不是AWS独有的，也不会消失。每个主要云提供商——实际上，每个主要技术提供商——都是半自主团队的投资组合，其路线图偶尔会在客户环境中发生冲突。这将再次发生，涉及不同的服务、不同的认证协议和不同的计费项目。问题不是组织结构图是否会产生另一个这样的差距。它会的。问题是差距出现后会发生什么：响应看起来像问责制——在废弃截止日期之前而不是之后承认不兼容性——还是看起来像耸肩和三个付费替代方案？
永远不要将可以用一个非常大的组织结构图充分解释的事情归咎于恶意。只是别忘了检查发票。
Q&A
Q1：PostgreSQL 14升级后为什么会导致AWS Glue停止工作？
A：PostgreSQL 14默认采用SCRAM-SHA-256认证方案，但AWS Glue的连接测试基础设施使用的内部驱动程序不支持这种新认证方式，会返回"Authentication type 10 is not supported"错误。
Q2：AWS为这个兼容性问题提供了哪些解决方案？
A：AWS提供三种解决方案：将数据库密码加密降级到旧标准、自带JDBC驱动程序（会禁用连接测试）、或将ETL工作流重写为Python shell作业。但这些方案都需要放弃托管服务的价值或撤销安全改进。
Q3：PostgreSQL 13扩展支持费用是多少？
A：扩展支持费用为前两年每个vCPU小时0.10美元，第三年翻倍。一个16-vCPU多可用区实例仅扩展支持费用一年就接近30,000美元。
热门跟贴