SQL replication testing

[Jason Antes [2]]

I need to test several LUN's that were replicated to my DR site between 2 EVA 8100 using CV 8.02. I have replicated the LUN's as "Read only" and presented them to my SQL server at my DR site. Being "read only", SQL doesn't want to read in the DB's which is fine. There are 2 ways of doing what I need to do:

1. Pause replication and copy the data to new LUN's that are read/write.

2. Break the replication and present the LUN's as read/write.

Problem with the first option is that when I try to copy the DB files off, they take up 4 times more space than they should (i.e. it's a 7 GB file but uses 28GB of space when I copy. Windows says it's only 7GB but the space used on an otherwise empty drive is 28GB). I've tried copying both to local disk and to a LUN, same result.

Problem with the second option is that I have to re-replicate the data after the test is complete. With respect to the second option, I'm having a little trouble with the procedure. I thought it was the following:

1. Pause replication (this keeps logs and DB with the same time stamps)
2. Remove members from the DR group keeping the remote vdisks
3. Change DR LUN's to read/write and present them to needed servers.

Problem with this is that I cannot remove the members from a DR group when replication is paused. I'm guessing that I wrote the procedure down wrong. I'm guessing that I just do steps 2 and 3. Any thoughts?

Thanks,
Jason

[Víctor Cespón · Accepted solution]

When the replication is suspended the copy of data from source to destination is suspended, but the relationship remains and the changes will be copied when you resume the link.
In this state you cannot remove members from the DR Group, nor delete members.
If you have a Bussiness Copy license, you can create a snapshot or snapclone of the destination vdisks and present them as read/write to a host.
Other possibility is to suspend the DR Group and then delete it. It will leave the source and destination disks untouched. Then you can present the destination disks.
But you will have to delete them before recreating the DR Group.

This is all supposing you use synchronous replication. If using asynchronous you must change to synchronous and allow the log buffer to empty before doing anything.

[Jason Antes [2]]

Ah, that is what I was missing on this. I had changed over to Asynchronous replication and added the "Pause" replication step where I really just wanted the delete.

Any idea as to why copying files from a paused or still replicating LUN winds up being 4 times as large as it should be?

[inetcfg]

Jason,

We just implemented a similar with CA, for our Exchange and SQL environment.

Would you mind describing your setup and how that's working out for you?

Our plan is to replicate the LUNs that are presented to the source servers (Exchange and SQL) to our DR site. Should we ever need to bring up the DR site, my thought would be to turn on the server that the DR LUNs are presented to.

What we can't figure out is a) can we replicate the OS LUN to capture any Windows patches and registry changes, and b) is there a way to script this sort of "failover" and "failback?"

Any help would be much appreciated.

[Jason Antes [2]]

From what I understand of what you are doing, you are:

1. Booting from SAN
2. Have your data stores on SAN

With CA, it block level replicates so if you are booting from SAN and replicating the boot LUNs it will capture all the changes that you make including patches, etc. So yes, you should be able to set up another server to boot to that lun in your DR site and have it come up. Now that also means that your network there must be a duplicate of your production network otherwise you won't have any connectivity to anything other than the SAN. It will also take Windows a bit to figure out it's new paths since the fiber WWN are going to be different. I understand that you can script the fail over but it is beyond what I have done.

At my site we do not boot from SAN. What we have set up is either VM's or physical servers connected to our DR SAN with the DR luns presented as "Read Only" so that the DR servers can see the data on them but cannot change them until a fail over situation.

In order for SQL replication to work, the SQL luns should be in synchronous replication mode. To test you have to be able to delete the DR group and all members at the same time which you can only do if it is in synchronous mode. At that point you present the luns needed to your DR server and have the DBA's attach to the database. They will scream up and down that this will not work, at least ours did, but once we got them to just do it they were suprised but it did work fine. They are now no longer SQL mirroring or log shipping.