Hi!

On Wed, 11 Oct 2000, Robert Krueger wrote:

[description of budget-friendly Orion setup - snip]

> sounds very nice but what about the database? how do you cluster that 
> without spending an arm and a leg? our experience is, that it's not that 
> hard to set up clustered web services with static pages and servlets but 
> the really expensive part is, when you want that high availability for your 
> database. it doesn't buy you much if you have highly available ejbs when 
> the database server goes down. many people use clustered apache/jserv on 
> linux and cheap pc-hardware for high volume transactional websites but have 
> a large enterprise sun running oracle in the back. anyone out there running 
> a configuration with orion that includes a database with failover that 
> doesn't blow up the budget too much (compared to other components)?

Ah. Deja Vu. :-) I'm involved with a startup company here in Sweden,
and considering Orion as app server we are also contemplating what
non-arm-and-a-leg-spending ways there are to enable a database for
failover and load-balancing functionality.

We are looking at either PostgreSQL, InterBase, SAP-DB or MySQL (yeah,
I know) as our database. We have not seen any currently freely available
solutions for failover for either of those (anybody?). So, we are thinking
about implementing something by ourselves. Nothing definite so far, but:

- The synchronizing of data will be done on the application-level, not
  by the database servers themselves. See below.
- We'll avoid numeric sequences for record keys to make this easier.
  We will implement some unique key-generation scheme based on whatever
  is needed to make keys unique but still not rely on strict monotone
  numeric sequences or similar ( md5(table_name+timestamp()), perhaps? ).
- We'll code a DB-abstraction layer that takes care of executing
  all update queries against all configured database servers and
  all read queries against one of them known to be alive and lightly
  loaded (or not recently accessed, or some other scheme).
- I guess that if we need database-specific stuff such as stored
  procedures or similar we need to use the same database software
  for all failover machines.
- If we stay away from database-specifics we could possibly allow
  failover between different database products. Would be cool.
  Using straight, standard SQL, could make this feasible.

These are very premature thoughts, we are getting closer to the
planning and design stage, but we haven't actually started yet.
Any thoughts? Ridiculously naive? Or possible to pull off?

> robert

/David

--------------------------------Reach me by--------------------------------
- Email: [EMAIL PROTECTED], WWW: http://www.dtek.chalmers.se/~d0dak/ -
----------------------------------/David-----------------------------------


Reply via email to