[MDEV-28687] Regarding the 1-year support for major releases VS upgrading Created: 2022-05-28  Updated: 2023-09-18  Resolved: 2023-09-18

Status: Closed
Project: MariaDB Server
Component/s: Server
Fix Version/s: N/A

Type: Task Priority: Major
Reporter: Nuno Assignee: Daniel Black
Resolution: Incomplete Votes: 0
Labels: None


 Description   

Hello,

One thing that has been keeping me reluctant of upgrading from MariaDB 10.5 to one of the latest versions (10.7~10.9) is because of the support/EOL of those versions being only 1 year.

10.5 => 24 Jun 2025
10.6 => 06 Jul 2026

10.7 => 14 Feb 2023
10.8 => 20 May 2023
10.9 => likely to follow same pattern (1 year)

I can understand why it's being done like that.

However, the problem is that the Upgrade process isn't comfortable enough to accommodate for these short EOL dates.

-

To upgrade a major version, I need to:

1) Make sure the my.cnf file is compatible with version I'm upgrading to (variables removed, etc)

2) Put website maintenance page (downtime)

3) Shut down MariaDB server (downtime)

4) Uninstall current version (downtime)

5) Install new version (downtime)

6) Start MariaDB server (downtime)

7) Run mysql_upgrade (downtime)

8) Hope that everything went smoothly, and remove website maintenance page

-

Having to do this every year just so that we keep Support active is unfortunately "not acceptable" if you must be 24 hours online.
Minor versions aren't so bad, because we just need a quick restart after updating the rpm, every few months.

Any thoughts on this?

Do you have other suggestions, or is there something I'm not thinking well about?

Thank you very much!



 Comments   
Comment by Sergei Golubchik [ 2022-05-29 ]

The announcement of these yearly releases (https://mariadb.org/new-innovation-release-model/) said

Starting with the next major update, the new MariaDB Server release series will be available on a quarterly basis and each release series will be maintained for one year. In collaboration with Linux distributions, some release series will be selected for longer maintenance windows, expected to happen at least every other year.

That is, there definitely will be long-term support releases, approximately every second year. The exact timing is determined to match the release schedule of major Linux distributions.

Comment by Nuno [ 2022-05-29 ]

Thank you very much serg for taking the time to respond to me.

Where can I know which those LTS releases are? Would that be disclosed in the Release Notes page of those specific releases?

Comment by Nuno [ 2022-05-30 ]

Sorry - I can see easily whether a release is Short Term of Long Term, in this page: https://mariadb.com/kb/en/mariadb-server-release-dates/

Thank you very much!

Comment by Daniel Black [ 2023-08-31 ]

Sorry for late response. I evidently meant to respond to this and forgot.

https://mariadb.org/new-innovation-release-model/ and https://mariadb.org/mariadb-10-11-is-lts/ describes long term support releases approximately every 2 years for 5 years duration so you won't need frequent major updates.

I also generally assume that major upgrades are testing in a test environment before going live so the configuration changes can be planned and the "hope" gets replaced with certainty. I appreciate that replicating a production workload in a test environment is a hard endeavour so I'll be back working on https://github.com/mariaDB/SCARY/ very soon to facilitate testing a new version by proxy/inspection.

A quick way to test your current configuration before upgrade is:

$ my_print_defaults --mariadbd
# Take these options and run a container with those options:
$ podman run --rm --env MARIADB_ROOT_PASSWORD=testpassword mariadb:{version} {options here}

During development we're trying to deprecate options rather than hard removing so some of this pain is removed however there has been a couple of items missed (MDEV-27730).

Is mysql_upgrade (now called mariadb-upgrade) a significant time consumer on larger systems? If its execution in the test environment didn't change any tables beyond the system tables (which it hasn't for a long time) mariadb-upgrade --upgrade-system-tables could be used to speed this up. Alternately we could work to parallelize this non-system check.

Generated at Thu Feb 08 10:02:42 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.