Implementing Replication Overview
The process of implementing replication is different depending on the type of replication and the options you choose, but, in general, replication is composed of the following stages:
Configuring replication and publishing data
Creating and initializing subscriptions
This topic provides information on each step, with links to more detailed descriptions. In addition to understanding the steps required to configure replication, it is important to understand considerations for:
Implementation. For more information, see Solution Design Considerations (Replication).
Security. For more information, see Security and Protection (Replication).
Performance. For more information, see Performance (Replication).
Backup and restore. For more information, see Backing Up and Restoring Replicated Databases.
After replication is configured, follow the administration best practices described in Best Practices for Replication Administration.
Configuring Replication and Publishing Data
Replication deployment begins when you configure the Publisher and Distributor. The Distributor plays a primary role in transactional replication; however it plays a more limited role in merge and snapshot replication, being used only for agent history and error reporting and monitoring purposes. Merge replication and snapshot replication typically use a Distributor that runs on the same computer as the Publisher, whereas transactional replication might use a remote Distributor, particularly if the Publisher is a high throughput OLTP system. For more information about configuring the Distributor and Publisher, see Configuring Distribution.
After the Publisher and Distributor are configured, you can create publications based on data, subsets of data, and database objects. When you create a publication, you determine:
The data and database objects that you want to replicate.
Which type of replication you will use and which replication options, including filtering.
Where the snapshot files will be stored and when the initial synchronization will occur, unless you are delivering the initial dataset manually.
Other properties to set for the publication.
For more information about creating publications, see Publishing Data and Database Objects.
Depending on the type of replication and the options you chose when configuring the publication, the Subscriber might be able to modify data after the initial dataset has been delivered and propagate these data changes to the Publisher, which can then propagate the changes to other Subscribers. The following replication types allow Subscribers to modify replicated data and have those modifications propagated back to the Publisher:
Merge replication. For more information, see Merge Replication Overview.
Transactional replication with updatable subscriptions. For more information, see Updatable Subscriptions for Transactional Replication.
Peer-to-peer transactional replication. For more information, see Peer-to-Peer Transactional Replication.
Bidirectional transactional replication. For more information, see Bidirectional Transactional Replication.
Creating and Initializing Subscriptions
After you create a publication, you can create subscriptions and configure additional options. For more information, see Subscribing to Publications.
Whether you choose snapshot replication, transactional replication, or merge replication, replication by default creates an initial snapshot of the publication schema and data, and then saves it to the snapshot folder location you specified. After a subscription is created, the initial snapshot is applied based on the schedule you indicated when creating the publication. You can bypass one or more of the snapshot steps if the Subscriber already has the initial dataset or you want to apply it manually. For more information, see Initializing a Subscription.
Synchronization is the process of data being propagated between the Publisher and Subscribers after the initial dataset has been applied at the Subscriber. For snapshot replication, synchronization means reapplying the snapshot at the Subscriber so that schema and data at the subscription database is consistent with the publication database. For transactional replication, synchronizing data means that data modifications, such as inserts, updates, and deletes, are distributed between the Publisher and Subscribers (and from Subscribers back to the Publisher in the case of updating subscriptions). For merge replication, synchronization means that data modifications made at multiple sites are merged, any conflicts are detected and resolved, and data eventually converges to the same data values at all sites. For more information about synchronization, see Synchronizing Data.