Het uploaden van blob- of blokinhoud mislukt in Azure Blob Storage
In dit artikel wordt beschreven hoe u fouten kunt oplossen die kunnen optreden wanneer u Microsoft Azure Blob Storage samen met uw cloudtoepassingen gebruikt om blob te uploaden of inhoud te blokkeren.
Vereisten
- Een opslagaccount van een van de volgende opslagservices:
- Azure Storage SDK
- Azure Storage Explorer
- PowerShell
Symptomen
U ontvangt een van de volgende foutberichten.
Foutcode | Foutbericht |
---|---|
BlockCountExceedsLimit |
"Het aantal niet-verzonden blokken mag de maximumlimiet van 100.000 blokken niet overschrijden." |
InvalidBlobOrBlock |
"De opgegeven blob- of blokinhoud is ongeldig." |
InvalidBlock of InvalidBlockList |
"De opgegeven lijst met blokkeringen is ongeldig." |
Oorzaak 1: De bloklengte die is opgegeven in de aanroep Put Block is niet geldig
De bloklengte die is opgegeven in de URI-aanvraag Put Block is om een of meer van de volgende redenen niet geldig:
De toepassing of client heeft een blokgrootte opgegeven die niet wordt ondersteund.
De grootte van het blok is groter dan de maximaal toegestane blokgrootte. Als u de limieten voor de blokgrootte wilt vinden voor verschillende versies van de Blob Service REST API, raadpleegt u de sectie Opmerkingen van het naslagartikel 'Put Block'.
Wanneer u probeerde blokken met gegevens te uploaden met behulp van meer dan één toepassing, waren er niet-verzonden blokken met inconsistente bloklengten. Deze situatie treedt op omdat verschillende toepassingen verschillende lengten gebruiken om gegevens te uploaden of omdat een vorige upload is mislukt.
De blob heeft te veel niet-verzonden blokken omdat een vorige uploadbewerking is geannuleerd. Het maximum aantal niet-verzonden blokken dat aan een blob kan worden gekoppeld, is 100.000.
Verwijder de niet-verzonden blokken door een van deze oplossingen te implementeren.
Oplossing 1: Wacht tot de garbagecollection de niet-verzonden gegevens heeft opgehaald
Wacht zeven dagen totdat de niet-verzonden bloklijst is opgeschoond door garbagecollection.
Oplossing 2: Een dummy-blob gebruiken om de gegevensoverdracht uit te voeren
Gebruik de Azure Storage SDK om de gegevens over te dragen met behulp van een dummy-blob. Ga hiervoor als volgt te werk:
Maak een dummy-blob die dezelfde blobnaam heeft en zich in dezelfde container bevindt. Deze blob kan een lengte van nul hebben.
Breng de blob over met behulp van een niet-blokkeringsoverdracht.
Oplossing 3: De lijst met niet-verzonden blokkeringen doorvoeren met behulp van de Azure Storage SDK
Gebruik de Azure Storage SDK om de lijst met niet-verzonden blokkeringen door te voeren en de blob op te schonen. Ga hiervoor als volgt te werk:
Haal de niet-verzonden blokkeringslijst op door een URI-aanvraag voor lijst met blokkeringen ophalen te maken waarin de
blocklisttype
URI-parameter is ingesteld opuncommitted
.Voer de blokkeringslijst door met behulp van de URI-aanvraag Put Block List .
Verwijder de blob.
De volgende PowerShell-functie is een voorbeeld van hoe u een niet-verzonden blokkeringslijst ophaalt en deze vervolgens verwijdert. Voor de functie zijn de volgende parameters vereist.
Parameternaam | Beschrijving |
---|---|
-StorageAccountName |
De naam van het opslagaccount. |
-SharedAccessSignature |
Een SAS-token (Shared Access Signature) dat gebruikmaakt van de URI-parameters <ss=b;srt=sco;sp=rwldc> . Deze parameters worden beschreven in Sas-URI van een account maken. |
-ContainerName |
De naam van de opslagcontainer. |
-BlobName |
De naam van de blob. |
[CmdletBinding()] Param(
[Parameter(Mandatory=$true, Position=1)] [string] $StorageAccountName,
[Parameter(Mandatory=$True, Position=1)] [string] $SharedAccessSignature,
[Parameter(Mandatory=$True, Position=1)] [string] $ContainerName,
[Parameter(Mandatory=$True, Position=1)] [string] $BlobName
)
# Build the URI strings in the REST API for GET and DELETE.
$uriDelete = (
"https://$StorageAccountName.blob.core.windows.net/",
"$ContainerName",
"/",
"$BlobName",
"$SharedAccessSignature"
) -Join ""
$uriGet = (
"$uriDelete",
"&comp=blocklist",
"&blocklisttype=uncommitted"
) -Join ""
Write-Host "The Delete URI is $uriDelete."
Write-Host "The Get URI is $uriGet."
# Make a REST API call to get the uncommitted block list.
$listFileURI = Invoke-WebRequest -Uri $uriGet -Method Get
$FileSystemName = $listFileURI.Content
$String = $FileSystemName -replace '' , ''
$String |
Select-Xml –XPath "/BlockList/UncommittedBlocks/Block" |
Select-Object -Expand Node
$Count = $String.Count
# Delete the blob and the uncommitted block.
if ($Count.Count -gt 0) {
$listFileURI1 = Invoke-WebRequest -Uri $uriDelete -Method Delete
$FileSystemName1 = $listFileURI1.StatusCode
Write-Host "The deletion was successful. The API returned status code $FileSystemName1."
}
Write-Host "Check whether the uncommitted blocks are still present."
Try {
$listFileURI2 = Invoke-WebRequest -Uri $uriGet -Method Get
} Catch {
# $err = $_.Exception
Write-Host "StatusCode:" $_.Exception.Response.StatusCode.value__
Write-Host "StatusDescription:" $_.Exception.Response.StatusDescription
}
Write-Host (
"In this error message, we can verify that the",
"uncommitted blocks and their respective blob have been deleted.",
"The name and size of the uncommitted blocks that have been deleted are shown."
)
Oorzaak 2: PUT-bewerkingen worden gelijktijdig uitgevoerd voor een blob
Er treedt een timing- of gelijktijdigheidsprobleem op. Dit zorgt ervoor dat er meerdere PUT-bewerkingen (Put Block) op ongeveer hetzelfde moment worden uitgevoerd voor één blob. Met de bewerking Lijst met blokken plaatsen wordt een blob geschreven door de lijst met blok-id's op te geven waaruit de blob bestaat. Als u wilt worden geschreven als onderdeel van een blob, moet een blok naar de server zijn geschreven in een eerdere Put Block-bewerking .
Opmerking
Deze fout kan optreden tijdens gelijktijdige upload doorvoeringen nadat u het uploaden hebt gestart, maar voordat u het doorvoert. In dit geval mislukt het uploaden. De toepassing kan het uploaden opnieuw proberen wanneer de fout optreedt, of een andere herstelactie proberen die is gebaseerd op het vereiste scenario.
Oplossing: Leases gebruiken
In plaats van optimistische gelijktijdigheid te gebruiken, kunt u pessimistische gelijktijdigheid (leases) implementeren met behulp van de Azure Storage SDK of een hulpprogramma op basis van gui, zoals Azure Storage Explorer. Zie Gelijktijdigheid in blobopslag beheren voor meer informatie over optimistische en pessimistische gelijktijdigheid.
Als de fout wordt veroorzaakt door gelijktijdigheidsproblemen, moet u mogelijk ook de niet-verzonden blokken opschonen door een van de oplossingen in Oorzaak 1 te volgen.
Contacteer ons voor hulp
Als u vragen hebt of hulp nodig hebt, maak een ondersteuningsaanvraag of vraag de Azure-communityondersteuning. U kunt ook productfeedback verzenden naar de Feedback-community van Azure.
Feedback
https://aka.ms/ContentUserFeedback.
Binnenkort beschikbaar: In de loop van 2024 zullen we GitHub-problemen geleidelijk uitfaseren als het feedbackmechanisme voor inhoud en deze vervangen door een nieuw feedbacksysteem. Zie voor meer informatie:Feedback verzenden en weergeven voor