在 Cloud Spanner 中，从 API 角度来看，partitionDML 是否遵循相同的重试/超时行为？

Question

从 API 角度来看，partitionDML 是否遵循相同的重试/超时行为？是否重试所有分区？还是只有失败的？

• 这种情况发生的频率和最大间隔是多少？ 1s - 5s 等等...可以配置吗？

从应用程序的角度应该如何管理？如果分区 DML 失败 - 意识到幂等性以及要么全有要么全无的事实 - 但如果失败，客户是否需要相应地管理任何内容？

从故障排除的角度来看……我们在 api 上遇到了哪些类型的错误？换句话说，如果特定分区发生故障，我们如何进行故障排除（如何修复一系列数据）？ 这是用于支付应用程序，因此一致性很重要。

Answer 1

这一切都记录在https://cloud.google.com/spanner/docs/dml-partitioned#execution-transactions

如果分区 DML 语句成功，则 Spanner 会针对键范围的每个分区至少运行该语句一次。

注意“至少一次”...这就是为什么 DML 语句需要幂等 - 即可以多次执行而没有副作用。这严重限制了可能发生的更新类型。

如果语句的执行导致错误，则所有分区的执行都会停止，并且 Spanner 会为整个操作返回该错误

这可能意味着有些分区成功了，有些分区失败了，有些甚至还没有尝试过。

一致性很重要。

分区 DML 仅在分区内具有一致性和原子性，而不是跨整个表。

如果您想确保一致性，那么可以编写代码来执行批量正常事务，其中对行集执行读取/更新事务，并且由应用程序处理失败/重试和报告的逻辑。如果您需要一致性，请使用非分区 DML。

• 所有分区都重试了吗？还是只有失败的人？ 对于暂时性错误，例如行修改争用，仅重试失败的分区。

• 这种情况发生的频率和最大间隔是多少？ 1s - 5s 等等...可以配置吗？ 整个 ExecutePartitionedDML 操作的总体超时为 1 小时 (IIRC)，无法在每个分区上指定较低的超时或超时。

从故障排除的角度来看……我们在 api 上遇到了哪些类型的错误？换句话说，如果特定分区发生故障，客户如何排除故障（如何修复一系列数据）？

您将从第一个失败的分区中收到一个错误，该错误的方式与您从正常 DML 中收到错误的方式类似 - 错误将包括原因...但如果他们预计会出现很多错误，这将是一个非常严重的错误。识别有问题的行的缓慢方法