azure - 神秘消失的Azure开发存储 Assets

Question

我们正在构建一个由 Azure 存储支持的站点。一个辅助角色有一些在启动时从 blob 下载的文件。文件一旦存储就不会被修改，我们只是将它们拉下来并使用它们。

有时，当尝试从开发存储下载这些文件时，存储模拟器服务会返回 500 错误。我们可以列出 blob 中的文件并获取元数据，但不能下载文件本身。我们找到的唯一解决方案是删除 blob 并重新上传。

还有其他人遇到过这种情况吗？

更新:1.7 SDK

Answer 1

可能的解决方案(解决方法)

1. 退出存储模拟器；
2. 打开管理 Sql Server Management Studio 2012；
3. 附加C:\Users\<username>\DevelopmentStorageDb201206.mdf文件(其中 <username> 是受影响用户的名称)；
4. 如果不允许附加，请将 mdf 和日志文件复制到其他驱动器然后附加，否则您可以访问 LocalDB ( (localdb)\v11.0 );
5. 查找存储过程 CommitBlockList ;
6. 更改SET UncommittedBlockIdLength = NULL至SET UncommittedBlockIdLength = 0 ;
7. 执行它；
8. 关闭 Management Studio；
9. 将这些已编辑的 mdf、日志文件复制到原始位置；
10. 启动存储模拟器；

我是如何到达那里的

我发现大约每 7 天只有 BLOCK blob 被删除。
在开发/测试过程中，出于测试目的再次创建这些 blob 是很痛苦的。
尝试查找存储模拟器源代码但找不到。
打开日志记录 C:\Users\<username>\AppData\Local\DevelopmentStorage将以下内容添加到 DevelopmentStorage.201206.config

<LogPath>C:\Users\<username>\AppData\Local\DevelopmentStorage\Logs</LogPath>  
<LoggingEnabled>true</LoggingEnabled>  

经过痛苦的等待，在日志中发现以下内容:

DefragmentBlobFiles BlobInfo Name 40f5e12f-65a5-4a3a-ae46-41c71c8514c0/file1.txt, ContainerName storage1, Directory c:\users\username\appdata\local\developmentstorage\ldb\blockblobroot\1\12735b4b-f9ed-481b-a091-78387facf05b, ROFile , RWFile c:\users\username\appdata\local\developmentstorage\ldb\blockblobroot\1\12735b4b-f9ed-481b-a091-78387facf05b\1, Size5

我认为上述碎片整理不会造成任何问题。
发现另一条日志:

BlockBlob: Load Interval failed. IsGC: True, Exception at System.Number.ParseDouble(String value, NumberStyles options, NumberFormatInfo numfmt) at Microsoft.WindowsAzure.DevelopmentStorage.Store.BlockBlobGarbageCollector.GetTimerIntervalOrDefault(Boolean isGC)

因此，对于 BlockBlob，未提交的 block 将由该 BlockBlobGarbageCollector 进行垃圾收集。我在任何地方都找不到垃圾收集这些未提交 block 的频率。我认为这也不是造成问题的原因。

另一个日志:

BlockBlob: Checking Directory C:\Users\username\AppData\Local\DevelopmentStorage\LDB\BlockBlobRoot\1\0477877c-4cb3-4ddb-a035-14a5cf52d86f in the list of valid directories
BlockBlob: Deleting Directory C:\Users\username\AppData\Local\DevelopmentStorage\LDB\BlockBlobRoot\1\0477877c-4cb3-4ddb-a035-14a5cf52d86f

上面的日志显示了问题。模拟器必须确定有效的 blockblob 目录。

检查数据库架构DevelopmentStorageDb201206 。找到了一些类似 IsCommitted 的列和UncommittedBlockIdLength 。发现ClearUncommittedBlocks正在设置UncommittedBlockIdLength至null 。任何未被删除的 Blob 都具有 UncommittedBlockIdLength值0。所以检查存储过程CommitBlockList并更改UncommittedBlockIdLength为 0 而不是 null 。我认为以前版本的模拟器必须检查 IsCommitted和UncommittedBlockIdLength两者都是为了确定有效的 blockblob 目录，而在此版本中它可能仅检查 UncommittedBlockIdLength如null并删除所有这些 block blob 文件。

正如我所说，大约需要 7 天的时间才能确定该解决方案是否永久修复了该问题。我还有 4 天时间来验证它。

如果这是一种有效的解决方法，...Microsoft 欠我 6 个小时；)