NDB API 现在已经相当成熟,并且在最近的版本中几乎没有发生重大变化。在发生更改的地方,此类更改会在受影响的对象和方法的文档中指明。
NDB API 应用程序的 API 版本由libndbclient
用于提供 NDB API 功能的应用程序版本决定。由于需要支持滚动升级,我们对多个版本(7.3、7.4、7.5、7.6、8.0)进行了基本测试,包括连接新版本数据节点的旧 API 版本和连接新版本数据节点的新 API 版本。旧版本的数据节点。我们不再对 NDB 7.3 之前的版本执行此类测试,因为这些版本不再在生产中维护或支持。
此外,在 NDB 8.0 中,与 7.4 之前的 API 版本的某些兼容性已被删除,但在 7.4、7.5 和 7.6 版本中保留。
当新功能添加到 时NDB
,通常以这样的方式完成,即新功能包括检查当前连接的数据节点是否正在运行支持该功能的版本。这样做是为了防止在集群完全升级到添加支持的版本之前的滚动升级期间意外使用新功能。
如果使用较新版本的 NDB API 的应用程序针对不支持该应用程序使用的较新功能的较旧集群运行,则该应用程序会在尝试使用该功能时引发错误代码 4003 Function not implemented yet . 其他错误可能取决于所涉及的新功能(请参阅第 2.4.2 节,“NDB 错误代码:按类型”)。
当使用旧版本的应用程序
libndbclient
连接到运行新版本的集群时NDB
,数据节点应该支持旧的 API 调用,但还有其他注意事项。特别是,如果集群上的模式使用了旧 API 版本不支持的较新功能,则操作可能达不到最佳状态或导致错误。此处列出了一些示例:
集群中有表使用 7.5 之前
JSON
未知的数据类型NDB
NDB
集群使用一张或多张全复制表, 7.5之前版本 不支持集群包括使用生成列的表,这些列在
NDB
7.5 之前的版本 中不受支持
在线升级集群时(即使用滚动重启),现有的表模式会被保留,从而避免过早激活新模式功能。当升级重新创建架构并恢复所有数据时,情况并非如此,此时新版本可能默认使用新架构功能。出于这个原因,最好的做法是在升级生产系统之前使用特定的模式、操作和版本进行测试,以发现在将旧应用程序或 SQL 节点连接到运行新版本
NDB
.