server migration\upgrade

  • We have a sql 2008r2 active/passive cluster with a log ship RO node also part of solution that we want to move to sql 2014 and AG. THis supports a large 3rd party medical records database. One of two choices

    Build new active/passive 2014 cluster with sql 2014 AG and also have a Read Only node for reports in somewhat isolated environment, migrate Database to new group, remove old active/passive cluster and move new AG environment into that domain keeping the name the same for primary. Not a big fan of this but it does save us from all the Citrix and other connections being changed.

    2nd solution is build everything the same in current domain with new cluster name, shutdown old cluster after migrating database and make all necessary connections changes to Citrix, this would be our only current cluster and not sure solution one is worth the risk.

    Got 2 months to do this so any opinions welcomed

  • Make no mistake this is an extremely involved task and will need careful planning. Couple of questions first though before I make a recommendation

    so the clustered instance, is it a default or named instance?

    how easy is it for you to change all of the reporting connections?

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

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

  • it is named, I am a little wary of building an AG and then bringing it in to a domain. DId this at old job with a 2008 cluster and we had issues. I would rather live with the pain point of changing connections, also we could stand up the ag and do some initial testing for connections. This is our first AG and 2014 server, trying to avoid any unforeseen complications, I can live with fixing connections

  • As it's a named instance, let's assume you have

    THENETWORKNAME\Instance

    You want a new cluster with an availability group and all clients to connect for write and readintent connections.

    Dump the LS secondary server and use a readonly replica in the Availability Group to provide read intent query access. This will require the correct configuration of your read only routing scripts.

    So, with that in mind, at a high level this is what I would do

    • Build the new cluster alongside the current cluster (it doesn't matter that the new cluster Client Access Point is different that's not how you connect to the instance anyway)
    • deploy your sql instances to the new cluster, get everything configured and running including any sql agent jobs, logins, etc
    • get a copy of the current database over to the intended Primary replica on the new cluster, leave it unrecovered.
    • when you get your outage to move the database, use either log backups or diffs or both to bring the new database to a consistent state, the original will now be unavailable
    • the database is now live on the new cluster, if you want to you can reuse the network name from the old sql instance and use it as your Availability group Client Access Point (including the IP). The instance name is the only thing you'll need to remove from connections strings

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

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

  • that's kind of what my game plan was. When we made a cluster with the same name and then moved it into the domain the one it was replacing we had all kinds of trouble. Been a dba for 20 years but not a network expert and there were all kinds of klugy things going on. I believe the KISS principle is better served

  • tcronin 95651 (9/30/2015)


    When we made a cluster with the same name and then moved it into the domain the one it was replacing we had all kinds of trouble.

    Yep, you don't give it the same name. In fact the client access point you use for the cluster itself has no bearing on any instances installed. It's just the management entry point for the cluster.

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

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

Viewing 6 posts - 1 through 5 (of 5 total)

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