jcrespo added a comment. `/* Wikibase\Client\Usage\Sql\EntityUsageTable::touchUsageBatch 127.0.0.1 */` creates lots of row updates without checking lag on the slaves. Even if a single one was short (which is not, according to this very same ticket), creating many updates without checking replication lag has the same effect. It is problematic when using statement-based replication, but even more when run in ROW-based replication -it creates lag, specially over a smaller bandwidth channels such as WAN.
It prevents s3 from using ROW-based replication, which in turn is slowly creating production data corruption due to other queries which will take years to fix. Why s3? Because most of updates there have to do with maintaining the wbc_entity_usage table, as there are a lot of small wikis using wikidata. Causes of lag are tracked on: https://phabricator.wikimedia.org/T95501 I created that ticket, went to holidays, then investigated more and didn't have the time to update it (it is not trivial to know the exact cause when I first reported it). Hoo asked me my opinion recently, and he told me to share it here. Wikidata is *not the only issue creating lag*, but it is the probably the only one where things get worse in ROW-based replication. My past experiences of reporting production, high impact database issues using the https://phabricator.wikimedia.org/tag/wikidata/ tag is that they are discarded as "low" importance. I am currently asking for extra hardware to isolate wikidata on its own shard (s8), so it doesn't affect other other production data (specially, dewiki), as in a previous schema change. TASK DETAIL https://phabricator.wikimedia.org/T111769 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: hoo, jcrespo Cc: JanZerebecki, hoo, daniel, jcrespo, aude, Aklapper, Izno, Wikidata-bugs, GWicke, Mbch331, Krenair _______________________________________________ Wikidata-bugs mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
