如何排查當 ElastiCache 出現“Status Code: 400; Error Code: xxx” 錯誤的問題。
當您使用 AWS CloudFormation 或是直接使用 AWS API call 去操作 ElastiCache 時,當出現 “Status Code: 400; Error Code: xxx” 錯誤時,有許多可能的原因,這邊舉些常見的例子,來提供參考。
★ 近日整理常見的案例及 ElastiCache Status Code: 400 錯誤後,有機會能夠發佈在 AWS Support Knowledge Center 中,希望能幫忙到遇到此問題的客戶,詳細請參考以下文檔。
When invoking my AWS CloudFormation stack or using the AWS API call for Amazon ElastiCache, the request fails and I receive the following error:
“Status Code: 400; Error Code: xxx”
Short description:
When you start an AWS API request directly or using a CloudFormation stack, AWS performs initial syntax checks. These checks verify that the request is complete and has all mandatory parameters. The following are common reasons the 400 error occurs
★以下常見錯誤的說明,當遇到 Status Code: 400 後,要先查看 Error Code: xxx 來判斷遇到的是什麼問題,而在這段錯誤訊息前,也會有該錯誤的說明。例如 Error Code: Throttling 這個訊息的前面,就有 Error: “Rate exceeded” 這樣的說明,通過說明內容,可以容易得知這個錯誤的意思。
▶ Error: “Rate exceeded (Service: AmazonElastiCache; Status Code: 400; Error Code: Throttling; Request ID: xxx)”
→ 簡單來說,就是您在短時間內滿執行多次 AWS API,而導致您的 AWS API Call 被限流,最適合的解法就是降低執行的頻率及次數。
▶ Error: “cache.xxx (VPC) is not currently supported in the availability zone xxx. Retry the launch with no availability zone or target: xxx. (Service: AmazonElastiCache; Status Code: 400; Error Code: InsufficientCacheClusterCapacity; Request ID: xxx)”.
→ 這也是常見的問題,當您創建(Create) ElastiCache集群時,若是該節點類型的實例,若是在特定可用區(AZ)數量不足時,就有可能會遇到這個問題,另外更換機型(Change node tye)、或是增加副本實例(Adding replica nodes)、或是增加分片組(Adding shards),都有可能會遇到這樣的狀況,這跟一般EC2實例是一樣的,因為ElastiCache也是用一般的EC2實例來運行 Redis/Memcached服務。而解決方式也是跟EC2實例是一致的,請參考文檔: InsufficidentCacheClusterCapacity。
▶ Error: “The subnet ID subnet-xxx is in use (Service: AmazonElastiCache; Status Code: 400; Error Code: SubnetInUse; Request ID: xxx)”.
→ 這個問題常發生在使用當使用 AWS CloudFormation stack 去創建 Amazon ElastiCache集群後,若已創建的 subnet-xxx 被其他的資源使用中的話,該 AWS CloudFormation stack 是無法正常刪除的。 這跟您要刪除特定 subnet 或是 vpc,但有資源仍佔用時,是一樣無法正常刪除的,這也是一種保護資源的機制,這常見透過 AWS CloudFormation 來刪除相關 Amazon ElastiCache 相關資源。解決方式就是刪除相依的AWS資源,再執行原本的動作。
▶ “xxx. (Service: AmazonElastiCache; Status Code: 400; Error Code: InvalidParameterValue”; Request ID: xxx)”.
▶ “yyy (Service: AmazonElastiCache; Status Code: 400; Error Code: InvalidParameterCombination; Request ID: xxx)”.
→ Error Code: InvalidParameterValue 及 InvalidParameterCombination 這兩種的報錯,可能原因就比較多元了,但主要的原本是在執行該 AWS API 中代入參數,不符合 ElastiCache 的要求。
舉例來說,ElastiCache Redis 不支援用新版本的 Redis 備份檔,來創建舊版的 Redis 集群(Cannot restore redis from 6.0.5 to 5.0.6.); 另外,若有使用 Redis 中 AUTH 密碼功能的話,也常因為配置的密碼長度,所以在創建(Create) ElastiCache集群失敗,也常發生在透過 AWS API 去修改Redis 中 AUTH 密碼。
★ 排查方式,除了要先查看 Error Code: xxx 來判斷遇到的是什麼問題外,建議先用 AWS ElastiCache 控制台去操作您要執行的動作,再去 CloudTrail 去找出該操作的記錄,再去比對CloudTrail Request API 命令的參數,跟您在 AWS CloudFormation stack 中的配置,或是您要執行 AWS ElastiCache API 要代入的參數有那些不同。 簡單來說 AWS ElastiCache 控制台中,會有許多★防呆的機制★。
例如特定機型只支援特定的版本(例如: M6g 節點類型,僅適用於 Redis 引擎 5.0.6 以上版本),在 AWS ElastiCache 控制台,當您選則m6g機型時 , 就只能選 Redis 版本大於 5.0.6,但當您直接使用 AWS ElastiCache API 時,若是帶入參數不符合這個限制,就會直接報錯而失敗,這部份是比較難排查的。
→ Error Code: Cannot use the given parameters when creating new replication group in an existing global replication group. (Service: AmazonElastiCache; Status Code: 400; Error Code: InvalidParameterCombination;)
這個錯誤訊息,也是比較難排查的,當您有使用 Global Datastore 時,或是使用 AWS CloudFormation stack 或是 使用 AWS ElastiCache API 來操作 Amazon ElastiCache 的話,也容易出錯,所以這部份也建議直接使用 AWS ElastiCache 控制台來操作。
→ No permission to access S3 object: s3-bucket/dump.rdb (Service: AmazonElastiCache; Status Code: 400; Error Code: InvalidParameterValue; )
這個錯誤訊息,常見於以下兩個狀況:
- 匯出快照備份,到s3 buck中(Exporting a backup)。
- 或是使用特定 s3 buck 中的 redis RDB 檔案,來創建新的 ElastiCache Redis 集群(Create new redis cluster from redis rdb file)。
而這個錯訊的操作,一般都是權限(Permission)的問題。
◆ 匯出快照備份,到s3 buck中(Exporting a backup)。
→→ 請照這篇 Step 2: Grant ElastiCache access to your Amazon S3 bucket 來檢查權限。
◆ 或是使用特定 s3 buck 中的 redis RDB 檔案,來創建新的 ElastiCache Redis 集群(Create new redis cluster from redis rdb file)。
→→ 請照這篇 Step 4: Grant ElastiCache read access to the .rdb file 來檢查權限。