Hi,
No action required. Just a heads up.
Since there were some problems around machine capacities, slow queries and subsequent slave lag and alarms in the past months, springle suggested to point the s[23467]-analytics-slave aliases to the new analytics-store machine. That should kill some of the problems at the root.
This migration gets tracked in Bug 66068 [1].
No action is required from you, the change should be transparent. Keep using the aliases in the same manner as you did up to now. This email is merely a heads up about the switch.
Have fun, Christian
[1] https://bugzilla.wikimedia.org/show_bug.cgi?id=66068
Thanks Christian.
On Tue, Jun 3, 2014 at 4:50 AM, Christian Aistleitner < christian@quelltextlich.at> wrote:
Hi,
No action required. Just a heads up.
Since there were some problems around machine capacities, slow queries and subsequent slave lag and alarms in the past months, springle suggested to point the s[23467]-analytics-slave aliases to the new analytics-store machine. That should kill some of the problems at the root.
This migration gets tracked in Bug 66068 [1].
No action is required from you, the change should be transparent. Keep using the aliases in the same manner as you did up to now. This email is merely a heads up about the switch.
Have fun, Christian
[1] https://bugzilla.wikimedia.org/show_bug.cgi?id=66068
-- ---- quelltextlich e.U. ---- \ ---- Christian Aistleitner ---- Companies' registry: 360296y in Linz Christian Aistleitner Gruendbergstrasze 65a Email: christian@quelltextlich.at 4040 Linz, Austria Phone: +43 732 / 26 95 63 Fax: +43 732 / 26 95 63 Homepage: http://quelltextlich.at/
Analytics mailing list Analytics@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/analytics
This should not happen until some important indexes have been carried over to analytics store.
In other words, block on https://rt.wikimedia.org/Ticket/Display.html?id=7594 please.
-Aaron
On Tue, Jun 3, 2014 at 7:19 AM, Toby Negrin tnegrin@wikimedia.org wrote:
Thanks Christian.
On Tue, Jun 3, 2014 at 4:50 AM, Christian Aistleitner < christian@quelltextlich.at> wrote:
Hi,
No action required. Just a heads up.
Since there were some problems around machine capacities, slow queries and subsequent slave lag and alarms in the past months, springle suggested to point the s[23467]-analytics-slave aliases to the new analytics-store machine. That should kill some of the problems at the root.
This migration gets tracked in Bug 66068 [1].
No action is required from you, the change should be transparent. Keep using the aliases in the same manner as you did up to now. This email is merely a heads up about the switch.
Have fun, Christian
[1] https://bugzilla.wikimedia.org/show_bug.cgi?id=66068
-- ---- quelltextlich e.U. ---- \ ---- Christian Aistleitner ---- Companies' registry: 360296y in Linz Christian Aistleitner Gruendbergstrasze 65a Email: christian@quelltextlich.at 4040 Linz, Austria Phone: +43 732 / 26 95 63 Fax: +43 732 / 26 95 63 Homepage: http://quelltextlich.at/
Analytics mailing list Analytics@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/analytics
Analytics mailing list Analytics@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/analytics
On Tue, Jun 3, 2014 at 11:43 PM, Aaron Halfaker ahalfaker@wikimedia.org wrote:
This should not happen until some important indexes have been carried over to analytics store.
In other words, block on https://rt.wikimedia.org/Ticket/Display.html?id=7594 please.
Noted.
s3-analytics-slave switched over a fortnight ago for maintenance reasons, but all those small wikis shouldn't suffer too much without the additional indexes.
The other CNAMEs won't switch over until the indexes are ready. Since we're only switching one per week and I expect the indexing to finish this week, there shouldn't be a problem.
Sean
Another question:
What should we do with s5-analytics-slave? Last year at Aaron's request this was made writable like s1 with staging and personal databases. Could it revert to using analytics-store with only staging?
I'd like to copy over personal DBs and staging from dbs5 and dbs1 onto the dbstore. Right now, I don't see myself using the s5 slave (assuming I get similar or better performance from dbstore).
If this is very painful, I can move my own data. It would give me an opportunity to perform some cleanup -- though I don't expect much since I do that with some regularity anyway.
-Aaron
On Tue, Jun 3, 2014 at 11:42 PM, Sean Pringle springle@wikimedia.org wrote:
Another question:
What should we do with s5-analytics-slave? Last year at Aaron's request this was made writable like s1 with staging and personal databases. Could it revert to using analytics-store with only staging?
Analytics mailing list Analytics@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/analytics
Hi,
TL;DR: If you use staging.nov13_dewiki_* tables, speak up!
On Wed, Jun 04, 2014 at 02:42:11PM +1000, Sean Pringle wrote:
Another question:
What should we do with s5-analytics-slave? Last year at Aaron's request this was made writable like s1 with staging and personal databases. Could it revert to using analytics-store with only staging?
Summing up the last two weeks, * Aaron said that he would not be affected for s5. * No one said thon would oppose the move.
The only affected tables visible to the research user seem to be [1]: staging.nov13_dewiki_article_page staging.nov13_dewiki_creation staging.nov13_dewiki_move staging.nov13_dewiki_move_revision staging.nov13_dewiki_page staging.nov13_dewiki_page_origin staging.nov13_dewiki_user_stats
Do those tables ring a bell for someone?
If no one claims them by 2014-06-26: * I assume the above tables are no longer needed, and they can be dropped, and * I assume we can point the s5-analytics-slave alias to dbstore1002 like for the other slaves from $SUBJECT.
Have fun, Christian
[1] _________________________________________________________________ qchris@stat1003 // jobs: 0 // time: 21:58:19 // exit code: 0 cwd: ~ mysql --defaults-extra-file=~/.my.cnf.research --host s5-analytics-slave.eqiad.wmnet -e 'show databases;' +--------------------+ | Database | +--------------------+ | information_schema | | dartar | | dewiki | | log | | prod | | rfaulk | | staging | | wikidatawiki | +--------------------+
_________________________________________________________________ qchris@stat1003 // jobs: 0 // time: 21:58:22 // exit code: 0 cwd: ~ for db in dartar log prod rfaulk staging ; do echo $db ; mysql --defaults-extra-file=~/.my.cnf.research --host s5-analytics-slave.eqiad.wmnet -e 'show tables;' $db ; done dartar log prod rfaulk staging +----------------------------+ | Tables_in_staging | +----------------------------+ | nov13_dewiki_article_page | | nov13_dewiki_creation | | nov13_dewiki_move | | nov13_dewiki_move_revision | | nov13_dewiki_page | | nov13_dewiki_page_origin | | nov13_dewiki_user_stats | +----------------------------+
Thanks Christian.
Those are tables I created for https://meta.wikimedia.org/wiki/Research:Wikipedia_article_creation. They are no longer needed. They can be deleted immediately.
-Aaron
On Wed, Jun 18, 2014 at 5:15 PM, Christian Aistleitner < christian@quelltextlich.at> wrote:
Hi,
TL;DR: If you use staging.nov13_dewiki_* tables, speak up!
On Wed, Jun 04, 2014 at 02:42:11PM +1000, Sean Pringle wrote:
Another question:
What should we do with s5-analytics-slave? Last year at Aaron's request this was made writable like s1 with staging and personal databases. Could it revert to using analytics-store with only staging?
Summing up the last two weeks,
- Aaron said that he would not be affected for s5.
- No one said thon would oppose the move.
The only affected tables visible to the research user seem to be [1]: staging.nov13_dewiki_article_page staging.nov13_dewiki_creation staging.nov13_dewiki_move staging.nov13_dewiki_move_revision staging.nov13_dewiki_page staging.nov13_dewiki_page_origin staging.nov13_dewiki_user_stats
Do those tables ring a bell for someone?
If no one claims them by 2014-06-26:
- I assume the above tables are no longer needed, and they can be dropped, and
- I assume we can point the s5-analytics-slave alias to dbstore1002 like for the other slaves from $SUBJECT.
Have fun, Christian
[1] _________________________________________________________________ qchris@stat1003 // jobs: 0 // time: 21:58:19 // exit code: 0 cwd: ~ mysql --defaults-extra-file=~/.my.cnf.research --host s5-analytics-slave.eqiad.wmnet -e 'show databases;' +--------------------+ | Database | +--------------------+ | information_schema | | dartar | | dewiki | | log | | prod | | rfaulk | | staging | | wikidatawiki | +--------------------+
qchris@stat1003 // jobs: 0 // time: 21:58:22 // exit code: 0 cwd: ~ for db in dartar log prod rfaulk staging ; do echo $db ; mysql --defaults-extra-file=~/.my.cnf.research --host s5-analytics-slave.eqiad.wmnet -e 'show tables;' $db ; done dartar log prod rfaulk staging +----------------------------+ | Tables_in_staging | +----------------------------+ | nov13_dewiki_article_page | | nov13_dewiki_creation | | nov13_dewiki_move | | nov13_dewiki_move_revision | | nov13_dewiki_page | | nov13_dewiki_page_origin | | nov13_dewiki_user_stats | +----------------------------+
-- ---- quelltextlich e.U. ---- \ ---- Christian Aistleitner ---- Companies' registry: 360296y in Linz Christian Aistleitner Kefermarkterstrasze 6a/3 Email: christian@quelltextlich.at 4293 Gutau, Austria Phone: +43 7946 / 20 5 81 Fax: +43 7946 / 20 5 81 Homepage: http://quelltextlich.at/
Analytics mailing list Analytics@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/analytics
Hi Aaron,
On Wed, Jun 18, 2014 at 05:29:50PM -0500, Aaron Halfaker wrote:
Those are tables I created for [...] They are no longer needed. They can be deleted immediately.
Thanks!
Have fun, Christian
On Thu, Jun 19, 2014 at 8:15 AM, Christian Aistleitner < christian@quelltextlich.at> wrote:
- I assume we can point the s5-analytics-slave alias to dbstore1002 like for the other slaves from $SUBJECT.
Nice! :)
Hi,
On Thu, Jun 19, 2014 at 12:15:54AM +0200, Christian Aistleitner wrote:
TL;DR: If you use staging.nov13_dewiki_* tables, speak up!
On Wed, Jun 04, 2014 at 02:42:11PM +1000, Sean Pringle wrote:
What should we do with s5-analytics-slave? [...]
[ Some Tables ]
Do those tables ring a bell for someone?
If no one claims them by 2014-06-26:
- I assume the above tables are no longer needed, and they can be dropped, and
Aaron said we can drop them. No one else claimed them. So I dropped the tables.
- I assume we can point the s5-analytics-slave alias to dbstore1002 like for the other slaves from $SUBJECT.
Scheduling re-pointing the alias for 2014-07-02.
Have fun, Christian