btw, this is the list of all s3 dbs that are not in the dblist of s3 (and I doubt mediawiki could route requests to them):

affcomwiki
alswikibooks
alswikiquote
alswiktionary
bawiktionary
blocker
boards
boardvote
boardvote2005
boardvote2006
boardvote2007_test
boardvotetest
chwikimedia
closed_zh_twwiki
comcomwiki
de_labswikimedia
defoundation
dkwiki
dkwikibooks
dkwiktionary
en_labswikimedia
fixcopyrightwiki
flaggedrevs_labswikimedia
heartbeat
information_schema
jamestemp
katesdb
langcomwiki
liquidthreads_labswikimedia
mowiki
mowiktionary
mysql
noboardwiki
oai
ops
performance_schema
readerfeedback_labswikimedia
ru_sibwiki
sep11wiki
steward
strategyappswiki
sys
tlhwiki
tlhwiktionary
tokiponawiki
tokiponawikibooks
tokiponawikiquote
tokiponawiktionary
ukwikimedia
vewikimedia
webshop
wikiconfig
wikimania
zerowiki
zh_cnwiki
zh_twwiki

It seems tokipona wikis have been "deleted" in 2010 (T13511: Delete tokipona wikis) but dbs were not deleted.

Although I think we should clean them up, there are a number of databases of deleted wikis and DBA thinks deleting them will be troublesome. See T246055: Drop DB tables for now-deleted fixcopyrightwiki from production

sys schema is https://mariadb.com/kb/en/sys-schema/ and should be on all wmf databases, and the admin user should have access to it on mw databases.
ops is used for the log and functions of the query killer, should be on all mw databases (at least for now).
You should check against the closed.dblist- I have been an advocate that if those were to be kept, they shouldn't be on s3, but on a hypothetical "s0" very small section, (eg. on a vm) to save resources.
Others will be relics of the past of maintenance jobs/creation of wikis by mistake.

In T297297#7558467, @jcrespo wrote:

sys schema is https://mariadb.com/kb/en/sys-schema/ and should be on all wmf databases, and the admin user should have access to it on mw databases.

Yup, that's why I marked it as needed. It's there for the sake of completeness.

ops is used for the log and functions of the query killer, should be on all mw databases (at least for now).

I wasn't sure about this one, if so, I mark it as needed.

You should check against the closed.dblist- I have been an advocate that if those were to be kept, they shouldn't be on s3, but on a hypothetical "s0" very small section, (eg. on a vm) to save resources.
Others will be relics of the past of maintenance jobs/creation of wikis by mistake.

Well, closed dbs are still on s3 dblist. For example bgwikinews is in both of s3 and closed. From MediaWiki point of view, closed wikis are fully functional wikis that get software updates and schema updates and so on. They just don't let anyone (except stewards) edit them.

Deleted wikis on the other hand are a completely different story and they had different processes through out the years so we are now in a messed up state of each deleted wiki being a different and unique mess. The other problem is that not all of these dbs are wiki dbs. Looking at katesdb, it's random tables with random information and this makes schema changes and other maintenance work on s3 tricky and I sure hope it doesn't get replicated to the cloud. We don't know what's in them.

Sorry, when I said closed, I really meant deleted.dblist.

Related: T173606

There are opinions that deleting databases may cause issues (T227717#5327365), but it may also be an issue (and may be one more difficult to detect) if codes try to read from new database schema of a truncated (but not deleted) database of deleted wiki whose schema is never updated.

There are pros and cons and I think this needs to be discussed with other DBAs once they are back (and in a bigger setup) to find a solution. Maybe different dbs need different solutions. etc.

Given the number of tables in s3 is now a problem (which make DBA to drop core tables, see T397367: Drop unneeded empty tables from wikis), should we revisit it? we have ~30 deleted wikis in s3 which means we can drop ~1800 more tables.

In T297297#11157015, @Bugreporter wrote:

Given the number of tables in s3 is now a problem (which make DBA to drop core tables, see T397367: Drop unneeded empty tables from wikis), should we revisit it? we have ~30 deleted wikis in s3 which means we can drop ~1800 more tables.

The problem is still https://phabricator.wikimedia.org/T297297#7562079 unfortunately.
In the long term I think we need to split s3

Mentioned in SAL (#wikimedia-operations) [2025-11-05T13:50:11Z] <Amir1> cumin2024@db2205.codfw.wmnet[(none)]> drop database if exists katesdb; (T297297)

Mentioned in SAL (#wikimedia-operations) [2025-11-05T14:12:25Z] <Amir1> cumin2024@db2205.codfw.wmnet[(none)]> drop database if exists jamestemp; (T297297)

One comment for the future: one of the aims of the https://phabricator.wikimedia.org/source/operations-puppet/browse/production/modules/role/files/mariadb/check_private_data.py alarm was to detect dbs that shouldn't be on clouddbs. I wonder if you would find useful to setup a similar, auto-updated check for production, but reducing the scope to "dbs that are not on the configuration files" (private or not). Because making the changes to check for that would be extremelly trivial to me (it would be just removing extra checks). The checks uses a local updated copy of mwconfig/dblists.

Mentioned in SAL (#wikimedia-operations) [2025-11-06T16:16:12Z] <Amir1> cumin2024@db2205.codfw.wmnet[(none)]> drop database if exists boardvotetest and boardvote2007_test; (T297297)

Mentioned in SAL (#wikimedia-operations) [2025-11-10T12:43:18Z] <Amir1> drop database if exists de_labswikimedia; drop database if exists en_labswikimedia; drop database if exists flaggedrevs_labswikimedia; drop database if exists liquidthreads_labswikimedia; drop database if exists readerfeedback_labswikimedia; (T297297)

I explicitly drop tokipona wikis earlier since they are being requested to be created soon (under another code) and I want to avoid potential issues like what we had with vewikimedia.

In T297297#11349262, @jcrespo wrote:

One comment for the future: one of the aims of the https://phabricator.wikimedia.org/source/operations-puppet/browse/production/modules/role/files/mariadb/check_private_data.py alarm was to detect dbs that shouldn't be on clouddbs. I wonder if you would find useful to setup a similar, auto-updated check for production, but reducing the scope to "dbs that are not on the configuration files" (private or not). Because making the changes to check for that would be extremelly trivial to me (it would be just removing extra checks). The checks uses a local updated copy of mwconfig/dblists.

Yup. Once we have cleaned this up, that's the next step.

Mentioned in SAL (#wikimedia-operations) [2025-11-10T12:49:40Z] <Amir1> drop database if exists tokiponawiki; drop database if exists tokiponawikibooks; drop database if exists tokiponawikiquote; drop database if exists tokiponawiktionary; (T297297)

Mentioned in SAL (#wikimedia-operations) [2025-11-10T15:25:16Z] <Amir1> drop database if exists webshop (T297297)

Mentioned in SAL (#wikimedia-operations) [2025-11-11T12:22:44Z] <Amir1> drop database if exists alswikibooks; drop database if exists alswikiquote; drop database if exists alswiktionary; drop database if exists boardvote2005; drop database if exists boardvote2006; drop database if exists boardvote; (T297297)

Mentioned in SAL (#wikimedia-operations) [2025-11-12T15:30:41Z] <Amir1> cumin2024@db2205.codfw.wmnet[(none)]> drop database if exists affcomwiki; (T297297)

Mentioned in SAL (#wikimedia-operations) [2025-11-13T12:50:30Z] <Amir1> cumin2024@db2205.codfw.wmnet[(none)]> drop database if exists bawiktionary; drop database if exists chwikimedia; drop database if exists closed_zh_twwiki; drop database if exists comcomwiki; (T297297)

Mentioned in SAL (#wikimedia-operations) [2025-11-17T13:52:02Z] <Amir1> cumin2024@db2205.codfw.wmnet[(none)]> drop database if exists dkwiki; drop database if exists dkwikibooks; drop database if exists dkwiktionary; (T297297)

Mentioned in SAL (#wikimedia-operations) [2025-11-18T16:02:53Z] <Amir1> cumin2024@db2205.codfw.wmnet[(none)]> drop database if exists fixcopyrightwiki; drop database if exists langcomwiki; drop database if exists mowiki; drop database if exists mowiktionary; (T297297)

Mentioned in SAL (#wikimedia-operations) [2025-11-19T13:50:51Z] <Amir1> cumin2024@db2205.codfw.wmnet[(none)]> drop database if exists noboardwiki; drop database if exists ru_sibwiki; drop database if exists sep11wiki; drop database if exists strategyappswiki; (T297297)

Mentioned in SAL (#wikimedia-operations) [2025-11-19T14:12:59Z] <Amir1> cumin2024@db2205.codfw.wmnet[(none)]> drop database if exists tlhwiki; drop database if exists tlhwiktionary; drop database if exists ukwikimedia; drop database if exists zerowiki; drop database if exists zh_cnwiki; drop database if exists zh_twwiki; (T297297)

Mentioned in SAL (#wikimedia-operations) [2025-11-24T15:19:53Z] <Amir1> cumin2024@db2205.codfw.wmnet[(none)]> drop database if exists blocker; drop database if exists defoundation; drop database if exists oai; drop database if exists steward; (T297297)

oh one thing: I should check x1 dbs, if these wikis get recreated, then it'll be quite a fun time with x1.