You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: articles/azure-cache-for-redis/cache-migration-guide.md
+7-7Lines changed: 7 additions & 7 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -14,11 +14,11 @@ appliesto:
14
14
---
15
15
# Migrate to or between Azure Cache for Redis instances
16
16
17
-
This article describes several Azure Cache for Redis migration scenarios. You can migrate Redis caches running in private data centers, on cloud virtual machines (VMs), or in another cloud to Azure Cache for Redis.
17
+
This article describes several Azure Cache for Redis migration scenarios. You can migrate open-source Redis caches running on-premises or in cloud virtual machines (VMs), or hosted caches from other cloud platforms, to Azure Cache for Redis.
18
18
19
19
You can also migrate one Azure Cache for Redis instance to another instance. If you only need to move an Azure Redis cache from one Azure region to another, see [Move Azure Cache for Redis instances to different regions](cache-moving-resources.md).
20
20
21
-
Open-source Redis can run in many compute environments, such as private on-premises data centers or cloud-hosted virtual machines (VMs). Other hosting platforms like Amazon Web Services (AWS) host Redis cache services like AWS ElastiCache. You can usually migrate these Redis caches to Azure Cache for Redis with minimal interruption or downtime.
21
+
Open-source Redis can run in many compute environments, such as private on-premises data centers or cloud-hosted VMs. Other hosting platforms like Amazon Web Services (AWS) host Redis cache services like AWS ElastiCache. You can usually migrate these Redis caches to Azure Cache for Redis with minimal interruption or downtime.
22
22
23
23
## Migration options
24
24
@@ -33,7 +33,7 @@ How you migrate from one cache to another depends on where your cache exists and
33
33
34
34
### Create a new cache
35
35
36
-
If uninterrupted operations and potential data loss aren't concerns, the easiest way to move data to Azure Cache for Redis is to create an Azure Redis cache instance and connect your application to it. This approach isn't technically a migration. For example, if you use Redis as a look-aside cache of database records, you can easily rebuild the cache from scratch.
36
+
If uninterrupted operations and potential data loss aren't concerns, the easiest way to move data to Azure Cache for Redis is to create an Azure Redis cache instance and connect your application to it. For example, if you use Redis as a look-aside cache of database records, you can easily rebuild the cache from scratch. This approach isn't technically a migration.
37
37
38
38
General steps to implement this option are:
39
39
@@ -50,20 +50,20 @@ Open-source Redis defines a standard mechanism to take a snapshot of a cache's i
50
50
51
51
General steps to implement this option are:
52
52
53
-
1. Save a snapshot of the existing Redis cache. You can [configure Redis to save snapshots](https://redis.io/topics/persistence) periodically, or save manually using the [SAVE](https://redis.io/commands/save) or [BGSAVE](https://redis.io/commands/bgsave) commands. The RDB file is named *dump.rdb* by default and is located at the path specified in the *redis.conf* configuration file.
53
+
1. Save a snapshot of the existing Redis cache. You can [configure Redis to save snapshots](https://redis.io/topics/persistence) periodically, or save one manually using the [SAVE](https://redis.io/commands/save) or [BGSAVE](https://redis.io/commands/bgsave) commands. The RDB file is named *dump.rdb* by default and is located at the path specified in the *redis.conf* configuration file.
54
54
1. Create a new Premium-tier Azure Cache for Redis instance that's at least as large as the existing cache.
55
55
1. Copy the RDB file to an Azure storage account in the region where your new cache is located. You can use `AzCopy` for this task.
56
56
1.[Import](cache-how-to-import-export-data.md#import) the RDB file into the new cache. You can also use the PowerShell [Import-AzRedisCache](/powershell/module/az.rediscache/import-azrediscache) cmdlet.
57
57
1. Update your application to use the new cache instance.
58
58
59
59
> [!NOTE]
60
-
> To migrate data from another Azure Redis instance, first [export](cache-how-to-import-export-data.md#export) the RDB file from that instance, or use the PowerShell [Export](/powershell/module/az.rediscache/export-azrediscache) cmdlet.
60
+
> To migrate data from another Azure Redis instance, first [export](cache-how-to-import-export-data.md#export) the RDB file from that instance, or use the PowerShell [Export-AzRedisCache](/powershell/module/az.rediscache/export-azrediscache) cmdlet.
61
61
62
62
### Write to two Redis caches during migration
63
63
64
-
Rather than moving data between caches, you can temporarily set your application to write data to both an existing cache and a new one. The application reads data from the existing cache initially. When the new cache has enough data, you switch the application to that cache and retire the old one.
64
+
Rather than moving data between caches, you can temporarily set your application to write data to both an existing cache and a new one. The application reads data from the existing cache initially. When the new cache has enough data, you can switch the application to that cache and retire the old one.
65
65
66
-
For example, suppose you use Redis as a session store and the application sessions expire after seven days. After writing to both caches for seven days, you know the new cache contains all nonexpired session information and you can safely rely on it from that point on.
66
+
For example, suppose you use Redis as a session store and the application sessions expire after seven days. After writing to both caches for seven days, you know the new cache contains all nonexpired session information and you can safely rely on it from that point on. You can then retire the old cache.
Copy file name to clipboardExpand all lines: articles/azure-cache-for-redis/cache-retired-features.md
+3-4Lines changed: 3 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -17,8 +17,7 @@ appliesto:
17
17
18
18
On June 30, 2023, Redis version 4 was retired for Azure Cache for Redis instances. All new Azure Redis instances are version 6.
19
19
20
-
21
-
All existing Azure Redis instances were upgraded automatically to version 6. Redis version 6 is compatible with version 4 and applications continued to function seamlessly after the version upgrade.
20
+
Existing Azure Redis instances were upgraded automatically to version 6. Redis version 6 is compatible with version 4 and applications continued to function seamlessly after the version upgrade.
22
21
23
22
During the upgrade process, the replica node of the cache was first upgraded to run Redis version 6. The upgrade replica node then took over as the primary cache node while the former primary node rebooted to take on the role of replica. This process was exactly like the patching process described in [How does patching occur?](cache-failover.md#how-does-patching-occur)
24
23
@@ -28,8 +27,8 @@ During the upgrade process, the replica node of the cache was first upgraded to
28
27
29
28
- Cache instances that had geo-replication enabled had to unlink the caches before upgrade, upgrade both caches, and relink them after the upgrade.
30
29
31
-
-Cache instances that were affected by Cloud Service retirement couldn't upgrade to Redis 6 until after they migrated to a cache built on Virtual Machine Scale Set. Otherwise the automatic migration required around 30 minutes of downtime and full data loss on the cache.
30
+
-Caches that were affected by Cloud Service retirement had to migrate to a caches built on Virtual Machine Scale Set, or undergo an automatic upgrade requiring 30 minutes of downtime and full cache data loss.
32
31
33
-
For more information about upgrading Redis versions in Azure Cache for Redis, see [How to upgrade the version of your Redis instance](cache-how-to-upgrade.md). The upgrade process can be triggered through REST API, Azure CLI, or PowerShell command. Also see [Best practices for connection resilience](cache-best-practices-connection.md).
32
+
The Redis version upgrade process can be triggered through REST API, Azure CLI, or PowerShell command. For more information about upgrading Redis versions in Azure Cache for Redis, see [How to upgrade the version of your Redis instance](cache-how-to-upgrade.md). Also see [Best practices for connection resilience](cache-best-practices-connection.md).
34
33
35
34
To check the Redis version of your cache instance, select **Properties** from the left navigation menu of your cache page in the Azure portal.
Copy file name to clipboardExpand all lines: articles/azure-cache-for-redis/cache-troubleshoot-data-loss.md
+9-10Lines changed: 9 additions & 10 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -36,8 +36,7 @@ Azure Cache for Redis removes a key automatically if the key is assigned a timeo
36
36
37
37
To get statistics on how many keys have expired, use the [INFO](https://redis.io/commands/info) command. The `Stats` section shows the total number of expired keys. The `Keyspace` section provides more information about the number of keys with timeouts and the average timeout value.
Azure Cache for Redis requires memory space to store data and purges keys to free up available memory when necessary. When the `used_memory` or `used_memory_rss` values approach the configured `maxmemory` setting, Azure Redis starts evicting keys from memory based on [cache policy](https://redis.io/topics/lru-cache).
53
52
54
-
You can monitor the number of evicted keys by using the [INFO](https://redis.io/commands/info) command:
53
+
You can monitor the number of evicted keys by using the [INFO](https://redis.io/commands/info) command.
55
54
56
-
```console
55
+
```output
57
56
# Stats
58
57
59
58
evicted_keys:13224
@@ -63,7 +62,7 @@ evicted_keys:13224
63
62
64
63
Redis clients can issue the Redis [DEL](https://redis.io/commands/del) or [HDEL](https://redis.io/commands/hdel) commands to explicitly remove keys from Azure Redis. You can track the number of delete operations by using the [INFO](https://redis.io/commands/info) command. If `DEL` or `HDEL` commands were called, they're listed in the `Commandstats` section.
Standard or Premium tier Azure Cache for Redis instances are configured with a primary node and at least one replica. Data is copied from the primary to a replica asynchronously by using a background process.
77
76
78
-
The [redis.io](https://redis.io/topics/replication) website describes how Redis data replication works in general. For scenarios where clients write to Redis frequently, partial data loss can occur because replication isn't guaranteed to be instantaneous.
77
+
[Redis replication](https://redis.io/topics/replication)on the Redis website describes how Redis data replication works in general. For scenarios where clients write to Redis frequently, partial data loss can occur because replication isn't designed to be instantaneous.
79
78
80
79
For example, if the primary goes down after a client writes a key to it, but before the background process has a chance to send that key to the replica, the key is lost when the replica takes over as the new primary.
81
80
@@ -93,7 +92,7 @@ If most or all keys disappear from your cache, check the following possible caus
93
92
94
93
Azure Redis clients can call the Redis [FLUSHDB](https://redis.io/commands/flushdb) command to remove all keys in a single database or [FLUSHALL](https://redis.io/commands/flushall) to remove all keys from all databases in a Redis cache. To find out whether keys were flushed, use the [INFO](https://redis.io/commands/info) command. The `Commandstats` section shows whether either `FLUSH` command was called.
Azure Cache for Redis uses the `db0` database by default. If you switch to another database such as `db1` and try to read keys from it, Azure Redis doesn't find them. Every database is a logically separate unit and holds a different dataset. Use the Redis [SELECT](https://redis.io/commands/select) command to look for keys in other available databases.
105
+
Every database is a logically separate unit and holds a different dataset. Azure Cache for Redis uses the `db0` database by default. If you switch to another database such as `db1` and try to read keys from it, Azure Redis doesn't find them. Use the Redis [SELECT](https://redis.io/commands/select) command to look for keys in other available databases.
107
106
108
107
### Redis instance failure
109
108
110
-
Redis is an in-memory data store that keeps data on the physical or virtual machines (VMs) that host the Redis cache. A Basic-tier Azure Cache for Redis instance runs on only a single virtual machine (VM). If that VM is down, all data that you stored in the cache is lost.
109
+
Redis keeps data inmemory on the physical or virtual machines (VMs) that host the Redis cache. A Basic-tier Azure Cache for Redis instance runs on only a single virtual machine (VM). If that VM goes down, all data that you stored in the cache is lost.
111
110
112
111
Caches in the Standard and Premium tiers offer higher resiliency against data loss by using two VMs in a replicated configuration. When the primary node in such a cache fails, the replica node takes over to serve data automatically.
113
112
114
-
These VMs are located on separate domains for faults and updates, to minimize the chance of both VMs becoming unavailable at once. If a major datacenter outage happens, however, both VMs could still go down together. In these rare cases, your data is lost. Consider using [Redis data persistence](https://redis.io/topics/persistence) and [geo-replication](cache-how-to-geo-replication.md) to improve data protection against infrastructure failures.
113
+
These VMs are located on separate domains for faults and updates, to minimize the chance of both VMs becoming unavailable at once. If a major datacenter outage happens, however, both VMs could go down. In these rare cases, your data is lost. Consider using [data persistence](cache-how-to-premium-persistence.md) and [geo-replication](cache-how-to-geo-replication.md) to improve data protection against infrastructure failures.
0 commit comments