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

Question

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

有时，当尝试从开发存储下载这些文件时，Storage Emulator 服务会返回 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. 关闭管理工作室；
9. 将这些编辑过的 mdf、日志文件复制到原始位置；
10. 启动存储模拟器；

我是怎么到那里的

我发现大约每 7 天只有一次 BLOCK Blob 被删除。
在开发/测试过程中，为了测试目的再次创建这些 blob 是很痛苦的。
试图找到存储模拟器源代码，但找不到。 通过添加以下内容
打开登录C:\Users\<username>\AppData\Local\DevelopmentStorageDevelopmentStorage.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，目录 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：加载间隔失败。IsGC：是的，Microsoft.WindowsAzure.DevelopmentStorage.Store.BlockBlobGarbageCollector.GetTimerIntervalOrDefault（Boolean isGC）的 System.Number.ParseDouble（字符串值，NumberStyles 选项，NumberFormatInfo numfmt）异常

因此，对于 BlockBlob，未提交的块由该 BlockBlobGarbageCollector 进行垃圾收集。我无法找到这些未提交的块被垃圾收集的频率。我认为即使这也不会导致问题。

另一个日志：

BlockBlob：检查有效目录列表中的目录 C:\Users\username\AppData\Local\DevelopmentStorage\LDB\BlockBlobRoot\1\0477877c-4cb3-4ddb-a035-14a5cf52d86f
BlockBlob：删除目录 C:\Users\username\AppData \Local\DevelopmentStorage\LDB\BlockBlobRoot\1\0477877c-4cb3-4ddb-a035-14a5cf52d86f

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

检查数据库的架构DevelopmentStorageDb201206。发现几个列，如IsCommitted和UncommittedBlockIdLength。发现ClearUncommittedBlocks设置UncommittedBlockIdLength为null. 任何未被删除的 Blob 的UncommittedBlockIdLength值为 0。因此检查存储过程CommitBlockList并更改UncommittedBlockIdLength为 0 而不是null. 我认为以前版本中的模拟器必须检查IsCommitted并UncommittedBlockIdLength确定有效的块 blob 目录，而在这个版本中，它可能只检查UncommittedBlockIdLength并null删除所有这些块 blob 文件。

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

如果这是一种可行的解决方法，...微软欠我 6 小时；）

Answer 2

我没有解决方案，但我可以补充一点，当存储模拟器的后备存储是 SQL Server 2012 时，也会发生这种行为。我们已经多次看到这种情况。一切都很好，然后斑点消失了。我们的经验是，所有或几乎所有 blob 从文件系统中消失，而数据库引用仍然存在。不知道为什么会发生这种情况——没有明显的诱发事件。

Answer 3

我遇到了同样的问题。我怀疑 Azure 存储模拟器在 LocalDB 上运行时出现问题。原因如下：

• 当您遇到 500 错误时，使用 Management Studio 或 Server Explorer 打开 Blob 表，并找到有问题的 blob 的 DirectoryPath 字段的值（类似于 c:\users\username\appdata\local\developmentstorage\ldb\blockblobroot\1 \305469d0-7b68-4b1e-a41a-a429c21b6b9d

• 使用资源管理器导航到该路径并注意该目录为空

• 现在重新上传您的文件并导航到它上传到的新目录，注意有您的文件

那么，现在的问题是为什么 blob 文件会消失？

Answer 4

我还看到存储模拟器偶尔会返回有效请求。但通常重试请求会正常工作。始终建议重试失败的请求，除非响应表明请求无效（在这种情况下重试无论如何都不起作用）。即使您使用云存储，偶尔也可能会遇到临时网络不可用等问题。事实上，对于所有与网络相关的操作，都建议使用重试策略。

此外，如果您使用 .NET 存储客户端库，则可以利用内置的重试策略：http: //blogs.msdn.com/b/windowsazurestorage/archive/2011/02/03/overview-of -retry-policies-in-the-windows-azure-storage-client-library.aspx。

此致，

明旭。

Answer 5

也许解决这个问题的更简单的方法是升级到 Azure SDK 1.8——因为我已经从 1.7（大约两周前从 2012 年 11 月 23 日开始）升级，我的 blob 不再消失。

即使决定使用旧库，您也可以利用新的存储模拟器 - 实际上这些库是并排安装的，只有模拟器被升级（即新版本替换旧版本）但它们仍然与旧版本兼容版本。例如，我现在正在使用新的存储模拟器，但我仍然在我的 .NET 项目中引用 1.7 库。

更新 2013 年 8 月 30 日 18:00 UTC我在 Azure SDK 2.0 上再次遇到了这个问题——现在我写了几个星期的 blob，几分钟后我在访问它们时得到了 HTTP 500。我想知道这种行为是否是由我的存储模拟器的某些特性（例如太多的 blob 和/或容器）触发的——在这方面我想补充一点，我通过重命名数据库文件从存储模拟器 1.8 升级自架构（与 Visual Studio 相比）似乎是相同的，但也许我错过了一些重要的东西。

我现在正在评估是否升级到 Azure SDK 2.1 并希望这个问题得到修复或切换到使用真实存储帐户进行开发。

更新 2013-09-02 18:00 UTC我决定使用真实的存储帐户，原因如下：

• 通过 Azure SDK 更新维护存储数据的能力——存储模拟器通常会更改数据库的架构或位置，而在发行说明中没有任何注释，从而强制进行一些手动迁移；
• 能够使用 Azure 存储的所有功能，而不必担心生产和存储模拟器之间的差异（正如 Richard Astbury 在他的评论中所说）；
• 避免 SQL Server 实现特有的性能和维护问题（对我来说这是一个意外的复杂性）。