# How to understand translog stats

**URL:** <https://discuss.elastic.co/t/how-to-understand-translog-stats/300507>\
**Category:** Elasticsearch\
**Created:** [March 23, 2022, 11:57pm UTC](https://discuss.elastic.co/t/how-to-understand-translog-stats/300507 "2022-03-23T23:57:16Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![jthoni](https://avatars.discourse-cdn.com/v4/letter/j/b9e5f3/32.png) [@jthoni](https://discuss.elastic.co/u/jthoni)\
**Post date:** [March 23, 2022, 11:57pm UTC](https://discuss.elastic.co/t/how-to-understand-translog-stats/300507/1 "2022-03-23T23:57:16Z")

</div>

We are seeing the situation where when we restart ES, there is a long recovery time for the shards. The service is down usually for only about 90 seconds, but the recovery can be an hour or so. During my investigation, I am looking at the [index]/\_stats?level=shards api. I see this:

```auto
      "translog" : {
        "operations" : 1024765,
        "size_in_bytes" : 46171546377,
        "uncommitted_operations" : 502502,
        "uncommitted_size_in_bytes" : 21484734315,
        "earliest_last_modified_age" : 0
      },

```

I just want to understand what this is telling me so I can figure out if it is normal or not.

We are using the defaults for translog (v 6.8.8), so I would think the translog is getting flushed with each successful operation. If I look at the above, it is telling me that there is ~21 GB of uncommitted data. If it is getting flushed continuously, shouldn't this be much lower?

The index has 80 primary shards (with 2 replicas). Each shard is ~35-45 GB, and a total index size of 2.9 TB and 5.3 billion docs.

Thanks!

---

<div class="post-metadata">

**Author:** ![casterQ](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/casterq/32/93257_2.png) [@casterQ](https://discuss.elastic.co/u/casterQ)\
**Post date:** [March 24, 2022, 7:58am UTC](https://discuss.elastic.co/t/how-to-understand-translog-stats/300507/2 "2022-03-24T07:58:01Z")

</div>

The function of `translog` is to ensure data security and replay the operation(without falling disk) when there is a problem, `flush` operation will clear the translog

---

<div class="post-metadata">

**Author:** ![jthoni](https://avatars.discourse-cdn.com/v4/letter/j/b9e5f3/32.png) [@jthoni](https://discuss.elastic.co/u/jthoni)\
**Post date:** [March 24, 2022, 3:12pm UTC](https://discuss.elastic.co/t/how-to-understand-translog-stats/300507/3 "2022-03-24T15:12:06Z")

</div>

I have a rough idea of what translog is and why it is used. My question is around interpreting the response from the \_stats api. If we are not setting anything for index.translog.durability, I am assuming we are set for "request:"

> `request`
> 
> (default) `fsync` and commit after every request. In the event of hardware failure, all acknowledged writes will already have been committed to disk.

Should I expect therefore that the uncommitted\_operations is fairly low (as the operation should get flushed on completion)? I am just not certain if having a constant ~20 gb of uncommitted\_size\_in\_bytes is normal, or a sign of an issue.

Again, my goal is to track down why reinitialization of a shard takes an hour when the node was only offline for 90 seconds. If it was incorrectly replaying an inflated translog, that could be the reason.

---

<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:** [April 21, 2022, 3:12pm UTC](https://discuss.elastic.co/t/how-to-understand-translog-stats/300507/4 "2022-04-21T15:12:50Z")

</div>

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