Why not to use DFSR one way replication....
I won’t go into any support statements or nonsense in this post ( not foolish enough to step into that pie )
What I will do , is go into some technical reasons of why this doesn’t work so well.
Here is a sample setup:
Here is how it is setup in the connection properties.
As you can see – data should flow from Spat2k3 ( lets call him Master ) – then to Spatsoftgrid and then to 2k3entspat…
Let’s take the simplest test and start with an empty dir…
On Master:
C:\LINK1>dir
Volume in drive C has no label.
Volume Serial Number is ACA0-05C7
Directory of C:\LINK1
07/20/2007 10:55 AM <DIR> .
07/20/2007 10:55 AM <DIR> ..
0 File(s) 0 bytes
2 Dir(s) 74,052,800,512 bytes free
Now, on Master we will create a file – Megatron.txt
Let’s take a look at some of its properties of Megatron.txt… from a handy dandy super cool tool called WMI. “Heard of it,” you say? “Old news...” – ahh, but I bet most of you have never used WMIC, and if you have, perhaps you’ve never used the /format switch. It’s pretty cool, in that it will format the data in a multitude of possible ways – in this case, we’ll automatically make a web page.
Using WMIC, we’ll get at the DFSR data for Megatron.txt with the following command:
wmic /namespace:\\root\microsoftdfs /output:steve.htm path dfsridrecordinfo where filename="megatron.txt" get /format:hform.xsl & steve.htm
Steve.htm looks like this:
Node: SPAT2K3 - 1 Instances of DfsrIdRecordInfo
|
INSTANCE. | |
|
Property Name |
Value |
|
Attributes |
32 . |
|
Clock |
20070720180145.618455-000. |
|
CreateTime |
20070720180138.118791-000. |
|
Fence |
3. |
|
Fid |
23080948090276543 . |
|
FileHash |
0000000000000000 0000000000000000. |
|
FileName |
Megatron.txt. |
|
Flags |
5 . |
|
GVsn |
{015A0FFE-D3A0-4CD5-B582-74E913C70C49}-v277 . |
|
Index |
45 . |
|
ParentUid |
{B6801173-5A2D-4EBC-948A-1103293A21D8}-v1. |
|
ReplicatedFolderGuid |
B6801173-5A2D-4EBC-948A-1103293A21D8. |
|
Uid |
{015A0FFE-D3A0-4CD5-B582-74E913C70C49}-v276. |
|
UpdateTime |
20070720180145.634080-000. |
|
Usn |
15373960. |
|
Volume |
\\.\C:. |
|
. | |
A few things to note:
- The hash is zero’d – which means that the file was not replicated in from another server ( ever ). This is the originating server for this file; the file was originally written on this server.
- The GVsn and Uid are the same GUIDs
MSDN describes GVsn and Uid attributes as follows:
Please note the section in red highlighted..
GVsn
Data type: string
Access type: Read-only
The global version of the resource (file or folder). The format of this string is {DatabaseGUID}-VersionNumber, where DatabaseGUID is the GUID of the DFSR database and VersionNumber is an integer value assigned to each resource that increases when the resource is modified. Because the database GUID uniquely identifies the last computer that the resource was modified on, the GVsn property uniquely identifies a particular version of the resource.
Uid
Data type: string
Access type: Read-only
Qualifiers: Key
The unique identifier of the resource (file or folder). The format of this string is {DatabaseGUID}-VersionNumber, where DatabaseGUID is the GUID of the DFSR database and VersionNumber is an integer value assigned to each resource when it is created. Because the database GUID uniquely identifies the computer that the resource was created on, the Uid property uniquely identifies the resource.
Now let’s take a look at Megatron.txt (with WMIC) on the downstream partner – 2k3entspat:
Node: 2K3ENTSPAT - 1 Instances of DfsrIdRecordInfo
|
INSTANCE. | |
|
Property Name |
Value |
|
Attributes |
32 . |
|
Clock |
20070720180145.618455-000. |
|
CreateTime |
20070720180138.118791-000. |
|
Fence |
3. |
|
Fid |
19421773393038239 . |
|
FileHash |
6f148a3d16483482 c174df8db9efdf58. |
|
FileName |
Megatron.txt. |
|
Flags |
5 . |
|
GVsn |
{015A0FFE-D3A0-4CD5-B582-74E913C70C49}-v277. |
|
Index |
42 . |
|
ParentUid |
{B6801173-5A2D-4EBC-948A-1103293A21D8}-v1. |
|
ReplicatedFolderGuid |
B6801173-5A2D-4EBC-948A-1103293A21D8. |
|
Uid |
{015A0FFE-D3A0-4CD5-B582-74E913C70C49}-v276. |
|
UpdateTime |
20070720180145.875000-000. |
|
Usn |
1632158888. |
|
Volume |
\\.\C:. |
|
. | |
FileHash has been populated on this replica partner, and the GVsn’s and UID have not changed.
Let’s edit Megatron.txt on the Master… then compare the WMIC output again:
Node: SPAT2K3 - 1 Instances of DfsrIdRecordInfo
|
INSTANCE. | |
|
Property Name |
Value |
|
Attributes |
32 . |
|
Clock |
20070720182219.078819-000. |
|
CreateTime |
20070720180138.118791-000. |
|
Fence |
3. |
|
Fid |
23080948090276543 . |
|
FileHash |
0000000000000000 0000000000000000. |
|
FileName |
Megatron.txt. |
|
Flags |
5 . |
|
GVsn |
{015A0FFE-D3A0-4CD5-B582-74E913C70C49}-v283. |
|
Index |
45 . |
|
ParentUid |
{B6801173-5A2D-4EBC-948A-1103293A21D8}-v1. |
|
ReplicatedFolderGuid |
B6801173-5A2D-4EBC-948A-1103293A21D8. |
|
Uid |
{015A0FFE-D3A0-4CD5-B582-74E913C70C49}-v276. |
|
UpdateTime |
20070720182219.078819-000. |
|
Usn |
15381176. |
|
Volume |
\\.\C:. |
|
. | |
The GVsn changed from v277 to v283 – delta 6
The USN (Update Sequence Number) changed from 15373960 to 15381176 - delta 7216
So… the GVsn’s map to the following ( had via the VolumeInfo )
Master ( spat2k3) - 015A0FFE-D3A0-4CD5-B582-74E913C70C49
2nd tier ( spatsoftgrid ) - 028966E5-9B4F-47F2-8063-3DB47322CB69
3rd tier ( 2k3entspat ) - 60988F39-0028-4A1F-AB9C-A1B9556C89C1
Now, when DFSR updates are sent from an upstream partner to his downstream partner he creates a session and does a “join”. The upstream partner uses the version vectors to determine which updates to send to the downstream partner. The downstream partner then processes each update in a session determining whether to install the file data, delete resources, or if the update is subsumed by local content.
Here are the current Version Vectors for Megatron.txt on each server:
Master:
{60988F39-0028-4A1F-AB9C-A1B9556C89C1} |-> (9, 75] {028966E5-9B4F-47F2-8063-3DB47322CB69} |-> (9, 33] {015A0FFE-D3A0-4CD5-B582-74E913C70C49} |-> (9, 284]
2nd Tier:
{60988F39-0028-4A1F-AB9C-A1B9556C89C1} |-> (9, 75] {028966E5-9B4F-47F2-8063-3DB47322CB69} |-> (9, 49] {015A0FFE-D3A0-4CD5-B582-74E913C70C49} |-> (9, 284]
3rd Tier:
{60988F39-0028-4A1F-AB9C-A1B9556C89C1} |-> (9, 131] {028966E5-9B4F-47F2-8063-3DB47322CB69} |-> (9, 49] {015A0FFE-D3A0-4CD5-B582-74E913C70C49} |-> (9, 284]
Here is how to get that info…
C:\>wmic /namespace:\\root\microsoftdfs path DfsrReplicatedFolderInfo where ReplicatedFolderGuid="B6801173-5A2D-4EBC-948A-1103293A21D8" call getVersionVector
Executing (\\SPATSOFTGRID\root\microsoftdfs:DfsrReplicatedFolderInfo.ReplicatedFolderGuid="B6801173-5A2D-4EBC-948A-1103293A21D8")->getVersionVector()
Method execution successful.
Out Parameters:
instance of __PARAMETERS
{
ReturnValue = 0;
VersionVector = "{60988F39-0028-4A1F-AB9C-A1B9556C89C1} |-> (9, 75] {028966E5-9B4F-47F2-8063-3DB47322CB69} |-> (9, 49] {015A0FFE-D3A0-4CD5-B582-74E913C70C49} |-> (9, 284] ";
};
Now – if we make a change on the megatron.txt..
Node: SPAT2K3 - 1 Instances of DfsrIdRecordInfo
|
INSTANCE. | |
|
Property Name |
Value |
|
Attributes |
32 . |
|
Clock |
20070720231800.502787-000. |
|
CreateTime |
20070720180138.118791-000. |
|
Fence |
3. |
|
Fid |
23080948090276543 . |
|
FileHash |
0000000000000000 0000000000000000. |
|
FileName |
Megatron.txt. |
|
Flags |
5 . |
|
GVsn |
{015A0FFE-D3A0-4CD5-B582-74E913C70C49}-v286. |
|
Index |
45 . |
|
ParentUid |
{B6801173-5A2D-4EBC-948A-1103293A21D8}-v1. |
|
ReplicatedFolderGuid |
B6801173-5A2D-4EBC-948A-1103293A21D8. |
|
Uid |
{015A0FFE-D3A0-4CD5-B582-74E913C70C49}-v276. |
|
UpdateTime |
20070720231800.534036-000. |
|
Usn |
15431416. |
|
Volume |
\\.\C:. |
|
. | |
The VersionVector changes for the Master:
This is take on 2nd tier:
{60988F39-0028-4A1F-AB9C-A1B9556C89C1} |-> (9, 75] {028966E5-9B4F-47F2-8063-3DB47322CB69} |-> (9, 33]015A0FFE-D3A0-4CD5-B582-74E913C70C49} |-> (9, 286] ( used to be 284 )
So the GVsn Version info was v284
The previous VV info was 284
The new GVsn Version info is v286
The new VV info is 286
To just see how that works out during the downstream join - here are the 2nd tier DFSR logs:
20070720 16:16:43.100 2160 INCO 2947 InConnection::ReceiveVvUp Received VvUp connId:{2A0817CF-42C0-4EBC-B9D7-691E445D3234} csId:{B6801173-5A2D-4EBC-948A-1103293A21D8} csName:link1 vvUp:
{60988F39-0028-4A1F-AB9C-A1B9556C89C1} |-> { 10..75}
+ {028966E5-9B4F-47F2-8063-3DB47322CB69} |-> { 10..33}
+ {015A0FFE-D3A0-4CD5-B582-74E913C70C49} |-> { 10..285}
+
20070720 16:16:43.100 1488 INCO 3347 InConnection::RequestUpdates Requesting updates. credits:32 connId:{2A0817CF-42C0-4EBC-B9D7-691E445D3234} csId:{B6801173-5A2D-4EBC-948A-1103293A21D8} csName:link1
requestType:all cursor:{00000000-0000-0000-0000-000000000000}-v0 delta::{015A0FFE-D3A0-4CD5-B582-74E913C70C49} |-> { 285}
+
20070720 16:16:43.116 2160 INCO 3597 InConnection::ReceiveUpdates Received: uid:{015A0FFE-D3A0-4CD5-B582-74E913C70C49}-v276 gvsn:{015A0FFE-D3A0-4CD5-B582-74E913C70C49}-v285 fileName:Megatron.txt session:39 connId:{2A0817CF-42C0-4EBC-B9D7-691E445D3234} csId:{B6801173-5A2D-4EBC-948A-1103293A21D8} csName:link1
20070720 16:16:43.132 2764 MEET 1898 Meet::Download Download Succeeded : true updateName:Megatron.txt uid:{015A0FFE-D3A0-4CD5-B582-74E913C70C49}-v276 gvsn:{015A0FFE-D3A0-4CD5-B582-74E913C70C49}-v285 connId:{2A0817CF-42C0-4EBC-B9D7-691E445D3234} csName:link1 csId:{B6801173-5A2D-4EBC-948A-1103293A21D8}
20070720 16:16:43.132 2764 MEET 2166 Meet::InstallRename Move out previous version of same file updateName:Megatron.txt uid:{015A0FFE-D3A0-4CD5-B582-74E913C70C49}-v276 gvsn:{015A0FFE-D3A0-4CD5-B582-74E913C70C49}-v285 connId:{2A0817CF-42C0-4EBC-B9D7-691E445D3234} csName:link1
20070720 16:16:43.132 2764 MEET 3699 Meet::MoveOut Moving contents and children out of replica. newName:Megatron.txt-{015A0FFE-D3A0-4CD5-B582-74E913C70C49}-v284 updateName:Megatron.txt uid:{015A0FFE-D3A0-4CD5-B582-74E913C70C49}-v276 gvsn:{015A0FFE-D3A0-4CD5-B582-74E913C70C49}-v285 connId:{2A0817CF-42C0-4EBC-B9D7-691E445D3234} csName:link1record:
+ fid 0x3000000005F39
+ usn 0x27607a0
+ uidVisible 1
+ filtered 0
+ journalWrapped 0
+ slowRecoverCheck 0
+ pendingTombstone 0
+ recUpdateTime 20070720 22:06:23.485 GMT
+ present 1
+ nameConflict 0
+ attributes 0x20
+ gvsn {015A0FFE-D3A0-4CD5-B582-74E913C70C49}-v284
+ uid {015A0FFE-D3A0-4CD5-B582-74E913C70C49}-v276
+ parent {B6801173-5A2D-4EBC-948A-1103293A21D8}-v1
+ fence 16010101 00:00:00.000
+ clock 20070720 22:06:22.882
+ createTime 20070720 18:01:38.118 GMT
+ csId {B6801173-5A2D-4EBC-948A-1103293A21D8}
+ hash 79BD9394-5E6FFD1A-CC95E90B-297FF259
+ similarity 00000000-00000000-00000000-00000000
+ name Megatron.txt
+
20070720 16:16:43.132 2764 MEET 3740 Meet::MoveOut Purge existing file in Deleted updateName:Megatron.txt uid:{015A0FFE-D3A0-4CD5-B582-74E913C70C49}-v276 gvsn:{015A0FFE-D3A0-4CD5-B582-74E913C70C49}-v285 connId:{2A0817CF-42C0-4EBC-B9D7-691E445D3234} csName:link1
20070720 16:16:43.132 2764 MEET 3746 Meet::MoveOut RenameDelete file fid:0x3000000005F39 updateName:Megatron.txt uid:{015A0FFE-D3A0-4CD5-B582-74E913C70C49}-v276 gvsn:{015A0FFE-D3A0-4CD5-B582-74E913C70C49}-v285 connId:{2A0817CF-42C0-4EBC-B9D7-691E445D3234} csName:link1
20070720 16:16:43.132 2764 MEET 2190 Meet::InstallRename File moved. rootVolume:{894F2A05-FA61-11DB-B170-806E6F6E6963} parentFid:0x80000000011AA fidInInstalling:0x3000000005F3D usn:0x2763590 updateName:Megatron.txt uid:{015A0FFE-D3A0-4CD5-B582-74E913C70C49}-v276 gvsn:{015A0FFE-D3A0-4CD5-B582-74E913C70C49}-v285 connId:{2A0817CF-42C0-4EBC-B9D7-691E445D3234} csName:link1
20070720 16:16:43.132 2764 LDBX 3665 Ldb::Update Updating idRecord:
+ fid 0x3000000005F3D
+ usn 0x2763590
+ uidVisible 1
+ filtered 0
+ journalWrapped 0
+ slowRecoverCheck 0
+ pendingTombstone 0
+ recUpdateTime 16010101 00:00:00.000 GMT
+ present 1
+ nameConflict 0
+ attributes 0x20
+ gvsn {015A0FFE-D3A0-4CD5-B582-74E913C70C49}-v285
+ uid {015A0FFE-D3A0-4CD5-B582-74E913C70C49}-v276
+ parent {B6801173-5A2D-4EBC-948A-1103293A21D8}-v1
+ fence 16010101 00:00:00.000
+ clock 20070720 23:16:42.771
+ createTime 20070720 18:01:38.118 GMT
+ csId {B6801173-5A2D-4EBC-948A-1103293A21D8}
+ hash D8D12DCF-2EEAEDE9-AFA285EC-E63DC679
+ similarity 00000000-00000000-00000000-00000000
+ name Megatron.txt
+
20070720 16:16:43.132 2764 MEET 2233 Meet::InstallRename -> DONE Install-rename completed updateName:Megatron.txt uid:{015A0FFE-D3A0-4CD5-B582-74E913C70C49}-v276 gvsn:{015A0FFE-D3A0-4CD5-B582-74E913C70C49}-v285 connId:{2A0817CF-42C0-4EBC-B9D7-691E445D3234} csName:link1 csId:{B6801173-5A2D-4EBC-948A-1103293A21D8}
NOTE:
There were some timing issues when I gathered this data so you see it fluctuates between 284 and 285 – not 100% sure what went on there.
Anyway… when we edit it on the NON master – the 2nd tier. It will replicate down to 3rd tier but had no way of getting back up.
IMPORTANT: Per MSDN – we will see the GVsn data change because the database GUID uniquely identifies the last computer that the resource was modified on.
So now – after the change on 2nd tier -=-the GVsn data for megatron.txt looks like:
Master - {015A0FFE-D3A0-4CD5-B582-74E913C70C49}-v286.
2nd Tier - {028966E5-9B4F-47F2-8063-3DB47322CB69}-v50.
3rd Tier - {028966E5-9B4F-47F2-8063-3DB47322CB69}-v50.
You see that the GVsn data for the file matches on 2nd and 3rd tier – but not on the Master since it had no way of getting back up to the server.
Now take a deletion from the Master:
Delete the file megatron.txt on the master.
( This is the deletion change USN on the Master )
GVsn = {015A0FFE-D3A0-4CD5-B582-74E913C70C49}-v287
VVinfo = {60988F39-0028-4A1F-AB9C-A1B9556C89C1} |-> (9, 75] {028966E5-9B4F-47F2-8063-3DB47322CB69} |-> (9, 33] {015A0FFE-D3A0-4CD5-B582-74E913C70C49} |-> (9, 287]
VVinfo on the 2nd tier "{60988F39-0028-4A1F-AB9C-A1B9556C89C1} |-> (9, 75] {028966E5-9B4F-47F2-8063-3DB47322CB69} |-> (9, 51] {015A0FFE-D3A0-4CD5-B582-74E913C70C49} |-> (9, 287]
20070720 16:40:23.211 1436 INCO 2947 InConnection::ReceiveVvUp Received VvUp connId:{2A0817CF-42C0-4EBC-B9D7-691E445D3234} csId:{
B6801173-5A2D-4EBC-948A-1103293A21D8} csName:link1 vvUp:
{60988F39-0028-4A1F-AB9C-A1B9556C89C1} |-> { 10..75}
+ {028966E5-9B4F-47F2-8063-3DB47322CB69} |-> { 10..33}
+ {015A0FFE-D3A0-4CD5-B582-74E913C70C49} |-> { 10..287}
+
20070720 16:40:23.211 4008 INCO 3347 InConnection::RequestUpdates Requesting updates. credits:32 connId:{2A0817CF-42C0-4EBC-B9D7-691E445D3234} csId:{B6801173-5A2D-4EBC-948A-1103293A21D8} csName:link1 requestType:all cursor:{00000000-0000-0000-0000-000000000000}-v0 delta::{015A0FFE-D3A0-4CD5-B582-74E913C70C49} |-> { 287}
+
20070720 16:40:23.242 2764 MEET 4365 Meet::LocalDominates Conflicting gvsn:{028966E5-9B4F-47F2-8063-3DB47322CB69}-v50 updateName:Megatron.txt uid:{015A0FFE-D3A0-4CD5-B582-74E913C70C49}-v276 gvsn:{015A0FFE-D3A0-4CD5-B582-74E913C70C49}-v287 connId:{2A0817CF-42C0-4EBC-B9D7-691E445D3234} csName:link1
20070720 16:40:23.242 2764 MEET 4982 Meet::ReAnimate Local uidRelated has a version unknown to upstreamuidRelatedUid:{015A0FFE-D3A0-4CD5-B582-74E913C70C49}-v276 uidRelatedGvsn:{028966E5-9B4F-47F2-8063-3DB47322CB69}-v50 updateName:Megatron.txt uid:{015A0FFE-D3A0-4CD5-B582-74E913C70C49}-v276 gvsn:{015A0FFE-D3A0-4CD5-B582-74E913C70C49}-v287 connId:{2A0817CF-42C0-4EBC-B9D7-691E445D3234} csName:link1
So then we reanimate and net effect is that the file is not deleted on the 2nd or 3rd tier servers.
Hrmm reading through this post it is a little long winded.. I tried to have JakeBerm rewrite it to read better but its still a tough read. Sorry.
The best way to plow through this and really get something out of it is to just set it up and play with it yourself…
Spatdsg