Remove maintenance script fixSlaveDesync.php
authorKevin Israel <pleasestand@live.com>
Wed, 19 Aug 2015 10:26:01 +0000 (06:26 -0400)
committerKevin Israel <pleasestand@live.com>
Wed, 19 Aug 2015 10:33:53 +0000 (06:33 -0400)
commita7cb31718818113127d92f126f7355bf1c442632
tree8a41c386d0be5f55794467a688ea984018bf2506
parentbb080d8a57698607c2802b467970a3422abf0a22
Remove maintenance script fixSlaveDesync.php

Though this script was run on Wikimedia sites years ago (see T8399), there
are enough reasons to doubt it will be run again:

* There is a hardcoded maximum page_id value, which would have to be
  changed or removed before reuse.
* It scans the entire page table in a single SELECT query and stores all
  values of page_id and page_latest in a PHP array, which might not be
  feasible on a large wiki.
* It writes directly to slaves. In contrast, the manual page for
  pt-table-sync (from Percona Toolkit) says in general, "[...] it always
  makes the changes on the replication master, never the replication slave
  directly. This is in general the only safe way to bring a replica back
  in sync [...]".
* It only works on the page/revision/text tables. In contrast, pt-table-sync
  can work on any table having a primary key.
* It does try to detect whether revisions are missing on the master (instead
  of on the slave). However, this won't work because of a bug introduced in
  r91243 / bb1df74f8715 (it actually queries the master twice and puts the
  second result set in $slaveIDs).

Change-Id: I85c98821af308abf7dde8068d7cbca17d06b1362
RELEASE-NOTES-1.26
autoload.php
maintenance/fixSlaveDesync.php [deleted file]