Page MenuHomePhabricator

Detect object, schema and data drifts between mediawiki HEAD, production masters and replicas
Closed, ResolvedPublic

Description

While replica drift is not a concern, there is no account of schema changes on different hosts due to performance reasons, such as different partitioning system, or usage of the TokuDB engine instead of InnoDB.

Create a script or application to check for unaccounted object differences (tables, triggers, dbs), schema changes in tables and data differences.

While there are open source solutions for that, we need to accommodate those tools to our particular setup:

  • Sharding
  • Heavy use of filters
  • sanitized host with some of the data missing
  • Not yet applied or undocumented schema changes (good changes applied to production only but not to mediawiki; changes applied to mediawiki but never scheduled for production; etc.)

Related Objects

View Standalone Graph
This task is connected to more than 200 other tasks. Only direct parents and subtasks are shown here. Use View Standalone Graph to show more of the graph.
StatusSubtypeAssignedTask
Resolvedjcrespo
ResolvedMarostegui
ResolvedMarostegui
ResolvedSmalyshev
ResolvedMarostegui
ResolvedMarostegui
ResolvedMarostegui
ResolvedMarostegui
ResolvedLadsgroup
ResolvedNone
ResolvedMarostegui
ResolvedMarostegui
ResolvedMarostegui
ResolvedMarostegui
ResolvedMarostegui
ResolvedReedy
ResolvedMarostegui
ResolvedMarostegui
ResolvedMarostegui
DeclinedNone
ResolvedMarostegui
ResolvedMarostegui
ResolvedLadsgroup
ResolvedMarostegui
ResolvedMarostegui
ResolvedMarostegui
ResolvedMarostegui
ResolvedMarostegui
ResolvedMarostegui
ResolvedMarostegui
ResolvedLadsgroup
ResolvedMarostegui
ResolvedMarostegui
ResolvedLadsgroup
ResolvedKormat
ResolvedMarostegui
ResolvedKormat
ResolvedMarostegui
ResolvedKormat
ResolvedMarostegui

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

Thanks for this Amir - this is super useful feel free to move it to operations/software, better to have it there just in case.
As I mentioned on my email to Operations, let's try to get in a better shape first and fix the already created tickets, before automating it and sending reports that won't have much change over the weeks (as it will take time to fix all the drifts) and we know what happens when there's a weekly (or monthly) email that has no change...people tend to ignore it :-(

I would suggest we start working on fixing the drifts first and once we are in a much cleaner state, we can talk about scheduling and sending a report every once in XX days.

Again, thank you so much!

I just made a dashboard to keep track of drifts reported by my tool: https://drift-tracker.toolforge.org/

LSobanski renamed this task from Automate the check and fix of object, schema and data drifts between mediawiki HEAD, production masters and slaves to Detect object, schema and data drifts between mediawiki HEAD, production masters and replicas.May 14 2021, 10:59 AM
LSobanski updated the task description. (Show Details)

I updated the task to limit it to drift detection and spun automation into a separate task: T282857. These are effectively two separate tasks of different complexity and priority.

Ladsgroup claimed this task.

I just rewrote the dashboard in python to make it more maintainable and created Tool-drift-tracker (and created some tickets to tackle later, specially some tickets to automate the work much more.)

With https://drift-tracker.toolforge.org/report/core/

We can basically call this done ^^. Of course there are much more to be done but I consider this a good start.

A feature request for data differences (narrowly scoped) is tracked in https://phabricator.wikimedia.org/T207253.

@Umherirrender you don't need to add subtasks if you ask me. This task is in itself done.