Spat's WebLog (Steve Patrick)

When things go wrong...

Why not to use DFSR one way replication....

Why not to use DFSR one way replication....

  • Comments 2

 

 

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

 

 

 

 

 

 

 

 

 

 

Leave a Comment
  • Please add 7 and 2 and type the answer here:
  • Post
Page 1 of 1 (2 items)