From: "Adrian Crum" <[email protected]>
Jacques Le Roux wrote:
From: "Adrian Crum" <[email protected]>
Jacques Le Roux wrote:
Hi Deyan,
Thanks for your clear explanation and suggestion. As I'm busy with another
stuff, I have quickly put your comment as a quote in
OFBIZ-3333 .
There is however a major issue that CAN NOT be fixed in the current
implementation: the list and sequence of entities to be
synchronized gets created by entities' timestamp - date_created_tx and last_update_tx. It works as long as the clocks of all
the
syncing parties are in sync. You can easily achieve this by using NTP for
example - reliable enough. But if the clock of one of
the parties gets un-synced for just few minutes, and during those few minutes
records get inserted or updated than you are in
trouble. Syncing the clock back won't help you because you won't be able to sync the broken records due to foreign key
constraint
issues. Examples I could give but I guess you could think of such by yourselves
:)
So IMHO the best approach for synchronization is not the timestamp but the TRANSACTION LOG. This approach is used in all
major
databases - m$ $ql, oracle.
The problem with that approach is that it is database-specific. As an
alternative, you could query the other servers for their
current time and generate a set of offsets to adjust the timing.
Why asking from one to the others? Using NTP on all of them should be enough,
or do I miss something
Yes, you missed the part where one of the servers loses its NTP connection and
its time drifts.
I see, so a check between them should be done also, right. One important point is also the time interval between 2 sync runs. By
default OOTB it's 5min for push and 1 hour for pull. This lets a reasonnable period of time before the servers have really lost
their time syncs enough to be a problem. And could even be increased (say 15 mins for push) to avoid as much as possible this issue.
Also an alert on the NTP connection loss could add some security without needing to implement a check between servers, etc.
Jacques
PS: why mean Re: JUNK-> ?
Sorry about that. Our security appliance prepends JUNK-> to the subject line of suspected spam emails. Most likely your mail
server is on a blacklist somewhere. I try to remove it before replying, but sometimes I forget.
-Adrian
