How to avoid resetting jdbc state driver when migrating driver ?
I'm finalizing IDM engine migration to IDM 4.8.1 and the last driver is the JDBC driver.
When I will move the driver to the new server, the state file will be created and the DB will be read and synchronized again.
But I don't want that, as some manual changes in EDIR might be overwitted by the DB.
It there a way to copy the current JDBC state file an make sure that the driver will not resync ?
Thanks a lot.
Looks like the DOC gives the answer:
Changes That Can Force Triggerless Publisher Resynchronization#
If you delete state files, the triggerless publisher will build new state files by resynchronizing. If you move the JDBC driver without moving the state files, the triggerless publisher builds new state files by resynchronizing. Changing to and from the Remote Loader is a move. Therefore, if you move the JDBC driver using triggerless publication and want to prevent a full resynchronization, also move the jdbc_<GUID> file in the state directory.
Does anyone already tried this ?
Are we sure the GUID is the same when I migrate the driver from server to server ?
I did a try but apparently this does not work:
I did copy the stateless files from the old server , when I started the driver on the new server, it starts and create a new file .zoomdb and starts resync the driver .
Any idea to avoid resync ?
I am guessing the GUID it uses for the filename, differs server to server... (Or is it ObjectID named? In which case the objectID in each DIB can be different I think, in which case, it might need a rename on the new server once you get the servers object ID in the local DIB).
Actually, the GUI is the same on both servers, but the zoom DB does not exist and must be created.
I think the zoom DB creation triggers the resync.
So then the interesting question is, what is the relationship between the ZoomDB file vs the State file.
The state file is of ill defined format, usually of ObjectID name. This could be a file, like in the AD driver where it is XML with the DirSync cookie in it (same content as in DirXML-DriverStorage).
The JDBC drivers started with a JDBM hashmap, then that became MapDB hashmap. Theni t became ZoomDB.
I do not fully understand the relationship in the jDBC driver now between the two, which I expect is part of the issue.
The very dirty idea and please correct me on this one but got to put it out there: What if you start and stop and delete migrate event in the cache. (thinking outside the box here) 😅🤣
Disclaimer: I have not worked with JDBC driver yet!
You are right, this is what I'm going to do tonight:
1) Stop and disable all other drivers
2) Run the jdbc driver
3) All unwanted changes (if any) will be published to edir (cannot avoid that).
4) Restart all other drivers.
5) No changes will be processed.
Also, I thought about disabling publishing in the driver filter, but not sure that will help.
Why not add a final policy that veto all other actions exept for the start action. Like "If class=user then veto"
Start the driver let it process one round and when that is finished you take away the veto rule.