October 4, 2007 at 9:14 am
so here is the situation, we have an old SQL cluster with it's own DAS storage. We have new hardware with a new DAS.
We would like to (if possible) figure out a way to move the SQL to the new hardware and new DAS without downtime.
We know how to do this with Doubletake and our layer 7 switches, but this is a huge pain it the butt, because we have to basically snapshot the SQL on the new machine and copy all the objects, and confirm it then flip the layer 7 switch to the new port...etc. Doable, and it works, but is there a way to maybe move the SQL cluster from the old hardware to the new? I don't know of one, but then again, I have never tried this before. Any help you could provide would be great.
October 4, 2007 at 10:05 am
Depending on your definition of 'downtime' this is not possible. At some point, users will need to be disconnected from the old database and connected to the new database. All users connected to the old database at the time of the cut-over will experience some downtime as they are disconnected and must reconnect to the new database. Even if this is happening in the application so it is transparent to the users there must still be a point in time to where users are disconnected from the old DB and re-routed to the new DB.
October 4, 2007 at 11:33 am
OK that's what I thought. There is a way to do it without downtime, but it's a huge pain, but for anyone else wondering, here it is.
basically the process is this (if you don't know what doubletake does, check it out, it's actually a great product)
-build the new cluster
-replicate the old sql to the new with a 1 time snapshot
-start realtime replication on the new server (we use doubletake because it does the same as SQL rep, but it can do anything on the server)
-script and move over all the objects (users, SP's, triggers, jobs, roles...etc)
-test
-test again
-now here is where the layer 7 switch comes in handy (like a foundry ServerIron)
-flip the virtual ip address for the SQL cluster in the foundry from one cluster to the other.
-keep the old one running with replication going in-case something goes wrong.
-test again.
-monitor for a few days
-I would keep replication going with the old server for a while incase something blows up (metephorically speaking)
Viewing 3 posts - 1 through 2 (of 2 total)
You must be logged in to reply to this topic. Login to reply