Thank you for your thoughts, Travis!
As you say, there's unlikely to be any compatibility issues between
Trove and the replica databases; in any case, the replicas are due for
an upgrade soon.
We don't have any plans to actively shutdown older Trove databses. If a
situation does arise in the future where that's needed (e.g. a major
security concern) I will feel better knowing that alternatives have been
available for as long as possible.
Running offsite backups is fine (and mostly upside from our perspective)
unless you're using a ton of bandwidth and/or your database is extremely
large. You shouldn't feel any rush to upgrade your existing DB, although
I'm certainly interested in whether or not it is easy for you to
restore/import one of your backups onto the new engine.
I hope that's all of your concerns, let me know if I missed anything.
-Andrew
On 3/27/26 8:46 AM, Travis Briggs via Cloud wrote:
Hi Andrew,
My main concern is that the enwiki_p replica
at enwiki.analytics.db.svc.eqiad.wmflabs is currently on 10.11.13 and
I'm not aware of plans to upgrade it. Tools like ours (mwcurator/WP1)
connect to both the wiki replica and our Trove, and I'm wondering what
the implications of running on different versions would be.
Answering my own questions in public:
1) My general expectation is that newer versions of database software
are backwards compatible from an API perspective, and that differences
are adding features and optimizations.
2) Keeping in mind the above, I believe both the official MariaDB
connector Python library, as well as pymysql (which is what we
actually use) support both versions.
3) Having multiple versions for dev environment is not necessary
simply because our databases in dev are containerized. And even then,
it would only be a concern for the most paranoid of development
postures, which we don't take.
The other thing I worry about is that 10.5 is EOL, and 10.6 is only
supported until July 2026, like you mentioned. In my experience, EOL
is a phrase that makes SREs jumpy. I know you are planning on
continuing to operate existing versions /for now/ but I wonder if
there is a forced migration somewhere on the horizon (see what I did
there?). I'm thinking of the debian upgrades which were fairly painful
for us (though those I understand as being more critical).
Finally, as a data point for your team, WP1 performs nightly external
backups of our Trove database external to Horizon. I don't know if I
should be mentioning that because we might get in trouble for resource
usage 😅. We have successfully run restore operations in the form of
yearly exercises.
Thanks as always,
-Travis
On Fri, Mar 27, 2026 at 6:20 AM Andrew Bogott via Cloud-announce via
Cloud <[email protected]> wrote:
tl;dr: new trove database versions are coming! Existing trove db
servers will continue to run as before. Please provide feedback
about the specifics.
--
Sometime in the next few weeks I'd like to make a few updates to
the databases supported on cloud-vps. Unless you have your own
private database, toolforge users can ignore this email. If you
ever visit the 'databases' tab in Horizon please read on!
Right now we support the following database engines:
mariadb10.5.10 (21 instances)
mysql5.7.29(4 instances)
postgresql 12.7 (13 instances)
I propose to deprecate all three of those engines, and replace
them with:
mariadb12.2.2
postgres18
Here's how that would look, from a user standpoint:
1) **Any existing database instances will continue to run and
operatein Horizonas before.**
2) It will no longer be possible to create new database instances
with the deprecated engines.
3) It will no longer be possible to restore backups of databases
using the old engine without admin intervention -- if we do this,
I will be on hand to do manual restores if necessary. This
restriction is bound up with #2 above; either both rules stay or
both rules go.[0]
4) There will be no automatic or in-place upgrade path provided
from old version to new version. Any upgrades, if needed, will
have to be performed 'by hand' with something like an
outside-of-openstack dump and restore. This pains me but I've
spent some time testing and the internal storage formats are too
different for a smooth transition.
5) It will no longer be possible to create new mysql databases.
Mysql is not very popular, and as far as I know only provides a
functional subset of mariadb.
I'm making a lot of assumptions about you, the users, in this
proposal, so please speak up if (for example) you perform frequent
backup restores, or have a use case that requires mysql. You can
respond to this email, or follow up on the associated phab task[1].
If this email provokes only silence or agreement, then I will make
these changes on or near April 20.
[0] Currently only a total of 9 trove backups exist (and only 4 in
the last year), so I suspect no one is really relying on this
service on the regular.
[1] https://phabricator.wikimedia.org/T420737
_______________________________________________
Cloud-announce mailing list -- [email protected]
List information:
https://lists.wikimedia.org/postorius/lists/cloud-announce.lists.wikimedia.org/
_______________________________________________
Cloud mailing list -- [email protected]
List information:
https://lists.wikimedia.org/postorius/lists/cloud.lists.wikimedia.org/
_______________________________________________
Cloud mailing list [email protected]
List
information:https://lists.wikimedia.org/postorius/lists/cloud.lists.wikimedia.org/
_______________________________________________
Cloud-announce mailing list -- [email protected]
List information:
https://lists.wikimedia.org/postorius/lists/cloud-announce.lists.wikimedia.org/
