The linked post on Stackoverflow does not describe a way to roll back without data loss although it may only result in silent data loss in the versions mentioned there. I think it will not work at all when downgrading from 7.3.2 since protection was recently added to prevent this kind of unsafe activity.
Yeah, I have no experience on 7.3.2. But I did downgrade from 6.1 to 5.6 a couple of weeks back successfully. This wasn't documented, but I had to give it a try (see the reason below, it might help ES with some feedback):
- Take one master node down
- Delete the state files under /nodes/0 (data dir of dedicated master node)
- Start the master with 5.6
- Wait for it to join the cluster (it actually did)
- Repeat the above steps for rest of the master nodes
These were dedicated master nodes, BTW. Reason below (fun part):
We had an existing configuration to increase the max_compilations_per_min in our cluster settings. While upgrading the cluster, it started complaining after completing dedicated master upgrades that the configuration is deprecated, so you need to unset the configuration from cluster settings in order to complete the upgrade. However, there ain't anyway in Elastic to unset this particular cluster setting (I am surprised). We spent good amount of time on it, but nothing worked. At this point, I couldn't upgrade the cluster nor rollback (at least per documentation). I had to do something since this was our production cluster. So, I ended up trying the above steps (that's the only logical thing I could think of then).