The blog explains how lease management in Azure Storage works, covering the management of concurrent access to blobs and containers. It discusses key concepts such as acquiring, renewing, changing, releasing, and breaking leases, ensuring only the lease holder can modify or delete a resource for a specified duration. Additionally, it explores common troubleshooting scenarios in Azure Storage Lease Management.
Lease management in Azure Storage allows you to create and manage locks on blobs for write and delete operations. This is particularly useful for ensuring that only one client can write to a blob at a time, preventing conflicts and ensuring data consistency.
Key Concepts:
- Lease States: A blob can be in one of several lease states, such as Available, Leased, Expired, Breaking, and Broken. Each state indicates the current status of the lease on the blob.
- Lease Duration: The duration of a lease can be between 15 to 60 seconds, or it can be infinite. An infinite lease remains active until it is explicitly released or broken. In versions prior to 2012-02-12, the lock duration is 60 seconds.
- Lease Actions: There are several actions you can perform on a lease, including acquiring, renewing, releasing, and breaking the lease.
The diagram below illustrates the five states of a lease and the commands or events that trigger lease state changes. A lease in Azure Blob Storage manages concurrent access to blobs and containers, ensuring that only the lease holder can modify or delete a resource for a specified duration.
Available
The blob is not leased at present and is available for leasing. It transitions to the Leased state when acquired and stays in the Available state when released or written to.
Leased
When a lease is acquired, the blob enters a leased state and is locked from modification by others; it is available when released, leased when renewed or changed, breaking with a break period greater than 0, broken with a break period of 0, and expired when the lease period ends.
Expired
The lease has expired, but it can be renewed or re-acquired, transitioning to leased when acquired or available when terminated.
Breaking
The lease is terminated with a non-zero break period, remaining in the Breaking state if greater than 0, and entering the Broken state once the period ends or is set to 0, becoming available when released.
Broken
When a lease is broken, clients can acquire a new lease; it becomes Leased when acquired, remains broken if broken again, and moves to available when released or written to.
In addition, Lease management in Azure Storage allows you to create and manage locks on containers to control access for delete operations. This is particularly useful for ensuring that only one client can delete a container at a time, preventing conflicts and ensuring data consistency.
Troubleshooting Scenarios
Scenario 1: Lease ID Mismatch:
Error:
"The lease ID specified did not match the lease ID for the blob. RequestId:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx Time:YYYY-MM-DDTHH:mm:SS.Z
Cause:
This error occurs when:
• The lease ID provided in the request does not match the actual lease ID currently held by the blob.
• The lease has already expired or was broken, making the lease ID invalid.
• Another process has acquired a new lease, making the old lease ID incorrect.
Resolution:
Verify the Correct Lease ID
• Get the correct lease ID before performing lease operations.
• You can retrieve the current lease ID from your application logs or metadata if previously stored.
Acquire a New Lease If Needed
• If the lease has already expired or was broken, you must acquire a new lease before proceeding. To acquire a lease, please refer to lease action command above
Use the Correct Lease ID for Subsequent Operations
• Ensure all lease-related requests (renew, release, break, change) use the correct lease ID that was returned when acquiring the lease.
Scenario 2: Lease ID Missing
Error:
“There is currently a lease on the blob and no lease ID was specified in the request.
RequestId: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx Time:YYYY-MM-DDTHH:mm:SS.Z
Cause:
This error occurs when:
• You are trying to renew, release, or change a lease but did not include x-ms-lease-id in the request.
• The blob is already leased, but you are trying to acquire a new lease without breaking the existing one first.
• You are attempting to break a lease without including the lease ID when required (some scenarios do not require it)
Resolution:
Include the Lease ID in the Request
• Ensure you provide the correct x-ms-lease-id in the request header.
• Example for renewing a lease. To renew a lease, please refer to lease action command above
Verify If a Lease Exists Before Performing Operations
You can check the lease status by using the Get Blob Properties API:
curl -I -X HEAD "https://mystorageaccount.blob.core.windows.net/mycontainer/myblob?SAS_TOKEN" \ -H "x-ms-version: 2021-08-06"
If the lease status is “unlocked”, then there is no active lease, and you do not need to specify a lease ID.
Scenario 3: Lease ID Not Found:
Error:
There is currently no lease on the blob.
RequestId: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
Time: YYYY-MM-DDTHH:MM:SS.ssssssZ
Cause:
The error occurs when:
• You provide an incorrect or expired lease ID in lease operations such as renew, release, or change.
• The lease has already expired or been broken, making the lease ID invalid.
• The blob never had a lease in the first place.
• You are trying to release or renew a lease without specifying a lease ID when required.
Resolution:
Check If the Blob Has an Active Lease
Before performing any lease-related operation, you should verify the lease status using the Get Blob Properties API:
curl -I -X HEAD "https://mystorageaccount.blob.core.windows.net/mycontainer/myblob?SAS_TOKEN" \ -H "x-ms-version: 2021-08-06"
Look for these headers in the response:
x-ms-lease-status: locked → A lease is present.
x-ms-lease-status: unlocked → No lease is currently active.
x-ms-lease-state: expired → The lease has expired.
Ensure You Use the Correct Lease ID
If a lease is present, but you’re getting an error, ensure you are using the correct lease ID from when the lease was acquired. If you don’t have the lease ID, you may need to break the lease and acquire a new one.
If No Active Lease Exists, Acquire a New Lease. If the blob does not have an active lease, you need to acquire one before performing lease-related operations:
- If the lease ID is incorrect or missing, check the lease status first.
- If no lease exists, acquire a new lease before proceeding.
- If the lease ID is lost, break the lease and acquire a new one.
Scenario 4: Upgrade Azure Blob Storage with Azure Data Lake Storage capabilities
Error:
Unable to proceed HnsOn migration due to incompatible feature, Blob has active lease
Cause:
The HNS upgrade fails if any blob/container has an active lease.
Resolution:
- The upgrade might fail if an application writes to the storage account during the upgrade. To prevent such write activity:
- Quiesce any applications or services that might perform write operations.
- Release or break existing leases on containers and blobs in the storage account.
- After the upgrade has completed, break the leases you created to resume allowing write access to the containers and blobs.
Note
Breaking an active lease without gracefully disabling applications or virtual machines that are currently accessing those resources could have unexpected results. Be sure to quiesce any current write activities before breaking any current leases.
Additional Resources:
For more detailed information and troubleshooting tips, you can refer to the following resources:
Microsoft