【问题标题】:ElastiCache Maintenance Window AvailabilityElastiCache 维护时段可用性
【发布时间】:2015-01-20 06:57:55
【问题描述】:

我们计划使用 ElastiCache (Redis) 代替我们自己的 redis 集群。但是,“维护窗口”设置会产生一些问题,

如果我使用多可用区复制集群,elasticache 会在维护时段内故障转移到可用副本,还是整个集群在维护期间停机?

一般需要多长时间?

我们也可以使用 MemCached 代替 Redis,它在维护窗口期间是否有更好的可用性情况?

其他人如何处理 ElastiCache 维护窗口?不用停机?

谢谢!

【问题讨论】:

    标签: caching amazon-web-services redis amazon-elasticache


    【解决方案1】:

    一般需要多长时间?

    60 分钟以下:

    “如果在给定的一周内安排了“维护”活动,它将在您确定的 60 分钟维护窗口内的某个时间点启动并完成。”

    多久一次:

    软件修补很少发生(通常每几个月一次),并且很少需要超过维护窗口的一小部分。如果您在创建缓存集群时未指定首选的每周维护时段,则会分配 60 分钟的默认值。

    http://aws.amazon.com/elasticache/faqs/

    【讨论】:

      【解决方案2】:

      AWS 通常会进行 2 次维护。

      1. 持续托管维护更新。
      2. 服务更新

      创建集群时,您需要指定 60 分钟的维护窗口。通常所有的维护更新 (1) 都会在这段时间内进行。

      对于每项服务更新,您都会在有预定更新时收到通知。通知将采用电子邮件或弹性疼痛页面上的通知等形式...根据通知,您可以将服务更新重新安排到舒适的时间。如果您未能重新安排时间,它将默认选择您的维护时段并应用服务更新。

      基本上在维护更新期间,AWS 会将您的节点替换为具有所需更新的新节点。如果您将主/副本设置为多 az 并将自动故障转移设置为 true,则在主节点的维护窗口期间,您的副本将被提升为主节点,并且您的读/写请求将从那里得到服务。因此,理想情况下,您在维护期间看不到任何问题,可能需要几秒钟的停机时间才能将副本提升为主服务器。

      如果您没有将 multiaz 设置为自动故障转移为 true,或者您的 elasticache 只有一个节点,您将在维护窗口期间看到停机时间。

      Refer AWS documentation

      【讨论】:

        猜你喜欢
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 2010-10-06
        • 2010-10-12
        • 2021-05-31
        • 1970-01-01
        相关资源
        最近更新 更多