C# RavenDB-复制、WaitAsync和不同的电子标签

我正在尝试对

RavenDB

实现适当的负载平衡。我正在使用2台ravendb服务器。我使用的是

RavenDB

版本

3.0

这是我的代码（看起来像是因为我需要同步该操作）：

不幸的是，我得到了一个错误：

发生了一个或多个错误。->只能确认指定的 Etag 01000000-0000-0095-0000-000000 115E65已复制到1的0 00:01:00.0087214之后的服务器详细信息：Url:my second box Url，Etag: FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFF

当我转到raven Box时，我可以看到文档已被复制，但它有不同的电子标签。我想这可能是它找不到它的原因

我也做了一个简单的测试。我在其中一个盒子上使用了

ravendbstudio

界面和更新的文档，它被快速复制，但电子标签不同。我想我不知怎么地错过了电子标签和复制的概念

是否有任何设置可在复制过程中保留源电子标签

---

编辑：

添加了fiddler输出：

curl -k -i --raw -o 0.dat "http://SOURCE_IP_ADDRESS:8080/databases/DATABASE_NAME/replication/topology" -H "Raven-Client-Version: 3.0.0.0" -H "Accept-Encoding: gzip" -H "Host: SOURCE_IP_ADDRESS:8080" -H "Connection: Keep-Alive"
curl -k -i --raw -o 1.dat "http://SOURCE_IP_ADDRESS:8080/docs?id=Raven%%2FDatabases%%2FDATABASE_NAME" -H "Raven-Client-Version: 3.0.0.0" -H "Accept-Encoding: gzip" -H "Host: SOURCE_IP_ADDRESS:8080" -H "Connection: Keep-Alive"
curl -k -i --raw -o 2.dat -X POST "http://SOURCE_IP_ADDRESS:8080/databases/DATABASE_NAME/bulk_docs" -H "Raven-Client-Version: 3.0.0.0" -H "Accept-Encoding: gzip" -H "Content-Type: application/json; charset=utf-8" -H "Content-Encoding: gzip" -H "Host: SOURCE_IP_ADDRESS:8080" -H "Transfer-Encoding: chunked" -H "Expect: 100-continue"
curl -k -i --raw -o 3.dat "http://SOURCE_IP_ADDRESS:8080/databases/DATABASE_NAME/replication/topology" -H "Raven-Client-Version: 3.0.0.0" -H "If-None-Match: \"01000000-0000-0001-0000-00000000A243\"" -H "Accept-Encoding: gzip" -H "Host: SOURCE_IP_ADDRESS:8080"
curl -k -i --raw -o 4.dat "http://SOURCE_IP_ADDRESS:8080/databases/DATABASE_NAME/stats" -H "Raven-Client-Version: 3.0.0.0" -H "Accept-Encoding: gzip" -H "Host: SOURCE_IP_ADDRESS:8080"
curl -k -i --raw -o 5.dat "http://TARGET_IP_ADDRESS:8080/databases/DATABASE_NAME/replication/lastEtag?from=http%%3A%%2F%%2FSOURCE_IP_ADDRESS%%3A8080%%2Fdatabases%%2FDATABASE_NAME&dbid=f570866b-4b62-48d5-aef1-97b2217cef16" -H "Raven-Client-Version: 3.0.0.0" -H "Accept-Encoding: gzip" -H "Host: TARGET_IP_ADDRESS:8080"
curl -k -i --raw -o 6.dat "http://TARGET_IP_ADDRESS:8080/databases/DATABASE_NAME/replication/lastEtag?from=http%%3A%%2F%%2FSOURCE_IP_ADDRESS%%3A8080%%2Fdatabases%%2FDATABASE_NAME&dbid=f570866b-4b62-48d5-aef1-97b2217cef16" -H "Raven-Client-Version: 3.0.0.0" -H "Accept-Encoding: gzip" -H "Host: TARGET_IP_ADDRESS:8080"
curl -k -i --raw -o 7.dat "http://TARGET_IP_ADDRESS:8080/databases/DATABASE_NAME/replication/lastEtag?from=http%%3A%%2F%%2FSOURCE_IP_ADDRESS%%3A8080%%2Fdatabases%%2FDATABASE_NAME&dbid=f570866b-4b62-48d5-aef1-97b2217cef16" -H "Raven-Client-Version: 3.0.0.0" -H "Accept-Encoding: gzip" -H "Host: TARGET_IP_ADDRESS:8080"
curl -k -i --raw -o 8.dat "http://TARGET_IP_ADDRESS:8080/databases/DATABASE_NAME/replication/lastEtag?from=http%%3A%%2F%%2FSOURCE_IP_ADDRESS%%3A8080%%2Fdatabases%%2FDATABASE_NAME&dbid=f570866b-4b62-48d5-aef1-97b2217cef16" -H "Raven-Client-Version: 3.0.0.0" -H "Accept-Encoding: gzip" -H "Host: TARGET_IP_ADDRESS:8080"
curl -k -i --raw -o 9.dat "http://TARGET_IP_ADDRESS:8080/databases/DATABASE_NAME/replication/lastEtag?from=http%%3A%%2F%%2FSOURCE_IP_ADDRESS%%3A8080%%2Fdatabases%%2FDATABASE_NAME&dbid=f570866b-4b62-48d5-aef1-97b2217cef16" -H "Raven-Client-Version: 3.0.0.0" -H "Accept-Encoding: gzip" -H "Host: TARGET_IP_ADDRESS:8080"
curl -k -i --raw -o 10.dat "http://TARGET_IP_ADDRESS:8080/databases/DATABASE_NAME/replication/lastEtag?from=http%%3A%%2F%%2FSOURCE_IP_ADDRESS%%3A8080%%2Fdatabases%%2FDATABASE_NAME&dbid=f570866b-4b62-48d5-aef1-97b2217cef16" -H "Raven-Client-Version: 3.0.0.0" -H "Accept-Encoding: gzip" -H "Host: TARGET_IP_ADDRESS:8080"
curl -k -i --raw -o 11.dat "http://TARGET_IP_ADDRESS:8080/databases/DATABASE_NAME/replication/lastEtag?from=http%%3A%%2F%%2FSOURCE_IP_ADDRESS%%3A8080%%2Fdatabases%%2FDATABASE_NAME&dbid=f570866b-4b62-48d5-aef1-97b2217cef16" -H "Raven-Client-Version: 3.0.0.0" -H "Accept-Encoding: gzip" -H "Host: TARGET_IP_ADDRESS:8080"
curl -k -i --raw -o 12.dat "http://TARGET_IP_ADDRESS:8080/databases/DATABASE_NAME/replication/lastEtag?from=http%%3A%%2F%%2FSOURCE_IP_ADDRESS%%3A8080%%2Fdatabases%%2FDATABASE_NAME&dbid=f570866b-4b62-48d5-aef1-97b2217cef16" -H "Raven-Client-Version: 3.0.0.0" -H "Accept-Encoding: gzip" -H "Host: TARGET_IP_ADDRESS:8080"
curl -k -i --raw -o 13.dat "http://TARGET_IP_ADDRESS:8080/databases/DATABASE_NAME/replication/lastEtag?from=http%%3A%%2F%%2FSOURCE_IP_ADDRESS%%3A8080%%2Fdatabases%%2FDATABASE_NAME&dbid=f570866b-4b62-48d5-aef1-97b2217cef16" -H "Raven-Client-Version: 3.0.0.0" -H "Accept-Encoding: gzip" -H "Host: TARGET_IP_ADDRESS:8080"
curl -k -i --raw -o 14.dat "http://TARGET_IP_ADDRESS:8080/databases/DATABASE_NAME/replication/lastEtag?from=http%%3A%%2F%%2FSOURCE_IP_ADDRESS%%3A8080%%2Fdatabases%%2FDATABASE_NAME&dbid=f570866b-4b62-48d5-aef1-97b2217cef16" -H "Raven-Client-Version: 3.0.0.0" -H "Accept-Encoding: gzip" -H "Host: TARGET_IP_ADDRESS:8080"
curl -k -i --raw -o 15.dat "http://TARGET_IP_ADDRESS:8080/databases/DATABASE_NAME/replication/lastEtag?from=http%%3A%%2F%%2FSOURCE_IP_ADDRESS%%3A8080%%2Fdatabases%%2FDATABASE_NAME&dbid=f570866b-4b62-48d5-aef1-97b2217cef16" -H "Raven-Client-Version: 3.0.0.0" -H "Accept-Encoding: gzip" -H "Host: TARGET_IP_ADDRESS:8080"

最后一个请求会重复，直到崩溃，上面给出了一个例外

看起来etag请求的响应是：

{"MaxNumberOfItemsToReceiveInSingleBatch":null,"LastDocumentEtag":"FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF","LastAttachmentEtag":"FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF","ServerInstanceId":"26174fc9-74f5-410a-bef0-0f7cd844c481","Source":"http://SOURCE-RAVEN-SERVER:8080/databases/DATABASE-NAME","LastModified":"2017-02-06T09:05:32.8443655Z","LastBatchSize":1}

---

documentsEtag

的有效格式是什么？如果在保存更改后立即移动行，会发生什么情况？你在处理这个会议吗？请注意，

FFFF…

etag意味着无效的etag。当我调试通过时，它有来自异常的第一个值：01000000-0000-0095-0000-000000 115E65。我会尝试一下，在保存更改后立即将其移动，并在检查后尽快通知您。是的，我正在处理会话，我粘贴的代码在using语句中。我检查了您的建议，并在SaveChanges之后移动了etag行，行为完全相同。异常：只能确认指定的Etag 01000000-0000-0097-0000-0000000000 EA已在00:01:00.0123030之后复制到1台服务器中的0台。详细信息：Url:my Url，Etag:FFFFFFFF-FFFF-FFFFFFFF。异常第一部分的Etag与documentsEtag localvariable中的Etag相同。这里有点奇怪，它应该使用doc Etag。您能将fiddler输出发送到邮件列表吗？您指的是来自RavenDb盒或执行保存操作的客户端的fiddler吗？documentsEtag的有效值是多少？如果在保存更改后立即移动行，会发生什么情况？你在处理这个会议吗？请注意，

FFFF…

etag意味着无效的etag。当我调试通过时，它有来自异常的第一个值：01000000-0000-0095-0000-000000 115E65。我会尝试一下，在保存更改后立即将其移动，并在检查后尽快通知您。是的，我正在处理会话，我粘贴的代码在using语句中。我检查了您的建议，并在SaveChanges之后移动了etag行，行为完全相同。异常：只能确认指定的Etag 01000000-0000-0097-0000-0000000000 EA已在00:01:00.0123030之后复制到1台服务器中的0台。详细信息：Url:my Url，Etag:FFFFFFFF-FFFF-FFFFFFFF。异常第一部分的Etag与documentsEtag localvariable中的Etag相同。这里有点奇怪，它应该使用doc Etag。您能将fiddler输出发送到邮件列表吗？您是指来自RavenDb Box还是执行保存操作的客户端的fiddler？

{"MaxNumberOfItemsToReceiveInSingleBatch":null,"LastDocumentEtag":"FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF","LastAttachmentEtag":"FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF","ServerInstanceId":"26174fc9-74f5-410a-bef0-0f7cd844c481","Source":"http://SOURCE-RAVEN-SERVER:8080/databases/DATABASE-NAME","LastModified":"2017-02-06T09:05:32.8443655Z","LastBatchSize":1}