Change Details

# **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?:** Yes, like cu_changes is currently. Replicas should keep this table and it's data private. # **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. Progress: [] s1 [] s2 [] s3 [] s4 [] s5 [] s6 [] s7 [] s8

# **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. Progress: [] s1 [] s2 [] s3 [] s4 [] s5 [] s6 [] s7 [] s8

# **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?:** Yes, like cu_changes is currently.No, Replicas should keep this table and it'sas it contains private data privatea. # **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. Progress: [] s1 [] s2 [] s3 [] s4 [] s5 [] s6 [] s7 [] s8