Subject | Re: [Firebird-Architect] Re: RFC: Clustering |
---|---|
Author | Lester Caine |
Post date | 2006-11-21T07:48:04Z |
Jim Starkey wrote:
before the joke. Given that a lot of big money companies are now looking
to use broadband to provide pay viewing I don't see any problem with
sequential multicast. ( Roman provided the fine detail )
That said, I think I would be looking for a stepping stone approach.
Maintaining two or three 'current' versions of the data on remote sites
and replicating to read only copies for load sharing? If one of the
Master sites gets taken out, the other carries the full load until it is
restored, or perhaps a slave gets promoted. Since local copies of
Firebird can be run at no cost, a large number of slaves can be added so
that - for example - a retail network would have full copies of all
local transactions and stock at a store, but not that of other stores.
The insert/update activity would then be to a 'cluster' of machines that
provide fallover stability for the master data files.
We are probably talking middle tier software for the bulk of this, but
if the engine has the right hooks for some of the operations? Back to
the question of defining the problem?
--
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
> Roman Rokytskyy wrote:Multicast streaming would not be a lot of use if you got the punch line
>>
>>> The hardest is how to make sure the servers execute all in
>>> the same precise order. Without this, the scheme can't work.
>>> I don't have any idea of how you might do this, but perhaps
>>> you have a solution.
>>>
>> This is solvable, at least in case of LAN. One can use reliable
>> multicasting with total ordering protocol stack, which would guarantee
>> that the messages are delivered to all nodes in the same order. WANs
>> have bigger latencies, so the reliable multicast is not that reallistic.
>>
> Huh? Total ordering protocol stack? That takes a little explaining,
> particularly with a network made out of store and forward switches
> (about the only thing on the market today). Do you really think that
> the order of receipt of two packets from clients at opposite ends of a
> LAN is deterministic? How could it be? Any collision on ethernet
> causes each node to do a random rate and a retry. One collision
> anywhere on the LAN and the whole scheme collapses.
before the joke. Given that a lot of big money companies are now looking
to use broadband to provide pay viewing I don't see any problem with
sequential multicast. ( Roman provided the fine detail )
That said, I think I would be looking for a stepping stone approach.
Maintaining two or three 'current' versions of the data on remote sites
and replicating to read only copies for load sharing? If one of the
Master sites gets taken out, the other carries the full load until it is
restored, or perhaps a slave gets promoted. Since local copies of
Firebird can be run at no cost, a large number of slaves can be added so
that - for example - a retail network would have full copies of all
local transactions and stock at a store, but not that of other stores.
The insert/update activity would then be to a 'cluster' of machines that
provide fallover stability for the master data files.
We are probably talking middle tier software for the bulk of this, but
if the engine has the right hooks for some of the operations? Back to
the question of defining the problem?
--
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