Chapter 17 · Replication, Log Shipping, Distributed Availability, and Data Movement

Snapshot, Transactional, and Merge Replication Architecture and Appropriate Use Cases

Choose snapshot, transactional or merge replication from writer topology, freshness and conflict requirements while keeping backups and HA responsibilities separate.

Advanced175–220 minutesreplication architecture labSQL Server 2025 CU7 · 17.0.4065.4Compatibility 170 · Developer simulationSSMS 22.8.2 · Last reviewed August 2026

Learning outcomes

Chapter 16 kept a service available by moving ownership between replicas. Chapter 17 starts with a different question: what if the business wants copies of selected data in other places? Reporting, disconnected field work, regional distribution and integration do not all need whole-database failover. SQL Server replication is a family of data distribution technologies. It can copy selected objects and rows, but it does not replace backups, point-in-time recovery, cluster quorum or an application failover plan.

01

Explain Publisher, Distributor, Subscriber, publication, article, subscription and replication agents without treating replication as generic HA.

02

Distinguish snapshot, transactional and merge replication by change model, latency, writer topology and conflict behavior.

03

Inspect whether a local SQL Server instance is configured as a Publisher/Distributor/Subscriber before changing anything.

04

Recognize SQL Server 2025 edition and security boundaries, including Express publication limits and TLS/TDS changes.

05

Use a single-instance simulation to reason about replication lag and delivery without requiring a production topology.

1. Start with the publishing model

A Publisher exposes data. A publication groups one or more articles, such as tables or other supported objects. The Distributor stores replication metadata and, for transactional replication, queued commands in a distribution database. A Subscriber receives a publication through a subscription. These roles describe the data path; they do not tell you that a Subscriber is a recoverable replacement for the Publisher.

sql · record the local engine and data-movement feature context
SELECT SERVERPROPERTY('ProductVersion') AS product_version,       SERVERPROPERTY('ProductUpdateLevel') AS update_level,       SERVERPROPERTY('Edition') AS edition,       SERVERPROPERTY('EngineEdition') AS engine_edition,       SERVERPROPERTY('IsHadrEnabled') AS hadr_enabled,       SERVERPROPERTY('InstanceDefaultBackupPath') AS default_backup_path,       SERVERPROPERTY('ServerName') AS server_name;GOSELECT name, compatibility_level, recovery_model_desc,       is_published, is_subscribed, is_merge_published, is_distributorFROM sys.databasesWHERE name IN (N'ServiceHubLab', N'master', N'msdb') OR is_published=1 OR is_subscribed=1 OR is_merge_published=1 OR is_distributor=1;GO
sql · inspect Distributor and publication state without enabling replication
EXEC sys.sp_get_distributor;GOEXEC sys.sp_helpreplicationdboption;GOSELECT name, is_published, is_merge_published, is_subscribed, is_distributorFROM sys.databasesWHERE is_published=1 OR is_merge_published=1 OR is_subscribed=1 OR is_distributor=1;GO

On an untouched ServiceHub learning instance, the usual result is no configured Distributor and no published databases. That is useful evidence: it prevents a learner from running topology-changing procedures under a false assumption. SQL Server 2025 Express cannot be a replication Publisher; use free Enterprise Developer or Standard Developer for a publishing lab. Express can participate only in supported subscriber scenarios, and it lacks SQL Server Agent, which affects normal agent scheduling.

2. Three replication families solve different problems

Type Data movement Typical writer model Operational consequence
Snapshot Regenerates and applies a point-in-time snapshot Publisher is usually authoritative Simple mental model; large refreshes can be expensive and stale between snapshots.
Transactional Initial snapshot, then reads marked transactions from the Publisher log and delivers commands Publisher normally owns writes Low-latency distribution is possible, but the Distributor/agents/backlog are operational dependencies.
Merge Initial snapshot, then tracks changes at Publisher and Subscribers and reconciles them Multiple disconnected or intermittent writers Conflict detection/resolution and metadata growth become part of correctness.

Snapshot replication is appropriate when data changes infrequently or full refresh cost is acceptable. Transactional replication is designed for incrementally propagating committed changes. The Log Reader Agent scans the publication database transaction log and writes replicated commands into the distribution database; Distribution Agents deliver them to Subscribers. Merge replication tracks changes at multiple nodes and uses the Merge Agent to exchange them, so it needs conflict rules and a much stronger application-level ownership model.

sql · create a disposable data-movement decision lab
USE ServiceHubLab;GOIF SCHEMA_ID(N'lab17') IS NULL EXEC(N'CREATE SCHEMA lab17 AUTHORIZATION dbo;');GODROP TABLE IF EXISTS lab17.DeliveryQueue;DROP TABLE IF EXISTS lab17.SiteState;DROP TABLE IF EXISTS lab17.MovementRequirement;GOCREATE TABLE lab17.DeliveryQueue(  queue_id bigint IDENTITY PRIMARY KEY,  technology varchar(20) NOT NULL,  source_commit_id bigint NOT NULL,  created_at datetime2(3) NOT NULL DEFAULT SYSUTCDATETIME(),  delivered_at datetime2(3) NULL,  status varchar(16) NOT NULL DEFAULT 'PENDING');CREATE TABLE lab17.SiteState(  site_name varchar(30) NOT NULL PRIMARY KEY,  role_name varchar(30) NOT NULL,  last_commit_id bigint NOT NULL,  writable bit NOT NULL,  last_refresh_at datetime2(3) NOT NULL DEFAULT SYSUTCDATETIME());CREATE TABLE lab17.MovementRequirement(  requirement_name varchar(80) NOT NULL PRIMARY KEY,  whole_database bit NOT NULL,  subset_filtering bit NOT NULL,  multiple_writers bit NOT NULL,  automatic_failover bit NOT NULL,  target_rpo_seconds int NULL,  notes nvarchar(300) NULL);GO
sql · queue source commits and make latency observable
INSERT lab17.DeliveryQueue(technology, source_commit_id)VALUES ('TRANSACTIONAL', 70001),('TRANSACTIONAL',70002),('SNAPSHOT',70003);WAITFOR DELAY '00:00:01';UPDATE lab17.DeliveryQueueSET delivered_at=SYSUTCDATETIME(), status='DELIVERED'WHERE queue_id=1;SELECT queue_id, technology, source_commit_id, status,       DATEDIFF_BIG(millisecond,created_at,COALESCE(delivered_at,SYSUTCDATETIME())) AS age_msFROM lab17.DeliveryQueueORDER BY queue_id;GO

The simulation is not SQL Server replication; it isolates the operational idea. A committed source transaction can exist while downstream delivery is still pending. Therefore a Subscriber read has a freshness contract, not an automatic “same data now” guarantee.

3. Initialization is a deployment event

All three major replication types commonly use a Snapshot Agent for initialization. Snapshot files contain schema/data needed by the publication and must be protected like database data. The Distribution Agent applies snapshots for snapshot and transactional subscriptions; the Merge Agent applies merge initialization and later synchronization. Push versus pull describes where the Distribution/Merge Agent runs: Distributor for push, Subscriber for pull. That affects credentials, scheduling, network direction and where failures are diagnosed.

Wrong approach: “replication is our backup.”

If an application deletes a published row, replication can faithfully distribute the delete. If the publication schema is damaged, credentials expire, or a Subscriber is reinitialized, replication does not provide the independent restore points Chapter 15 established. Keep tested backups and restore drills even when replication is healthy.

SQL Server 2025 adds TDS 8.0/TLS 1.3 options to replication agents. Current Microsoft documentation also flags remote-Distributor upgrade/configuration issues in SQL Server 2025 scenarios, so remote distribution should be validated against the current CU/release notes before production change windows.

4. Production judgment

Use snapshot replication when periodic full distribution is acceptable; transactional replication when one authoritative write stream must be projected with low latency; merge only when offline/multi-writer synchronization and conflicts are explicit business requirements. Record who owns schema changes, agent credentials, snapshot storage, retention, reinitialization, conflict handling and monitoring. Chapter 17 Lesson 2 turns those architecture boxes into monitored publications, subscriptions and agent queues.

Check your understanding

  1. Why is a transactional Subscriber not automatically a disaster-recovery replacement for the Publisher?
  2. What role does the Distributor play in transactional replication?
  3. When does merge replication make sense compared with transactional replication?
  4. Why is initialization a security and capacity event?
  5. Can SQL Server 2025 Express act as a replication Publisher?
Review the answers

1. Replication distributes selected changes but does not provide quorum, automatic failover, full instance state, independent recovery history or protection from replicated logical mistakes.

2. It stores replication metadata and queued replicated commands; the Log Reader writes to it and Distribution Agents deliver from it.

3. When multiple/disconnected nodes need to write and later reconcile changes, with an explicit conflict model.

4. Snapshot files can contain large volumes of business data and consume storage/network while agents require protected credentials and access paths.

5. No. Use Standard Developer or Enterprise Developer for a free non-production Publisher lab; Express is limited to supported subscriber roles.

Authoritative references

Keep knowledge open

Help the academy stay free and grow.

If these tutorials save you time, a small donation supports new lessons, technical review, diagrams, examples, and long-term maintenance.

ETHEthereum / ERC-20 only
0x716c4Ab160C4B66F31a28AE2448BfF68fc3a2ef0

Send only Ethereum or ERC-20 compatible assets to this address.