SQL Server 2014: Merge Replication

Merge replication, like transactional replication, typically starts with a snapshot of the publication database objects and data. Subsequent data changes and schema modifications made at the Publisher and Subscribers are tracked with triggers. The Subscriber synchronizes with the Publisher when connected to the network and exchanges all rows that have changed between the Publisher and Subscriber since the last time synchronization occurred.

Merge replication is typically used in server-to-client environments. Merge replication is appropriate in any of the following situations:

  • Multiple Subscribers might update the same data at various times and propagate those changes to the Publisher and to other Subscribers.
  • Subscribers need to receive data, make changes offline, and later synchronize changes with the Publisher and other Subscribers.
  • Each Subscriber requires a different partition of data.
  • Conflicts might occur and, when they do, you need the ability to detect and resolve them.
  • The application requires net data change rather than access to intermediate data states. For example, if a row changes five times at a Subscriber before it synchronizes with a Publisher, the row will change only once at the Publisher to reflect the net data change (that is, the fifth value).

Merge replication allows various sites to work autonomously and later merge updates into a single, uniform result. Because updates are made at more than one node, the same data may have been updated by the Publisher and by more than one Subscriber. Therefore, conflicts can occur when updates are merged and merge replication provides a number of ways to handle conflicts.

Source:
Merge Replication

Keywords:
Replication, Sharding, Redundancy, Disconnected Data, SQL Server, SQL Server 2014, Microsoft

Comments

Popular posts from this blog

SQL Server Setup: Windows Firewall warning (Ports)

SQL Server 2014 Enterprise Edition: Server Setup: Feature Selection

How to read an assembly.dll.config