Replace wfGetLB

[lhc/web/wiklou.git] / docs / database.txt

diff --git a/docs/database.txt b/docs/database.txt
index 735f26b..6e88d68 100644 (file)
--- a/docs/database.txt
+++ b/docs/database.txt
@@ -8,7 +8,7 @@ By Tim Starling, January 2006.
 For information about the MediaWiki database layout, such as a 
 description of the tables and their contents, please see:
   https://www.mediawiki.org/wiki/Manual:Database_layout
-  https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/core.git;a=blob_plain;f=maintenance/tables.sql;hb=HEAD
+  https://phabricator.wikimedia.org/diffusion/MW/browse/master/maintenance/tables.sql
 
 
 ------------------------------------------------------------------------
@@ -17,7 +17,7 @@ description of the tables and their contents, please see:
 
 To make a read query, something like this usually suffices:
 
-$dbr = wfGetDB( DB_SLAVE );
+$dbr = wfGetDB( DB_REPLICA );
 $res = $dbr->select( /* ...see docs... */ );
 foreach ( $res as $row ) {
        ...
@@ -71,7 +71,7 @@ want to write code destined for Wikipedia.
 It's often the case that the best algorithm to use for a given task
 depends on whether or not replication is in use. Due to our unabashed
 Wikipedia-centrism, we often just use the replication-friendly version,
-but if you like, you can use wfGetLB()->getServerCount() > 1 to
+but if you like, you can use LoadBalancer::getServerCount() > 1 to
 check to see if replication is in use.
 
 === Lag ===
@@ -107,7 +107,7 @@ in the session, and then at the start of each request, waiting for the
 slave to catch up to that position before doing any reads from it. If
 this wait times out, reads are allowed anyway, but the request is
 considered to be in "lagged slave mode". Lagged slave mode can be
-checked by calling wfGetLB()->getLaggedSlaveMode(). The only
+checked by calling LoadBalancer::getLaggedReplicaMode(). The only
 practical consequence at present is a warning displayed in the page
 footer.
 
@@ -159,10 +159,7 @@ $dbw->commit( __METHOD__ );
 
 Use of locking reads (e.g. the FOR UPDATE clause) is not advised. They
 are poorly implemented in InnoDB and will cause regular deadlock errors.
-It's also surprisingly easy to cripple the wiki with lock contention. If
-you must use them, define a new flag for $wgAntiLockFlags which allows
-them to be turned off, because we'll almost certainly need to do so on
-the Wikimedia cluster.
+It's also surprisingly easy to cripple the wiki with lock contention.
 
 Instead of locking reads, combine your existence checks into your write
 queries, by using an appropriate condition in the WHERE clause of an