排查 Aurora DSQL 中的问题
注意
以下主题为您在使用 Aurora DSQL 时可能遇到的错误和问题提供故障排除建议。如果您发现某个问题未在此处列出,请联系 AWS 支持人员
主题
连接错误故障排除
error: unrecognized SSL error code: 6 或 unable to accept connection, sni was not received
可能您使用的 psql 版本早于 version 14
您可以使用 psql --version 来检查客户端版本。
error: NetworkUnreachable
尝试连接时出现 NetworkUnreachable 错误可能表示客户端不支持 IPv6 连接,而不是表示存在实际的网络问题。此错误通常发生在仅限 IPv4 的实例上,这是因为 PostgreSQL 客户端处理双堆栈连接的方式所致。当服务器支持双堆栈模式时,这些客户端首先将主机名解析为 IPv4 和 IPv6 地址。它们首先尝试 IPv4 连接,如果初始连接失败,则尝试 IPv6。如果系统不支持 IPv6,您将看到一条常规 NetworkUnreachable 错误,而不是一条明确的“IPv6 not supported”消息。
身份验证错误故障排除
IAM authentication failed for user "..."
在生成 Aurora DSQL IAM 身份验证令牌时,您可以设置的最长持续时间为 1 周。一周后,您将无法使用该令牌进行身份验证。
此外,如果您代入的角色已过期,Aurora DSQL 会拒绝您的连接请求。例如,如果您尝试使用临时 IAM 角色进行连接,即使您的身份验证令牌尚未过期,Aurora DSQL 也将拒绝连接请求。
要了解 IAM 如何与 Aurora DSQL 结合使用的更多信息,请参阅了解 Aurora DSQL 的身份验证和授权和 Aurora DSQL 中的 AWS Identity and Access Management。
An error occurred (InvalidAccessKeyId) when calling the GetObject operation: The AWS Access Key ID you provided does not exist in our records
IAM 拒绝了您的请求。有关更多信息,请参阅为什么签署请求。
IAM role <role> does not exist
Aurora DSQL 找不到您的 IAM 角色。有关更多信息,请参阅 IAM 角色。
IAM role must look like an IAM ARN
有关更多信息,请参阅 IAM 标识符 - IAM ARN。
用户与操作的映射错误
当身份验证令牌类型与数据库角色不匹配时,会发生此错误。Aurora DSQL 使用两种令牌类型:对于 admin 角色为 DbConnectAdmin,对于自定义数据库角色为 DbConnect。
-
如果您看到
Wrong user to action mapping. user: admin, action: DbConnect,请使用generate-db-connect-admin-auth-token来替代generate-db-connect-auth-token。 -
如果您看到
Wrong user to action mapping. user:,请使用myusername, action: DbConnectAdmingenerate-db-connect-auth-token来替代generate-db-connect-admin-auth-token。
授权错误故障排除
Role <role> not supported
Aurora DSQL 不支持 GRANT 操作。请参阅 Aurora DSQL 中支持的 SQL 命令子集。
Cannot establish trust with role <role>
Aurora DSQL 不支持 GRANT 操作。请参阅 Aurora DSQL 中支持的 SQL 命令子集。
Role <role> does not exist
Aurora DSQL 找不到指定的数据库用户。请参阅授权自定义数据库角色连接到集群。
ERROR: permission denied to grant IAM trust with role <role>
要向数据库角色授予访问权限,您必须使用管理员角色连接到集群。要了解更多信息,请参阅授权数据库角色在数据库中使用 SQL。
ERROR: role <role> must have the LOGIN attribute
您创建的任何数据库角色都必须具有 LOGIN 权限。
要纠正此错误,请确保您已创建具有 LOGIN 权限的 PostgreSQL 角色。有关更多信息,请参阅 PostgreSQL 文档中的 CREATE ROLE
ERROR: role <role> cannot be dropped because some objects depend on it
如果您删除具有 IAM 关系的数据库角色,Aurora DSQL 会返回错误,直到您使用 AWS IAM REVOKE 撤销该关系。要了解更多信息,请参阅撤销授权。
SQL 错误故障排除
Error: Not supported
Aurora DSQL 并不支持所有基于 PostgreSQL 的方言。要了解支持的内容,请参阅 Aurora DSQL 中支持的 PostgreSQL 功能。
Error: use CREATE INDEX ASYNC instead
要在包含现有行的表上创建索引,必须使用 CREATE INDEX
ASYNC 命令。要了解更多信息,请参阅在 Aurora DSQL 中异步创建索引。
错误:服务器不可用 (SQLSTATE XX000)
服务器不可用错误表示一种临时服务状态。您的连接仍然有效,因此无需重新连接即可重试。
请务必从头开始重试整个事务(包括 COMMIT 命令),并采用指数回退与抖动策略。
提交结果不确定
如果提交事务时出错,即使应用程序收到错误,事务也可能已提交。
尽可能将事务设计为幂等。对于非幂等事务,在您重试事务之前,请先确认 Aurora DSQL 是否已执行写入操作。
监控服务器不可用错误的发生率。偶尔出现重试属于正常现象。如果此类错误持续出现或影响应用程序性能,请联系 AWS Support。
并发控制响应的故障排除
OC000“错误:变更与另一个事务发生冲突(OC000)”
该事务尝试修改另一个并发事务正在处理的相同元组。这表明被修改的元组存在资源争用情况。要了解更多信息,请参阅 Aurora DSQL 中的并发控制。
OC001“错误:架构已被另一个事务更新(OC001)”
您的会话在时间 T1 加载了架构目录的缓存副本,版本为 V1。
另一个事务在时间 T2 将目录更新到版本 V2。
在时间 T3,会话运行查询时检测到版本已落后,并尝试根据新的目录更改重定基准。在某些情况下,重定基准无法成功,Aurora DSQL 会返回 40001 OC001 响应。T2 和 T3 之间的间隔可能从几毫秒到几分钟不等,因为查询处理器是被动地发现目录的更改,而不是主动接收更新。
当您从同一个会话重试时,Aurora DSQL 会刷新目录缓存。重试的事务使用目录 V2,只要自 T2 以来没有发生进一步的目录更改,该事务就会成功。
SSL/TLS 连接故障排除
SSL error: certificate verify failed
此错误表示客户端无法验证服务器的证书。请确保:
-
已正确安装 Amazon Root CA 1 证书。有关如何验证和安装此证书的说明,请参阅为 Aurora DSQL 连接配置 SSL/TLS 证书。
-
PGSSLROOTCERT环境变量指向正确的证书文件。 -
证书文件具有正确的权限。
Unrecognized SSL error code: 6
低于版本 14 的 PostgreSQL 客户端会发生此错误。要解决此问题,请将 PostgreSQL 客户端升级到版本 17。
SSL error: unregistered scheme (Windows)
这是使用系统证书时 Windows psql 客户端的一个已知问题。使用从 Windows 进行连接说明中描述的下载证书文件方法。
对 Amazon CloudWatch 数据库洞察控制台中缺失的指标进行问题排查
Aurora DSQL 集群未显示在 Amazon CloudWatch 数据库洞察控制台中
Amazon CloudWatch 数据库洞察使用来自 Aurora DSQL 数据库洞察的活动数据填充其集群选择器。有关 Aurora DSQL 数据库洞察的更多信息,请参阅使用 Aurora DSQL 数据库洞察监控 Aurora DSQL 集群。只有当集群在过去八天内产生了负载,并且该负载被 Aurora DSQL 活跃会话历史记录(DASH)采样器捕获后,该集群才会显示在数据库洞察中。
DASH 使用 1 秒采样机制,这可能会遗漏在数毫秒内完成的快速、低频事务。
请执行以下步骤,确认这是否能解释您所看到的情况:
-
确认您在过去八天内已在集群上运行事务。如果某个集群处于空闲状态超过该天数,无论您之前如何使用该集群,它都不会显示在数据库洞察中。要查看近期活动,请在 CloudWatch 中查看该集群的
TotalTransactions指标。有关该指标的更多信息,请参阅可观测性和性能。 -
对集群运行持续工作负载,使至少一个会话保持活跃状态。示例包括负载测试脚本、批量插入操作或长时间运行的查询。由于 DASH 每秒采样一次,短暂的工作负载可能无法被捕获,因此活动越持续,被采集到的概率就越高。
-
运行该工作负载后等待几分钟,然后再刷新数据库洞察控制台。
-
确认您查看的是创建该集群时所用的同一 AWS 区域和账户。选错区域或账户是导致集群看似缺失的常见原因。