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

Статья
04/10/2024

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

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

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

Симптомы

Появляется одно из следующих сообщений об ошибке.

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

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

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

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

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

Решение 1. Подождите, пока сборка мусора соберет незафиксированные данные

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

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

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

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

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

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

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

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

Имя параметра	Описание
`-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) выполняются примерно в одно и то же время для одного BLOB-объекта. Операция Put Block List записывает большой двоичный объект, указывая список идентификаторов блоков, составляющих большой двоичный объект. Чтобы записать как часть большого двоичного объекта, блок должен быть успешно записан на сервер в предыдущей операции Put Block .

Примечание.

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

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

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

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

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

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

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