Best approach

  • THis is a good one and I have been given 2 days for a solution.

    We have a vendor app which will run a our local and other HQ. THe database names have to be the same, but they want each location to have their own installation. They came up with the idea that we could have an active/passive cluster at each local with it's own storage. In the event there would be a complete failure at one of the sites, we would log ship or mirror to an instance on the cluster at the other site. So in effect we would have an active/passive cluster at each local which would also have another instance which would be a log ship or mirror server which the other site could connect to if failure at the other site happended. ANy one ever try this, or have a better approach. I am thinking of trying the mirror idea with the cluster

  • We have mirroring with Clusters for some of our databases and it works fine.

    may be you can have active/active cluster on both sites. One node will be for production and other for mirror.

  • I forgot to add important point, the db names will be the same at the 2 locations

  • If the DB names are the same, you won't be able to log ship or mirror and still have access to one of the databases.

    "The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
    - Theodore Roosevelt

    Author of:
    SQL Server Execution Plans
    SQL Server Query Performance Tuning

  • Could I not setup another instance on the existing clusters and log ship/mirror to that node?

  • timscronin (10/5/2011)


    Could I not setup another instance on the existing clusters and log ship/mirror to that node?

    Yeah, as long as it's a separate instance. In terms of a DR situation, mirroring would be the better approach. With some code changes you can have automatic connection failover to the second location.

    "The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
    - Theodore Roosevelt

    Author of:
    SQL Server Execution Plans
    SQL Server Query Performance Tuning

  • I would go down the mirroring route.

    However since Database Mirroring is 'per database' I would be cautious about using automatic failover. You don't want some databases principals on one site and some on another!!! If your databases are independant then there isn't a problem with automatic failover but if there is any cross database activity then I would be cautious.

    Roll on Denali and always on with Availability Groups we wouldn't have this problem.

    Thanks

    Chris

    ------------------------
    I am the master of my fate:
    I am the captain of my soul.
    ------------------------
    Blog: http://sqlserver365.blogspot.co.uk/
    Twitter: @ckwmcgowan
    ------------------------
  • Ok mirroring went out the window as a choice the vendors app has 8 databases

  • timscronin (10/5/2011)


    THis is a good one and I have been given 2 days for a solution.

    We have a vendor app which will run a our local and other HQ. THe database names have to be the same, but they want each location to have their own installation. They came up with the idea that we could have an active/passive cluster at each local with it's own storage. In the event there would be a complete failure at one of the sites, we would log ship or mirror to an instance on the cluster at the other site. So in effect we would have an active/passive cluster at each local which would also have another instance which would be a log ship or mirror server which the other site could connect to if failure at the other site happended. ANy one ever try this, or have a better approach. I am thinking of trying the mirror idea with the cluster

    Bear in mind with log shipping that if you did fail over to a partner database you would have to move the recently updated copy of the database back to the original node and re initialise the log shipping plan. Mirroring does offer better failover (manual or automatic) between nodes.

    With mirroring, can your network support the necessary bandwidth, you dont want the database failing over at the merest hint of network latency.

    -----------------------------------------------------------------------------------------------------------

    "Ya can't make an omelette without breaking just a few eggs" 😉

Viewing 9 posts - 1 through 8 (of 8 total)

You must be logged in to reply to this topic. Login to reply