In Doxygen 1.9.7, the URL generation logic changed such that input
files in directories (i.e. /docs/Hooks.md) are published with the
slug `md_docs_2Hooks.html` instead of `md_docs_Hooks.html`.
This was done to improve an edge case where if two conflicting
files existed (e.g. docs_Foo.md and docs/Foo.md) both can now get
their own stable URL in a determimistic way (e.g. as opposed to
a-z sorting and appending _2 only if a conflict exists). But this
made other more common URLs no longer stable. Work around this by
setting an explict permalink for each markdown file.
Ref https://github.com/doxygen/doxygen/issues/10721.
Change-Id: Ifeb03602452c1148bd372555bebac9922c583ac2
Some less trivial cases. Also update variable names.
This doesn't really change anything, but I hope it helps promote
getConnectionProvider() as the common way to do this.
Follow-up to 8604c384f6.
Change-Id: I6657d783375fac5c7fa856b884ff1fb09285e94c
The currently supported groups are documented in database.md.
While at it, prefer the string form of the $groups parameter where
possible, since the complexity of an array is never utilized, as the
groups either can't overlap, or are decided on by the caller instead.
This also helps with the simpler LBFactory::getConnection() proposed
in T326274.
Bug: T263127
Bug: T326274
Change-Id: I7a31a07a8c3f1e265ac43ab59f23326590b407c3
== What
* Trigger "lagged replica mode" even when all replicas are lagged.
This partially undoes I53b261dfe (f59e4ad95e).
This restores "shorten CDN cache" behaviour for third-party wikis.
* Change "lagged replica mode" to no longer have the side-effect of
making primary DBs read-only, under any circumstances.
* Change "getLaggedReplicaMode" to no longer trigger a connection.
If no data was queried, no stale data was served (mostly, there is
potential via Memcached, but we don't measure that either way, and
should be taken care of by rebound purges for production, though
as explained below, this mode doesn't matter for production).
== Why
Follows-up I53b261dfe (f59e4ad95e), which changed lagged-replica
mode to no longer be triggered when all replicas are lagged. This
was motivated by the fact that
1. It is understood that at WMF it is impossible for all replicas to
be lagged due to MySQL semi-sync, and
2. That this mode often triggers at WMF anyway due to how we measure
lag, and
3. When this mode is activated it needlessly makes MW read-only.
This has as downsides that it means lagged-replica mode no longer
triggers for third-parties without semi-sync either, and thus the
side-effect of shortening caches doesn't work, and the Skin footer
message wouldn't be shown either.
The problem we want to solve, which I think translates to both WMF
and thid-parties, is that MediaWiki doesn't need to be responsible
for turning the site read-only when a replica is lagged. For scales
where that is a big problem, MySQL semi-sync can be used by the site
admin, and smaller sites either don't have replicas or are small enough
to not yet have this problem, and likely would be bottlenecked well
before the DB level anyway.
As such, solve T314975 differently by removing this activation of
read-only mode instead, and preserve/restore the rest of it in simpler
form.
== Background
The docs were very outdated, in particular the statement about
30 seconds. Historical references to that changing:
* 2015: The MW default setting was lowered from 30s to 10s,
with commit I56a7f35382 (453d88605b, T95501).
* 2015: The WMF config for 'max lag' in $wgLBFactoryConf was gradually
lowered from 30s to 6s, e.g. commit I7f71d75b (744722e784) and
I02b1789095 (e8276e074f).
* 2019: The MW default was lowered from 10s to 6s,
with commit Ic2e82a8cc (e8276e074f).
Bug: T314975
Change-Id: Ie55aad42d99c71c54137c7c4138093082e561097
Add section to database.md outlining simple
usage of database groups and the 3 remaining
supported types.
Bug: T267077
Change-Id: I66cb2fb063f291afc94ff207ef8d9a035bfc6a86
