分布式数据(4)分布式与版本化


地理数据库复制基于传统版本化。复本创建期间,系统会将源和目标企业级地理数据库中的版本设置为复本版本。这些复本版本中的更改将在同步过程中进行交换。由于复本版本处于关联状态,因此可将其视为是通过扩展版本树来跨越多个地理数据库的方法。

可将默认版本或任何命名的版本用作父复本或子复本的复本版本。多个复本也可以共用同一复本版本。

一、复制和版本化

1.单向和双向复本

下图显示了单向复制和双向复制中的复本版本。对于双向复制,父复本将命名的版本 RV1 用作复本版本。单向复制示例中的父复本则将命名的版本 RV2 用作两个单向示例的复本版本。

对于企业级地理数据库中托管的两个子复本,默认版本即为复本版本。除了复本版本将用于复制过程之外,复本版本与其他版本没有任何区别。由于文件地理数据库不支持版本化,因此不会在单向复本的子复本地理数据库中创建复本版本。

注:
也可以使用指定版本作为下图中任一企业级地理数据库中的复本版本。
在这里插入图片描述

2.检出/检入复本

检出/检入复制能够复制版本化和非版本化数据。对于涉及版本化数据的检出复本,将创建一个新的指定版本以用作子复本上的复本版本,前提是子复本为企业级地理数据库。

检出/检入复制同时允许文件地理数据库托管子复本。由于这些地理数据库类型不支持版本管理,因此不会为子复本创建任何复本版本。检出非版本化数据时也是如此。对于此类情况,同步期间将使用附加逻辑来确定要发送的更改。

在检出/检入复制中,将使用复本的名称创建一个新版本。用户名和复本名称的组合必须是唯一的。例如,user1 和 user2 都可以创建一个名为 MyReplica 的复本,因为完整的复本名称是 user1.MyReplica 和 user2.MyReplica。但是,user1 不能创建多个名为 MyReplica 的复本,因为这样会造成复本名称不唯一。

下图显示了检出/检入复本及其复本版本的两个示例。一个父复本将版本 RV1 用作复本版本,而另一个父复本则将版本 RV2 用作复本版本。一个子复本由文件托管,另一个由企业级地理数据库托管。对于托管子复本的企业级地理数据库,创建期间会自动创建 RV2 并将其设置为复本版本。此复本版本的名称 RV2 取自复本的名称。将在此复本版本中对子复本执行编辑以同步回父复本。
在这里插入图片描述

二、同步和版本管理

对于企业级地理数据库中的复本,地理数据库复制在同步过程中使用版本化。版本化用于确定要发送和接收的变更。使用存档追踪单向复制中的变更是个例外。

下面分别介绍在上述每个同步过程中如何使用版本化:

1.发送变更

当复本发送变更时,将分析复本版本(在复本创建期间定义)和系统版本。此分析可以过滤出在早期同步中已经预先发送的编辑内容或确定需要重新发送的一些变更。对于文件地理数据库中的检出/检入复本,将分析包含所有编辑内容的内部表。对于使用存档的单向复制,将分析存档类以确定要发送的变更。

2.接收变更

复本接收变更时,会发生以下情况:

首先,变更将作用于同步版本。同步版本是复本版本的子版本,用于临时保存已同步的更改,直到对其进行协调并提交到复本版本。对于双向和单向复本,可能不会在同步之前创建版本,而对于检出/检入复本,将在创建复本时创建版本。下图中,复本版本可能是默认版本或指定版本。
在这里插入图片描述
接下来,将针对复本版本协调同步版本。此步骤中的行为取决于复本类型:

•双向复本 - 对于双向复本,协调过程中可能存在冲突。如果检测到冲突,则可使用协调策略确定如何处理这些冲突。如果没有冲突,或冲突已被自动协调策略解决,则复本版本将以同步版本提交。

•检出/检入复本 - 对于检出/检入复本,协调和提交过程可选,且默认不执行。如果选择不执行协调和提交,则变更将保留在同步版本中。以后可以手动协调和提交。如果决定执行协调和提交,则行为将与双向复本相同。

•单向复本 - 对于单向复本,将始终覆盖复本版本中的变更,且不会产生未解决的冲突。使用简单模型类型时,不必版本化子复本中的数据。如果未对子复本进行版本化,则变更将直接作用于基表。对于子复本托管在文件地理数据库中的情况,也会直接覆盖变更。
在这里插入图片描述
将变更提交到复本版本后,同步版本随即删除。对于双向复本,只要存在同步版本,就认为复本存在冲突。存在冲突时,复本可以接收变更但不会发送变更。
在这里插入图片描述
注:
建议以复本所有者身份登录时执行协调和提交。默认情况下,同步版本是私有版本,只有复本所有者才能访问。如果将其设为公共版本,则不是复本所有者也可以协调和保存更改。但是,必须以复本版本所有者身份登录时,才能提交更改。

猜你喜欢

转载自blog.csdn.net/baidu_28157641/article/details/109138888