I was wondering whether it would be possible to let the orion server(s) switch
datasource as a sort of
failover procedure. I haven't digged myself into clustering and failover, but here's
the idea.
Assuming you have made sure the server are running with failover and you have bought
yourself a SCSI-raid
configuration with a Y connection (that is the disk are connected to two systems), the
largest risk of failure
is the database server. If however orion could automatically switch on some sort of
connection timeout from
one server to another, you can solve this problem almost to easy.
This stil leaves you with a number of risks like:
- write failure of the db-software corrupting your database.
- program logic failures.
- site disaster (fire, flooding, tornado etc.).
- human error.
Depending on the sort system I guess, I could live with that.
Frank
On Wednesday, October 11, 2000 11:37 PM, David Kinnvall [SMTP:[EMAIL PROTECTED]]
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-----------------------------------
>
>
