Azure Storage を基盤とするサイトを構築しています。1 つのワーカー ロールには、起動時に BLOB からダウンロードするいくつかのファイルがあります。ファイルがストレージに保存されると、ファイルが変更されることはありません。ファイルをプルダウンして使用するだけです。
これらのファイルを開発ストレージからダウンロードしようとすると、ストレージ エミュレーター サービスが 500 エラーを返すことがあります。BLOB 内のファイルを一覧表示してメタデータを取得することはできますが、ファイル自体をダウンロードすることはできません。私たちが見つけた唯一の解決策は、ブロブを削除して再アップロードすることです。
他の誰かがこれに遭遇しましたか？
更新: 1.7 SDK
C:\Users\<username>\DevelopmentStorageDb201206.mdfファイルを添付(<username>は影響を受けるユーザーの名前);(localdb)\v11.0) にアクセスできます。CommitBlockList。SET UncommittedBlockIdLength = NULLしSET UncommittedBlockIdLength = 0ます。約 7 日ごとに BLOCK BLOB のみが削除されていることがわかりました。
テスト目的でこれらのブロブを再度作成することは、開発/テストの途中で苦痛でした。
ストレージ エミュレーターのソース コードを検索しようとしましたが、見つかりませんでした。
以下を追加
して、でのロギングを有効にしましたC:\Users\<username>\AppData\Local\DevelopmentStorageDevelopmentStorage.201206.config
<LogPath>C:\Users\<username>\AppData\Local\DevelopmentStorage\Logs</LogPath>
<LoggingEnabled>true</LoggingEnabled>
苦労して待った後、次のログが見つかりました:
DefragmentBlobFiles BlobInfo 名 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: True、Microsoft.WindowsAzure.DevelopmentStorage.Store.BlockBlobGarbageCollector.GetTimerIntervalOrDefault(Boolean isGC) での System.Number.ParseDouble(String 値、NumberStyles オプション、NumberFormatInfo numfmt) での例外
したがって、BlockBlobs の場合、コミットされていないブロックは、この 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 でした。そのため、ストアド プロシージャをチェックし、.ではなく 0 にCommitBlockList変更しました。以前のバージョンのエミュレーターは、有効なブロック blob ディレクトリを決定するために両方をチェックする必要があると思いますが、このバージョンでは、それらのブロック blob ファイルのみをチェックして削除する可能性があります。UncommittedBlockIdLengthnullIsCommittedUncommittedBlockIdLengthUncommittedBlockIdLengthnull
私が言ったように、このソリューションが完全に修正されるかどうかを確認するには、約 7 日かかります。検証まであと4日あります。
これが機能する回避策である場合、... Microsoft は私に 6 時間の猶予を与えています;)
私は同じ問題に遭遇しました。Azure ストレージ エミュレーターを LocalDB 上で実行すると、何か問題があるのではないかと思います。理由は次のとおりです。
500 エラーが発生したら、Management Studio またはサーバー エクスプローラーを使用して BLOB テーブルを開き、問題の BLOB の DirectoryPath フィールドの値を見つけます (c:\users\username\appdata\local\developmentstorage\ldb\blockblobroot\1 のようなものになります)。 \305469d0-7b68-4b1e-a41a-a429c21b6b9d
エクスプローラーを使用してそのパスに移動し、このディレクトリが空であることを確認します
ファイルを再アップロードし、アップロード先の新しいディレクトリに移動します。ファイルがあることに注意してください
では、ここで問題になるのは、なぜ blob ファイルが消えるのかということです。
解決策はありませんが、ストレージ エミュレーターのバッキング ストアが SQL Server 2012 の場合にもこの動作が発生することを付け加えておきます。しばらくはすべて問題ありませんが、ブロブは消えます。私たちの経験では、データベース参照が存続している間、すべてまたはほぼすべての BLOB がファイル システムから消えます。なぜこれが起こるのか手がかりはありません - 明らかな原因となるイベントはありません。
おそらく、この問題を解決するより簡単な方法は、Azure SDK 1.8 にアップグレードすることです。1.7 から (2012 年 11 月 23 日から、約 2 週間前に) アップグレードしたため、ブロブが消えなくなりました。
古いライブラリを使用することにした場合でも、新しいストレージ エミュレーターを利用できます。実際、ライブラリーは並行してインストールされ、エミュレーターのみがアップグレードされます (つまり、新しいバージョンが古いライブラリーを置き換えます) が、古いものと互換性があります。バージョン。たとえば、現在新しいストレージ エミュレーターを使用していますが、.NET プロジェクトではまだ 1.7 ライブラリを参照しています。
更新 2013-08-30 18:00 UTC Azure SDK 2.0 でこの問題が再び発生しました。ここ数週間、ブロブを作成し、数分後にそれらにアクセスすると HTTP 500 が発生します。この動作は、ストレージ エミュレーターのいくつかの特性 (たとえば、BLOB やコンテナーが多すぎるなど) によって引き起こされるのではないかと思います。 Visual Studio と比較して) 同じように見えましたが、何か重要なことを見逃していたのかもしれません。
現在、Azure SDK 2.1 にアップグレードするかどうかを評価しており、この問題が修正されるか、開発に実際のストレージ アカウントを使用するように切り替えることを願っています。
Update 2013-09-02 18:00 UTC次の理由から、実ストレージ アカウントを使用することにしました。
また、ストレージ エミュレーターが有効な要求に対して時折返されることも確認しました。ただし、通常はリクエストを再試行すると正常に機能します。応答が要求が無効であることを示していない限り、失敗した要求を再試行することを常にお勧めします (無効な場合、再試行は機能しません)。クラウド ストレージを使用していても、一時的にネットワークが利用できないなどの問題が発生することがあります。実際のところ、再試行ポリシーは、すべてのネットワーク関連操作に推奨されます。
さらに、.NET ストレージ クライアント ライブラリを使用すると、組み込みの再試行ポリシーを利用できます: http://blogs.msdn.com/b/windowsazurestorage/archive/2011/02/03/overview-of -retry-policies-in-the-windows-azure-storage-client-library.aspx .
よろしくお願いします、
明徐。