Amazon Elasticache 故障转移

Question

我们已经使用 AWS Elasticache 大约 6 个月了，没有任何问题。 每天晚上我们都会运行一个 Java 应用程序，它会刷新 redis 缓存的 DB 0，然后用更新后的数据重新填充它。 但是，在 7 月 31 日至 8 月 5 日期间，我们有 3 个实例成功刷新了我们的数据库，然后我们无法将新数据写入数据库。

我们在应用程序中遇到以下异常：

redis.clients.jedis.exceptions.JedisDataException: redis.clients.jedis.exceptions.JedisDataException: READONLY 你不能写一个只读的奴隶。

当我们查看 Elasticache 中的缓存事件时，我们可以看到

从主节点 prod-redis-001 到副本节点 prod-redis-002 的故障转移完成

我们无法诊断出这个问题，因为该应用程序在过去 6 个月内运行良好，我想知道它是否与 6 月 30 日发布的最新 Elasticache 版本有关。 https://aws.amazon.com/releasenotes/Amazon-ElastiCache

我们一直在写入我们的主节点，我们只有 1 个副本节点。

如果有人可以提供任何见解，将不胜感激。

编辑：这似乎是一个间歇性问题。 有些日子它会失败其他日子它运行良好。

Answer 1

过去几周我们一直与AWS支持人员联系，这就是我们所发现的。

大多数Redis请求是同步的，包括刷新，因此它将阻止所有其他请求。 在我们的例子中，我们实际上是冲洗19米键，它需要30秒以上。

Elasticache会定期执行运行状况检查，并且由于刷新正在运行，因此将阻止运行状况检查，从而导致故障转移。

我们一直在询问支持团队执行健康检查的频率，以便我们了解为什么我们的同花顺只会导致每周3-4次故障转移。 我们能得到的最好答案是“我们每隔30秒就会想到它”。 然而，我们的冲洗始终需要超过30秒并且不会一直失败。

他们说他们可能会实现配置健康检查时间的能力，但是他们说这不会很快就会完成。

他们可以给我们的最佳建议是：

1）创建一个全新的集群，用于加载新数据，而不是刷新以前的集群，将应用程序重新指向新集群，并删除旧集群。

2）如果您正在刷新的数据是数据的更新版本，请考虑不刷新，但更新和覆盖新密钥？

3）不要刷新数据，而是将项目的到期时间设置为正常刷新的时间，然后回收密钥（可能需要随机时间以避免雷鸣般的群体问题），然后重新加载数据。

希望这可以帮助 ：）

Answer 2

目前从 6.2 开始的 Redis 版本 AWS ElastiCache 有一个新的线程监控功能。 因此，健康检查不会与 Redis 的所有其他操作在同一线程中发生。Redis 可以继续执行长命令/lua 脚本，但仍将被视为健康。 由于这个新功能，故障转移应该更少发生。