Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Initial table synchronisation #29

Open
jeancz opened this issue Oct 12, 2019 · 4 comments
Open

Initial table synchronisation #29

jeancz opened this issue Oct 12, 2019 · 4 comments

Comments

@jeancz
Copy link

jeancz commented Oct 12, 2019

It would be nice, perform initial table synchronization (maybe optional in config) if the minimal version of the source table doesn't meet the version of the destination.

@fkierzek
Copy link

I get

ERROR|Cannot replicate table [dbo].[MonitoringParameter] to destination TestFK because minimum source version 238 is greater than destination version 2

Looking at the code it looks like the SyncInfo is not created because the call to check existance/create is after the above error message is shown which stops the execution.

I would be very helpful if the project Wiki said a word on how to go about it.

@mganss
Copy link
Owner

mganss commented Jun 28, 2022

If the SyncInfo table does not exist (i.e. no successful replication has been completed yet), the code determines the destination's current version using the SQL Server function CHANGE_TRACKING_CURRENT_VERSION() which yields the database's current version from SQL Server's change tracking point of view. When we execute the replication statements, the version in the destination database increases, but does not stay in sync with the version in the source (because we do not execute the exact same steps that were carried out in the source DB). That's why we need the SyncInfo table to record the source version that we replicated in the destination.

That said, in your specific case the source DB has already evolved beyond the point where the changes before version 238 have already disappeared from the source's change tracking (see https://docs.microsoft.com/en-us/sql/relational-databases/track-changes/enable-and-disable-change-tracking-sql-server). You need to make sure that the replication process is executed periodically before the change retention time window is expired. If you have missed replication window, you will need to restore a backup of the current source in the destination and then make sure that the replication process is executed before the source's next retention window expires.

@fkierzek
Copy link

fkierzek commented Jul 11, 2022 via email

@mganss
Copy link
Owner

mganss commented Jul 11, 2022

I think what I stumbled upon was a bug. Basically if SyncInfo table wasn't present in the destination database - it wouldn't be created and nothing would happen.

I don't think it's a bug but expected behavior. The SyncInfo table is created once the initial replication has been successfully completed. In your specific case I believe this has not happened yet because of the reason I outlined above in the second paragraph. Try restoring a fresh backup in the destination, then run the synchronization process again.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants