Replication lag in production can cause weird issues that are very hard to debug. Now that we run automated integration tests, always having a replication lag in our deployment environment may surface issues that developers usually are not aware of, and help us create better code.
Version: unspecified
Severity: enhancement
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Declined | None | T3268 Database replication lag issues (tracking) | |||
| Stalled | None | T40945 Need a way to simulate replication lag to test replag issues | |||
| Duplicate | None | T59583 Make deployment prep have continuous replication lag | |||
| Resolved | None | T62058 implement master-slave DB for beta labs |
(In reply to Siebrand Mazeland from comment #0)
Replication lag in production can cause weird issues that are very hard to
debug. Now that we run automated integration tests, always having a
replication lag in our deployment environment may surface issues that
developers usually are not aware of, and help us create better code.
From bug 60058
(In reply to Erik Bernhardson from comment #1)
setting the lag is fairly trivial, percona makes a tool for it called
pt-slave-delay.
That, and we need to have slaves setup first...
To do this by default seems incompatible with T87220. However, having an easy and documented way to induce lag seems useful indeed. Perhaps something one can cause by running a CLI command form a beta host. Or by having a depooled replica that is always lagged that can be selected via a WikimediaDebug option perhaps.
Merging into T40945.