November 20, 2013 at 8:33 pm
Hi,
I am currently running a SQL 2005 Standard failover cluster with some 250 databases. I also use mirroring for some of my mission critical databases.
I have been looking into using Neverfail to handle the DR/BCP but I am also moving to 2012 Enterprise. I would like to have all 250 databases as part of my DR/BCP plan and mirroring creates too many connections.
Would Always on be able to replicate all of my databases without creating any issues with the connections or otherwise? Would Neverfail give me any advantage over just using Always on considering I need to use Enterprise for features other than just Always on?
Thanks for your feedback in advance
Havoc_rah
November 21, 2013 at 4:27 am
havoc_rah (11/20/2013)
Hi,I am currently running a SQL 2005 Standard failover cluster with some 250 databases. I also use mirroring for some of my mission critical databases.
I have been looking into using Neverfail to handle the DR/BCP but I am also moving to 2012 Enterprise. I would like to have all 250 databases as part of my DR/BCP plan and mirroring creates too many connections.
Would Always on be able to replicate all of my databases without creating any issues with the connections or otherwise? Would Neverfail give me any advantage over just using Always on considering I need to use Enterprise for features other than just Always on?
Thanks for your feedback in advance
Havoc_rah
I have no experience with never fail so cannot really provide you a direct comparrison. Always on has its limitations, for example replication is not very well supported in an always on arcitecture.
But in terms of supporting connections the process is very similar to clustered SQL Instances.
You create your availaility groups, define within the group the databases that are part of that group, the servers that are replicas within the group and whether they have an synchronous or asynchronous copy of the data.
You then create a listener which will provide a virtual name for your applications to connect to rather that the actual instance name.
For you applications their connection string will use the listener name as the servername and at this point you can define the Application Intent on the connection string as to whether the request is read write or read only.
If its read only it can be serviced by any synchronous secondary servers, if read write it must be the read write primary. In the event of a failover the listener will redirect the request to the correct server.
Failover between the servers can be automatic and maunal depending on the synchronisation type so the downtime during failover is very similar to the downtime when failing over between cluster nodes.
Always on Availability Groups is a complicated technology and not all aspects play well with it. If I was you I would document all your HA \ DR requirements, the technology requirements you want available then create a evaluation environment for your solution. That way you can fully test the solution and ensure all aspects of your requirements are supported.
MCITP SQL 2005, MCSA SQL 2012
Viewing 2 posts - 1 through 1 (of 1 total)
You must be logged in to reply to this topic. Login to reply