我们已经使用 AWS Elasticache 大约 6 个月了，没有任何问题。每天晚上我们都有一个运行的 Java 应用程序，它将刷新我们的 redis 缓存的 DB 0，然后用更新的数据重新填充它。然而，在 7 月 31 日至 8 月 5 日期间，我们有 3 个实例成功刷新了我们的数据库，然后我们无法将新数据写入数据库。
我们的应用程序出现以下异常:
redis.clients.jedis.exceptions.JedisDataException: redis.clients.jedis.exceptions.JedisDataException: READONLY You can't write against a read only slave.
当我们查看 Elasticache 中的缓存事件时，我们可以看到
Failover from master node prod-redis-001 to replica node prod-redis-002 completed
我们无法诊断出该问题，并且由于该应用程序在过去 6 个月内运行良好，我想知道它是否与 6 月 30 日发布的最新 Elasticache 版本有关。 https://aws.amazon.com/releasenotes/Amazon-ElastiCache
我们一直在写入我们的主节点，而我们只有 1 个副本节点。
如果有人可以提供任何见解，我们将不胜感激。
编辑:这似乎是间歇性问题。有些日子它会失败，其他日子它运行良好。
最佳答案
过去几周我们一直在与 AWS 支持部门联系，这就是我们的发现。
大多数 Redis 请求都是同步的，包括刷新，因此它会阻塞所有其他请求。在我们的例子中，我们实际上刷新了 19m 的 key ，这需要超过 30 秒的时间。
Elasticache 定期执行健康检查，由于刷新正在运行，健康检查将被阻止，从而导致故障转移。
我们一直在询问支持团队执行健康检查的频率，以便我们了解为什么我们的刷新每周仅导致 3-4 次故障转移。我们能得到的最佳答案是“我们认为它每 30 秒一次”。然而，我们的冲洗始终需要超过 30 秒，并且不会一直失败。
他们表示他们可能会实现配置健康检查时间的功能，但他们表示不会很快完成。
他们能给我们的最好建议是:
1) Create a completely new cluster for loading the new data on, and instead of flushing the previous cluster, re-point your application(s) to the new cluster, and remove the old one.
2) If the data that you are flushing is an update version of the data, consider not flushing, but updating and overwriting new keys?
3) Instead of flushing the data, set the expiry of the items to be when you would normally flush, and let the keys be reclaimed (possibly with a random time to avoid thundering herd issues), and then reload the data.
希望这有帮助:)
关于amazon-web-services - Amazon Elasticache 故障转移，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/31844323/