[10:08:19] <wikibugs>	 10DBA, 10MediaWiki-Cache, 10Performance-Team (Radar), 10User-Marostegui: Replace parsercache keys to something more meaningful on db-XXXX.php - https://phabricator.wikimedia.org/T210725 (10Marostegui) Any objection against replacing the last key the 25th of June (Tuesday) early in the morning with the same...
[10:12:43] <wikibugs>	 10DBA: Compress and defragment tables on labsdb hosts - https://phabricator.wikimedia.org/T222978 (10Marostegui) @jcrespo can we maybe stop maintenance on labsdb1010 so it can catch up before the s4 failover next week and resume the compression after it? (T224852) I would prefer to have close to no lag on all th...
[10:21:28] <wikibugs>	 10DBA, 10Patch-For-Review: Productionize dbproxy101[2-7].eqiad.wmnet and dbproxy200[1-4] - https://phabricator.wikimedia.org/T202367 (10Marostegui) To recap on this, right now with the amount of proxies we have in use in eqiad we would be able to replace them 1:1 with these new ones, as m5 doesn't use the prox...
[14:37:51] <wikibugs>	 10DBA: Compress and defragment tables on labsdb hosts - https://phabricator.wikimedia.org/T222978 (10Marostegui) As we spoke...I have stopped the compression. The last compressed table was `fawiki.revision` so when resumed, it needs to be resumed from line `14054` of `/home/jynus/labsdb1010_tables_to_compress.tx...
[14:41:01] <wikibugs>	 10DBA: Compress and defragment tables on labsdb hosts - https://phabricator.wikimedia.org/T222978 (10Marostegui)
[16:34:16] <wikibugs>	 10Blocked-on-schema-change, 10DBA, 10MediaWiki-extensions-OATHAuth: Schema change to oath - https://phabricator.wikimedia.org/T225643 (10Bawolff)
[16:34:34] <wikibugs>	 10Blocked-on-schema-change, 10DBA, 10MediaWiki-extensions-OATHAuth: Schema change to oathauth_users - https://phabricator.wikimedia.org/T225643 (10Bawolff)
[16:47:38] <wikibugs>	 10DBA, 10MediaWiki-Database, 10MediaWiki-extensions-OATHAuth: Schema change to oathauth_users - https://phabricator.wikimedia.org/T225643 (10Marostegui) Can you elaborate a bit more on what you expect to store on those two new columns? I am removing the #blocked-on-schema-change tag until the change is merge...
[16:58:40] <wikibugs>	 10DBA, 10MediaWiki-Database, 10MediaWiki-extensions-OATHAuth: Schema change to oathauth_users - https://phabricator.wikimedia.org/T225643 (10Legoktm) I think the schema change also needs to be made on private wikis too.
[17:03:30] <wikibugs>	 10DBA, 10MediaWiki-Database, 10MediaWiki-extensions-OATHAuth: Schema change to oathauth_users - https://phabricator.wikimedia.org/T225643 (10Marostegui) Let's try to follow the template at https://wikitech.wikimedia.org/wiki/Schema_changes#Workflow_of_a_schema_change so it is clear for us (DBAs) where it is...
[20:45:04] <wikibugs>	 10DBA, 10MediaWiki-Database, 10MediaWiki-extensions-OATHAuth: Schema change to oathauth_users - https://phabricator.wikimedia.org/T225643 (10Reedy) >>! In T225643#5253921, @Marostegui wrote: > Can you elaborate a bit more on what you expect to store on those two new columns?  The first is like the 2fa type/n...
[20:45:28] <wikibugs>	 10DBA, 10MediaWiki-Database, 10MediaWiki-extensions-OATHAuth: Schema change to oathauth_users - https://phabricator.wikimedia.org/T225643 (10Reedy)
[20:47:49] <wikibugs>	 10DBA, 10MediaWiki-Database, 10MediaWiki-extensions-OATHAuth: Schema change to oathauth_users - https://phabricator.wikimedia.org/T225643 (10Reedy)
[20:50:45] <wikibugs>	 10DBA, 10MediaWiki-Database, 10MediaWiki-extensions-OATHAuth: Schema change to oathauth_users - https://phabricator.wikimedia.org/T225643 (10Reedy)
[20:52:11] <wikibugs>	 10DBA, 10MediaWiki-Database, 10MediaWiki-extensions-OATHAuth: Schema change to oathauth_users - https://phabricator.wikimedia.org/T225643 (10Reedy)
[20:55:03] <wikibugs>	 10DBA, 10MediaWiki-Database, 10MediaWiki-extensions-OATHAuth: Schema change to oathauth_users - https://phabricator.wikimedia.org/T225643 (10Reedy)
[23:24:43] <wikibugs>	 10DBA, 10MediaWiki-Database, 10MediaWiki-extensions-OATHAuth: Schema change to oathauth_users - https://phabricator.wikimedia.org/T225643 (10jcrespo) Just to be clear, before we enter a deadlock :-)- we normally wait for changes to be merged to HEAD (as per deployment policy, all database changes should be "...