fixcopyrightwiki (on s3) has been dropped from appserver config and can now have its tables deleted. No back-up needed.
|Open||None||T18660 Database table cleanup (tracking)|
|Open||None||T54921 Database tables to be dropped on Wikimedia wikis and other WMF databases (tracking)|
|Open||None||T246055 Drop DB tables for now-deleted fixcopyrightwiki from production|
|Open||CCicalese_WMF||T238803 Retire fixcopyright.wikimedia.org|
|Resolved||Vgutierrez||T239141 Redirect all traffic for fixcopyright.wikimedia.org to https://policy.wikimedia.org/policy-landing/copyright/|
|Resolved||bd808||T246056 Remove any references to fixcopyrightwiki from the meta-index in Wikimedia Cloud Services|
As this wiki has been removed everywhere, this triggered the check_private data alert to let us know there's "private" data on sanitarium hosts (and labs hosts) as this week doesn't show up on the dblists anymore.
We need to either exclude it from the check, or go ahead and drop it from sanitarium master (with replication) which is db1112 for s3.
In order to avoid this alert from firing, I have dropped this database on db1112 and db2074 (sanitarium masters) with replication enabled, so it has been dropped from sanitarium and labs hosts.
I took a backup (1.6M) of its tables just in case, which is temporary at:
root@cumin1001:/home/marostegui/T246055# ls -lh total 3.1M -rw-r--r-- 1 root root 1.6M Mar 4 13:17 codfw_fixcopyrightwiki.sql -rw-r--r-- 1 root root 1.6M Mar 4 13:15 eqiad_fixcopyrightwiki.sql
@Bstorm @JHedden @bd808 can you guys please remove the view for this database? It has already been deleted, but the views are still there and hence triggering the private data check.
I guess I can just issue a drop database fixcopyrightwiki_p directly, but I am wondering if this better be done via maintain-views?
Done from the wikireplicas
root@cumin1001:~# for i in labsdb1009 labsdb1010 labsdb1011 labsdb1012; do echo $i; mysql.py -h$i -e "show databases like 'fixcopyright%'";done labsdb1009 labsdb1010 labsdb1011 labsdb1012
We should not get more private data alerts.
(not to do so)
T169928: Evaluate how hard would be to get aa(wikibooks|wiktionary) and howiki databases deleted
T227717: Drop DB tables for now-deleted zerowiki from production
(to do so but first rename them)
T260112: Remove muswiki and mhwiktionary from s3
Personally I support the latter - first rename database of each of deleted wikis, then delete them. (For a reason: deleted wikis may contains outdated database schema, and may cause issues if the database is somehow used elsewhere)