| Subject | Re: [Firebird-Architect] RFC: Clustering |
|---|---|
| Author | Lester Caine |
| Post date | 2006-11-22T07:58:43Z |
Jiri Cincura wrote:
always use a UTC/GMT 'NOW' and require you to use LOCAL_... if you
really want a local time. I'm having to manually insert UTC timestamps
where this is trying to provide cross database support :(
Not just a clustering problem - a major headache generally.
While I understand the discussion on time sync, if time is an important
part of the update process, then as has been stated NTP is not good
enough. I'm still using Rugby time code receivers and we still have
problems with the second not changing identically across a site ( we get
some picky SOB's who stand at one end of a platform and expect to see
all the clocks change at once ) but fortunately that is within the spec
- as long as the clock display is within a one second window... I can
see a situation with multiple sites around the world tracking
astronomical events needing accurate time and in these special cases
atomic clocks would be the only solution, but I think that where a
duplicate data record *IS* a copy of another, the timestamp should be
part of the insert/update data not added separately by the server? Again
not limited to clustering, but a general requirement for good design
when multiple copies are required?
--
Lester Caine - G8HFL
-----------------------------
L.S.Caine Electronic Services - http://home.lsces.co.uk
Model Engineers Digital Workshop -
http://home.lsces.co.uk/ModelEngineersDigitalWorkshop/
Treasurer - Firebird Foundation Inc. - http://www.firebirdsql.org/index.php
> = m. Th = wrote:This is the precise reason that 'NOW' is actually wrong. Other databases
>> - If you talking about "now" as a variable which gets the current time,
>> this isn't a problem in a LAN, at least in a Windows Domain one, dunno
>> for Linux, but the things should be the same, where it's imposed (by the
>> Kerberos protocol which is used) that all the workstations to have the
>> clocks in sync. (ie. a time server is required).
>
> Sorry, if I miss something and I ask dumb question, but how will be solved,
> if one machine is in England (GMT) and other in Ohio (GMT-5 AFAIK)? And what
> happends if one or other will crash, what about the syncing?
always use a UTC/GMT 'NOW' and require you to use LOCAL_... if you
really want a local time. I'm having to manually insert UTC timestamps
where this is trying to provide cross database support :(
Not just a clustering problem - a major headache generally.
While I understand the discussion on time sync, if time is an important
part of the update process, then as has been stated NTP is not good
enough. I'm still using Rugby time code receivers and we still have
problems with the second not changing identically across a site ( we get
some picky SOB's who stand at one end of a platform and expect to see
all the clocks change at once ) but fortunately that is within the spec
- as long as the clock display is within a one second window... I can
see a situation with multiple sites around the world tracking
astronomical events needing accurate time and in these special cases
atomic clocks would be the only solution, but I think that where a
duplicate data record *IS* a copy of another, the timestamp should be
part of the insert/update data not added separately by the server? Again
not limited to clustering, but a general requirement for good design
when multiple copies are required?
--
Lester Caine - G8HFL
-----------------------------
L.S.Caine Electronic Services - http://home.lsces.co.uk
Model Engineers Digital Workshop -
http://home.lsces.co.uk/ModelEngineersDigitalWorkshop/
Treasurer - Firebird Foundation Inc. - http://www.firebirdsql.org/index.php