# Cluster state when gateway is down **URL:** \ **Category:** Elasticsearch\ **Created:** [August 8, 2010, 10:14pm UTC](https://discuss.elastic.co/t/cluster-state-when-gateway-is-down/3197 "2010-08-08T22:14:56Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![ppearcy](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/ppearcy/32/980_2.png) [@ppearcy](https://discuss.elastic.co/u/ppearcy)\ **Post date:** [August 8, 2010, 10:14pm UTC](https://discuss.elastic.co/t/cluster-state-when-gateway-is-down/3197/1 "2010-08-08T22:14:56Z")
First off, I was thrilled when I tested out what would happen when my gateway goes away. It appears that the cluster snapshot just fails that time around and all the transactions pending snapshotting are kept until the gateway is available again and all is snapshotted and happy. So, this means you don't need to ensure 100% gateway uptime. However, it would be awesome if the cluster health could somehow reflect that the gateway is unavailable. While the gateway is unavailable, large swaths of data could be lost if a cluster shutdown occurs. Any thoughts? Thanks, Paul ---
**Author:** ![kimchy](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/kimchy/32/44952_2.png) [@kimchy](https://discuss.elastic.co/u/kimchy)\ **Post date:** [August 8, 2010, 10:18pm UTC](https://discuss.elastic.co/t/cluster-state-when-gateway-is-down/3197/2 "2010-08-08T22:18:12Z")
Agreed. Need to think which API would best fit that, the cluster health or the index status API. I plan to also add index stats API which will probably include how long and when the last snapshot was taken (and if there is on in progress "now"). -shay.banon On Mon, Aug 9, 2010 at 1:14 AM, Paul [ppearcy@gmail.com](mailto:ppearcy@gmail.com) wrote: > First off, I was thrilled when I tested out what would happen when my > gateway goes away. It appears that the cluster snapshot just fails > that time around and all the transactions pending snapshotting are > kept until the gateway is available again and all is snapshotted and > happy. So, this means you don't need to ensure 100% gateway uptime. > > However, it would be awesome if the cluster health could somehow > reflect that the gateway is unavailable. While the gateway is > unavailable, large swaths of data could be lost if a cluster shutdown > occurs. > > Any thoughts? > > Thanks, > Paul ---
**Author:** ![kimchy](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/kimchy/32/44952_2.png) [@kimchy](https://discuss.elastic.co/u/kimchy)\ **Post date:** [August 8, 2010, 10:19pm UTC](https://discuss.elastic.co/t/cluster-state-when-gateway-is-down/3197/3 "2010-08-08T22:19:28Z")
Ohh, and to reassure you, yes, this is by design that the cluster can survive gateway "(long) hiccups". -shay.banon On Mon, Aug 9, 2010 at 1:18 AM, Shay Banon [shay.banon@elasticsearch.com](mailto:shay.banon@elasticsearch.com)wrote: > Agreed. Need to think which API would best fit that, the cluster health or > the index status API. I plan to also add index stats API which will probably > include how long and when the last snapshot was taken (and if there is on in > progress "now"). > > -shay.banon > > On Mon, Aug 9, 2010 at 1:14 AM, Paul [ppearcy@gmail.com](mailto:ppearcy@gmail.com) wrote: > > > First off, I was thrilled when I tested out what would happen when my > > gateway goes away. It appears that the cluster snapshot just fails > > that time around and all the transactions pending snapshotting are > > kept until the gateway is available again and all is snapshotted and > > happy. So, this means you don't need to ensure 100% gateway uptime. > > > > However, it would be awesome if the cluster health could somehow > > reflect that the gateway is unavailable. While the gateway is > > unavailable, large swaths of data could be lost if a cluster shutdown > > occurs. > > > > Any thoughts? > > > > Thanks, > > Paul ---
**Author:** ![ppearcy](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/ppearcy/32/980_2.png) [@ppearcy](https://discuss.elastic.co/u/ppearcy)\ **Post date:** [August 13, 2010, 3:39am UTC](https://discuss.elastic.co/t/cluster-state-when-gateway-is-down/3197/4 "2010-08-13T03:39:23Z")
Yeah, very cool and impressive stuff 🙂 FYI, I opened this ticket to track: > > > Expose both recovery (either from gateway or another peer) and snapshot status, …including both real time status and the last status. On Aug 8, 4:19 pm, Shay Banon [shay.ba...@elasticsearch.com](mailto:shay.ba...@elasticsearch.com) wrote: > Ohh, and to reassure you, yes, this is by design that the cluster can > survive gateway "(long) hiccups". > > -shay.banon > > On Mon, Aug 9, 2010 at 1:18 AM, Shay Banon [shay.ba...@elasticsearch.com](mailto:shay.ba...@elasticsearch.com)wrote: > > > Agreed. Need to think which API would best fit that, the cluster health or > > the index status API. I plan to also add index stats API which will probably > > include how long and when the last snapshot was taken (and if there is on in > > progress "now"). > > > -shay.banon > > > On Mon, Aug 9, 2010 at 1:14 AM, Paul [ppea...@gmail.com](mailto:ppea...@gmail.com) wrote: > > > > First off, I was thrilled when I tested out what would happen when my > > > gateway goes away. It appears that the cluster snapshot just fails > > > that time around and all the transactions pending snapshotting are > > > kept until the gateway is available again and all is snapshotted and > > > happy. So, this means you don't need to ensure 100% gateway uptime. > > > > However, it would be awesome if the cluster health could somehow > > > reflect that the gateway is unavailable. While the gateway is > > > unavailable, large swaths of data could be lost if a cluster shutdown > > > occurs. > > > > Any thoughts? > > > > Thanks, > > > Paul ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [July 6, 2017, 4:20am UTC](https://discuss.elastic.co/t/cluster-state-when-gateway-is-down/3197/5 "2017-07-06T04:20:50Z")
Closed on July 6, 2017, 4:20am UTC