# Can't take down deprecated node without breaking communication (and missing logs)

**URL:** <https://discuss.elastic.co/t/cant-take-down-deprecated-node-without-breaking-communication-and-missing-logs/56544>\
**Category:** Elasticsearch\
**Created:** [July 27, 2016, 3:49pm UTC](https://discuss.elastic.co/t/cant-take-down-deprecated-node-without-breaking-communication-and-missing-logs/56544 "2016-07-27T15:49:23Z")\
**Posts on this page:** 3\
**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:** [July 27, 2016, 3:49pm UTC](https://discuss.elastic.co/t/cant-take-down-deprecated-node-without-breaking-communication-and-missing-logs/56544/1 "2016-07-27T15:49:23Z")

</div>

I have been running into many problems trying to upgrade my cluster from 2.0.0 to 2.3.2 (see [Problems with mixed version cluster during rolling upgrade?](https://discuss.elastic.co/t/problems-with-mixed-version-cluster-during-rolling-upgrade/56318)).

I finally went ahead and brought up new clean VM's with 2.3.2 and added them to the cluster. Once all allocation was complete, I pulled one 2.0.0 node out at a time, waiting for state to return to green before removing the next.

This process went fine until I took out the 2.0.0 node that had been the master. When I took it out, the entire cluster lost communication (i.e. I could not even get stats with Sense). I bought that node back up, and 30 seconds later the cluster was back. A 2.3.2 cluster was selected as master, so now this 2.0.0 node is in the cluster, but it is not the master, and is not hosting _any_ shards. It does not seem to have any purpose, but when I take it down, the entire cluster fails.

I tried digging into logs, and I am finding that the 2.0.0 node is the only one outputting any logs. If I send an intentionally malformed query to the cluster, the "Failed to execute" log entry appears on the 2.0.0 node, but I see nothing on the 2.3.2 nodes. This leads me to think that logging is at the root of this such that if I bring down 2.0.0 the cluster fails as it can't write logs. Why would this be? I am using the same logging strategy on the new nodes as I have on all my other nodes. In config.yml I have:

path.logs: F:\logs

I run ES as a service, so in _bin/service.bat manager_ I have set the "Log path" to "F:\logs."

Note that on the new nodes I _do_ see things like the cluster.service remove/added messages when other nodes come up / go down.

Thanks!  
~john

---

<div class="post-metadata">

**Author:** ![javanna](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/javanna/32/4698_2.png) [@javanna](https://discuss.elastic.co/u/javanna)\
**Post date:** [July 28, 2016, 11:42am UTC](https://discuss.elastic.co/t/cant-take-down-deprecated-node-without-breaking-communication-and-missing-logs/56544/2 "2016-07-28T11:42:03Z")

</div>

> [@jthoni](#):
>
> If I send an intentionally malformed query to the cluster, the "Failed to execute" log entry appears on the 2.0.0 node, but I see nothing on the 2.3.2 nodes.

Which node are you sending that malformed request to?

What is the output of `GET /_cat/nodes?v` and `GET _cluster/health`?

---

<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:** [July 5, 2017, 10:32pm UTC](https://discuss.elastic.co/t/cant-take-down-deprecated-node-without-breaking-communication-and-missing-logs/56544/3 "2017-07-05T22:32:05Z")

</div>