Read below to learn how sync works.
Below is a basic overview of how sync functions.
When sync begins, it looks through tracking tables in the local database and compares the date modified to the receiving database's tracking tables. Then, the Ektron Window Service begins to batch the database in parts to prepare it to move over.
When files are moved over, such as Assets, PrivateAssets, UploadedFiles, UploadedImages, and AssetLibrary, the sync process uses encrypted knowledge files to compare the sending and receiving servers of files that have been updated or moved over previously. Then, it'll move the files over.
At the end of the process, sync checks sync certificates to make sure they are valid.
A more detailed explanation
When sync begins, it uses the Ektron Window Service over the port 8732 to look through the tracking tables within the local database and compares to the receiving database's tracking tables. The purpose of tracking tables is as you might expect, to track actions taken on content for syncing purposes. This information allows eSync to make decisions about whether to move, delete, or update content to on the receiving end of a sync.
You can see when a row was last changed by the last_changed_datetime field. This is helpful when you want to see when a row was changed in comparison to the corresponding row of the database you are syncing to. This can show which side the content was edited on most recently which can explain why a particular row isn't syncing as expected.
Another helpful field in the tracking tables is sync_row_is_tombstone. This shows if content had been deleted at one point. If the sync_row_is_tombstone is set to 1 that indicates the content was deleted and cannot be recreated which explains why sync will not work as a restore method.
Then, the Ektron Window Service and database stored procedures begin to batch the database in parts to prepare it to move over. The batch size depends on the listing in the Sync Settings within the workarea/database. In general, do not change the batch size unless specifically recommended by support.
The tracking knowledge first begins when sync is used for the first time between two databases; specifically when the sync relationship is first created. The knowledge grows over time and must match properly between the two databases. If one restores the database to a prior version, the other database must be restored as well or the knowledge will no longer match.
The tracking knowledge is fragile and has a history. Because of this it is best to start sync knowledge with a strong foundation by syncing to a min database or using backup and restore synchronization steps(see documentation). Creating a new relationship between two previously populated databases often causes knowledge issues in the future.
When files are moved over, such as Assets, PrivateAssets, UploadedFiles, UploadedImages, and AssetLibrary, the Ektron Window Service and Microsoft Sync File Watcher look to the encrypted knowledge files to compare the sending and receiving servers of files that have been updated or moved over previously. Then, those processes move the files over using the 8732 port and Ektron Window Service to communicate as the files are being transferred. Those files are placed as temp files in the temp file directory on the receiving server, then shuffled into where they should be placed as the process continues.
At the end of the process, sync checks the sync certificates to make sure that they are valid.