我们正在构建一个由 Azure 存储支持的站点。一个辅助角色有一些在启动时从 blob 下载的文件。文件一旦存储就不会被修改,我们只是将它们拉下来并使用它们。
有时,当尝试从开发存储下载这些文件时,存储模拟器服务会返回 500 错误。我们可以列出 blob 中的文件并获取元数据,但不能下载文件本身。我们找到的唯一解决方案是删除 blob 并重新上传。
还有其他人遇到过这种情况吗?
更新:1.7 SDK
最佳答案
可能的解决方案(解决方法)
- 退出存储模拟器;
- 打开管理 Sql Server Management Studio 2012;
- 附加
C:\Users\<username>\DevelopmentStorageDb201206.mdf
文件(其中<username>
是受影响用户的名称); - 如果不允许附加,请将 mdf 和日志文件复制到其他驱动器然后附加,否则您可以访问 LocalDB (
(localdb)\v11.0
); - 查找存储过程
CommitBlockList
; - 更改
SET UncommittedBlockIdLength = NULL
至SET UncommittedBlockIdLength = 0
; - 执行它;
- 关闭 Management Studio;
- 将这些已编辑的 mdf、日志文件复制到原始位置;
- 启动存储模拟器;
我是如何到达那里的
我发现大约每 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 个小时;)
关于azure - 神秘消失的Azure开发存储 Assets ,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/11252499/