How to remove Synchrony data
Platform Notice: Data Center - This article applies to Atlassian products on the Data Center platform.
Note that this knowledge base article was created for the Data Center version of the product. Data Center knowledge base articles for non-Data Center-specific features may also work for Server versions of the product, however they have not been tested. Support for Server* products ended on February 15th 2024. If you are running a Server product, you can visit the Atlassian Server end of support announcement to review your migration options.
*Except Fisheye and Crucible
This guide applies to Confluence 7.0 and later. For Confluence 6.x versions see How to reduce the size of Synchrony tables.
Purpose
When collaborative editing is enabled, Synchrony is used to synchronise changes made in the editor. This is how multiple people can see each others changes in real time.
Each page and blog post has its own Synchrony change log, which contains a graph of all edits to that page or blog post. In busy Confluence sites the database tables that store the Synchrony change logs can grow very quickly, and because the change logs store all changes as they happen, they may retain personally identifiable information, even after the page they relate to is deleted.
Solution
From Confluence 7.0 we provide two scheduled jobs for removing Synchrony data:
- Synchrony data eviction (soft)
- Synchrony data eviction (hard).
The soft eviction job runs regularly in the background. The hard eviction job is available for when you need to remove Synchrony data more aggressively, and is disabled by default. Both jobs remove the entire Synchrony change log for the relevant page or blog post. It's not possible to remove only part of the Synchrony data associated with a page or blog.
Before exploring how these jobs work in detail, it's useful to understand what we mean when we talk about 'saving changes':
- Synchrony records every keystroke and saves it in the Synchrony change log for the page.
- Confluence auto-saves the contents of the editor as a draft when someone exits the editor using the Close button, and every 30 seconds while they are in the editor (this auto-save interval is configurable).
- Confluence attempts to auto-save the contents of the editor as a draft when someone exits the editor by closing the tab or navigating away. If the browser crashes, or there is high latency sometimes this save will fail. Data is not lost, because the next time someone edits the page, the changes will be picked up from the Synchrony change log.
Soft removal job
This job runs every 10 minutes, and pro-actively cleans up Synchrony change logs that are no longer needed. This helps keep the Synchrony database tables a manageable size. When it runs, the following messages are printed on the atlassian-confluence.log:
2022-01-16 18:12:25,962 INFO [Caesium-1-2] [synchrony.service.http.SynchronyRequestExecutor] execute Initiating Locking API request: SynchronyUnlockRequest
2022-01-16 18:12:25,895 INFO [Caesium-1-2] [synchrony.service.http.SynchronyRequestExecutor] execute Initiating Locking API request: SynchronyLockRequestA Synchrony change log is eligible to be cleaned up by the soft eviction job if:
- The Synchrony change log for a page / blog has not been modified in the past three days.
- The page or blog post has no active editing sessions (no-one has this page open in the editor).
There should be virtually no impact to end-users, because Confluence auto-saves changes regularly, and the job will ignore any pages and blog posts with an active editing session.
However, if the last person in a collaborative editing session left the editor, and changes weren't auto-saved (for example if their browser crashes), any changes between the last auto-save and leaving the editor will be lost when data is evicted.
Hard eviction job
This job is disabled by default. It can be run manually, or you can schedule it to run periodically if required.
This job will evict the synchrony data for any page or blog post that is older than 15 days. For example, if a page was created more than 15 days ago, and subsequently edited every day after that, all synchrony data associated with the page would be evicted by the hard eviction job. This particular page would not be eligible to be cleaned up by the soft eviction job, because it was edited within the last three days of each time the job ran.
The hard eviction job guarantees there is no synchrony data older than 15 days in your database, which is particularly useful if you need to remove personally identifiable information from Synchrony, or you want to reduce the amount of data in the Synchrony tables more aggressively than the soft removal job does.
There may be some impact to end-users:
- People currently in the editor when the job runs will see an error prompting them to copy their changes and refresh. The editor will be read-only until the page is refreshed. This is similar to the behaviour when Confluence can't connect to Synchrony.
- People who left the editor and their changes weren't auto-saved (for example if their browser crashes), may lose any changes between the last auto-save, and the point that the job is run.
Depending on the size of your Synchrony tables, this job can take a long time, and have a noticeable performance impact, if it has not been run for some time. If you plan to schedule this job to run regularly, consider manually truncating the Synchrony tables first, to avoid any performance issues the first time it runs. This isn't necessary the first time you upgrade to a Confluence 7.x version, as an upgrade task will truncate these tables for you.
Changing the job behaviour
In the Scheduled Jobs screen you can run a job manually, change what time, or how frequently it should run. See Scheduled Jobs for more information.
You can also change the default behaviour of these scheduled jobs using system properties. In most cases the default values will be adequate. For example, you could:
| Property | Description | Default value |
|---|---|---|
synchrony.eviction.removal.content.batch.count.per.tx | The number of content records, which are removed in single transaction and within single locking/unlocking. Making this batch size bigger will make the throughput better, but on the other hand prolonged Synchrony lock holding can be more intrusive from end user perspective. Default value is a good enough tradeoff between the two. | 10 |
synchrony.eviction.content.lock.timeout.default.ms | Content lock timeout for eviction. Time period, during which Synchrony will refuse to serve certain content, which eviction jobs are about to clean up. | 300000 |
| Synchrony Data Removal (Soft) | ||
synchrony.eviction.soft.job.threshold.hours | Number of hours content shouldn't be modified to be eligible for deletion. | 72 |
synchrony.eviction.content.soft.search.count.per.tx | Search batch size for soft removal eviction job Tweaking this value has the following trade-off: | 200 |
synchrony.eviction.soft.job.content.batch.count | Number of content entities to clean during one job invocation | 1000 |
| Synchrony Data Removal (Hard) | ||
synchrony.eviction.content.hard.search.count.per.tx | Search batch size for hard removal eviction job. | 100000 |
synchrony.eviction.hard.job.threshold.hours | Minimum age of data in Synchrony change logs, which should be deleted | 240 |
See Configuring System Properties for details on how to apply to these properties.
Removing Synchrony data manually
If you're using Confluence 6.x, or you need to delete all Synchrony data at once (not gradually using the scheduled jobs) you can choose to truncate the Synchrony database tables.
See How to reduce the size of Synchrony tables for more information. As always, we recommend taking a full backup of your database before making changes directly on your database.