I am thinking your best solution is to create a table with a uuid column
and reference that to sync up your data. That would also allow data
dumps to be restored to another machine with the proper identifier
because the identifier is really a characteristic of the data, not of
the xlog or cluster install state.
The problem with that is the you could restore to another machine and
then two machines would have the same uuid values. I wonder if you
should be generating a new uuid after every sync to prevent that
problem. That would fix cases where someone restored their data and
tried to sync up again and got duplicate data.
Exactly that is my current solution and the "... two machines would have" is the current problem.
Changing the UUID does not fit into the current structure, where I log within the central db "Database UUID 123123 patched up with modification number xxx"; and only select the not-yet-done modifications.
That "two machines with same UUID values" was the reason I hoped for that identifier ...
Thanks again for caring, now I know that my solution was quite okay.
My next idea is something like "select md5(relevant_structure_elements_of_database) and to create the DML by checking the differences...
best wishes,
HArald
GHUM Harald Massa
persuadere et programmare
Harald Armin Massa
Spielberger Straße 49
70435 Stuttgart
0173/9409607
no fx, no carrier pigeon
-
LASIK good, steroids bad?
