How much time do you have? I say that becuase you may burn a lot of time
trying to solve those database issues that are solved in some of the other
commercial products.
For replication you could use snapshots wither by doing exports/imports or
data copying on a periodic basis so that you could at least recover fairly
quickly....
I have not used DB2 but people have mentioned that it is fairly inexpensive
when compared to Oracle.....
I would have thought that the SAP product would have had failover and
perhaps even Postgress???
Cory
At 11:37 PM 10/11/00 +0200, David Kinnvall wrote:
>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-----------------------------------
>
>
>
