MASTER_POS_WAIT() does not work accross out datacenters due to the binlogs have no direct relationship.
We need an option to use a different method, such as:
a) MASTER_GTID_WAIT()
b) Checking the heartbeat table and sleeping a bit until timeout/sync (in non-transaction mode to avoid repeatable-read staleness)
| Subject | Repo | Branch | Lines +/- | |
|---|---|---|---|---|
| Enable MASTER_GTID_WAIT() on s6 | operations/mediawiki-config | master | +2 -0 | |
| Added GTID support to slave lag methods | mediawiki/core | master | +187 -52 |
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | aaron | T88445 MediaWiki active/active datacenter investigation and work (tracking) | |||
| Resolved | aaron | T135027 MASTER_POS_WAIT() alternative that works cross-DC | |||
| Resolved | jcrespo | T133385 Implement GTID replication on MariaDB 10 servers | |||
| Resolved | dduvall | T138778 Upgrade mariadb in deployment-prep from Precise/MariaDB 5.5 to Jessie/MariaDB 5.10 | |||
| Resolved | dduvall | T147110 Delete deployment-db1 and deployment-db2 |
Other restrictions noted by Giuseppe: default must be compatible with regular, simple mediawiki replication.
I have to recheck, but I am not sure we only sleep, we also compare directly after doing a write (is posa > posb), so it is slightly more complex than just changing that one function, we have to overload that class we slightly patched last time.
Change 289985 had a related patch set uploaded (by Aaron Schulz):
[WIP] Added GTID support to slave lag methods
Thank you for this. These checks keeps getting more and more complex, which means it will need extensive testing. GTID will take some time to be fully deployed on the cluster, it has some rough edges on ops side, but it is in progress.
Upgrading MariaDB on Beta-Cluster-Infrastructure got filled by @aaron as T138778: Upgrade mariadb in deployment-prep from Precise/MariaDB 5.5 to Jessie/MariaDB 5.10
Change 302635 had a related patch set uploaded (by Aaron Schulz):
Enable MASTER_GTID_WAIT() on s6