SQL Server 2012 - DB Mirroring + Log Shipping + Multi-Subnet

Question

Hi again,
So AG would be nice to have, but considering the costs of getting it, well, it is a no go for me at the moment (This is like a 1:20 ratio considering Std comes with server licencing and enterprise is only per 2 cores).
So, having 2 sites, with different subnet. Is it possible to configure automatic failover for DBM ? We are running Windows 2012 R2 which supports multi subnet failover. But what about DBM in this case ?
Can the witness be configured on a third site ? (I was thinking of having the following weights: Site 1:2, Site 2:1, Quorum:2 just to have no reconfig to do in case of Datacenter failure)
Also, in order to offload some of the backup load as the DB are somewhat big (1TB), I was thinking of having one additional node per site to which the logs are shipped and that are used to run the backups. The question being, is it possible to log ship from
each "primary" on each site rather than have the primary on site 1 do it for all the servers across the subnets ?
It would be a setup like this:
Site 1 Primary <---DBM---> Site 2 Primary (Hot failover)
Site 1 Primary <---LogShips---> Site 1 Secondary
Site 2 Primary <---LogShips---> Site 2 Secondary
And thus reduces the load on the link between the 2 sites.
I do hope to see AG in the future for Std as they are removing DBM in the next version.
Thanks,

Answer 1

The idea behind the cluster is to have a single IP on which the applications can reach the DB in case of a failover to the secondary site.
This requires a failover cluster instance - mirroring does not work this way.
Because as far as I understand it, either the application has to be aware and able to switch to the new DB primary, or we can use a multisubnet cluster or we can manually reconfigure the applications (so painful)
Mirroring has the failover partner attribute in the connection string that can be utilized. A multi-subnet cluster would require, again, a FCI.
AFAIK, DBM is not recommended for more than 10 DB on an instance due to the worker threads.
"It depends". There can be worker thread issues, but this will entirely depend on your hardware and architecture of processor/SQL Server. In 32-bit world it'll eat up all of your worker threads. In 64-bit world on a decent server it shouldn't be
a problem to have 10-20 out of the box.
I don't mind having to failover multiple database residing on the same instance and having to setup them per DB.
If any of your databases have a dependency on one another, this isn't going to work well as one database could be failed over and another might not be. Just food for thought.
What it sound like you really want is a failover cluster instance and use log shipping to have a "readable copy" somewhere even if it is behind on time. The problem comes in is that a cluster all has to be in the same domain and part of the same
cluster. Your thoughts involve a separate cluster - so I'm not sure why two different ones unless you have multiple environments you're trying to add some HA to.
-Sean
The views, opinions, and posts do not reflect those of my company and are solely my own. No warranty, service, or results are expressed or implied.