Documentation really needs to be improved. I was also looking for similar thing. I’ve OpenSearch 2.3 and willing to upgrade it to 2.4 in proper way (without/less downtime, no loss of data). Cannot find best practicies for upgrade yet.
So as far as I am aware there are only 2 modes of upgrading major versions. The first is a blue/green where you bring up a new cluster, begin directing traffic to it and then migrate the older data to it with a job such as consuming from the old cluster with fluentbit. This method is no downtime but is more work as it assumes you can stand up two clusters side by side and have a mechanism to easily switch traffic from one cluster to another.
The second, is to do an in place migration where you on the same nodes stop OpenSearch, then on the same nodes, upgrade OpenSearch and so long as you are mounting the same data store location it should find it and then update all the metadata to support the new version. This method requires downtime. Unless you have a queue in front of OpenSearch (like Kafka) then there is the potential that data sent during this period could be lost. Assuming you are using fluentbit you could leverage its buffering but it is fairly limited and isn’t really designed to be a resilient queue.