DynamoDB global table version mismatch

TL;DR — DynamoDB 有两个全局表版本：2017.11.29（Legacy）和 2019.11.21（Current）。当成员表不满足要求时，创建一个 legacy 全局表或添加一个副本会失败——legacy 副本必须是空的、共享相同的名称、键模式和匹配的 GSI、启用了 DynamoDB Streams（新旧映像），并使用一致的写入容量——而把一个版本的 API 指向另一个版本的表会直接失败。对齐每个副本的配置（或升级到 Current 版本），然后重试。

含义

ValidationException: Cannot create a global table from a table with ...
ValidationException: ... replicas must have the same ... across all regions

Legacy 版本（2017.11.29）把独立创建的区域表拼接成一个命名的全局表，因此它要求成员表精确对齐。Current 版本（2019.11.21）在表本身上管理复制——你用 UpdateTable 添加副本——并跨副本自动同步 TTL、自动扩缩、GSI 和静态加密设置。当你合并的表不一致，或者工具与错误版本的 API 表面对话时，就会出现版本不匹配错误。

为什么会发生

一个副本表不为空——legacy 的 CreateGlobalTable/UpdateGlobalTable API 要求每个成员表都不含数据。
名称或键模式不匹配——所有副本必须共享相同的表名和主键。
不匹配的 GSI——全局二级索引在名称以及哈希/排序键上都必须跨副本匹配。
Streams 关闭或视图类型错误——每个 legacy 副本都需要启用 DynamoDB Streams，且带有项目的新旧两种映像。
不一致的写入容量——AWS 要求写入容量设置在副本表和匹配的二级索引之间一致地设置（推荐自动扩缩，或相等的复制写入容量单元）。
混用两个版本——把 legacy API（DescribeGlobalTable、UpdateGlobalTable）指向一个 Current 版本的表会返回 GlobalTableNotFoundException 而非正常工作。
过时的 AWS CLI/SDK——一个早于 2019.11.21 模型的版本无法驱动基于 UpdateTable 的副本管理。

如何修复

跨所有区域标准化成员表——相同的名称和键模式、匹配的 GSI、启用了带新旧映像的 streams，以及一致的写入容量/自动扩缩目标。
检查当前状态——每个区域用 DescribeTable（Current）或 DescribeGlobalTableSettings（一个仅 Legacy 的 API），并分别用 UpdateTable 或 UpdateGlobalTableSettings 修正偏差。
有意识地把 Legacy 升级到 Current——通过控制台的 Update version 流程，它需要在每个副本区域中拥有 dynamodb:UpdateGlobalTableversion 权限，且副本在升级期间会持续提供读写服务。
在管理 Current 版本副本之前，把你的 AWS CLI/SDK 更新到较新的版本。
把副本添加到一个兼容的基础表——Current 版本副本用 UpdateTable 添加（表可能已经含有数据，但目标区域中必须尚不存在同名的表）；legacy 副本必须从空开始。

在管理一张多区域表，想在不切换控制台的情况下比较配置？DynoTable 桌面应用按区域连接，让你能在一处细看每个副本的模式和索引。

在 DynoTable 中测量

在创建全局表之前，比较跨区域的架构、GSI 和流设置 — 使用 ⌘P 切换，使用 ⌘K 打开每个副本，并并排展开 Indexes 和 Stream 面板。使用 pricing calculator 估计复制写入成本。在“设置”→“配置文件”下使用 Test Connection 配置每个区域。参见连接 AWS和安装。

来源

DynamoDB global tables versions（2026-07-13 验证）
CreateGlobalTable — Amazon DynamoDB API Reference（2026-07-13 验证）

参考资料

最后核实于 2026-07-13，依据上方链接的 AWS 官方文档。

DynamoDB global table version mismatch

含义

为什么会发生

如何修复

在 DynoTable 中测量

来源

相关错误

参考资料