Respondida Moving off of HyperV installation to bare-metal.

  • lunes, 05 de marzo de 2012 20:24
     
     

    I am new to my company but not SQL, and have stepped in it very deeply..

    We are running our main application with the SQL back end running on a HyperV instance.  The underlying machine is barely enough to handle our database, and we are rapidly outgrowing it.  I have tentative approval to set up new hardware and migrate the database to it, but I need to have a 0 down time plan.  Ii all goes well with move to hareware, we will be setting up another server very soon to provide full active/passive failover.

    My main question is, can I set up the new server as the failover device?  After it has mirrored the instance housed on the HyperV, I should be able to force the failover, and be running on the new hardware.  We are a 24/7 company, and I want to keep from going down at all.  A few minutes for the failover to be forced is the most we can tolerate.  

    Unfortunately, the sheer size of our database (650GB today) makes it impractical to detach / move / reattach the database.

Todas las respuestas

  • martes, 06 de marzo de 2012 13:48
     
     Respondida

    Your main question as to have the new server as a failover device , I was able to find these threads where they confirm that it is possible in windows 2008. have a look through it

    thread1

    thread2

    For other possibilities I have successfully done both of the below methods in similar situations

    Setting up two way replication between the two instances and as you have almost identical data, all you need to do is to just point your applications to the new server when ever you are ready. In this way not that you are also getting away with no downtime, it also provides you with a failback mechanism should you need to go back to your old system.

    Another option is to use LogShipping, but it takes a bit more downtime, ie the time it takes for the last bits of transaction logs to be restored and making the dbs in recovery mode before you can flip the application to point to the new db's

    There will be downsides to both as you might have to make changes in your existing methods like having to add GUIDS for merge replication etc, but I have successfully migrated to machines following these procedures.


    Regards, Ashwin Menon My Blog - http:\\sqllearnings.com

  • martes, 06 de marzo de 2012 13:54
     
     Respondida

    Hi,
    Also, you could set-up your new hardware as you want it, i.e. cluster, system databases, logins, etc. then mirror the user databases from the existing vm to the new physical.  Failing over should be very quick and then you just have to re-direct the clients, i.e. DNS or client update



    Thanks,

    Andrew Bainbridge
    SQL Server DBA

    Please click "Propose As Answer" if a post solves your problem, or "Vote As Helpful" if a post has been useful to you

  • martes, 06 de marzo de 2012 20:16
     
     
    Thanks guys.  I'll mark an answer when we do the implementation (very soon, that poor hyperV box is choking), and update the thread with actual procedures.  Just knowing it can be done makes my life easier, even if I still have to actually do it. ;-)