Amazon 故障 CloudSearch

下列主題說明您在使用 Amazon 時可能遇到的問題的解決方案 CloudSearch。

上傳文件

如果您的文件資料格式不正確或包含無效的值，當您嘗試上傳該文件或將其用於為您的網域設定欄位時就會收到錯誤。以下是一些常見問題及其解決方案：

• 無效的 JSON — 如果您使用的是 JSON，首先要做的是確保文檔批次中沒有 JSON 語法錯誤。為此，請透過驗證工具如 JSON 驗證程式執行檢查。這可找出資料的任何基本問題。

• 無效的 XML — 文件批次必須是格式正確的 XML。若您的欄位包含 XML 資料，即尤其可能會遇到問題；資料必須為 XML 編碼或用 CDATA 區段括住。要找出任何問題，請透過驗證工具如 W3C 標記驗證服務執行您的文件批次。

• 無法辨識為文件 Batch — 如果 Amazon 在您使用主控台上傳資料時，Amazon CloudSearch 無法將您的資料辨識為有效的文件批次，Amazon CloudSearch 會產生包含單一內容欄位和一般中繼資料欄位 (例如content_encodingcontent_type、和resourcename) 的有效批次。由於這些欄位通常並非供網域設定使用，您將收到指出欄位不存在的錯誤。同樣地，如果您嘗試從無效批次設定網域，Amazon 會 CloudSearch 回應內容和中繼資料欄位，而不是批次中的欄位。

  首先，確認批次為有效的 XML 或 JSON。如果是，則檢查有否任何無效的文件 ID，並確認已為每份文件指定操作類型。對於新增操作，確認每份文件皆有指定類型、ID 以及至少一個欄位。刪除操作則只需指定類型和 ID。如需資料格式化方式的詳細資訊，請參閱Creating Document Batches。

• 含有錯誤值的文件 ID — 文件 ID 可以包含任何字母或數字，以及下列字元：_-= #;:/? @ &. 文件 ID 必須至少為 1，且不得超過 128 個字元。

• 沒有值的多值欄位 — 在 JSON 中指定文件資料時，您無法將空陣列指定為欄位的值。多值欄位必須包含至少一個值。

• 錯誤字元 — 如果您在產生文件批次時未篩選資料，可能很難偵測到的一個問題是，可能會包含 XML 中無效的字元。JSON 和 XML 批次均只能包含有效 XML 格式的 UTF-8 字元。您可以使用 JSON 驗證程式或 W3C 標記驗證服務之類的驗證工具找出無效的字元。

刪除 Amazon CloudSearch 域中的所有文檔

Amazon CloudSearch 目前不提供刪除域中所有文檔的機制。

刪除文檔後，Amazon CloudSearch 域名不會縮小

如果您的網域已擴充以容納索引大小，而您刪除了大量文件，則網域會在下次重建完整索引時縮減。雖然索引會定期自動重建，但為了盡快縮小規模，您可以在完成刪除文件後明確執行索引。

文件更新延遲

傳送大量的單一文件批次可能導致每份文件轉變為可搜尋所需的時間增加。如果您的更新將產生大量流量，即必須以批次方式進行更新。建議您使用接近 5 MB 上限的批次大小。如需詳細資訊，請參閱 Creating Document Batches。

您可以每天 (每隔 24 小時) 載入多達 10,000 個文件批次，每一批次的大小達 5 MB。每天載入的資料量過多將致使文件更新延遲情況益發嚴重。為了減輕此風險，您可以選擇較大的執行個體類型，以提高更新容量。如需詳細資訊，請參閱 在 Amazon 中設定擴展選項 CloudSearch。

將文檔上傳到 Amazon CloudSearch 域時出現大量 5xx 錯誤

如果您平行化上傳，且您的網域位於 search.small 執行個體上，您可能會遇到令人難以接受的 504 或 507 錯誤率。將所需的執行個體類型設為更大的執行個體類型，會增加您的更新容量並降低錯誤率。如需如何處理 5xx 錯誤的詳細資訊，請參閱處理錯誤。如需如何預先調整網域規模以增加上傳容量的相關資訊，請參閱在 Amazon 中設定擴展選項 CloudSearch。

在 Amazon 中搜索延遲和超時 CloudSearch

若您遇到回應時間過久或頻繁出現內部伺服器錯誤 (通常為 507 或 509 錯誤) 的狀況，或者察覺您的搜尋網域在搜尋的資料量並未大幅增加的情形下仍迭增耗用執行個體時數，則微調您的搜尋請求以減少處理負擔將有所助益。如需詳細資訊，請參閱 在 Amazon 中調整搜索請求性能 CloudSearch。增加所需的複寫計數也可加速處理搜尋請求。如需詳細資訊，請參閱 在 Amazon 中設定擴展選項 CloudSearch。

507 和 509 錯誤通常表示您的搜尋服務已超載。這可能是因為您提交的搜尋請求數量或複雜性所致。Amazon CloudSearch 通常會自動擴展以處理負載。由於部署其他搜尋執行個體需要一些時間，因此建議您使用指數輪詢重試原則來暫時降低要求率並將要求失敗率降至最低。如需詳細資訊，請參閱錯誤重試和指數輪詢。

某些使用模式 (例如將複雜的搜尋查詢提交至單一小型搜尋執行個體) 有時可能會導致逾時，而不會觸發自動調整規模。如果您重複遇到很高的錯誤率，可以透過 Amazon CloudSearch 服務限制請求表單明確要求額外容量。

在 Amazon 中搜索多面查詢的延遲 CloudSearch

若您使用 buckets 選項依值區歸納面向資訊卻發生查詢效能遲緩的狀況，請嘗試將值區方法設為 interval。如需詳細資訊，請參閱 依值區歸納面向資訊。

搜索 Amazon CloudSearch 域時，5xx 錯誤突然增加

如果您的搜尋網域流量突然激增，Amazon 會在您的網域中新增搜尋執行個體以處理增加的負載進行 CloudSearch 回應。不過，設定新的執行個體需要幾分鐘的時間。在新的執行個體已就緒可開始處理請求之前，您可能會遇到 5xx 錯誤一時增多的情形。如需如何處理 5xx 錯誤的詳細資訊，請參閱處理錯誤。如需如何預先調整網域規模以處理預期的搜尋請求高峰的相關資訊，請參閱在 Amazon 中設定擴展選項 CloudSearch。

在 Amazon 中更新索引選項後索引失敗 CloudSearch

若您變更了網域的索引組態，當您編製索引時，某些情況下可能會出現「驗證失敗」的錯誤。這表示您所設定的索引欄位選項與您的索引中現存的文件不相容。特別是您變更了索引欄位的類型，而您的索引中有些文件其所含資料與該類型不相容所致。例如，假使您將 literal 欄位變更為 int 欄位，而您有些文件的該欄位包含英數資料，可能就會發生這種情況。發生這種情況時，Amazon 會將正在處理的所有欄位的狀態 CloudSearch 設定為該FailedToValidate州。還原不相容的組態變更，即可成功重新建立索引。若是必要的變更，請務必將不相容的文件從索引中移除，方可使用新的組態。若您無法找出是哪些變更造成錯誤或需要協助辨別不相容的文件，請聯絡支援部門。

提交 Amazon CloudSearch 請求時找不到域

您無法使用 2011-02-01 命令列工具或軟體開發套件存取網域。同樣地，您無法使用命令列工具或軟體開發套件存取 2011-02-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 位址。

如需詳細資訊，請參閱 configure access policies。

Amazon CloudSearch 主控台許可錯誤

若要存取主控台，您必須已獲許可執行 DescribeDomains 動作。對特定網域和動作的存取權限可能受到設定的 IAM 存取政策的限制。此外，從 Amazon S3 儲存貯體或 DynamoDB 表格上傳資料需要存取這些服務和資源。如需 Amazon CloudSearch 存取政策的詳細資訊，請參閱configure access policies。

使用萬用字元搜尋文字欄位並未產生預期的結果

提交搜尋請求時，您要搜尋的文字會經歷相同的文字處理，因此可對索引中出現的文字加以比對。不過，當您執行字首搜尋時，不會對搜尋詞彙執行文字分析。這表示已啟用相關字詞功能時若搜尋以 s 結尾的字首，通常不會比對該字詞的單數形式。凡結尾為 s 的任何字詞皆會發生這種情況，而不單只限於複數。例如，假使您對電影範例資料的 actor 欄位搜尋 Anders，就會有三部符合條件的電影。若您搜尋 Ander*，則除了同樣三部以外還會多出其他幾部電影。然而，搜尋 Anders* 將找不到任何相符項目。這是因為存放於索引中的字詞為 ander，而 anders 並未出現在索引中。

如果相關字詞功能導致萬用字元搜尋未能傳回所有相關的相符項目，您可以透過將 AlgorithmicStemming 選項設為「無」抑制文字欄位的相關字詞功能，或者將資料對應至 literal 欄位而非 text 欄位。

如需 Amazon 如何 CloudSearch 處理文字的詳細資訊，請參閱Amazon CloudSearch 的文字處理。

使用游標深入翻頁時得到不一致的結果

當您使用游標翻頁瀏覽依文件分數 (_score) 排序的結果集時，若兩次請求相隔其間發生了索引更新，您可能就會得到不一致的結果。如果您的網域複寫計數大於一，這種情況也有可能發生，因為更新會最終一致地套用於網域內的各執行個體。若您遇到此問題，請避免將結果依分數排序。您可以使用 sort 選項依特定欄位排序，或者使用 fq 代替 q 指定您的搜尋條件 (對篩選條件查詢不會計算文件分數)。

使用開發套件時的憑證錯誤

因為 AWS 開發套件是使用您的電腦的 CA 憑證，因此當您嘗試使用開發套件時，在 AWS 上的憑證變更可能導致連線失敗。錯誤訊息會不同，但通常包含以下文字：

SSL3_GET_SERVER_CERTIFICATE:certificate verify failed

您可以保留電腦的 CA 憑證和作業系統，以防止這些失敗 up-to-date。如果您在企業環境中遇到此問題，且並無管理使用專屬的電腦，則您可能需要尋求管理員協助更新程序。

以下清單列出作業系統及 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_12 (2006 年 5 月)、5 更新版本 2 (2005 年 3 月) 及所有更新版本，包括 Java 6 (2006 年 12 月)、7 和 8 (其預設信任 CA 清單中需包含至少其中一項所需的 CA)。

三個憑證授權機構如下：

• Amazon 根 CA 1

• Starfield Services 根憑證授權機構：G2

• Starfield 類別 2 憑證授權機構

前兩個授權單位的根憑證可從 Amazon 信任服務取得，但保留電腦 up-to-date 是更直接的解決方案。若要進一步了解 ACM 提供的憑證，請參閱 AWS Certificate Manager 常見問答集。

注意

上述憑證目前仍非必要項目，但已排定於 2017 年 11 月部署至 AWS 伺服器。