[00:17:30] <mutante>	 hey DBAs
[00:17:36] <mutante>	 can we:
[00:17:49] <mutante>	 - make a dump of bugzilla database (dbproxy1001)
[00:17:58] <mutante>	 - somehow have it backed up somewhere
[00:18:04] <mutante>	 - drop the database
[00:18:34] <mutante>	 also, when dropping GRANTs, do we just delete them, like here
[00:18:36] <mutante>	 https://gerrit.wikimedia.org/r/#/c/220548/
[02:23:46] <springle>	 mutante: it is backed up, but idk for how long bacula keeps stuff. is that considered a "forever" solution? if not, why drop it...
[02:26:10] <mutante>	 springle: it's considered "forever". how long bacula keeps it depends which pool we put it in. there is an archive pool that keeps stuff longer
[02:26:35] <mutante>	 so we released a sanitized version of the db on dumps
[02:26:48] <mutante>	 i just wanted to keep the non-sanitized version somewhere too
[02:27:43] <springle>	 mutante: thoughts on last comment on https://gerrit.wikimedia.org/r/#/c/220548/ ?
[02:29:19] <mutante>	 springle: just keeping it sounds good to me, i would say, yes, i want that. re: data retention.. that's a good point, it also applies to the archive pool in bacula
[02:29:31] <springle>	 yeah
[02:29:42] <springle>	 this is why i'm wary of dropping anything
[02:29:55] <springle>	 plus DBA has natural aversion to dropping data... *twitch* :)
[02:30:02] <mutante>	 hmm.. ok. let me figure this out..
[02:30:06] <mutante>	 ..by asking Ariel or something
[02:30:18] <springle>	 in any case, grant is gone
[02:30:22] <mutante>	 i would say, don't do anything for right now and i'll get back to it
[02:30:25] <mutante>	 ah, cool
[02:30:39] <mutante>	 so i just merge that puppet change too?
[02:31:06] <springle>	 yep
[02:31:16] <springle>	 so it will never be re-applied
[02:32:42] <mutante>	 done, thank you!
[02:33:02] <springle>	 mutante: so that codfw box i put BZ dump on months ago, we can have it back?
[02:33:09] <springle>	 not that we need it
[02:33:26] <springle>	 but do not want it to fall off the radar
[02:33:36] <mutante>	 springle: yes, you can
[02:33:44] <mutante>	 i deleted the installation that used that.. today
[02:34:23] <mutante>	 i made the sanitized dump on that which is now here
[02:34:25] <mutante>	 http://dumps.wikimedia.org/other/bugzilla/
[02:34:34] <springle>	 excellent thanks
[02:35:12] <mutante>	 killing all that was/is https://phabricator.wikimedia.org/T103193
[02:38:09] <mutante>	 running for food.. i made a note on the ticket just in case we forget
[02:38:43] <mutante>	 heh, because you are channel op you automatically get the notification in phabricator due to the @ sign :) bbl
[02:39:49] <springle>	 :)
[06:29:25] <jynus>	 anything left for us to do in bugzilla?
[06:39:22] <jynus>	 springle, regarding "ignoring the pool" I was worried that some application was ignoring the mediawiki config and still query a depooled server
[06:40:08] <jynus>	 as it is not  the case, I am not worried and do not care, the activity is over a long period of time but not to actual data
[06:43:41] <jynus>	 so someone again is sending multiple copies of the exact same slow query to dbstore1002
[06:52:58] <jynus>	 I commented the wrong cron- it is the user stats on stat1003
[07:15:03] <jynus>	 for context: https://gerrit.wikimedia.org/r/#/c/220716/
[07:51:40] <jynus>	 I am thinking if all our problems with statistics would go away with a column-based ENGINE/datastore
[09:57:38] <jynus>	 50 minutes only for the automatic buffer pool load for db1018 :-)
[13:18:45] <jynus>	 small hw issue on es2004, not repooling T103843
[13:56:05] <jynus>	 closed T101084, reopen if you do not agree
[17:20:44] <jynus>	 will start checking backup, ibdata1, and other preparations for T101516 tomorrow