TLDR:
* We'd like to drop MySQL 5.5 support for the
"lagDetectionMethod=pt-heartbeart"
option in $wgLBFactoryConf.
* If you have not configured the lagDetectionMethod option, or use MySQL
5.6+, then this does not affect you.
Hi,
If you host MediaWiki using MySQL (or MariaDB) and have a cluster of two or
more database hosts (using replication), then MediaWiki uses lag detection,
via the wikimedia/rdbms library. For example, if lag is too high, MediaWiki
tries to connect to a different replica database, or it may automatically
set the wiki in read-only mode for a few seconds until replication catches
up.
By default, MediaWiki uses the MySQL built-in "Seconds_Behind_Master"
feature to power this lag detection.
We also support use of Percona's pt-heartbeat service, which can be more
accurate, [1] and is what WMF currently uses. However, we are currently
unable to use its accuracy very well, because TIMESTAMPDIFF is not
supported in MySQL 5.5 (it was introduced in MySQL 5.6.4). [2]
In order to make pt-heartbeat more useful as a lag detection method, whilst
avoiding expensive roundtrips or runtime detection (which are not
acceptable in this hot code path), we'd either have to support three lag
detection methods, or to change the current one to require MySQL 5.6.
MySQL 5.5 reached end-of-life in Dec 2018, and there is an open proposal at
T273375 to drop support for it completely in a future version of MediaWiki.
[3] However, I'd like to propose we drop support for it now with the
pt-heartbeat feature specifically, as being opt-in and rarely used, so as
to not require additional complexity and maintenance for us in the form a
third lag detection method. Especially, as it might not be used by anyone.
If you're affected by this, then the upcoming MediaWiki 1.36 release would
require that you either set MW to use the default lag detection instead, or
upgrade to MySQL 5.6+.
Task: https://phabricator.wikimedia.org/T248481
Patch: https://gerrit.wikimedia.org/r/c/mediawiki/core/+/657471
--
Timo Tijhof
Performance Team
Wikimedia Foundation
[1]
https://www.percona.com/blog/2014/05/02/how-to-identify-and-cure-mysql-replication-slave-lag/
[2] https://dev.mysql.com/doc/relnotes/mysql/5.6/en/news-5-6-4.html
[3] https://phabricator.wikimedia.org/T273375
* We'd like to drop MySQL 5.5 support for the
"lagDetectionMethod=pt-heartbeart"
option in $wgLBFactoryConf.
* If you have not configured the lagDetectionMethod option, or use MySQL
5.6+, then this does not affect you.
Hi,
If you host MediaWiki using MySQL (or MariaDB) and have a cluster of two or
more database hosts (using replication), then MediaWiki uses lag detection,
via the wikimedia/rdbms library. For example, if lag is too high, MediaWiki
tries to connect to a different replica database, or it may automatically
set the wiki in read-only mode for a few seconds until replication catches
up.
By default, MediaWiki uses the MySQL built-in "Seconds_Behind_Master"
feature to power this lag detection.
We also support use of Percona's pt-heartbeat service, which can be more
accurate, [1] and is what WMF currently uses. However, we are currently
unable to use its accuracy very well, because TIMESTAMPDIFF is not
supported in MySQL 5.5 (it was introduced in MySQL 5.6.4). [2]
In order to make pt-heartbeat more useful as a lag detection method, whilst
avoiding expensive roundtrips or runtime detection (which are not
acceptable in this hot code path), we'd either have to support three lag
detection methods, or to change the current one to require MySQL 5.6.
MySQL 5.5 reached end-of-life in Dec 2018, and there is an open proposal at
T273375 to drop support for it completely in a future version of MediaWiki.
[3] However, I'd like to propose we drop support for it now with the
pt-heartbeat feature specifically, as being opt-in and rarely used, so as
to not require additional complexity and maintenance for us in the form a
third lag detection method. Especially, as it might not be used by anyone.
If you're affected by this, then the upcoming MediaWiki 1.36 release would
require that you either set MW to use the default lag detection instead, or
upgrade to MySQL 5.6+.
Task: https://phabricator.wikimedia.org/T248481
Patch: https://gerrit.wikimedia.org/r/c/mediawiki/core/+/657471
--
Timo Tijhof
Performance Team
Wikimedia Foundation
[1]
https://www.percona.com/blog/2014/05/02/how-to-identify-and-cure-mysql-replication-slave-lag/
[2] https://dev.mysql.com/doc/relnotes/mysql/5.6/en/news-5-6-4.html
[3] https://phabricator.wikimedia.org/T273375