From d087a7704561b1d0ccc60305a34c90820f33c1ab Mon Sep 17 00:00:00 2001 From: HamzaAqel <42034142+HamzaAqel@users.noreply.github.com> Date: Fri, 27 Dec 2024 15:40:13 +0300 Subject: [PATCH 1/2] Update concepts-storage.md Clarify the 4096 boundaries. --- articles/postgresql/flexible-server/concepts-storage.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/articles/postgresql/flexible-server/concepts-storage.md b/articles/postgresql/flexible-server/concepts-storage.md index 07223fe43b..d0615f9609 100644 --- a/articles/postgresql/flexible-server/concepts-storage.md +++ b/articles/postgresql/flexible-server/concepts-storage.md @@ -4,7 +4,7 @@ description: This article describes the storage options in Azure Database for Po author: kabharati ms.author: kabharati ms.reviewer: maghan -ms.date: 12/16/2024 +ms.date: 12/27/2024 ms.service: azure-database-postgresql ms.subservice: flexible-server ms.topic: conceptual @@ -111,14 +111,14 @@ As an illustrative example, let's consider a server with a storage capacity of 2 The default behavior increases the disk size to the next premium SSD storage size. This increase is always double in both size and cost, regardless of whether you start the storage scaling operation manually or through storage autogrow. Enabling storage autogrow is valuable when you're managing unpredictable workloads, because it automatically detects low-storage conditions and scales up the storage accordingly. -The process of scaling storage is performed online, without causing any downtime, except when the disk is provisioned at 4,096 GiB. This exception is a limitation of [Azure managed disks](/azure/virtual-machines/managed-disks-overview). If a disk is already 4,096 GiB, the storage scaling activity isn't triggered, even if storage autogrow is turned on. In such cases, you need to scale your storage manually. Remember that, in this specific case, manual scaling is an offline operation and should be scheduled in alignment with your business needs. +The process of scaling storage is performed online, without causing any downtime, except when the disk is provisioned at 4,096 GiB. This exception is a limitation of [Azure managed disks](/azure/virtual-machines/managed-disks-overview). If a disk is already 4,096 GiB, the storage scaling activity isn't triggered, even if storage autogrow is turned on. In such cases, you need to scale your storage manually. Please be aware that in this scenario (reaching or crossing the 4096 GiB boundary), manual scaling is an offline operation. We recommend scheduling this task to align with your business needs. All other operations can be performed online. > [!NOTE] > Regardless of the type of storage you assign to your instance, storage can only be scaled up, not down. ## Limitations and considerations of storage autogrowth -- Disk scaling operations are typically performed online, except in specific scenarios involving the boundary of 4,096 GiB. These scenarios include reaching or crossing the limit of 4,096 GiB. For instance, scaling from 2,048 GiB to 8,192 GiB triggers an offline operation. In the Azure portal, moving to 4 TB, which is represented as 4,095 GiB, keeps the operation online. However, if you explicitly specify 4 TB as 4,096 GiB, such as in Azure CLI, the scaling operation is completed in offline mode, since it reaches the limit of 4,096 GiB. +- Disk scaling operations are typically performed online, except in specific scenarios involving crossing the boundary of 4,096 GiB. These scenarios include reaching or crossing the limit of 4,096 GiB. For instance, scaling from 2,048 GiB to 8,192 GiB triggers an offline operation. In the Azure portal, moving to 4 TB, which is represented as 4,095 GiB, keeps the operation online. However, if you explicitly specify 4 TB as 4,096 GiB, such as in Azure CLI, the scaling operation is completed in offline mode, since it reaches the limit of 4,096 GiB. - Host Caching (ReadOnly and Read/Write) is supported on disk sizes less than 4 TiB. Any disk that is provisioned up to 4,095 GiB can take advantage of Host Caching. Host caching isn't supported for disk sizes more than or equal to 4,096 GiB. For example, a P50 premium disk provisioned at 4,095 GiB can take advantage of Host caching and a P50 disk provisioned at 4,096 GiB can't take advantage of Host Caching. Customers moving from lower disk size to 4,096 GiB or higher lose the ability to use disk caching. From 3bb5a1b16d9620e0a11fb59e3c02d9e1bc27256f Mon Sep 17 00:00:00 2001 From: HamzaAqel <42034142+HamzaAqel@users.noreply.github.com> Date: Fri, 27 Dec 2024 15:48:34 +0300 Subject: [PATCH 2/2] Add details on reduced downtime scaling feature --- articles/postgresql/flexible-server/concepts-storage.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/articles/postgresql/flexible-server/concepts-storage.md b/articles/postgresql/flexible-server/concepts-storage.md index d0615f9609..e6d197767c 100644 --- a/articles/postgresql/flexible-server/concepts-storage.md +++ b/articles/postgresql/flexible-server/concepts-storage.md @@ -118,7 +118,7 @@ The process of scaling storage is performed online, without causing any downtime ## Limitations and considerations of storage autogrowth -- Disk scaling operations are typically performed online, except in specific scenarios involving crossing the boundary of 4,096 GiB. These scenarios include reaching or crossing the limit of 4,096 GiB. For instance, scaling from 2,048 GiB to 8,192 GiB triggers an offline operation. In the Azure portal, moving to 4 TB, which is represented as 4,095 GiB, keeps the operation online. However, if you explicitly specify 4 TB as 4,096 GiB, such as in Azure CLI, the scaling operation is completed in offline mode, since it reaches the limit of 4,096 GiB. +- Disk scaling operations are typically performed online, except in specific scenarios involving crossing the boundary of 4,096 GiB. These scenarios include reaching or crossing the limit of 4,096 GiB. For instance, scaling from 2,048 GiB to 8,192 GiB triggers an offline operation. In the Azure portal, moving to 4 TB, which is represented as 4,095 GiB, keeps the operation online. However, if you explicitly specify 4 TB as 4,096 GiB, such as in Azure CLI, the scaling operation is completed in offline mode, since it reaches the limit of 4,096 GiB. Oflline scale operation usually takes anywhere between 2 to 10 minutes. With the [reduced downtime scaling feature](./concepts-scaling-resources.md), this duration is reduced to less than 30 seconds. This reduction in downtime during scaling resources improves the overall availability of your database instance. - Host Caching (ReadOnly and Read/Write) is supported on disk sizes less than 4 TiB. Any disk that is provisioned up to 4,095 GiB can take advantage of Host Caching. Host caching isn't supported for disk sizes more than or equal to 4,096 GiB. For example, a P50 premium disk provisioned at 4,095 GiB can take advantage of Host caching and a P50 disk provisioned at 4,096 GiB can't take advantage of Host Caching. Customers moving from lower disk size to 4,096 GiB or higher lose the ability to use disk caching.