Sql server SQL Server事务复制：将行推送到订阅服务器表

我正在研究SQL Server事务复制。我们正在开发三个内部应用程序，每个应用程序都有自己的数据库。我们需要允许同一用户访问不同的应用程序

我们正在考虑建立一个与应用程序数据库分离的

用户

数据库，这样我们就不会在三个不同的数据库中复制用户数据。在复制过程中，我们希望

用户

数据库成为发布者，三个应用程序数据库成为订阅者。我们认为发布者数据库将

将新注册的用户推送到订阅服务器，因此我们正在复制用户数据（插入/更新/删除）

将用户从发布服务器发布到订阅服务器是否会在事务中发生？事务复制的
事务
部分是否保证从发布服务器到订阅服务器的推送成功完成

注册的最终结果将是一个包含用户GUID（以及其他数据点）的令牌。注册完成后创建的令牌将返回给调用应用程序，以便用户可以继续使用目标应用程序

目标应用程序将解压缩令牌，并使用用户的GUID确保用户有权访问该应用程序。因此，复制过程必须将用户的GUID推送到订阅服务器数据库，以便在目标应用程序解压缩令牌并检查相应应用程序数据库中是否存在用户的GUID后，用户的GUID可用

我们看得对吗？对此方法的任何指导都将不胜感激。谢谢。
将所有3个应用程序指向同一个用户数据库，并将所有3个应用程序插入到同一个表中，不是更容易吗

但是，假设你需要将它们分开，并回答你的问题

事务复制是有效的，它只是订阅服务器上正在发布的文章的日志重播，而且速度很快。在我的工作中，我们将大量复制用于ETL/仓库/报告目的，每天几乎实时地复制数千万行数据。有延迟，但只有一两秒钟

考虑到手头的信息，你所描述的听起来确实可行。一旦插入新用户，它几乎会在事务提交后立即出现在订阅服务器数据库中

从MSDN：

日志读取器代理在分发服务器上运行；它通常连续运行，但也可以根据您建立的计划运行。执行时，日志读取器代理首先读取发布事务日志（与常规SQL Server数据库引擎操作期间用于事务跟踪和恢复的数据库日志相同）并标识任何INSERT、UPDATE和DELETE语句，或对标记为复制的事务中的数据所做的其他修改。接下来，代理将这些事务分批复制到分发服务器上的分发数据库。日志读取器代理使用内部存储过程sp_replcmds获取下一组commands从日志中标记为复制。然后分发数据库成为存储转发队列，更改从该队列发送到订阅服务器。只有提交的事务才会发送到分发数据库。“

我认为在这里提到合并（双向）复制也很重要

无法在事务（单向）复制中更新订阅服务器数据。这样做会破坏复制，通常必须重新初始化订阅才能修复它。合并复制是双向的，其中订阅服务器是可更新的，这些更新将传播到发布服务器和其他订阅服务器

合并复制的配置更为复杂，根据我的经验，维护起来也更为困难，但是它可以让您的每个应用程序
插入
/
更新自己的用户数据库副本，并让这些更改流到其他用户数据库

MSDN:
将所有3个应用程序指向同一个用户数据库，并让所有3个应用程序插入同一个表不是更容易吗

但是，假设你需要将它们分开，并回答你的问题

事务复制是有效的，它只是订阅服务器上正在发布的文章的日志重播，而且速度很快。在我的工作中，我们将大量复制用于ETL/仓库/报告目的，每天几乎实时地复制数千万行数据。有延迟，但只有一两秒钟

考虑到手头的信息，你所描述的听起来确实可行。一旦插入新用户，它几乎会在事务提交后立即出现在订阅服务器数据库中

从MSDN：

日志读取器代理在分发服务器上运行；它通常连续运行，但也可以根据您建立的计划运行。执行时，日志读取器代理首先读取发布事务日志（与常规SQL Server数据库引擎操作期间用于事务跟踪和恢复的数据库日志相同）并标识任何INSERT、UPDATE和DELETE语句，或对标记为复制的事务中的数据所做的其他修改。接下来，代理将这些事务分批复制到分发服务器上的分发数据库。日志读取器代理使用内部存储过程sp_replcmds获取下一组co从日志中标记为复制的mmand。然后，分发数据库将成为存储转发队列，更改将从该队列发送到订阅服务器。只有提交的事务才会发送到分发数据库