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 腳本，但仍將被視為健康。 由於這個新功能，故障轉移應該更少發生。