on 2010 Nov 10 11:46 PM
We currently run SQL Anywhere 11 with mirroring (HA) under Linux for our Production environment. Due to increasing growth of our databases, we have purchased a new SAN and will be migrating the databases to it once installation is complete. This SAN at our data center site will match the SAN at our HQ and it will (reportedly) provide storage replication between the two. I was considering the idea of changing the database to stand-alone mode (breaking the mirror) since when we move to the SAN both copies of the db would be stored on the SAN anyway and be replicated. Since the db data will be replicated, I guess the remaining risk is hardware failure of the db server itself. If that happens the secondary db server could be used as a hot spare. If any have opinions on pros/cons or similar experiences, I would love to hear them. This is all new territory for us. Thanks.
Request clarification before answering.
In addition to what Tyson said, if you want to rely on SAN replication then you must test failover to make sure that the replicated database and log files can actually be started successfully with no loss of committed transactions... using your SAN environment... and that this testing must be repeated every time the SAN software and/or hardware is changed or upgraded.
Also, neither SAN replication nor HA are a substitute for a backup and recovery plan.
One thing you might investigate: The SAN vendor may not have any experience with SQL Anywhere databases, but check for their experience with Oracle, Microsoft SQL Server, etcetera, to see if any special accomodations are required, any special "replication agents" or modules or whatever. If such special thingies are required, then they probably do not exist for SQL Anywhere, and SAN replication will not work for SQL Anywhere.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
One thing that HA protects from is software failure of the database server. If an assertion happens and the process has to terminate, you might not want to replicate that data, but start with previous transactions that SQL Anywhere has already safely committed and replicated. You wouldn't want the database that failed an assertion to be replicated, because the replicated copy could quite possibly fail the assertion as well.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
52 | |
6 | |
5 | |
5 | |
5 | |
4 | |
3 | |
3 | |
3 | |
3 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.