Unsolved
This post is more than 5 years old
7 Posts
0
2691
Remove intermediary node in a Cascading Replication of Data Domain
Hello everybody!
Cascading Replication: Replication without DD B
DD A------>DD B------>DD C DD A -------> DD C
I'd like to know if i remove the intermediary node (DD B) in a Cascading Replication of Data Domain, can DD A continue to replicate on DD C without need to restart the replication process?
Thanking you in advance for your help in this matter!
L.
Mohammed AbuAyyash
24 Posts
0
February 20th, 2015 01:00
Lionhands,
I don't see why it won't work.
Try it first with one directory using "resync" command after recreating the replication set between DDA --> DDC and see the result.
Generally DD should start recognising the same data blocks and seeding only the deltas.
lionhands
7 Posts
0
February 20th, 2015 03:00
I don't think that Data Domain recognizes the data blocks residing in his target, I think that it takes into account the blocks that he has sent to the target, and those are two different things.
The question is if while DD A replied on DD B, meanwhile he kept in mind that the blocks of data replicated on DD B, would be automatically replicated on DD C, then when we go to resynchronize DD A on DD C, DD A already knows what blocks were sent to DD C, and without going to see which data blocks are located on the DD C (because I don't think DATA DOMAIN REPLICATOR SOFTWARE can do this,or maybe am I wrong?).
L.
Mohammed AbuAyyash
24 Posts
0
February 20th, 2015 04:00
Lionhards,
Here is more information about "Resynchronizing Recovered Data"
Resynchronization is the process of recovering (or bringing back into sync) the data between a source and destination replication pair after a manual break.
The replication pair are resynchronized so both endpoints contain the same data.
A replication resynchronization can be used to recreate a deleted context, when a directory replication destination runs out of space while the source destination still has data to replicate. Resynchronization can also be used to convert a collection replication to directory replication.
This is also useful when it is to be a source directory for cascaded replication. A conversion is started with a replication resync that filters all data from the source Data Domain system to the destination Data Domain system.
This implies that seeding can be accomplished by first doing collection replication then breaking collection replication, then doing directory replication resync.
I don't see in the text that "Resync" will sweep the target and start send all the data over the networker!
So, try just one Directory!
lionhands
7 Posts
0
February 20th, 2015 05:00
Moab, I thank you and you've been very kind!
One day I hope to try to do this experiment, and obtain satisfactory results!
L.
Mohammed AbuAyyash
24 Posts
0
February 20th, 2015 05:00
You are Welcome.
I'll be waiting for the result...
kris1231
12 Posts
0
April 3rd, 2017 14:00
Anyone tried this ? Is it possible to remove DD B with DD A --> DD C ?
James_Ford
30 Posts
1
April 4th, 2017 07:00
Hi Lionhands,
So you don't specify what type of replication you are using here however I will assume its mtree replication (as this is the most common type of native replication used in the field). If so then you won't simply be able to change replication to run from DD-A -> DD-C as mtree replication is based around snapshots and as these two systems don't currently replicate directly they won't share a common snapshot on which to base their resync.
As a result (assuming this is mtree replication) what you will need to do is:
1. Break the existing replication contexts so that all systems are fundamentally separate from each other, i.e.:
Break DD-A -> DD-B
Break DD-B -> DD-C
2. Rename the existing mtree on DD-C so that it has a temporary name, i.e.:
# mtree rename /data/col1/[existing name] /data/col1/[temporary name]
3. Configure mtree replication between DD-A and DD-C, for example:
# replication add source mtree://[DD-A]/data/col1/[mtree on DD-A] destination mtree://[DD-C]/data/col1/[new mtree name on DD-C]
Note that:
The above command would need to be run on both DD-A and DD-C
The new mtree name on DD-C should be of an mtree which does not currently exist (mtree replication will create this mtree)
4. Initialise the mtree replication context:
# replication initialize mtree://[DD-C]/data/col1/[new mtree name on DD-C]
5. Once the initialise is complete delete the temporary mtree on DD-C created in step 2:
# mtree delete /data/col1/[temporary name]
The reason for doing things like this is that DD-C currently contains most (if not all) of the data in the mtree you are replicating from DD-A. If you simply delete the existing data on DD-C then set up a new context and initialise there is a good chance clean will run on DD-C before the initialise is complete so a reasonable amount of data will need to be sent in full from DD-A -> DD-C again. By renaming the existing mtree on DD-C and keeping it until the initialise is complete you are guaranteeing that DD-C keeps most (if not all) of the data the new replication context needs to replicate from DD-A -> DD-C. As a result when you run the initialise very little physical data will need to be sent over the wire from DD-A -> DD-C and most of the traffic will just be metadata meaning that the initialise will be much much quicker than if you started from scratch. Basically even though you perform an initialise this will be much more like a resync.
Note that if you are using directory replication then similar steps can be taken however the commands are slightly different.
Thanks, James
kris1231
12 Posts
0
April 12th, 2017 14:00
Thank you James for posting the steps.
One question:
In the first step do I need to break replication between A -->B ? Is it possible to break the replication just for B-->C and then rename the Mtree on C and setup one-to-many Mtree replication from A--> C. I want to make sure atleast one Mtree replication is always configured throughout this process so that data is available on the DR system in case of recovery. Once sync is completed between A-->C then I want to break the replication between A -->B and decommission B. Do you see any challenges in this approach ? Appreciate your input.
James_Ford
30 Posts
0
April 13th, 2017 06:00
Yes that should be OK - you can have A replicating to separate mtrees on B and C concurrently. As a result B will stay in sync with A whilst C initialises so this should do what you need.
Thanks, James