Administration
When running Gluesync you don’t have to worry about much - the log will slowly record any activity, and Gluesync itself will monitor the source data set to mirror any changes to the specified destination.
In the long run you may want to update some configuration settings to better reflect changed requirements or data source refactoring.
Configuration data is loaded at boot, so after updating the config file you should restart Gluesync for the new settings to take effect.
Performing a full table synchronization again
When the data model is updated, you can decide whether to leave already-mirrored data as-is or perform a new synchronization of all source data. This very much depends on the type of changes you made to the configuration and data modelling settings.
If you need to re-synchronize a full table, your easiest option will be to simply remove the relevant row inside Gluesync’s own state tracking table, which is automatically managed inside the source database by the Gluesync user specified in the settings and is called gs_state_preservation.
The table has three columns:
-
The name of the table the state is being tracked for
-
The last transactionID that has been successfully mirrored across
-
The timestamp of the last successful mirroring operation
To force a re-synchronization simply locate the row in this table that refers to the table (or rows, for more than one table) that was updated in the configuration, and remove them before starting Gluesync back again.
At boot Gluesync will check the table, and for any table that is described in the configuration file but is not found in the gs_state_preservation table, will perform a full synchronization. Data already existing in the destination database will be updated with any new fields.