- CREATEs to run: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/CheckUser/+/866684/10/schema/mysql/patch-cu_log_event-def.sql and https://gerrit.wikimedia.org/r/c/mediawiki/extensions/CheckUser/+/866684/10/schema/mysql/patch-cu_private_event-def.sql
- Where to run those changes: all.dblist
- When to run those changes: Blocks patches for several security tickets (e.g. T316414), however, no need to rush.
- If the schema change is backwards compatible: Yes.
- If the schema change has been tested already on some of the test/beta wikis: beta cluster doesn't have checkuser
- if the data should be made available on the labs replicas and/or dumps: No, data is private.
Table creation specific Q&As:
- Should this table be replicated to wiki replicas?: No, as it contains private data.
- Will you be doing cross-joins with the wiki metadata?: A join to the logging table for entries in the cu_log_event will occur.
- Size of the table (number of rows expected): Unsure of exact numbers as I do not have raw access to cu_changes on WMF wikis. The two tables will have less entries than what cu_changes currently has (as these tables are being added to split up what cu_changes stores into multiple tables).
- Expected growth per year (number of rows): Like cu_changes, the data will be purged after a set expiry time (currently 3 months). Once the tables have existed for 3 months or if a maintenance script is run to fill the tables, the tables will then not grow or shrink by any large amount
- Expected amount of queries, both writes and reads (per minute, per hour...per day, any of those are ok): As I do not have access to this information, I cannot give specifics for this. However, what I can say is:
- Reads: Very similar to cu_changes as all three tables will in most cases be read together
- Writes: Smaller than the writes to cu_changes - dependent on how many log events are being triggered
- Examples of queries that will be using the table: TBC - Need to work on a patch that makes use of the new system. Queries are either to be separately run or combined via a UNION (there may be cases where only some of the three tables are queried):
- SELECT ... FROM [cu_changes, cu_private_event] WHERE ... LIMIT ...
- SELECT ... FROM cu_log_event INNER JOIN logging ON cue_log_id = log_id WHERE ... LIMIT ...
Creating new tables over adding a new column to cu_changes was suggested by Ladsgroup. The change has been merged, but open to discussion on improvements if they are needed.