Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Applies to: 
SQL Server
Azure SQL Managed Instance
Subscriptions can be deactivated or can expire if they are not synchronized within a specified retention period. The action that occurs depends on the type of replication and the retention period that is exceeded.
To set retention periods, see Set the Expiration Period for Subscriptions, Set the Distribution Retention Period for Transactional Publications (SQL Server Management Studio), and Configure Publishing and Distribution.
Transactional replication
Transactional replication uses the maximum distribution retention period (the @max_distretention parameter of sp_adddistributiondb (Transact-SQL)) and the publication retention period (the @retention parameter of sp_addpublication (Transact-SQL)):
If a subscription isn't synchronized within the maximum distribution retention period (default of 72 hours) and there are changes in the distribution database that aren't delivered to the Subscriber, the subscription is marked deactivated by the Expired Subscription clean up job that runs on the Distributor. You must reinitialize the subscription.
If a subscription isn't synchronized within the publication retention period (default of 336 hours), the subscription expires and is dropped by the Expired subscription clean up job that runs on the Publisher. (Before the fix in KB4014798, the job was named Distribution cleanup.) You must recreate and synchronize the subscription.
If a push subscription expires, it's completely removed, but pull subscriptions aren't. You must clean up pull subscriptions at the Subscriber. For more information, see Delete a Pull Subscription.
Merge Replication
Merge replication uses the publication retention period (the @retention and @retention_period_unit parameters of sp_addmergepublication (Transact-SQL)). When a subscription expires, you must reinitialize it because the process removes metadata for the subscription. The Expired subscription clean up job that runs on the Publisher drops subscriptions that aren't reinitialized. By default, this job runs daily. It removes all push subscriptions that don't synchronize for double the length of the publication retention period. For example:
If a publication has a retention period of 14 days, a subscription can expire if it doesn't synchronize within 14 days.
If the Publisher is running SQL Server 2005 (9.x) or a later version and the agent for the subscription is from SQL Server 2005 (9.x) or a later version, a subscription only expires if there are changes to the data in that subscription's partition. For example, suppose a Subscriber receives customer data only for customers in Germany. If the retention period is set to 14 days, the subscription expires on day 14 only if there are changes to the German customer data in the last 14 days.
From 14 days to 27 days after the last synchronization, you can reinitialize the subscription.
At 28 days after the last synchronization, the Expired subscription clean up job drops the subscription. If a push subscription expires, it's completely removed, but pull subscriptions aren't. You must clean up pull subscriptions at the Subscriber. For more information, see Delete a Pull Subscription.
Considerations for setting the publication retention period for merge publications
Keep the following considerations in mind when setting the retention period for merge publications:
The retention period for merge publications includes a 24-hour grace period to accommodate Subscribers in different time zones. For example, if you set a retention period of one day, the actual retention period is 48 hours.
Cleanup of merge replication metadata depends on the publication retention period:
Replication can't clean up metadata in the publication and subscription databases until the retention period is reached. Use caution when specifying a high value for the retention period, because it can negatively affect replication performance. Use a lower setting if you can reliably predict that all Subscribers will synchronize regularly within that time period.
You can specify that subscriptions never expire (a value of 0 for
@retention), but don't use this value because metadata can't be cleaned up.
Set the retention period for any republisher to a value equal to or less than the retention period set at the original Publisher. Also, use the same publication retention values for all Publishers and their alternate synchronization partners. Using different values might lead to non-convergence. If you need to change the publication retention value, reinitialize the Subscriber to avoid the non-convergence of data.
If you increase the publication retention period after a cleanup and a subscription tries to merge with the Publisher (which already deleted the metadata), the subscription won't expire because of the increased retention value. However, the Publisher doesn't have enough metadata to download changes to the Subscriber, which leads to non-convergence.