AWS aurora-dsql: Retry guidance for server unavailable (SQLSTATE XX000) errors
Summary
Documents handling of transient 'server unavailable (SQLSTATE XX000)' errors: retry the whole transaction with exponential backoff and jitter, avoid reconnecting, design idempotent transactions, and verify writes when commit outcome is uncertain.
Security assessment
The guidance addresses reliability and data-integrity (duplicate/uncertain writes on retry), not an attack vector or a fixed flaw. There is no mention of authentication, encryption, or access control, so it is at most tangentially security-relevant hardening advice.
Evidence
+Design transactions to be idempotent when possible. For non-idempotent transactions, confirm whether Aurora DSQL applied the write before you retry the transaction.
Diff
diff --git a/aurora-dsql/latest/userguide/troubleshooting.md b/aurora-dsql/latest/userguide/troubleshooting.md index 64163aa26..eab0c755c 100644 --- a//aurora-dsql/latest/userguide/troubleshooting.md +++ b//aurora-dsql/latest/userguide/troubleshooting.md @@ -116,0 +117,14 @@ To create an index on a table with existing rows, you must use the `CREATE INDEX +### Error: server unavailable (`SQLSTATE XX000`) + +A server unavailable error indicates a temporary service condition. Your connection remains active, so you can retry without reconnecting. + +Always retry the entire transaction from the beginning, including the `COMMIT` command, with exponential backoff and jitter. + +###### Uncertain commit outcome + +If the error occurs while committing a transaction, the transaction might have committed even though your application received an error. + +Design transactions to be idempotent when possible. For non-idempotent transactions, confirm whether Aurora DSQL applied the write before you retry the transaction. + +Monitor the rate of server unavailable errors. Expect occasional retries. If the errors become sustained or affect application performance, contact AWS Support. +