Manual:ChronologyProtector
<translate> Please [[<tvar name=1>Special:EditPage/Manual:ChronologyProtector</tvar>|expand]] this page.</translate> <translate> The reason given is:</translate> This was written by someone who was not previously familiar with ChronologyProtector, after reading and trying to understand the code. |
The ChronologyProtector is a mechanism to present each user of a wiki with a consistent view of actions on the wiki in the face of a replicated database setup.
In a setup with one primary database and several replica databases, without ChronologyProtector it would be possible that a user saves an edit and then the subsequent page read for the just-saved page is served from a replica that has not yet seen the database transaction corresponding to the edit, making it appear to the user as though their edit had not been saved. ChronologyProtector prevents this by saving the replication position when a user causes a database write, and waiting on subsequent requests until the chosen replica has caught up with that position. The load balancer will try to avoid selecting replicas that are lagged by more than that position; if this is not possible and the wait times out, the load balancer enters “lagged replica mode”.
Replication positions for each user are stored in the $wgChronologyProtectorStash.
In a multi-datacenter setup, the cache implementation should include its own advisory cross-DC replication.
(ChronologyProtector can inform the load balancer if the replication positions could not themselves be replicated.)
ChronologyProtector’s concept of a user is dictated by a client ID, which is usually stored in a cookie (a very short-lived one – after a certain timeout, chronology protection is not necessary because replication lag exceeding that time would cause the whole wiki to become read-only) and otherwise derived from the user’s IP address and user agent. As long as users don’t roam between IPs, they should get the same client ID even across different domains (where the cookie does not apply).
ChronologyProtector is operated at the load balancer factory level, and can protect the chronology of any number of load balancers. As long as the chronology protector stash is configured correctly and users do not roam between IPs, chronology protection ought to work across a large wiki farm spanning multiple domains and data centers.
