This documentation contains work-in-progress information for future Elastic Stack and Cloud releases. Use the version selector to view supported release docs. It also contains some Elastic Cloud serverless information. Check out our serverless docs for more details.

« Failback when clusterA comes back Data store architecture »

› › ›

Perform update or delete by query

edit

Perform update or delete by query

edit

It is possible to update or delete the documents but you can only perform these actions on the leader index.

First identify which backing index contains the document you want to update.

resp = client.search(
    index="logs-generic-default*",
    filter_path="hits.hits._index",
    query={
        "match": {
            "event.sequence": "97"
        }
    },
)
print(resp)

response = client.search(
  index: 'logs-generic-default*',
  filter_path: 'hits.hits._index',
  body: {
    query: {
      match: {
        'event.sequence' => '97'
      }
    }
  }
)
puts response

const response = await client.search({
  index: "logs-generic-default*",
  filter_path: "hits.hits._index",
  query: {
    match: {
      "event.sequence": "97",
    },
  },
});
console.log(response);

### On either of the cluster ###
GET logs-generic-default*/_search?filter_path=hits.hits._index
{
"query": {
    "match": {
      "event.sequence": "97"
    }
  }
}

If the hits returns "_index": ".ds-logs-generic-default-replicated_from_clustera-<yyyy.MM.dd>-*", then you need to proceed to the next step on cluster A.
If the hits returns "_index": ".ds-logs-generic-default-replicated_from_clusterb-<yyyy.MM.dd>-*", then you need to proceed to the next step on cluster B.
If the hits returns "_index": ".ds-logs-generic-default-<yyyy.MM.dd>-*", then you need to proceed to the next step on the same cluster where you performed the search query.

Perform the update (or delete) by query:

resp = client.update_by_query(
    index="logs-generic-default",
    query={
        "match": {
            "event.sequence": "97"
        }
    },
    script={
        "source": "ctx._source.event.original = params.new_event",
        "lang": "painless",
        "params": {
            "new_event": "FOOBAR"
        }
    },
)
print(resp)

response = client.update_by_query(
  index: 'logs-generic-default',
  body: {
    query: {
      match: {
        'event.sequence' => '97'
      }
    },
    script: {
      source: 'ctx._source.event.original = params.new_event',
      lang: 'painless',
      params: {
        new_event: 'FOOBAR'
      }
    }
  }
)
puts response

const response = await client.updateByQuery({
  index: "logs-generic-default",
  query: {
    match: {
      "event.sequence": "97",
    },
  },
  script: {
    source: "ctx._source.event.original = params.new_event",
    lang: "painless",
    params: {
      new_event: "FOOBAR",
    },
  },
});
console.log(response);

### On the cluster identified from the previous step ###
POST logs-generic-default/_update_by_query
{
  "query": {
    "match": {
      "event.sequence": "97"
    }
  },
  "script": {
    "source": "ctx._source.event.original = params.new_event",
    "lang": "painless",
    "params": {
      "new_event": "FOOBAR"
    }
  }
}

If a soft delete is merged away before it can be replicated to a follower the following process will fail due to incomplete history on the leader, see index.soft_deletes.retention_lease.period for more details.

« Failback when clusterA comes back Data store architecture »