Real World Enterprise SQL Server Replication Implementations Presented by Kun Lee sa@ilovesql.com
About Me DBA Manager @ CoStar Group, Inc. MSSQLTip.com Author (http://www.mssqltips.com/sqlserverauthor/15/kunlee/) Father of two children Hobbyist Photographer
Abstract Come learn how to design, setup and manage SQL Server Replication for a large distributed enterprise with multiple data centers. Learn about some of the technical options such as Re-publishers, Hub and Spoke architecture, Peer-to-Peer replication, pre and post snapshots, automating deployments, monitoring, optimizations and more. With each of these options I will outline many of the configuration options, benefits and issues for each of the technologies based on my experience from the field. My goal is to share my findings to help you make better decisions when using SQL Server Replication so you don t have to go through the same issues that I have experienced.
There is no one tool/solution fits every problem
Scope of this Presentation What is NOT I am not trying to teach you how to write TSQL I am not trying to teach you how to setup all the replications and others I cannot demo everything since the topic is too broad but I will try some though. What is I am trying to show you how and why I make those decisions I am trying to show you what is the benefits and side effects
Not my style Presentation Not much of Demo I will try as much as possible to entertain all of you If no one sleeps at the end, that would be great!
Quick Poll Have you used SQL Replications? What types of replication have you used? And Why?
Technologies that I will cover Replication Link Server Transactional Synonyms Peer to Peer Merge Snapshot Mirroring/Always On CDC/CT Trigger Service Broker Backup & Restore Clustering View & Indexed View F5 (BigIP) Stretch VLAN / Overlay Transport Virtualization (OTV) SAN DMZ/LAN Database Snapshot Disaster Recovery Archiving
Problems to solve Security Performance Scale out vs Scale up Disaster Recovery Reports Cost Reduce SQL Server Edition Number of Servers
Sample Toplogies <Old & Simple Version>
One SQL server I wish Life is easy!
Having Locking issue when someone runs Reports? Database Snapshots if you have Enterprise Edition Backup and restore as different database name Replication to the same server
Having Locking or Resource issue when someone runs Reports? But have Performance SLA on Source DB? Backup & Restore Target Server needs to have the same edition or higher Edition Downtime during Restoring Log Shipping is one way to work around Mirroring but requires Enterprise Edition to see data on other side and can t have customized index for the query on target AlwaysOn also requires Enterprise Edition and can t have customized index for the query for the query on target
Having Locking issue or Resource when someone runs Reports? But have Performance SLA on Source DB? Cont. Transactional SQL Replication Standard Edition Supports Customized index for Target Server Limitation on publisher Articles
Transactional Replication You want incremental changes to be propagated to Subscribers as they occur. The application requires low latency between the time changes are made at the Publisher and the changes arrive at the Subscriber. The application requires access to intermediate data states. For example, if a row changes five times, transactional replication allows an application to respond to each change (such as firing a trigger), not simply the net data change to the row. The Publisher has a very high volume of insert, update, and delete activity. The Publisher or Subscriber is a non-sql Server database, such as Oracle.
Replication Things to consider PK on Publisher Pull vs. Push Replication Snapshot requires some downtime (Lock) Separate Distributor Educate Developers what to do and what not to do No truncate No big huge update Can t drop table Can t just update subscriber (transactional replication) Need to consider what index is required on subscriber How to maintain DEV/TST(QA)/PRD License Shared Publisher
Multiple R/O servers on two Different Data Center Washington DC Replication Same over and over Wasting network bandwidth Slow down replication Los Angeles
Multiple R/O servers on two Different Data Center Re-publisher
Republish Data This is MSFT supported Technology See Republish Data
DEMO
Republish Data Requirements & Tips You need to make sure subscriber DB (republisher) always has Primary Key so you can republish Depending situation, you may want to use one of below techniques to snapshot Compressed Snapshot (not recommendable as it is) Snapshot to Remote location file server and apply snapshot (works pretty well) Snapshot to local as either Raw or compressed (depending on size) and copy manually and Load from remote location Last resolution because it isn t easy to automated
Republishing and Processing for Summary/Aggregate for Customers LAN/Trust DMZ Processing fire wall Publisher Re-Publisher & Processing Subscriber R/O Server
DEMO with CDC & Post Snapshots
What about DML from Customers?
Multiple R/O servers on two Different Data Center Re-publisher Merge among all servers?
Merge Replication Pro Cons Conflict resolution Support Mobile Frequent update on Subscriber Data Filtering No need special process to Syncing Data 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 changes only once at the Publisher to reflect the net data change (that is, the fifth value). Performance overhead (Adding GUID, etc) Latency Each Subscriber requires a different partition of data. High Maintenance and configuration Requires Snapshot which is very resource intensive and lock tables some period time
Peer to Peer Replication
Peer to Peer Replication Pro Cons Replication is used to improve scalability and availability. Minimal latency is required. Reinitialized with Backup and Restore Data is not partitioned among Subscribers. Conflicts typically do not occur, but they must be detected if they do. Reinitialized with Backup and Restore Adding a new article is cumbersome Better to come up with own way not to conflict data such as introducing Silo ID
WHITE BOARD TIME
Final Thought & Questions? Devils in Detail
Thank you! For attending this session sa@ilovesql.com