Huutoanbui3(a)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(a)lists.wikimedia.org> đã
viết:
Send MediaWiki-l mailing list submissions to
mediawiki-l(a)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(a)lists.wikimedia.org
You can reach the person managing the list at
mediawiki-l-owner(a)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:
1. Re: [Cargo] table format for _pageData and _fileData (Yaron Koren)
2. 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(a)wikiworks.com>
To: MediaWiki announcements and site admin list
<mediawiki-l(a)lists.wikimedia.org>
Subject: Re: [MediaWiki-l] [Cargo] table format for _pageData and
_fileData
Message-ID:
<CAGmQEQFfb--cRyPLFZik63su2qM-Nk73+0jyT+hc=
zOjf39C+w(a)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(a)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(a)wikimedia.org>
To: wikitech-l(a)lists.wikimedia.org, mediawiki-l(a)lists.wikimedia.org
Subject: [MediaWiki-l] GitHub's "Automated Security Fixes" have been
disabled on the Wikimedia Org
Message-ID:
<CAOCnLWYP_A9ugC+q3U=
mF70mFOhvWygdAea3ewxHdKoMCZEemg(a)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/configu…
[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(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
------------------------------
End of MediaWiki-l Digest, Vol 194, Issue 5
*******************************************