Skip to content

Commit a24c8f8

Browse files
authored
Update cache-how-to-active-geo-replication.md
1 parent e940ac7 commit a24c8f8

File tree

1 file changed

+29
-0
lines changed

1 file changed

+29
-0
lines changed

articles/azure-cache-for-redis/cache-how-to-active-geo-replication.md

Lines changed: 29 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -136,6 +136,35 @@ New-AzRedisEnterpriseCache -Name "Cache2" -ResourceGroupName "myResourceGroup" -
136136

137137
As before, you need to list both _Cache1_ and _Cache2_ using the `-LinkedDatabase` parameter.
138138

139+
## Scaling instances in a geo-replication group
140+
It is possible to scale instances that are configured to use active geo-replication. However, a geo-replication group with a mix of different cache sizes can introduce problems. To prevent these issues from occurring, all caches in a geo replication group need to be the same size and capacity.
141+
142+
Since it is difficult to simultaneously scale all instances in the geo-replication group, Azure Cache for Redis has a locking mechanism. If you scale one instance in a geo-replication group, the underlying VM will be scaled, but the memory available will be capped at the original size until the other instances are scaled up as well. And any other scaling operations for the remaining instances are locked until they match the same configuration as the first cache to be scaled.
143+
144+
### Scaling example
145+
For example, you may have three instances in your geo-replication group, all Enterprise E10 instances:
146+
147+
| Instance Name | Redis00 | Redis01 | Redis02 |
148+
|-----------|:--------------------:|:--------------------:|:--------------------:|
149+
| Type | Enterprise E10 | Enterprise E10 | Enterprise E10 |
150+
151+
Let's say you want to scale up each instance in this geo-replication group to an Enterprise E20 instance. You would first scale one of the caches up to an E20:
152+
153+
| Instance Name | Redis00 | Redis01 | Redis02 |
154+
|-----------|:--------------------:|:--------------------:|:--------------------:|
155+
| Type | Enterprise E20 | Enterprise E10 | Enterprise E10 |
156+
157+
At this point, the `Redis01` and `Redis02` instances can only scale up to an Enterprise E20 instance. All other scaling operations are blocked.
158+
>[!NOTE]
159+
> The `Redis00` instance is not blocked from scaling further at this point. But it will be blocked once either `Redis01` or `Redis02` is scaled to be an Enterprise E20.
160+
>
161+
162+
Once each instance has been scaled to the same tier and size, all scaling locks are removed:
163+
164+
| Instance Name | Redis00 | Redis01 | Redis02 |
165+
|-----------|:--------------------:|:--------------------:|:--------------------:|
166+
| Type | Enterprise E20 | Enterprise E20 | Enterprise E20 |
167+
139168
## Flush operation
140169

141170
Due to the potential for inadvertent data loss, you can't use the `FLUSHALL` and `FLUSHDB` Redis commands with any cache instance residing in a geo-replication group. Instead, use the **Flush Cache(s)** button located at the top of the **Active geo-replication** working pane.

0 commit comments

Comments
 (0)