High Availability-2

Replication
Replication Allows you to copy and distribute data and objects from one database to another and then
continually stream data modifications as they are made
Replication
Types of Replication
Replication types
Types of Replication
Topology
Transactional replication Components
 Transactional Replication Log Reader Agent

Run at the distributor

-- Typically runs continuously
-- Can run according to a schedule

First reads the publication transaction log, Using internal

sp_replcmds procedure, for any

-- Insert, Update, Delete operations

-- Schema modifications
Coples transactiosn in batches to the distribution database at
the distributor
-- Only committed transactions are sent
-- Calls sp_repldone to mark where replication last completed
and markd log entries to allow log truncation/clearning.
Transactional Replication distribution agent

Runs at:

Distributor for “push” subscriptions

Subscriber for “pull” subscriptions

Copies transactions:
From distribution database
To subscription database
Checks if Publisher and Subscriber data match if the subscription is marked for validation
Deployment: Wizard or Scripts?

Method 1: wizard only

Great for getting started with replication or for deploying simpler topologies
Masks actions you may not want to occur or should occur but do not

Method 2: wizard to script -> adjust script -> deploy

Allows for establishing a baseline and then adjusting accordingly
Great for disaster-recovery exercises, removing click-by-click at 2 a.m.

Method 3: script only

Forces a deep understanding of the ‘moving parts’
Precise decision making and micro-managing, but very easy to miss steps if configuring from scratch
Numerous procedures, parameters and arguments, including bitmask values like @schema_option
Configuring the Distributor

sp_adddistributor
Configures the server as a distributor

sp_adddistributiondb
Creates a distribution database and associated schema

sp_adddistpublisher
Maps a publisher to a specified distribution database
Creating the Publication

sp_replicationdboption
Enable publication for a database

sp_addlogreader_agent
Adds a Log Reader Agent for a given database

sp_addpublication
Creates a snapshot or transactional publication

sp_addpublication_snapshot
Creates a Snapshot Agent

sp_addarticle
Adds an article to a publication
Creating a Push Subscription

sp_addsubscription (at Publisher)

Adds a subscription

sp_addpushsubscription_agent(at Publisher)

Creates new scheduled Distribution Agent job

Creating a Pull Subscription

sp_addsubscription(at Publisher)
Adds a subscription

sp_addpullsubscription(at Subscriber)
Adds a pull subscription

sp_addpullsubscription_agent(at Subscriber)
Creates new scheduled Distribution Agent job
Factors that Affect Replication
Performance

Server, storage, network hardware, network, and distance

Distributor location and isolation

Collocated with Publisher, standalone, Subscriber?
1:M Distributor to Publisher? 1:1 Distributor to Publisher?

Concurrent non-replicated activity (Log Reader penalty)

Filter complexity
Very large duration and volume transactions
Maintenance activities (like re-indexing)
Factors that Affect Replication
Performance

Table as article in >1 publication

Agent profile options (some help, some can hurt)
Schedules impact performance (continuous is typically better)
Key metrics: latency, throughput, concurrency, synchronization
timespan, resource overhead
Distribution Database

Think of it no differently from other application databases or tempdb when it comes

to growth, monitoring, performance overhead
Transactional replication: all transactions are written to and read from the distribution
database
Merge replication: usage is significantly less, storing history and miscellaneous
information about merge replication

Database volume, availability and collocation matters and contributes to the ‘local
vs. remote’ decision
Sizing can be significantly impacted by retention settings and also the
immediate_syncoption when ‘true’
sp_addpublication’simmediate_sync

When immediate_sync= true

New Subscribers can use the latest snapshot files within the retention period
Commands and transactions will also be available within the retention period, increasing the distribution database
size requirements significantly for databases with high throughput
Snapshot files for the publication are created for all articles each time the Snapshot Agent runs, even if only one
article was added

When immediate_sync= false:

Snapshot files are only created if there are new subscriptions
If you add a new article and you execute the Snapshot Agent, only a snapshot of the new article is produced

The Wizard makes it easy to enable “Create a snapshot immediately and keep the snapshot
available to initialize subscriptions” vs. scheduling at a later time
Log Reader Agent and Transaction Log
Activity

Log Reader scans transaction log looking for transactions to be replicated

The scan includes all transaction log records, including non-replicated transactions

Log Reader latency will be impacted by:

Excessive Virtual Log File counts due to many small auto-growths increase the overhead, thus increasing transactional
latency
Concurrent I/O path overhead
Hidden Costs of a Single Command
 Transactional Replication and Database Mirroring

A role can benefit from its database being mirrored if the replication Agents can connect to it
after a mirroring failover
Publisher (full support)Agent configuration specifies the failover partner so Agents automatically reconnect to the publication
database after a mirroring failover

Subscriber (limited support)No support for automatic reconnection of the Distribution Agent
Subscriptions must be recreated after mirroring failover of subscription database Limited recreation possible using ‘initialize from
LSN’ method

Distributor (no support)Server name of the Distributor cannot change, and a mirroring failover keeps the database name but
changes the server name

Log Reader will wait for log records to harden on the publication database mirror before replicating
to the distribution database
Transactional Replication and Failover Clustering
Supported for all replication roles since the virtual network name and instance name failover with the
database

This is the only mechanism that provides high availability for the distribution database

Virtualization high availability can also be used since the failover occurs at the Virtual Machine level across hypervisor nodes, and
the server and instance names remain the same
Transactional Replication and Availability Groups

Publisher instances need to share a common Distributor

Use a remote Distributor that is NOT on one of the intended replicas

Secondary replica can’t be a Publisher

New sp_redirect_publisherproc used to map publication to availability group listener

New distribution database sp_validate_replica_hosts_as_publishersto verify all replica hosts can serve as
Publishers for the publication

Replication Monitor uses the original Publisher name, not the availability group listener name
Setting Warnings and Thresholds

Replication Monitor enables you to monitor the health of a specific replication topology

In Replication Monitor, when the threshold is met or exceeded, a warning is displayed in the status column for the
subscription and the publication with which it synchronizes

You can enable warnings for the following performance conditions (as applicable to transactional replication)
Imminent subscription expiration
Exceeding the specified latency
Alerts

Reaching a threshold can also trigger an alert

Typically useful alerts:

Replication: Agent failure

Replication: Agent retry
Replication: expired subscription dropped
Replication: Subscriber has failed data validation
Replication: subscription reinitialized after validation failure
SQL Server performance condition alert on distribution database (file sizes) or a custom monitoring script
and job

Don’t forget to enable the alerts (some are off by default)

Alerts may not fire when you expect: E.g. in continuous mode, the ‘Agent failure’ alert will not raise
alerts until Agent retries are done or subscription expiration Default is 2,147,483,647 retries (full number is
obscured due to size on the GUI)

If jobs are stopped, no alerting associated with the job One solution is to schedule periodic checks on the
agent job status , alerting and/or starting them if stopped
Always on Availability

-Enable Windows Clustering on Each Node Enable AG on Each Instance

-Add Participating Nodes to Cluster Create Endpoint on Each Replica
-Validate Cluster Grant Connect on Each Endpoint
Create Cluster Create Availability Group on Primary
Multi-subnet Considerations Join Each Secondary to Group
Linux? AG is Database Level Protection
AG Without a Domain?
Join Database to AG
Configure Synchronous / Asynchronous Replication Select IP for Each Subnet
Configure Manual / Automatic Failover Configure Listener
Configure Read-only / Non Read-only Secondary Test Listener
Test Failovers

Read-only Routing
Offloading Backups
Failover Behavior
Setup Monitoring
Always on
Always On Quorum Modes
majority establish quorum and can select a primary node

should leave enough remaining nodes to still establish quorum

file share(s) that form a majority establish quorum and can select a primary node

server that all nodes can see. File share should be separate from other nodes

shared disk resource that form a majority establish quorum and can select a primary node

protected resource will select any node it can communicate with as the primary node
Always On AG Without a Domain

A DNS server and common DNS suffix across all nodes

Same local administrator with same password on all nodes

Registry setting: LocalAccountTokenFilterPolicy–Value 1

(allows a local admin to remotely administer another server)
Windows cluster
Active / Passive vs Active / Active
More ….
Failover Clustering isn’t only a SQL Server technology
Clustering terms don’t apply equally to each implementation
Active -Active vs Active Passive
Critical to a healthy cluster
Network quality of service for cluster communication is critical
-heartbeat
-intra cluster communication
-failover
Failover is automatic but momentary interruption can occur
Applications dependent on your SQL Server should maintain
retry logic and good error handling
End of H-A