我是一名#程序员，不是DBA，我有幸接手了数据库管理任务。所以在回答这个问题时请记住这一点。
我被要求在两个数据库之间创建一个实时双向镜像，它们之间有 10 兆位连接。因此，当其中一个数据库发生变化时，另一个数据库也会更新。这不是标准的数据镜像/故障转移任务，其中一个数据库是主数据库，另一个数据库是备份数据库 - 两者都是实时的，每个数据库都需要立即反映对另一个数据库所做的更改。
在我看来，这听起来像是一项艰巨的任务，甚至是不可能的——毕竟在一个拥有大量用户的快速变化的环境中，这将耗费大量的资源，并在各处创建锁和作业队列。
有可能吗？如果可以，有人能给我一些基本说明和/或告诉我一些可以开始阅读和研究的地方吗？
干杯，马特
答案1
你会看到某种形式的复制- 合并或事务。有很多指南可以帮助您选择最适合您环境的类型。
当然，如果从字面上理解，业务需求往往是不可能的 - 例如，他们总是希望始终保持 100% 一致、没有延迟、任何类型的查询都不会受到惩罚。你必须管理一些期望。它永远不会是免费的。
复制也往往需要更改架构（例如向事务发布的表添加 rowguidcol 列）。如果您确实要走复制路线，我建议您首先尝试在一些小型练习数据库上进行设置，以了解它的工作原理以及您在使用过程中可能遇到的问题。
答案2
听起来你正在寻求合并复制。这并不简单，需要你的应用程序知道它是如何工作的。
如果您身边没有经验丰富的 DBA 来确保正确设置，合并复制通常会导致令人头痛的问题和许多熬夜、错过最后期限和停机。即便如此 - 我也有客户报告由于环境配置稍有错误而“不可能发生”的错误。
我强烈建议您了解基本要求，而不是盲目地遵循合并复制路径。
根据我的经验，我发现大多数情况下我通常能够使用日志传送和/或 SQL 镜像。
答案3
为了达到这个目标你需要测试的确实是复制但不是任何形式：事务性点对点复制 （点对点是从 SQL 2005 版本开始引入的）。我并不是说这没有麻烦，而且会很容易……您需要一个了解 DBA 的人，否则您将对您不太了解的事情负责 :)
合并复制可以合并在复制中每个参与服务器所做的修改，但不是实时的。每个服务器都将保持自主，直到冲突得到解决。合并发生时，您可以安排时间表。它不是实时的。
交易性对等复制通过在多个服务器实例（也称为节点）中维护数据副本来提供横向扩展和高可用性解决方案。对等复制建立在事务复制的基础上，可在以下环境中传播事务一致的更改：接近实时。这使得需要扩展读取操作的应用程序能够将来自客户端的读取分布到多个节点。由于数据在节点之间以近乎实时的方式维护，因此对等复制提供了数据冗余，从而提高了数据的可用性。
考虑先阅读以下文档，祝你好运。这会很有趣 :)
http://www.sql-server-performance.com/articles/dba/PeertoPeer_Replication_in_SQL_Server_2008_p2.aspx