Highly available database ....
Posted in 2006
Topics: General Discussion
I am looking for a solution for Informix (7.31 or 9.4) to have high availability. Like in OracleRAC, you could have multiple nodes sharing same set of datafiles/database. If one node goes down, the other(s) continue to up and serve. Preferred environment - HP / Unix Thanks, Vivek
VC wrote: > I am looking for a solution for Informix (7.31 or 9.4) to have high > availability. Like in OracleRAC, you could have multiple nodes sharing > same set of datafiles/database. If one node goes down, the other(s) > continue to up and serve. > > Preferred environment - HP / Unix > > Thanks, > > Vivek Shared everything is not an option with Informix. The only shared everything architecture other than Oracle is DB2 on the mainframe. Informix has HA solutions but they are not the subsecond transparent failovers you likely associate with RAC. -- Daniel A. Morgan http://www.psoug.org damorgan@x.washington.edu (replace x with u to respond)
DA Morgan said: > > VC wrote: >> I am looking for a solution for Informix (7.31 or 9.4) to have high >> availability. Like in OracleRAC, you could have multiple nodes sharing >> same set of datafiles/database. If one node goes down, the other(s) >> continue to up and serve. > > Shared everything is not an option with Informix. The only shared > everything architecture other than Oracle is DB2 on the mainframe. > Informix has HA solutions but they are not the subsecond transparent > failovers you likely associate with RAC. You can build a cluster of ER nodes, each one a member of an HDR pair, with update anywhere replication, then build your application to be aware of the multiple ER nodes. If a node goes down, just repeat your operation on the next node. Your failover time is the time it takes to timeout a given operation. -- Bye now, Obnoxio "C'est pas parce qu'on n'a rien ' dire qu'il faut fermer sa gueule" - Coluche did i mention i like nulls? heck, i even go so far as to say that all columns in a table except the primary key could/should be nullable. this has certain advantages, for example, if you need to insert a child record and you don't have a parent row for it, just do an insert into the parent table with the primary key value (everything else null), and voila, relational integrity is preserved. but this is, admittedly, a bit controversial among modellers. --r937, dbforums.com