Hi, Some months ago I posted a question on this list (see [1]) about the possibility of supporting "rolling downgrade" in Geode in order to downgrade a Geode system to an older version, similar to the "rolling upgrade" currently supported. With your answers and my investigations my conclusion was that the main stumbling block to support "rolling downgrades" was the compatibility of persistent files which was very hard to achieve because old members would require to be prepared to support newer versions of persistent files.
We have come up with a new approach to support rolling downgrades in Geode which consists of the following procedure: - For each locator: - Stop locator - Remove locator files - Start locator in older version - For each server: - Stop server - Remove server files - Revoke missing-disk-stores for server - Start server in older version Some extra details about this procedure: - The starting and stopping of processes may not be able to be done using gfsh as gfsh does not allow to manage members in a different version than its own. - Redundancy in servers is required - More than one locator is required - The allow_old_members_to_join_for_testing needs to be passed to the members. I would like to ask two questions regarding this procedure: - Do you see any issue not considered by this procedure or any alternative to it? - Would it be reasonable to make public the "allow_old_members_to_join_for_testing" parameter (with a new name) so that it might be valid option for production systems to support, for example, the procedure proposed? Thanks in advance for your answers. Best regards, -Alberto G. [1] http://mail-archives.apache.org/mod_mbox/geode-dev/201910.mbox/%3cb080e98c-5df4-e494-dcbd-383f6d979...@est.tech%3E
