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)不要刷新数据,而是将项目的到期时间设置为正常刷新的时间,并让密钥被回收(可能需要随机时间以避免雷鸣般的群体问题),然后重新加载数据.

希望这可以帮助 :)