I'm not sure if this is the right thread to post this topic, so please tell me if it's not.
We are trying to implement a Database failover server (or a Database cluster server) using SQLServer 2000, but without a real clustering from the database server itself, because we have a problem regarding the real Database clustering. So we are looking for a solution, where we assume we have two different databases, one is active and the other are passive, and whenever the active database is down for any reason, the passive database is activated and takes control of other requests. Does anyone have a good solution for this, without having to do it programmatically?
Originally posted by Nadeem Awad:
We are trying to implement a Database failover server (or a Database cluster server) using SQLServer 2000, but without a real clustering from the database server itself.
Does anyone have a good solution for this, without having to do it programmatically?
What application server are you using? Also, what are you using for your persistence connectivity? There *may* be something in their you can use depending on the webserver and database connection method. Aside from that, I'm not sure what you are looking for. If you are not using real database clustering, then its usually better for a developer to handle it since it can handle more complex logic such as half-completed or nested transactions.
One programmatic solution if this is JDBC is to use a factory method to connect to the database so that a user never calls a specific database directly, and the level of indirection can be leveraged in a database failure.
I'm using JBoss Application Server, and JDBC for my persistence connectivity. I'm searching to see if there is a well known, tested solution that fulfils my requirement. Of course, implementing this programmatically is valid, but the my management doesn't prefer it because we are somehow approaching a deadline and we haven't developed anything similar to this. So, we might not cover all the aspects or cases for this scenario. Therefore, we are keeping this solution as our last resort.
[ November 30, 2005: Message edited by: Nadeem Awad ]
Usually, the difficulty in setting something like this is consistency, making sure all databases are consistent so that when one fails the others can pick up quickly. Its often a trade off between speed and safety. For example, initiating a 2PC for all transactions guarentees a certain amount of reliability, but often slows performance to a crawl. Alternatively, asynchronous updates improve performance but reduce reliability since the recovering database may not be fully up-to-date when you want to use it.
In the end, it really matters how your using the data in the database. Good luck though, failover/recovery is not a trivial matter!