It looks like both page-create and revision-create tables are receiving quite a bit of data, for rebision-create we have about 1 million records daily. We need to define an agreggation strategy for this table to keep this data long term , otherwise it is soon going to be too big as this data is public by nature and does not need to be deleted.
Description
Description
Details
Details
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | Ottomata | T150369 Record an event every time a new content namespace page is created | |||
| Resolved | Ottomata | T169898 Managing size of page-create and revision-create tables in storage. Aggregation? |
Event Timeline
Comment Actions
Hm, I had thought that the revision-create data would be about the same size as the EventLogging analytics Edit schema data. Is this not true? If so, then it may actually be too big for MySQL at all.
I think Kaldari only cares about page-create, so perhaps we should not insert revision-create data into MySQL at all.
Comment Actions
Yep, only care about page-create data. I would be fine with not inserting revision-create data into MySQL at all.
Comment Actions
Change 364262 had a related patch set uploaded (by Ottomata; owner: Ottomata):
[operations/puppet@production] Stop writing mediawiki.revision-create events to EventLogging analytics MySQL
Comment Actions
Change 364262 merged by Ottomata:
[operations/puppet@production] Stop writing mediawiki.revision-create events to EventLogging analytics MySQL