[05:47:02] <Amir1>	 o/
[05:48:05] <marostegui>	 hey
[06:12:47] <Amir1>	 I'm deploying the spamblacklist fix for double parsing in every edit
[07:01:51] <marostegui>	 I am going to prepare failover m1 proxy from dbproxy1012 to dbproxy1014 reason: https://phabricator.wikimedia.org/T298586#7608024
[07:17:33] <marostegui>	 failover done
[07:17:52] <marostegui>	 I will monitor the connections to make sure they move to the new proxy smoothly 
[09:29:53] <Amir1>	 marostegui: if you drop the index, would IGNORE INDEX statements that have it fail?
[09:30:22] <Amir1>	 I want to know if I need to drop the IGNORE INDEX from core now
[09:33:35] <marostegui>	 Amir1: yes, they will fail
[09:33:48] <marostegui>	 Amir1: I didn't know we had ignores for rev_page_id :(
[09:33:56] <Amir1>	 so then don't drop the index until I remove them
[09:34:01] <marostegui>	 yep
[09:34:19] <Amir1>	 that was basically how we made the experiment that if it actually slows down the dumper or not
[09:34:36] <marostegui>	 ok!
[09:36:13] <marostegui>	 Anyways, I will get run_schema_change.py check ready for that schema change 
[09:36:18] <marostegui>	 I will ask you for a review later
[09:45:30] <Amir1>	 sure. Thanks
[11:50:47] <Amir1>	 the grant of x1/x2 on flowdb is on `%flowdb%` in one range and `flowdb` on another range
[11:50:52] <Amir1>	 which one I should go?
[11:51:27] <Amir1>	 In puppet it's flowdb, I go with that
[15:07:15] <kormat>	 marostegui: re: T297605, is there a replacement host planned for db1115?
[15:07:15] <stashbot>	 T297605: Shutdown Tendril and dbtree - https://phabricator.wikimedia.org/T297605
[15:08:06] <marostegui>	 what do you mean?
[15:08:22] <sobanski>	 Do we need one for something else that runs on that host?
[15:08:35] <marostegui>	 nop
[15:08:46] <kormat>	 marostegui: db1115+db2093 are the `db_inventory` "section"
[15:08:54] <kormat>	 orchestrator uses them, as does zarcillo
[15:08:56] <marostegui>	 but I would still like to get the refresh for db1115 
[15:09:21] <marostegui>	 but orchestrator runs on db2093 right?
[15:09:40] <kormat>	 it does, because we were waiting for db1115 to be upgraded to a modern mariadb
[15:09:50] <marostegui>	 what I mean is: db1115 needs to be refreshed and I still want that replacement
[15:10:00] <kormat>	 so, sure, no argument there
[15:10:08] <kormat>	 it's just i don't see a plan mentioned in that task for a replacement
[15:10:11] <kormat>	 which makes me nervous
[15:10:12] <marostegui>	 yeah, db1115 will be upgraded to bullseye or buster and later replaced by new hardware
[15:10:34] <sobanski>	 So to summarize, I don't think "decommission db1115" means physical removal
[15:10:51] * kormat squints
[15:10:53] <marostegui>	 no, sorry maybe I wasn't clear about it
[15:10:55] <sobanski>	 It's still good to use
[15:11:00] <marostegui>	 it will be used
[15:11:11] <sobanski>	 And will be replaced with new HW in due time (not this cycle)
[15:11:17] <kormat>	 marostegui: 🤌
[15:11:21] <marostegui>	 yeah, whenever it comes 
[15:11:34] <marostegui>	 we cannot simply upgrade MySQL there that won't worl
[15:11:52] <marostegui>	 so we need to save whatever databases we want and then put them there (or clone it from db2093)
[15:12:36] <marostegui>	 feel free to reword the task if needed