Don't throw an exception when waiting for replication times out
authorTim Starling <tstarling@wikimedia.org>
Thu, 16 Aug 2018 07:01:55 +0000 (17:01 +1000)
committerTim Starling <tstarling@wikimedia.org>
Mon, 3 Sep 2018 02:29:35 +0000 (12:29 +1000)
commite8df0fbab17b9ef40b306c437a626acc852902bf
treee13190025f843a7dbd1525f4f369975eb0a7840f
parent60f1fd00124de0ab61203fc03d36e575a9f386ad
Don't throw an exception when waiting for replication times out

For maintenance scripts it is usually harmful to throw an exception.
For jobs the exception was already caught and handled appropriately,
so this can continue as before. For DeferredUpdates it was extremely
harmful to throw an exception. So in the web case, reduce the timeout to
1s and continue as normal if the 1s timeout is reached. This allows the
DeferredUpdate to be throttled without being killed.

In the updater, increase the replication wait timeout to 5 minutes.
ALTER TABLE could indeed cause replication lag, but exiting the update
script with an exception will probably ruin your day. Update actions are
not necessarily efficiently restartable.

Do not call JobQueue::waitForBackups() when jobs are popped. Maybe it
makes sense to call a queue-specific replication wait function for
bulk inserts, like copyJobQueue.php, but doing it when jobs are popped
just makes no sense. Surely the worst that could happen is that the
queue would become locally empty? Removing this waitForBackups() call
avoids waiting for replication twice when JobQueueDB is used.

Bug: T201482
Change-Id: Ia820196caccf9c95007aea12175faf809800f084
includes/GlobalFunctions.php
includes/installer/DatabaseUpdater.php
includes/installer/MysqlUpdater.php
includes/jobqueue/JobRunner.php
includes/jobqueue/jobs/RecentChangesUpdateJob.php
includes/jobqueue/jobs/RefreshLinksJob.php
includes/libs/rdbms/exception/DBReplicationWaitError.php
includes/libs/rdbms/lbfactory/ILBFactory.php
includes/libs/rdbms/lbfactory/LBFactory.php
maintenance/Maintenance.php
maintenance/updateSpecialPages.php