We currently have a SQL Anywhere 11 High Availability setup. It is synchronous. We have been looking to get a relatively live copy of the DB to an offsite location. It looks like our HA secondary DB might be the solution. So here's the setup we are thinking off:
Location 1 (main site) - Primary DB - Arbiter Location 2 (disaster recovery site) - Secondary DB
Locations 1 and 2 will have a VPN between them that will be used for communication between the two sites. Our main concern is latency: what will a synchronous VPN connected HA setup do to our transaction times? Due to legacy software, we do know that doubling transaction times will result in squaring locking issues. Do we need to go to a-synchronous HA? What will happen to our transaction times if the primary fails?
I realize we can all benchmark this (and we will) but to get real data that would require us to actually put our production machines in that config. I'd like to brainstorm it out before we commit to that.
What are your thoughts?
You might want to consider using the scale-out feature in version 12. This would allow you to keep your current configuration with both mirroring partner servers in one location and with them communicating synchronously. You would add a COPY server at the disaster recovery site. Log pages would be sent to the copy server asynchronously, with occasional synchronous requests to prevent flooding the server. In the unlikely event of a disaster requiring the copy server's instance of the database to be made writable, some manual (or scripted) effort would be required to start the database.
answered 14 Jan '11, 20:09
If you are using the synchronous mode then e.g. an Insert will need the additional round trip time to your backup site before the main site server will respond the commit. So if e.g. latency is 150 ms between the sites I would count with at least 300 ms exec time per statement.
answered 17 Jan '11, 16:31