ES5.5.0 query instability analysis and solutions

Problem Description

  1. When querying data based on keywords, it can be found the previous time, but may not be found when querying again (appears when the data has just been written)
  2. When using the general query interface, the number of queries is unstable (appears when the data is just written)

Summary: After data consumption is written to ES, after a refresh cycle (usually 30s or 60s for large amounts of data), the data is processed in batches to generate segments and index prefixes, which can be queried externally, but the query will not Stable conditions, generally do not exceed 1 minute to stabilize.

Cause Analysis

Elasticsearch's index shards have two attributes: primary shard and replica. The function of the replica is failover and load balancing.

Failover: When the host or node where the primary shard is located fails, the replica is automatically upgraded to the primary shard.

Load balancing: Both the primary shard and the replica provide the same query capability externally.

When data is written, it is first written to the main shard, and then synchronized to the corresponding index shard from the main shard. If multiple queries are performed during this period, es will perform load balancing and randomly select the primary shard or replica to perform the query task. At this time, there is no data on the replica, and query instability will occur.

solution

ES provides a preference query mode preference, which has the following parameters in version 5.5:

  • _primary is only queried on the primary shard
  • _primary_first Query on the primary shard first, if the primary shard is unavailable or the query fails, query on the replica
  • _replica only queries on the replica
  • _replica_first Query on the replica first, if the replica is not available or the query fails, query on the primary shard
  • _local If the local shard is available, the query will be executed on the local shard first
  • _prefer_nodes:abc,xyz preferentially query on the node with the specified id
  • _shards: 2, 3 priority to query on the shard with the specified id
  • _only_nodes is limited to perform operations on specific nodes
  • Custom (string) value

Most of the time it is not necessary to use the preference function deliberately.

According to the current data scenario, primary_first or replica_first can be used to solve query instability, but it will increase the query pressure of the cluster and cannot use the load balancing function.

Guess you like

Origin blog.csdn.net/yml_try/article/details/108647525
Recommended