Re: High Availability Options
- From: hpuxrac <johnbhurley@xxxxxxxxxxxxx>
- Date: Sat, 31 May 2008 03:05:58 -0700 (PDT)
On May 28, 8:05 pm, Pat <pat.ca...@xxxxxxxxxxxxxxx> wrote:
snip
You don't need EE for RAC necessarily.
You don't need RAC at all necessarily for HA. Actually as Moans
Nogood has demonstrated often people lose reliability and availability
when implementing RAC.
Start by defining exactly what HA means to the customer. How much
downtime can they tolerate and how often?
The specifications I had to work on were:
Primary production environment should take < 2 minutes to recover from
a hardware failure (RAC does this for me I believe)
RAC "could" handle this but as Moans has pointed out ( repeatedly )
implementing RAC and supporting RAC requires a huge investment not
only in licensing costs but in training, testing, verification, etc.
It is not unusual that people find they cause more downtime than they
gain by attempting to implement RAC. It requires a huge investment in
personnel, equipment, testing, etc. You cannot just setup a
production RAC environment without having a test RAC environment to
practice on and perfect everything.
Don't undersell the amount of time and effort and cost involved in an
implementation like this if you choose RAC.
For example, 2 minutes is an eternity and could possibly be handled by
having a spare server setup that can mount the storage and perform
instance recovery. Or a standby database on the primary site.
Lots of possible HA solutions might fit into what you have described
so far.
In the event we lose the primary data center, we should be able to to
have the DR environment up in < 10 minutes. Frankly I'm not sure the
requisite network changes would propagate in < 10 minutes in the event
we flat out lost a data center, but those were the parameters I had to
work with.
You can do the remote HA either with oracle techniques or with storage
based alternatives. Again lots of choices here.
We are switching out EMC symmetrix synchronous SRDF over to Clariion
based mirrorview async.
My understanding is I can set up RAC with Oracle Standard just fine,
so that more or less meets my production criteria (although the SAN
does remain a single point of failure, albeit an unlikely one)
The hard part though is how to make sure that my offsite DR database
is up to data. Dataguard will do that for me, and I can live in
asynchronous mode (in a disaster we can afford to lose a few unapplied
logs; this is not a financial app). Dataguard though (I think)
requires enterprise.
Why don't you actually look at the licensing options and choices
instead of guessing?
The hard part of this spec for me at least is the offsite DR site,
which is kind of ironic, because the other database we have in house
is mysql and it has the opposite problem. Remote slaves are easy to
set up (and part of the core product). There's no equivalent to RAC at
all though (don't get me started about what mysql laughably calls
their cluster solution).
Not sure this is relevant to what you are asking here. No need to
start some kind of oracle/mysql flame war we get enough of the oracle/
sql server ones here.
Good luck and keep questioning all your assumptions.
.
- References:
- High Availability Options
- From: Pat
- Re: High Availability Options
- From: hpuxrac
- Re: High Availability Options
- From: Pat
- High Availability Options
- Prev by Date: Re: SQL Server for Oracle DBAs
- Next by Date: Re: SQL Server for Oracle DBAs
- Previous by thread: Re: High Availability Options
- Next by thread: Re: High Availability Options
- Index(es):
Relevant Pages
|
