On 27.07.23 17:33, Vicențiu Ciorbaru via developers wrote:
Rather than offer a half-truth, I would us just take a clear stance. We either fully support downgrading between minor versions officially (which has implications on how we approach bug fixes, especially on the storage side), or we don't even encourage it at all, stating "at your own risk", or do a full dump and restore as the only recovery method.
minor versions are not an issue. There were a very few cases where minor aspects of the mysql schema changed in minor releases, but AFAIR the last time we did that was in 10.2 days. Nowadays mysql_upgrade even immediately returns when seeing a stored version info file from a previous run containing the same major version number unless you use --force. The problem always was with major upgrades only, and there we don't support downgrades not only as we don't have a tool to revert mariadb-upgrade changes (I filed a feature request for such a tool looooong ago when MySQL-MariaDB migrations still were a more common thing, back in 5.x days of 'in-place alternative', but it never happened ...). The other, and IMHO much more important reason, is that data file formats can change between major versions, and once a storage engine has started to write data using a new / change format that is not backwards compatible there is no way back anymore anyway. Heck, we even have pre-upgrade checks in our RPM and deb packages that prevent you from doing a major version upgrade via "apt-get upgrade" or "yum update" to prevent such non-versible upgrades from happening accidentally, for major version upgrade you have to explicitly uninstall, then re-install, the server packet. Or did I miss something here while merely browsing over the previous messages on the thread only? -- Hartmut Holzgraefe, Principal Support Engineer (EMEA) MariaDB Corporation | http://www.mariadb.com/