# Metrics for replica sync - ES 7.0.1

**URL:** <https://discuss.elastic.co/t/metrics-for-replica-sync-es-7-0-1/227866>\
**Category:** Elasticsearch\
**Created:** [April 14, 2020, 7:48am UTC](https://discuss.elastic.co/t/metrics-for-replica-sync-es-7-0-1/227866 "2020-04-14T07:48:44Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![dinesh\_gnanasamy](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/dinesh_gnanasamy/32/63402_2.png) [@dinesh\_gnanasamy](https://discuss.elastic.co/u/dinesh_gnanasamy)\
**Post date:** [April 14, 2020, 7:48am UTC](https://discuss.elastic.co/t/metrics-for-replica-sync-es-7-0-1/227866/1 "2020-04-14T07:48:44Z")

</div>

Are there any specific metrics which indicate if the replica shards are out of sync wrt primary shards.

I checked something which appears relatively closer from `_cat/shards` API

`seq_no.global_checkpoint` , `sqg` , `globalCheckpoint` - Global checkpoint.  
`seq_no.local_checkpoint` , `sql` , `localCheckpoint` - Local checkpoint

But I was looking for some metric which is derived from checkpoint values which would be more on lines of `List of shards which are currently out of sync with their corresponding primaries`

Are there any such direct out-of-sync metrics available or in case no such direct metrics are available,

1. Is it logical to derive from above checkpoint values shardwise ?
2. What is the exact way of deriving the same from checkpoint values ?

Thanks in advance

- dinesh

---

<div class="post-metadata">

**Author:** ![DavidTurner](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/davidturner/32/22453_2.png) [@DavidTurner](https://discuss.elastic.co/u/DavidTurner)\
**Post date:** [April 14, 2020, 8:15am UTC](https://discuss.elastic.co/t/metrics-for-replica-sync-es-7-0-1/227866/2 "2020-04-14T08:15:53Z")

</div>

Running replicas are never out-of-sync with the primary, so it's not really clear what you're trying to do here.

---

<div class="post-metadata">

**Author:** ![dinesh\_gnanasamy](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/dinesh_gnanasamy/32/63402_2.png) [@dinesh\_gnanasamy](https://discuss.elastic.co/u/dinesh_gnanasamy)\
**Post date:** [April 16, 2020, 9:10am UTC](https://discuss.elastic.co/t/metrics-for-replica-sync-es-7-0-1/227866/3 "2020-04-16T09:10:21Z")

</div>

@DavidTurner,

Since the replication is asynchronous (as I understand clients are ack'd for writes by ES after primary shards complete local translog persistence), would there no be possibility of replica not being able to catch-up with primary due to factors like long-pause GCs even when the cluster is in steady state - even without HA conditions like recovery ?

-dinesh

---

<div class="post-metadata">

**Author:** ![DavidTurner](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/davidturner/32/22453_2.png) [@DavidTurner](https://discuss.elastic.co/u/DavidTurner)\
**Post date:** [April 16, 2020, 9:25am UTC](https://discuss.elastic.co/t/metrics-for-replica-sync-es-7-0-1/227866/4 "2020-04-16T09:25:50Z")

</div>

Replication is synchronous: indexing is not acked until all active shard copies have persisted the operations.

---

<div class="post-metadata">

**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\
**Post date:** [May 14, 2020, 9:25am UTC](https://discuss.elastic.co/t/metrics-for-replica-sync-es-7-0-1/227866/5 "2020-05-14T09:25:55Z")

</div>

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.