Change Details

a) Have WANObjectCache automatically use small TTLs if slave lag gets too close to the HOLDOFF threshold This is useful for a full-network partition scenario between DCs. We could have a DC-local cached value trigger this. A one-thread-at-time deferred update can contact the master and wait for slaves to make sure things are OK. If it fails, the WAN cache will know (from reading the key) that something is wrong and lower all set() TTLs to stop stale data from getting stuck for the whole set() TTL (that could be days, weeks...). b) Likewise with CDN expiry headers c) Trigger wfReadOnly() in the slave DC to discourage form submission (if we use pt-heartbeat this will happen for free). d) If the master DC is "up", try to direct traffic there instead, so people do not submit forms with stale data and edit conflicts (or override newer stuff). This can use sticky DC cookies or maybe LVS health checks, ect...several options exist there.

During partitions which cause unbounded DB lag increases: a) Have WANObjectCache automatically use small TTLs if slave lag gets too close to the HOLDOFF threshold This is useful for a full-network partition scenario between DCs. We could have a DC-local cached value trigger this. A one-thread-at-time deferred update can contact the master and wait for slaves to make sure things are OK. If it fails, the WAN cache will know (from reading the key) that something is wrong and lower all set() TTLs to stop stale data from getting stuck for the whole set() TTL (that could be days, weeks...). b) Likewise with CDN expiry headers c) Trigger wfReadOnly() in the slave DC to discourage form submission (if we use pt-heartbeat this will happen for free).

During partitions which cause unbounded DB lag increases: a) Have WANObjectCache automatically use small TTLs if slave lag gets too close to the HOLDOFF threshold This is useful for a full-network partition scenario between DCs. We could have a DC-local cached value trigger this. A one-thread-at-time deferred update can contact the master and wait for slaves to make sure things are OK. If it fails, the WAN cache will know (from reading the key) that something is wrong and lower all set() TTLs to stop stale data from getting stuck for the whole set() TTL (that could be days, weeks...). b) Likewise with CDN expiry headers c) Trigger wfReadOnly() in the slave DC to discourage form submission (if we use pt-heartbeat this will happen for free). d) If the master DC is "up", try to direct traffic there instead, so people do not submit forms with stale data and edit conflicts (or override newer stuff). This can use sticky DC cookies or maybe LVS health checks, ect...several options exist there.