Replication Agents used with Microsoft SQL Server replication carry out the tasks associated with copying and distributing data. The Active Roles replication model employs the Snapshot Agent and Merge Agents.
The Snapshot Agent prepares schema and initial data files of published tables and stored procedures, stores the snapshot files, and records information about synchronization in the distribution database. In the Active Roles replication model, the Snapshot Agent runs at the Publisher.
The Merge Agent applies the initial snapshot to the Subscriber, and moves and reconciles incremental data changes that occur. Each Subscriber has its own Merge Agent that connects to both the Publisher and the Subscriber and updates both.
In the Active Roles replication model, the Merge Agents run continuously at the Publisher. Each Merge Agent uploads data changes from its Subscriber to the Publisher, and downloads data changes from the Publisher to the Subscriber.
Replication model overview
Understanding the Replication model
NOTE: Operations related to replication are not supported by the Azure SQL databases.
Active Roles replication propagates the changes to configuration data to all replication partners whenever the data is modified on any one of replication partners. To achieve this goal, Active Roles relies on the merge replication provided by Microsoft SQL Server. For details on merge replication, refer to the content indexed under the Merge Replication topic in SQL Server Books Online.
In the Active Roles environment, the SQL Server replication function is used to propagate changes to configuration data to all the replication partners, as soon as data is modified on one of the replication partners. The replication process is initiated immediately after changes are committed to a replication partner. Active Roles does not offer the facility to change this behavior.
As there is usually a moderate volume of changes, and since replication only propagates modified data (merge replication model), the amount of replication traffic is manageable. Therefore, you do not need to schedule or manually force replication in Active Roles.
A merge replication model normally requires a means of resolving conflicts that could result from changing the same data on different replication partners. In the Active Roles replication model, the outcome of the conflict is decided on a “later wins” basis, that is, the last to modify the data wins the conflict.
In the Active Roles replication model, each Administration Service database server can have one of the following roles:
This section briefly discusses the following elements of the Active Roles replication model:
- Replication group management
- Data synchronization and conflict resolution
Replication group management
The tasks performed when managing a replication group include the Publisher-related tasks, such as Promote or Demote, and the Subscriber-related tasks, such as Add or Delete.
This task assigns the Publisher role to the Administration Service database server, thereby creating a replication group. When performing the Promote task, SQL Server creates the AelitaReplica publication, and starts the Snapshot Agent. The Agent creates an initial snapshot of schema and data, and saves it to the snapshot folder.
Active Roles automatically specifies and passes to SQL Server all replication settings, such as filters, type of replication, and retention period for subscriptions. For details, see Viewing replication settings later in this document.
This task adds the Administration Service database server to the replication group, thus assigning the Subscriber role to the database server. When performing the Add task, SQL Server starts the Merge Agent. The Agent copies data from the Publisher’s snapshot folder to the Subscriber SQL Server. This process is referred to as applying the initial snapshot (see "Create and Apply the Snapshot" in SQL Server Books Online at http://msdn.microsoft.com/en-us/library/ms151785.aspx).
This task removes the Subscriber from the replication group, causing the database server to revert to the standalone state. When performing the Delete task, SQL Server deletes the subscription at the Publisher. The database of the former Subscriber retains the replicated data.
This task removes the Publisher from the replication group, causing the database server to revert to the standalone state. The Publisher can only be demoted after all of its Subscribers are deleted. When performing the Demote task, SQL Server deletes the AelitaReplica publication, and erases data in the snapshot folder.
Data synchronization and conflict resolution
After applying the initial snapshot to Subscribers, SQL Server tracks changes to published data at the Publisher and at the Subscribers:
- When data is modified at a Subscriber, the data changes are sent to the Publisher. Then, the Publisher propagates the data changes to the other Subscribers.
- When data is modified at the Publisher, the data changes are propagated to the Subscribers.
These operations are performed by the Merge Agents running on the Publisher SQL Server.
The Merge Agents are configured so that once data changes are made at a given replication partner, it normally takes two minutes or less for SQL Server to start synchronizing the data changes with other replication partners. The time required for the synchronization process to be completed depends on SQL Server load and on the bandwidth of network connections. As there is normally a moderate volume of data changes, the replication traffic is manageable.
The synchronization process tracks data changes on both the Subscribers and the Publisher. At the Publisher, the changes are merged to form a single version of the data. During the merge, some conflicts may be found where multiple Subscribers modified the same data.
.Any conflict between the arrived values is automatically resolved based on the Microsoft SQL Server DATETIME (Later Wins) Conflict Resolver: The winner of the conflict is chosen according to a “later wins” solution, with the last to modify the data winning the conflict. For information about conflict resolvers, see Microsoft COM-Based Resolvers in SQL Server Books Online at http://msdn.microsoft.com/en-us/library/ms152573.aspx.