-
- Veteran
- Posts: 283
- Liked: 11 times
- Joined: May 20, 2010 4:17 pm
- Full Name: Dave DeLollis
- Contact:
SQL server replication Best Practices?
I am in the process of creating a replication job for our 2008 SQL VM. I will be replicating from an ESX cluster attached to an iSCSI SAN to a separate ESX cluster attached to an FC SAN on a CX4. Are there any best practices or any "gotchas" that are out there to look for or to follow?
-
- VP, Product Management
- Posts: 27368
- Liked: 2799 times
- Joined: Mar 30, 2009 9:13 am
- Full Name: Vitaliy Safarov
- Contact:
Re: SQL server replication Best Practices?
Hi Dave,
There are lots of existing discussions on this topic, but here is what I've got off the top of my head:
1. Enable "application aware image processing" option.
2. If you're not running daily backup jobs of this SQL Server or not using native backup tools to protect this SQL Server, enable logs truncation option via advanced job settings. Be aware that starting from version 6.1 our replication jobs do not truncate logs by default.
3. Deploy proxy server on your target cluster, in this case VM data should be written to your SAN through ESX I/O stack (HotAdd mode).
Thanks!
There are lots of existing discussions on this topic, but here is what I've got off the top of my head:
1. Enable "application aware image processing" option.
2. If you're not running daily backup jobs of this SQL Server or not using native backup tools to protect this SQL Server, enable logs truncation option via advanced job settings. Be aware that starting from version 6.1 our replication jobs do not truncate logs by default.
3. Deploy proxy server on your target cluster, in this case VM data should be written to your SAN through ESX I/O stack (HotAdd mode).
Thanks!
-
- Veteran
- Posts: 283
- Liked: 11 times
- Joined: May 20, 2010 4:17 pm
- Full Name: Dave DeLollis
- Contact:
Re: SQL server replication Best Practices?
Thank you Vitaliy.
I do currently backup this SQL server daily with Veeam. I will not truncate the logs with the replication job since we are doing daily backups. I was also planning on using Application Aware processing (VSS) when replicating. I was going to do 4 hour replications with just keeping 1 restore point. Will it interfere with my backup job if a replication job is currently running or if the job starts after the backup job?
I do currently backup this SQL server daily with Veeam. I will not truncate the logs with the replication job since we are doing daily backups. I was also planning on using Application Aware processing (VSS) when replicating. I was going to do 4 hour replications with just keeping 1 restore point. Will it interfere with my backup job if a replication job is currently running or if the job starts after the backup job?
-
- Veteran
- Posts: 283
- Liked: 11 times
- Joined: May 20, 2010 4:17 pm
- Full Name: Dave DeLollis
- Contact:
Re: SQL server replication Best Practices?
Also, I am using a physical Veeam server that is zoned into the iSCSI and FC SANs and is being used as a proxy for backups. I assume, technically, I do not need a proxy on the target cluster, correct? I'm not saying I won't install an agent on a VM on the target cluster though.
-
- VP, Product Management
- Posts: 27368
- Liked: 2799 times
- Joined: Mar 30, 2009 9:13 am
- Full Name: Vitaliy Safarov
- Contact:
Re: SQL server replication Best Practices?
I would recommend to have at least few restore points to avoid situations when you replicate already corrupted source VM (infected by some sort of malware). Having multiple restore points will ensure that you can always restore to a proper VM state.Daveyd wrote:I was going to do 4 hour replications with just keeping 1 restore point.
Not at all, you can point your backup and replication jobs to the same VM and do not bother yourself with the scheduling/overlap problems.Daveyd wrote:Will it interfere with my backup job if a replication job is currently running or if the job starts after the backup job?
Yes, you can use only 1 proxy to replicate your VM, however to write data in the HotAdd mode, your proxy should have access to the datastores you're replicating VMs to. If you do not have such proxy then VM data will go through the network stack.Daveyd wrote: I assume, technically, I do not need a proxy on the target cluster, correct? I'm not saying I won't install an agent on a VM on the target cluster though.
-
- Enthusiast
- Posts: 39
- Liked: 2 times
- Joined: Feb 05, 2010 4:43 pm
- Full Name: Michael Harris
- Contact:
Re: SQL server replication Best Practices?
I'd like to piggy back off of this question.
I have a SQL backup that I exclude a virtual disk (archive data) during backup. It's data that never changes, so I have a static backup of the data on disk and also on tape.
In a backup job, I have the option to exclude this disk from the vm configuration.
I noticed than when configuring a replication job and choosing the same exclusion this option is not present.
Is there a reason why ? Will the replicated VM know to "remove this disk from the config" or will it go looking for this disk and error out because it can't find it?
Thanks
I have a SQL backup that I exclude a virtual disk (archive data) during backup. It's data that never changes, so I have a static backup of the data on disk and also on tape.
In a backup job, I have the option to exclude this disk from the vm configuration.
I noticed than when configuring a replication job and choosing the same exclusion this option is not present.
Is there a reason why ? Will the replicated VM know to "remove this disk from the config" or will it go looking for this disk and error out because it can't find it?
Thanks
-
- VP, Product Management
- Posts: 27368
- Liked: 2799 times
- Joined: Mar 30, 2009 9:13 am
- Full Name: Vitaliy Safarov
- Contact:
Re: SQL server replication Best Practices?
Hi Michael,
Our replication job adjusts VM configuration file by default, so there is no need to have this checkbox anymore. This was done on purpose, as we wanted to minimize the risk of having inconsistent VM configuration which could prevent you from starting your VM replica in the disaster situations.
Thanks!
Our replication job adjusts VM configuration file by default, so there is no need to have this checkbox anymore. This was done on purpose, as we wanted to minimize the risk of having inconsistent VM configuration which could prevent you from starting your VM replica in the disaster situations.
Thanks!
Who is online
Users browsing this forum: d.artzen, lando_uk, orb and 171 guests