[Wikidata-bugs] [Maniphest] [Commented On] T162562: Choose a field length for entity id columns and stick to it

Marostegui added a comment. Once you've decided which size goes best for the needs and the future, just let us (dba) know. Obviously the smaller the better, but that is probably not possible :-)TASK DETAILhttps://phabricator.wikimedia.org/T162562EMAIL PREFERENCEShttps://phabricator.wikimedi

[Wikidata-bugs] [Maniphest] [Commented On] T162252: Create SQL database and Tables for Cognate extension to be used on Wiktionaries

Marostegui added a comment. Yup, we can leave labs aside for the "first stage" and then study those without blocking this task I would say.TASK DETAILhttps://phabricator.wikimedia.org/T162252EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Ma

[Wikidata-bugs] [Maniphest] [Commented On] T162252: Create SQL database and Tables for Cognate extension to be used on Wiktionaries

Marostegui added a comment. A quick look on the x1 production hosts (thanks Jaime for the clarification) shows no replication filters so for those, we should be fine to create all on the master and let it replicate. As Jaime mentioned, for labs we might need to manually intervene there, if

[Wikidata-bugs] [Maniphest] [Commented On] T162252: Create SQL database and Tables for Cognate extension to be used on Wiktionaries

Marostegui added a comment. In T162252#3163937, @jcrespo wrote: So that we are not a blocker- creation of tables in production, specially if we have already given the OK to the plans, is not considered a schema change, so anyone with production rights can do it- you just need to mark it on the

[Wikidata-bugs] [Maniphest] [Updated] T162252: Create SQL database and Tables for Cognate extension to be used on Wiktionaries

Marostegui added a comment. As per T148988#2742029 I assume this is all public info and no further filtering is required when replicating to labs. Most of the *wiktionary databases currently live in s3 so I would assume we need to create the new database and the 3 tables there too?TASK DETAILhttps

[Wikidata-bugs] [Maniphest] [Commented On] T160887: Wikibase\Repo\Store\Sql\SqlEntitiesWithoutTermFinder::getEntitiesWithoutTerm can take 19 hours to execute and it is run by the web requests user

Marostegui added a comment. I am afraid this not only runs on vslow slaves. db1070 is not receiving vslow traffic just yet (it was depooled for reimage and only pooled with just normal traffic to warm it up by the end of the week) see: https://noc.wikimedia.org/conf/highlight.php?file=db

[Wikidata-bugs] [Maniphest] [Unassigned] T144010: Drop eu_touched in production

Marostegui removed Marostegui as the assignee of this task. TASK DETAILhttps://phabricator.wikimedia.org/T144010EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: MarosteguiCc: Marostegui, jcrespo, Aklapper, gerritbot, hoo, QZanden, Minhnv-2809, D3r1ck01, Izno

[Wikidata-bugs] [Maniphest] [Commented On] T159718: Evaluate if it is possbile to add an empty column for full entity ID to wb_terms without affecting wikidata.org users

Marostegui added a comment. In T159718#3079126, @WMDE-leszek wrote: Thank you @jcrespo and @Marostegui for your comments. I am happy I asked and you made me sketch the whole big plan. As you might have realized , I am really not a DB expert. Therefore some not smart things in the plan

[Wikidata-bugs] [Maniphest] [Commented On] T159718: Evaluate if it is possbile to add an empty column for full entity ID to wb_terms without affecting wikidata.org users

Marostegui added a comment. In T159718#3077513, @jcrespo wrote: Populate new column at the same time than the current one (ideally with code, but if you do not want to touch code, it can even be made with a trigger) + populate old values with maintenance If possible, I would avoid using

[Wikidata-bugs] [Maniphest] [Commented On] T159718: Evaluate if it is possbile to add an empty column for full entity ID to wb_terms without affecting wikidata.org users

Marostegui added a comment. In T159718#3076201, @jcrespo wrote: Evaluate if it is feasible to add such an "empty" column without making Wikidata readonly. we can probably do it How certain are you? In my experience, the biggest blocker on production is not the size, but how busy th

[Wikidata-bugs] [Maniphest] [Commented On] T159718: Evaluate feasibility of adding a column for full entity ID to wb_terms

Marostegui added a comment. Hi! The wt_terms table is a quite big table (as you already probably know) it is around 230G on disk. That means the ALTER table will take quite a while. The good news is that adding a column can be done in-place so we can probably do it without causing delay on the

[Wikidata-bugs] [Maniphest] [Commented On] T156638: Large amount of "DatabaseMysqlBase::lock failed to acquire lock 'wikidatawiki-activeusers'" timeout-errors on wikidata since 2017-01-30 8:05 UTC

Marostegui added a comment. In T156638#2985541, @hoo wrote: This is probably due to the large amounts of edits on Wikidata. Taking. Thank you!TASK DETAILhttps://phabricator.wikimedia.org/T156638EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: hoo

[Wikidata-bugs] [Maniphest] [Commented On] T156638: Large amount of "DatabaseMysqlBase::lock failed to acquire lock 'wikidatawiki-activeusers'" timeout-errors on wikidata since 2017-01-30 8:05 UTC

Marostegui added a comment. This is still happening: https://logstash.wikimedia.org/goto/dd30b48bf0857dbaa62241363df3e3b0TASK DETAILhttps://phabricator.wikimedia.org/T156638EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: MarosteguiCc: Marostegui, Aklapper

[Wikidata-bugs] [Maniphest] [Commented On] T151681: DispatchChanges: Avoid long-lasting connections to the master DB

Marostegui added a comment. Holding connections on the master: if there are 5-10 jobs running it shouldn't be a big deal as I assume only 10 connections (max) will be just connected (but not doing anything, right?). It can be a problem if the master is under heavy stress, however, if the

[Wikidata-bugs] [Maniphest] [Commented On] T144010: Drop eu_touched in production

Marostegui added a comment. A quick salt run: sudo salt -C 'G@mysql_role:master and G@site:codfw and G@mysql_group:core' cmd.run 'find /srv/sqldata/ -name wbc_entity_usage.frm ' Shows it is present in all the shards, so what I have done is rename this column in db2048 (s1 -

[Wikidata-bugs] [Maniphest] [Claimed] T144010: Drop eu_touched in production

Marostegui claimed this task. TASK DETAILhttps://phabricator.wikimedia.org/T144010EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: MarosteguiCc: jcrespo, Aklapper, gerritbot, hoo, Marostegui, Minhnv-2809, D3r1ck01, Izno, Luke081515, Wikidata-bugs, aude

<    3   4   5   6   7   8