Merge pull request #37002 from MashaMSFT/rahul-fix

Document scaling operations for Managed Instances with Geo-Replicas

Author: prmerger-automator[bot]

azure-sql/database/scale-resources.md

@@ -73,6 +73,12 @@ Scaling resources is the easiest and the most effective way to improve performan
 - [Read scale-out](read-scale-out.md) is an available feature where you are getting one read-only replica of your data where you can execute demanding read-only queries such as reports. A read-only replica will handle your read-only workload without affecting resource usage on your primary database.
 - [Database sharding](elastic-scale-introduction.md) is a set of techniques that enables you to split your data into several databases and scale them independently.
 
+## Scaling operations for geo-replicas
+
+When your Azure SQL resource has a geo-replica, consider the following guidance for your scaling operations:
+- Azure SQL Database: [Active geo-replication](active-geo-replication-overview.md#scale-primary-database), [failover groups](failover-group-configure-sql-db.md#upgrading-or-downgrading-primary-database)
+- Azure SQL Managed Instance: [Failover groups](../managed-instance/failover-group-configure-sql-mi.md#scaling-instances)
+
 ## Related content
 
 - For information about improving database performance by changing database code, see [Find and apply performance recommendations](database-advisor-find-recommendations-portal.md).

azure-sql/managed-instance/failover-group-configure-sql-mi.md

@@ -471,7 +471,9 @@ Instances in a failover group remain separate Azure resources, and no changes ma
 This section is duplicated in /managed-instance/failover-group-sql-mi.md.. Please ensure changes are made to both documents.  
 -->
 
-The configuration of your primary and secondary instance should be the same. This includes the compute size, storage size, and service tier. If you need to change the configuration of your failover group, you can do so by scaling each instance to the same configuration accordingly. 
+The configuration of your primary and secondary instance should be the same. This includes the compute size, storage size, and service tier. If you need to change the configuration of your failover group, you can do so by scaling each instance to the same configuration accordingly.
+
+Downgrading the secondary instance to a lower service tier or compute size than the primary instance can cause performance degradation after failover.
 
 To avoid problems from a lower service tier or under-resourced geo-secondary getting overloaded, or having to reseed during an upgrade or downgrade process, consider the following: 
 
@@ -484,7 +486,12 @@ To avoid problems from a lower service tier or under-resourced geo-secondary get
   - Scaling the storage size.
   - [Changing the memory allocation](resource-limits.md#flexible-memory) of your [Next-gen General Purpose](service-tiers-next-gen-general-purpose-use.md) instance.
 
+When trying to scale the service tier, vCores, and storage at the same time (for example, scaling up vCores and service tier while scaling down storage), don't change all three simultaneously. Instead, use one of the following approaches:
+
+- **Option 1**: Scale the service tier first (keep storage and vCores the same), following the upgrade/downgrade order described previously. Then scale storage and vCores separately.
+- **Option 2**: Scale storage first (keep service tier and vCores the same), following the upgrade/downgrade order described previously. Then scale the service tier and vCores separately.
 
+This two-step approach prevents the secondary replica with fewer resources from becoming overloaded, which can cause reseeding during the scaling process.
 
 ## Permissions