本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# 疑難排解 Amazon CloudSearch
下列主題說明使用 Amazon CloudSearch 時可能遇到問題的解決方案。
**Topics**
+ [上傳文件](#ts.uploaddocs)
+ [刪除 Amazon CloudSearch 網域中的所有文件](#ts.cleardomain)
+ [Amazon CloudSearch 網域在刪除文件後不會縮減規模](#ts.notscalingdown)
+ [文件更新延遲](#ts.slowupdates)
+ [將文件上傳至 Amazon CloudSearch 網域時發生大量 5xx 錯誤](#troubleshooting-upload-timeouts)
+ [在 Amazon CloudSearch 中搜尋延遲和逾時](#ts.searchfailures)
+ [在 Amazon CloudSearch 中搜尋面向查詢的延遲](#ts.slow-facet-searches)
+ [搜尋 Amazon CloudSearch 網域時 5xx 錯誤突然增加](#troubleshooting-increased-errors)
+ [在 Amazon CloudSearch 中更新索引選項後索引失敗](#ts.indexingfailures)
+ [提交 Amazon CloudSearch 請求時找不到網域](#troubleshooting-domain-not-found)
+ [網域資訊未一併傳回可搜尋的文件份數](#troubleshooting-searchable-documents)
+ [未在 Amazon CloudSearch 中運作的組態服務存取政策](#troubleshooting-configuration-access-policies)
+ [搜尋和文件服務存取政策未在 Amazon CloudSearch 中運作](#troubleshooting-search-doc-access-policies)
+ [Amazon CloudSearch 主控台許可錯誤](#troubleshooting-console-access)
+ [使用萬用字元搜尋文字欄位並未產生預期的結果](#ts.wildcardsearchresults)
+ [使用游標深入翻頁時得到不一致的結果](#ts.deeppaging)
+ [使用開發套件時的憑證錯誤](#troubleshooting-certificates)
## 上傳文件
如果您的文件資料格式不正確或包含無效的值，當您嘗試上傳該文件或將其用於為您的網域設定欄位時就會收到錯誤。以下是一些常見問題及其解決方案：
+ **無效的 JSON** — 如果您使用的是 JSON，首先要做的是確保文件批次中沒有 JSON 語法錯誤。為此，請透過驗證工具如 [JSON 驗證程式](http://jsonlint.com)執行檢查。這可找出資料的任何基本問題。
+ **無效的 XML** - 文件批次必須是格式正確的 XML。若您的欄位包含 XML 資料，即尤其可能會遇到問題；資料必須為 XML 編碼或用 CDATA 區段括住。要找出任何問題，請透過驗證工具如 [W3C 標記驗證服務](http://validator.w3.org/)執行您的文件批次。
+ **無法辨識為文件批次** - 如果您使用主控台上傳資料時，Amazon CloudSearch 無法將資料辨識為有效的文件批次，Amazon CloudSearch 會產生有效的批次，其中包含單一內容欄位和一般中繼資料欄位`content_type`，例如 `content_encoding`、 和 `resourcename`。由於這些欄位通常並非供網域設定使用，您將收到指出欄位不存在的錯誤。同樣地，如果您嘗試從無效批次設定網域，Amazon CloudSearch 會回應內容和中繼資料欄位，而不是批次中的欄位。
首先，確認批次為有效的 XML 或 JSON。如果是，則檢查有否任何無效的文件 ID，並確認已為每份文件指定操作類型。對於新增操作，確認每份文件皆有指定類型、ID 以及至少一個欄位。刪除操作則只需指定類型和 ID。如需資料格式化方式的詳細資訊，請參閱[建立文件批次](preparing-data.md#creating-document-batches)。
+ **具有錯誤值的文件 IDs **- 文件 ID 可以包含任何字母或數字以及下列字元：\$1 - = \$1 ； ： / ？ @ &。 文件 IDs 長度必須至少為 1 個字元，且不可超過 128 個字元。
+ **沒有值的多值欄位** - 在 JSON 中指定文件資料時，您無法將空陣列指定為欄位的值。多值欄位必須包含至少一個值。
+ **錯誤的字元** - 如果您在產生文件批次時未篩選資料，可能難以偵測的一個問題是可包含 XML 中無效的字元。JSON 和 XML 批次均只能包含有效 XML 格式的 UTF-8 字元。您可以使用 [JSON 驗證程式](http://jsonlint.com)或 [W3C 標記驗證服務](http://validator.w3.org/)之類的驗證工具找出無效的字元。
## 刪除 Amazon CloudSearch 網域中的所有文件
Amazon CloudSearch 目前不提供刪除網域中所有文件的機制。
## Amazon CloudSearch 網域在刪除文件後不會縮減規模
如果您的網域已擴展以容納您的索引大小，而且您刪除了大量文件，則下次重建完整索引時，網域會縮減規模。雖然索引會定期重建，但為了盡快縮減規模，您可以在完成刪除文件時明確[執行索引](indexing.md)。
## 文件更新延遲
傳送大量的單一文件批次可能導致每份文件轉變為可搜尋所需的時間增加。如果您的更新將產生大量流量，即必須以批次方式進行更新。建議您使用接近 5 MB 上限的批次大小。如需詳細資訊，請參閱[建立文件批次](preparing-data.md#creating-document-batches)。
您可以每天 (每隔 24 小時) 載入多達 10,000 個文件批次，每一批次的大小達 5 MB。每天載入的資料量過多將致使文件更新延遲情況益發嚴重。為了減輕此風險，您可以選擇較大的執行個體類型，以提高更新容量。如需詳細資訊，請參閱[在 Amazon CloudSearch 中設定擴展選項](configuring-scaling-options.md)。
## 將文件上傳至 Amazon CloudSearch 網域時發生大量 5xx 錯誤
如果您平行化上傳，且您的網域位於 search.small 執行個體上，您可能會遇到無法接受的高速率 504 或 507 錯誤。將所需的執行個體類型設為更大的執行個體類型，會增加您的更新容量並降低錯誤率。如需如何處理 5xx 錯誤的詳細資訊，請參閱[處理錯誤](error-handling.md)。如需如何預先調整網域規模以增加上傳容量的相關資訊，請參閱[在 Amazon CloudSearch 中設定擴展選項](configuring-scaling-options.md)。
## 在 Amazon CloudSearch 中搜尋延遲和逾時
若您遇到回應時間過久或頻繁出現內部伺服器錯誤 (通常為 507 或 509 錯誤) 的狀況，或者察覺您的搜尋網域在搜尋的資料量並未大幅增加的情形下仍迭增耗用執行個體時數，則微調您的搜尋請求以減少處理負擔將有所助益。如需詳細資訊，請參閱[在 Amazon CloudSearch 中調整搜尋請求效能](tuning-search.md)。增加所需的複寫計數也可加速處理搜尋請求。如需詳細資訊，請參閱[在 Amazon CloudSearch 中設定擴展選項](configuring-scaling-options.md)。
507 和 509 錯誤通常表示您的搜尋服務超載。這可能是因為您提交的搜尋請求數量或複雜性所致。Amazon CloudSearch 通常會自動擴展以處理負載。由於部署其他搜尋執行個體需要一些時間，我們建議您使用指數退避重試政策暫時降低請求率，並將請求失敗降至最低。如需詳細資訊，請參閱[錯誤重試和指數退避](https://docs.aws.amazon.com/general/latest/gr/api-retries.html)。
某些使用模式，例如將複雜的搜尋查詢提交至單一小型搜尋執行個體，有時可能會導致逾時，而不會觸發自動擴展。如果您重複遇到高錯誤率，您可以透過 Amazon CloudSearch [Service Limit Request ](https://console.aws.amazon.com/support/home#/case/create?issueType=service-limit-increase&limitType=service-code-cloudsearch-partitions-and-instances)表單明確請求額外的容量。
## 在 Amazon CloudSearch 中搜尋面向查詢的延遲
若您使用 `buckets` 選項依值區歸納面向資訊卻發生查詢效能遲緩的狀況，請嘗試將值區方法設為 `interval`。如需詳細資訊，請參閱[依值區歸納面向資訊](faceting.md#bucketing-facets)。
## 搜尋 Amazon CloudSearch 網域時 5xx 錯誤突然增加
如果您的搜尋網域流量突然遽增，Amazon CloudSearch 會透過將搜尋執行個體新增至您的網域來回應，以處理增加的負載。不過，設定新的執行個體需要幾分鐘的時間。在新的執行個體已就緒可開始處理請求之前，您可能會遇到 5xx 錯誤一時增多的情形。如需如何處理 5xx 錯誤的詳細資訊，請參閱[處理錯誤](error-handling.md)。如需如何預先調整網域規模以處理預期的搜尋請求高峰的相關資訊，請參閱[在 Amazon CloudSearch 中設定擴展選項](configuring-scaling-options.md)。
## 在 Amazon CloudSearch 中更新索引選項後索引失敗
若您變更了網域的索引組態，當您編製索引時，某些情況下可能會出現「驗證失敗」的錯誤。這表示您所設定的索引欄位選項與您的索引中現存的文件不相容。特別是您變更了索引欄位的類型，而您的索引中有些文件其所含資料與該類型不相容所致。例如，假使您將 `literal` 欄位變更為 `int` 欄位，而您有些文件的該欄位包含英數資料，可能就會發生這種情況。發生這種情況時，Amazon CloudSearch 會將正在處理的所有欄位的狀態設定為 `FailedToValidate` 狀態。還原不相容的組態變更，即可成功重新建立索引。若是必要的變更，請務必將不相容的文件從索引中移除，方可使用新的組態。若您無法找出是哪些變更造成錯誤或需要協助辨別不相容的文件，請聯絡支援部門。
## 提交 Amazon CloudSearch 請求時找不到網域
您無法使用 2013-01-01 命令列工具或 SDKs 存取 2011-02-01 網域。同樣地，您無法使用 2011-02-01 命令列工具或 SDKs 存取 2013-01-01 網域。請務必在您的請求中指定正確的 API 版本並使用合適的命令列工具或開發套件。
## 網域資訊未一併傳回可搜尋的文件份數
`aws cloudsearch describe-domains` 和 `DescribeDomains` 不會傳回網域內可搜尋的文件份數。若要取得可搜尋的文件份數，請使用主控台或向您的網域搜尋端點提交 `matchall` 請求。
```
q=matchall&q.parser=structured&size=0
```
## 未在 Amazon CloudSearch 中運作的組態服務存取政策
如果您同時擁有 2011 和 2013 網域、已設定存取組態服務的 IAM 政策，且收到*未授權*的錯誤，請注意 Amazon CloudSearch ARN 與 2011-02-01 API 和 2013-01-01 API 不同。若要允許使用者存取 2011 和 2013 網域，IAM 政策中必須允許存取兩者的 ARN。例如：
```
{
"Statement": [
{
"Effect": "Allow",
"Action": [
"cloudsearch:*",
],
"Resource": "arn:aws:cloudsearch:*",
"Resource": "arn:aws:cs:*"
}
]
}
```
若您的 2011 政策授與了對特定網域或動作的存取權，則您必須將該等限制納入您的政策。請注意 2011 網域僅支援 `cloudsearch:*` 動作，且若您嘗試對透過 2011-01-01 API 所建立的網域設定資源層級許可，即有可能還會出現其他錯誤。
## 搜尋和文件服務存取政策未在 Amazon CloudSearch 中運作
如果您為網域的搜尋端點及文件服務端點設定了存取政策但收到*「403 請求已遭管理規則禁止」*的錯誤，即有可能是以下某一問題所導致。
+ 確定您已在請求中指定 API 版本和資源名稱。例如，若要使用 2013-01-01 API 上傳文件，網域的文件服務端點後面必須附加 `/2013-01-01/documents/batch`：
```
doc-movies-123456789012.us-east-1.cloudsearch.amazonaws.com/2013-01-01/documents/batch
```
若要使用 2013-01-01 API 提交搜尋請求，網域的搜尋端點後面必須附加 `/2013-01-01/search`：
```
search-movies-123456789012.us-east-1.cloudsearch.amazonaws.com/2013-01-01/search?q=star+wars&return=title
```
若要使用 2013-01-01 API 取得建議，網域的搜尋端點後面必須附加 `/2013-01-01/suggest`：
```
search-movies-123456789012.us-east-1.cloudsearch.amazonaws.com/2013-01-01/suggest?q=kat&suggester=mysuggester
```
+ 若您是從 EC2 執行個體連接，請確定存取政策已指定該 EC2 執行個體的公有 IP 位址。
+ 若您是從位於路由器後方的電腦連接，請確定存取政策已指定您面向公眾的 IP 位址。
如需詳細資訊，請參閱[設定 Amazon CloudSearch 的存取](configuring-access.md)。
## Amazon CloudSearch 主控台許可錯誤
若要存取主控台，您必須已獲許可執行 `DescribeDomains` 動作。特定網域和動作的存取可能受限於設定的 IAM 存取政策。此外，從 Amazon S3 儲存貯體或 DynamoDB 資料表上傳資料需要存取這些服務和資源。如需 Amazon CloudSearch 存取政策的詳細資訊，請參閱 [設定 Amazon CloudSearch 的存取](configuring-access.md)。
## 使用萬用字元搜尋文字欄位並未產生預期的結果
提交搜尋請求時，您要搜尋的文字會經歷相同的文字處理，因此可對索引中出現的文字加以比對。不過，當您執行字首搜尋時，不會對搜尋詞彙執行文字分析。這表示已啟用相關字詞功能時若搜尋以 `s` 結尾的字首，通常不會比對該字詞的單數形式。凡結尾為 `s` 的任何字詞皆會發生這種情況，而不單只限於複數。例如，假使您對電影範例資料的 `actor` 欄位搜尋 `Anders`，就會有三部符合條件的電影。若您搜尋 `Ander*`，則除了同樣三部以外還會多出其他幾部電影。然而，搜尋 `Anders*` 將找不到任何相符項目。這是因為存放於索引中的字詞為 `ander`，而 `anders` 並未出現在索引中。
如果相關字詞功能導致萬用字元搜尋未能傳回所有相關的相符項目，您可以透過將 `AlgorithmicStemming` 選項設為「無」抑制文字欄位的相關字詞功能，或者將資料對應至 `literal` 欄位而非 `text` 欄位。
如需 Amazon CloudSearch 如何處理文字的詳細資訊，請參閱 [Amazon CloudSearch 中的文字處理](text-processing.md)。
## 使用游標深入翻頁時得到不一致的結果
當您使用游標翻頁瀏覽依文件分數 (`_score`) 排序的結果集時，若兩次請求相隔其間發生了索引更新，您可能就會得到不一致的結果。如果您的網域複寫計數大於一，這種情況也有可能發生，因為更新會最終一致地套用於網域內的各執行個體。若您遇到此問題，請避免將結果依分數排序。您可以使用 `sort` 選項依特定欄位排序，或者使用 `fq` 代替 `q` 指定您的搜尋條件 (對篩選條件查詢不會計算文件分數)。
## 使用開發套件時的憑證錯誤
因為 AWS 開發套件是使用您的電腦的 CA 憑證，因此當您嘗試使用開發套件時，在 AWS 上的憑證變更可能導致連線失敗。錯誤訊息會不同，但通常包含以下文字：
```
SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
```
您可以將電腦的 CA 憑證和作業系統保持在最新版本以避免此類作業失敗。如果您在企業環境中遇到此問題，且並無管理使用專屬的電腦，則您可能需要尋求管理員協助更新程序。
以下清單列出作業系統及 Java 版本的最低版本需求：
+ 具備自 2005 年 1 月起之更新的 Microsoft Windows 版本，或更新版本 (其信任清單中需包含至少其中一項所需的 CA)。
+ Mac OS X 10.4 搭配適用於 Mac OS X 10.4 發行版本 5 (2007 年 2 月) 的 Java，Mac OS X 10.5 (2007 年 10 月) 和更新版本 (其信任清單中需包含至少其中一項所需的 CA)。
+ Red Hat Enterprise Linux 5 (2007 年 3 月)、6 和 7 以及 CentOS 5、6 和 7，全部均需在其預設信任 CA 清單中包含至少其中一項所需的 CA。
+ Java 1.4.2\$112 (2006 年 5 月)、5 更新版本 2 (2005 年 3 月) 及所有更新版本，包括 Java 6 (2006 年 12 月)、7 和 8 (其預設信任 CA 清單中需包含至少其中一項所需的 CA)。
三個憑證授權機構如下：
+ Amazon 根 CA 1
+ Starfield Services 根憑證認證機構：G2
+ Starfield 類別 2 憑證認證機構
前兩個授權機構的根憑證可以從 [Amazon 信任服務](https://www.amazontrust.com/repository/)取得，但是將電腦保持在最新狀態是更直接的解決方案。若要進一步了解 ACM 提供的憑證，請參閱 [AWS Certificate Manager 常見問答集](https://aws.amazon.com/certificate-manager/faqs/#certificates)。
**注意**
上述憑證目前仍非必要項目，但已排定於 2017 年 11 月部署至 AWS 伺服器。