Elasticsearch:一般的なエラー

原因

このエラーは、X-Pack SQL プラグインのクエリで、text 型のフィールドに LIKE 演算子 を使用すると発生します。

ソリューション

LIKE 演算子 は keyword 型フィールドの完全一致フィルタリングのみをサポートしています。代わりに keyword フィールドを使用するようにクエリを切り替えてください。

背景情報については、Unable to run SQL query on multi fields using Elastic Search v. 7.3 および SQL and multi-fields をご参照ください。

原因

フィールドが keyword としてマッピングされた場合、Elasticsearch は自動的に .keyword サブフィールドを作成しません。titleForSearch.keyword のような存在しないサブフィールドに対してワイルドカードクエリ文を実行しても、結果は返されません。

ソリューション

親フィールドに対して wildcard または regexp クエリを実行するように、クエリステートメントを更新します。 例：

{
  "query": {
    "wildcard": {
      "titleForSearch": "*keyword*"
    }
  }
}

最適化の提案

• アナライズされた全文検索が必要な場合は、データを再インデックスし、IK トークナイザーを使用してフィールドを text として明示的にマッピングしてください。

• keyword 型を保持する場合は、親フィールドをクエリし、不要な .keyword サフィックスを削除します。

• 動的マッピング戦略による差異を避けるために、アプリケーションコードでマッピングを明示的に定義してください。

原因

Elasticsearch は keyword 型を小文字でのみサポートします。マッピングで大文字の KEYWORD を使用すると、No handler for type [KEYWORD] エラーが発生します。

ソリューション

影響を受けるフィールドタイプを"KEYWORD"から"keyword"に変更し、マッピングを再送信します。

追加のトラブルシューティング

マッピングが正しいにもかかわらずエラーが続く場合は、ソースデータベースに新しく追加されたフィールドが原因で、DataWorks タスクなどの同期タスクが無効な型のマッピングを自動作成していないか確認してください。アプリケーションコードまたは同期ツールでフィールド定義を検証してください。

原因

このエラーは、コサイン距離測定関数で設定されたインデックスに対して、aliyun-knn プラグインを使用してベクトル検索を実行する際に表示されます。

ソリューション

以下を確認してください：

• クラスターバージョン： aliyun-knn プラグインには、カーネル V1.2 以降の Elasticsearch V6.7、またはカーネル V1.4 以降の Elasticsearch V7.10 が必要です。バージョン要件については、「aliyun-knn プラグインの使用」をご参照ください。

• スクリプトクエリメソッド： スクリプトクエリでは script_score パラメーターを使用する必要があります。

• フィールドのネスト： クエリで指定されたフィールドが、インデックスマッピングのネスト構造と一致していることを確認してください。インデックスがネストされたフィールドを使用している場合、クエリもそれに応じてネストされたフィールドを参照する必要があります。

原因

単一の一括書き込みリクエストが http.max_content_length の制限 (デフォルトは 100 MB) を超えています。この制限は変更しないでください。

ソリューション

リクエストごとに書き込まれるデータは、ドキュメント数に平均ドキュメントサイズを掛けたものに等しくなります。ドキュメントサイズは変動するため、リクエストあたり 5 MB からチューニングを開始し、最大 15 MB まで調整してください。ガイダンスについては、「バルクリクエストの使用とサイジング」および「HTTP 設定」をご参照ください。

原因

クラスターでインデックスの自動作成が無効になっています。

ソリューション

• 静的な方法 (推奨): [YML ファイル設定] パネルで自動インデックス作成を有効にします。 手順については、「YML ファイルを設定する」をご参照ください。

• 動的メソッド： 対応する API コマンドを実行して、クラスターを再起動せずにインデックスの自動作成を有効にしてください。

エラーの説明

このエラーは、クラスターが 1 つ以上のシャードでクエリを処理できない場合に表示されます。

原因

一般的な原因には、ノードの切断、再起動後のシャードのリカバリ中、またはディスクの破損などがあります。

ソリューション

ステップ 1：診断

クラスターのモニタリングデータとログを確認して、根本原因を特定してください。たとえば、ディスク容量の不足や、シャード割り当てを妨げるインデックスまたはクラスター設定の誤りなどです。

ステップ 2：未割り当てシャードの修正

ノードの切断または未割り当てシャードが原因の場合：

1. Kibana コンソールにログインします。

2. シャードの割り当て状況を確認します：

   説明

   すべてのシャードがすでに割り当てられている場合、このコマンドはエラーを返しますが、これは想定内の動作です。

   GET /_cluster/allocation/explain

3. 失敗したシャードの割り当てを再試行します：

POST /_cluster/reroute?retry_failed=true

原因

データノードのディスク使用量が 95% を超えると、Elasticsearch は書き込み保護をトリガーし、すべてのインデックスに read_only_allow_delete を設定します。書き込みはブロックされ、読み取りと削除のみが許可されます。85% のしきい値はシャードの作成に影響し、95% のしきい値は書き込み保護をトリガーします。

ソリューション

ステップ 1：高いディスク使用率 (根本原因) の解決

まず、根本的なディスク使用率の問題に対処してください。ディスク容量の拡張、未使用インデックスの削除、またはインデックスライフサイクル管理の設定などのオプションについては、「ディスク使用率の高さと読み取り専用インデックス」をご参照ください。

ステップ 2：書き込みアクセスの復元

ディスク使用率の問題を解決した後、すべてのインデックスの読み取り専用フラグをリセットしてください：

PUT */_settings
{
   "index.blocks.read_only_allow_delete": null
}

原因

SSL 接続を介してプレーンテキストトラフィックが送信されると、クラスターログに次のような SSL/TLS エラーが表示されます。これは通常、暗号化通信が有効になっていないノードが、暗号化が有効になっているノードに接続しようとする際に発生します。

content :
[o.e.t.TcpTransport ] [XBJo5pR] exception caught on transport layer [Netty4TcpChannel{localAddress=0.0.0.0/0.0.0.0:9300, remoteAddress=/89.248.xxx}], closing connection
io.netty.handler.codec.DecoderException: io.netty.handler.ssl.NotSslRecordException: not an SSL/TLS record: 0300002f2axxxx8
61736xxx a0100080003000000

ソリューション

以下を確認してください：

• HTTP と HTTPS の不一致： クラスターで HTTPS が有効になっていない場合、アクセスは HTTP 経由でのみ可能です。HTTPS 経由でクラスターにアクセスすると、このエラーが発生します。HTTPS を有効にするには、「HTTPS の有効化」をご参照ください。

• IP アドレスがホワイトリストにない： クラスターログに表示されている IP アドレスがパブリック IP アドレスホワイトリストに含まれていることを確認してください。必要な特定の IP アドレスまたは CIDR ブロックのみを追加し、0.0.0.0/0 は追加しないでください。

その他の SSL/TLS エラーパターンについては、「一般的な SSL/TLS の例外」をご参照ください。

原因

クラスターで API キー認証が有効になっていません。

ソリューション

API キーの使用には、クラスターで HTTPS が有効になっている必要があります。これを解決するには HTTPS を有効にしてください。「HTTPS の有効化」をご参照ください。

エラーの説明

Transport クライアント 5.5 または 5.6 を使用してポート 9300 経由で接続すると、次のようなエラーが表示されることがあります：

NoNodeAvailableException[None of the configured nodes are available: [{#transport#-1}{HVdK7Cffxxxx_P0c9nxxxx}{es-cn-v1qqweee****.elasticsearch.aliyuncs.com}{172.17.XX.XX:9300}]]

ソリューション

172.17.XX.XX IP アドレスは、クラスター内の実際のノードではありません。これは、該当するクライアントバージョンの既知の問題です。代わりに Transport Client 5.3.3 を使用してください。詳細については、「Transport Client (5.x)」をご参照ください。

エラーの説明

apack.qos.ratelimit.enabled でスロットリングを有効にすると、リミッターを設定する際に次のエラーが表示されます：

{
   "error": {
      "root_cause": [
         {
            "type": "unsupported_operation_exception",
            "reason": "unsupported_operation_exception: only define search or bulk action for limit"
         }
      ],
      "type": "unsupported_operation_exception",
      "reason": "unsupported_operation_exception: only define search or bulk action for limit"
   },
   "status": 500
}

原因

aliyun-qos プラグインは最新バージョンではありません。GET /_cat/plugins?vを実行して現在のバージョンを確認します。想定される最新バージョンは次のとおりです。

• Elasticsearch V7.10： 7.10.0_ali1.6.0.2

• 他のすべてのバージョン： <ES version>-rc4

ソリューション

クラスターのバージョンに基づいてアップグレードしてください：

• V7.10 クラスター： カーネルを V1.6.0 にアップグレードしてください。「クラスターのバージョンをアップグレード」をご参照ください。

• その他のバージョン： Elasticsearch の技術エンジニアにプラグインをアップグレードしてもらうには、チケットを起票してください。アップグレード後、変更を有効にするためにクラスターを再起動してください。

原因

これらのエラーは、オープンソースの Elasticsearch 7.4 のバグが原因であり、業務への影響はありません。このバグは 7.4 より後のバージョンで修正されています。

ソリューション

Alibaba Cloud Elasticsearch V7.4 は提供を終了しています。より新しいバージョンを実行しているクラスターを購入してください。切り替え前にデータを移行する必要がある場合は、「データ移行ソリューションの選択」を参照して、ワークロードに適したアプローチを選択してください。

原因

ターゲットの Object Storage Service (OSS) バケットがアーカイブストレージクラスを使用している場合、PUT _snapshot/my_backup を実行するとこのエラーが発生します。アーカイブバケットからデータを読み取るにはオブジェクトの復元が必要ですが、これは Elasticsearch のスナップショット操作と互換性がありません。

ソリューション

Elasticsearch クラスターと同じリージョンにある標準ストレージクラスの OSS バケットを使用してください。手順については、「手動スナップショットの作成と手動スナップショットからのデータ復元」をご参照ください。