Huutoanbui3@gmail.com Toi chua nhan duoc mot khoan tien nao ca .neu nhu muon hop tac lau dai thi xin mong la moi nguoi hay lam ciec theo mot cach thuc te .va dung doi hoi nheu qua .xin cam on
Vào 19:03 Th 7, 09 thg 11 2019 mediawiki-l-request@lists.wikimedia.org đã viết:
Send MediaWiki-l mailing list submissions to mediawiki-l@lists.wikimedia.org
To subscribe or unsubscribe via the World Wide Web, visit https://lists.wikimedia.org/mailman/listinfo/mediawiki-l or, via email, send a message with subject or body 'help' to mediawiki-l-request@lists.wikimedia.org
You can reach the person managing the list at mediawiki-l-owner@lists.wikimedia.org
When replying, please edit your Subject line so it is more specific than "Re: Contents of MediaWiki-l digest..."
Today's Topics:
- Re: [Cargo] table format for _pageData and _fileData (Yaron Koren)
- GitHub's "Automated Security Fixes" have been disabled on the Wikimedia Org (Sam Reed)
Message: 1 Date: Fri, 8 Nov 2019 11:00:38 -0500 From: Yaron Koren yaron@wikiworks.com To: MediaWiki announcements and site admin list mediawiki-l@lists.wikimedia.org Subject: Re: [MediaWiki-l] [Cargo] table format for _pageData and _fileData Message-ID: <CAGmQEQFfb--cRyPLFZik63su2qM-Nk73+0jyT+hc= zOjf39C+w@mail.gmail.com> Content-Type: text/plain; charset="UTF-8"
Hi Jan,
Oh, that's too bad. I didn't know that MyISAM doesn't support database clustering. (You might be the first person to run Cargo on a clustered database - it's good to know that it seems to be working, other than this one problem.)
You're right that the MyISAM requirement is only for old database versions
- the last version of MySQL that had this problem was 5.6, and that version
came out in 2013, and will stop being supported in a little over a year. I could have added a new setting like $wgCargoUseMyISAMForTablesWithSearchtextFields, but that seemed like overkill, so I decided instead to just remove this code that forces the use of MyISAM. Hopefully there aren't too many people who (a) are using Cargo with MySQL <= 5.6 (or its MariaDB equivalent), (b) use InnoDB by default, (c) use the _pageData or _fileData tables, and (d) will recreate these tables in the future. If there are, they'll have to either manually re-add this code in, or update to a more recent DB version.
Anyway, if you get the latest version of the Cargo code, and recreate these tables, the problems will hopefully be gone.
-Yaron
On Fri, Nov 8, 2019 at 6:52 AM Jan Böhme jan@idea-sketch.com wrote:
Hi,
for our production system I’m using a MariaDB Galera cluster as RDMS backend. Though there is a feature to enable (experimental) replication
of
MyISAM tables, this doesn't play well with Cargo. Certain operations involving _pageData tables caused the cluster to reach an inconsistent
data
state, thus stopping replication and ultimately falling apart.
I could isolate the cause to the following transaction (which is embedded between two inserts for the same thing):
BEGIN /* Wikimedia\Rdbms\Database::begin */ SHOW /* Wikimedia\Rdbms\DatabaseMysqlBase::tableExists */ TABLES LIKE 'cargo__staff__NEXT' SHOW /* Wikimedia\Rdbms\DatabaseMysqlBase::tableExists */ TABLES LIKE 'cargo__staff___files' DELETE /* Wikimedia\Rdbms\Database::delete */ FROM `cargo__staff` WHERE `_pageID` = '273' DELETE /* Wikimedia\Rdbms\Database::delete */ FROM `cargo___pageData` WHERE `_pageID` = '273' COMMIT /* Wikimedia\Rdbms\Database::commit */
cargo__staff table being InnoDB, cargo___pageData being MyISAM. Unfortunately this leads to the delete statement on the InnoDB table not being replicated, while the delete on the MyISAM table is. Thus on the following insert the row already exists, causing a unique key violation
and
inconsistent cluster state.
Is it really still necessary to use MyISAM for these tables? Full text indices are available on InnoDB for quite some time now, so I’m wondering whether this still needs to be supported or if it would be possible to
make
both choices available.
Best: Jan.
-- idea-sketch
Jan Böhme & Uwe Schützenmeister Lößnitzstr. 14 01097 Dresden
www.idea-sketch.com http://www.idea-sketch.com/
Tel.: +49 . (0)351 . 810 74 250 Mobil: +49 . (0)179 .53 41 641
MediaWiki-l mailing list To unsubscribe, go to: https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
-- WikiWorks · MediaWiki Consulting · http://wikiworks.com
Message: 2 Date: Fri, 8 Nov 2019 18:42:37 -0700 From: Sam Reed reedy@wikimedia.org To: wikitech-l@lists.wikimedia.org, mediawiki-l@lists.wikimedia.org Subject: [MediaWiki-l] GitHub's "Automated Security Fixes" have been disabled on the Wikimedia Org Message-ID: <CAOCnLWYP_A9ugC+q3U= mF70mFOhvWygdAea3ewxHdKoMCZEemg@mail.gmail.com> Content-Type: text/plain; charset="UTF-8"
Just a heads up that "Automated Security Fixes" have been disabled on the Wikimedia GitHub org. See [1]
The reason for this is that it generates pull requests on non canonical repositories (ie where Gerrit is the default development location) that require developers to close them.
If this is a feature you want on your repo generally, because you canonically develop on GitHub, you can re-enable these on your repo by clicking the "Security" tab, and then selecting "Automated Security Fixes" in the top right corner. See [2] for more info. If you do develop canonically in GitHub, please let us know at [3].
Note, this doesn't affect the security alerts related to outdated packages etc in a repo.
Thanks!
Sam
[1] https://phabricator.wikimedia.org/T237337 [2]
https://help.github.com/en/github/managing-security-vulnerabilities/configur... [3] https://phabricator.wikimedia.org/T237470 [4]
https://help.github.com/en/github/managing-security-vulnerabilities/viewing-...
Subject: Digest Footer
MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
End of MediaWiki-l Digest, Vol 194, Issue 5
mediawiki-l@lists.wikimedia.org