Отправка содержимого большого двоичного объекта или блока завершается сбоем в Хранилище BLOB-объектов Azure

Статья
04/10/2024

В этой статье описывается, как устранить сбои, которые могут возникнуть при использовании Microsoft Хранилище BLOB-объектов Azure вместе с облачными приложениями для отправки большого двоичного объекта или блокировки содержимого.

Предварительные требования

Учетная запись хранения из одной из следующих служб хранения:
пакет SDK служба хранилища Azure
Обозреватель службы хранилища Azure
PowerShell

Симптомы

Вы получаете одно из следующих сообщений об ошибках.

Код ошибки	Сообщение об ошибке
`BlockCountExceedsLimit`	"Число незафиксированных блоков не может превышать максимальное ограничение в 100 000 блоков".
`InvalidBlobOrBlock`	"Указанное содержимое большого двоичного объекта или блока недопустимо".
`InvalidBlock` или `InvalidBlockList`	"Указанный список блоков недопустим".

Причина 1. Длина блока, указанная в вызове put Block, не допустима

Длина блока, указанная в запросе URI блока put , не допустима для одной или нескольких следующих причин:

Приложение или клиент указали размер блока, который не поддерживается.
Размер блока превышает максимальный допустимый размер блока. Сведения о ограничениях размера блока для разных версий REST API службы BLOB-объектов см . в разделе "Примечания " справочной статьи "Put Block".
При попытке отправить блоки данных с помощью нескольких приложений существовали незафиксированные блоки, которые имели несогласованную длину блоков. Эта ситуация возникает из-за того, что разные приложения используют разные длины для отправки данных или из-за сбоя предыдущей отправки.
Большой двоичный объект имеет слишком много незафиксированных блоков, так как предыдущая операция отправки была отменена. Максимальное количество незафиксированных блоков, которые могут быть связаны с большим двоичным объектом, составляет 100 000.

Удалите незафиксированные блоки, реализуя одно из этих решений.

Решение 1. Дождитесь сбора мусора для сбора незафиксированных данных

Подождите семь дней, пока незафиксированный список блоков будет удален сборкой мусора.

Решение 2. Использование фиктивного большого двоичного объекта для передачи данных

Используйте пакет SDK служба хранилища Azure для передачи данных с помощью фиктивного большого двоичного объекта. Для этого выполните следующие шаги.

Создайте фиктивный большой двоичный объект с одинаковым именем большого двоичного объекта и находится в одном контейнере. Этот большой двоичный объект может иметь длину от нуля.
Перенесите большой двоичный объект с помощью разблокированного переноса.

Решение 3. Фиксация незафиксированного списка блокировок с помощью пакета SDK для служба хранилища Azure

Используйте пакет SDK служба хранилища Azure, чтобы зафиксировать незафиксированный список блокировок и очистить большой двоичный объект. Для этого выполните следующие шаги.

Получите незафиксированный список блокировок, выполнив запрос URI списка блоков , в котором blocklisttype задан uncommittedпараметр URI.
Зафиксируйте список блоков с помощью запроса URI списка блокировок .
Удалите большой двоичный объект.

Следующая функция PowerShell является примером того, как получить незафиксированный список блокировок, а затем удалить его. Для функции требуются следующие параметры.

Наименование параметра	Description
`-StorageAccountName`	Имя учетной записи хранения.
`-SharedAccessSignature`	Маркер подписанного URL-адреса (SAS), использующий параметры `<ss=b;srt=sco;sp=rwldc>`URI. Эти параметры описаны в разделе "Создание URI SAS учетной записи".
`-ContainerName`	Имя контейнера хранилища.
`-BlobName`	Имя большого двоичного объекта.

[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."
)

Причина 2. Операции PUT выполняются одновременно для большого двоичного объекта

Возникает проблема с временем или параллелизмом. Это приводит к тому, что несколько операций PUT (Put Block) выполняются примерно в одно и то же время для одного большого двоичного объекта. Операция Put Block List записывает большой двоичный объект, указав список идентификаторов блоков, составляющих большой двоичный объект. Для записи в рамках большого двоичного объекта блок должен быть успешно записан на сервер в предыдущей операции Put Block .

Примечание.

Эта ошибка может возникать во время параллельных фиксаций отправки после запуска отправки, но перед фиксацией. В этом случае отправка завершается ошибкой. Приложение может повторить отправку при возникновении ошибки или попробовать другое действие восстановления, основанное на требуемом сценарии.

Решение. Использование аренды

Вместо использования оптимистического параллелизма попробуйте реализовать пессимистический параллелизм (аренды) с помощью пакета SDK служба хранилища Azure или средства на основе графического интерфейса, например служба хранилища Azure Explorer. Дополнительные сведения об оптимистичной и пессимистической параллелизме см. в разделе "Управление параллелизмом в хранилище BLOB-объектов".

Если ошибка вызвана проблемами параллелизма, может потребоваться также очистить незафиксированные блоки, выполнив одно из решений в причине 1.

Свяжитесь с нами для получения помощи

Если у вас есть вопросы или вам нужна помощь, создайте запрос в службу поддержки или обратитесь за поддержкой сообщества Azure. Вы также можете отправить отзыв о продукте в сообщество отзывов Azure.

Поделиться через