Hi,
we currently have a replication lag of more than one day again.
http://tools.wikimedia.de/~interiot/cgi-bin/zedbot,blame
says "root 2 days, 5 HOURS"
What in the world is going on there? ;)
Regards, Aka
Andre Karwath schrieb:
Hi,
we currently have a replication lag of more than one day again.
http://tools.wikimedia.de/~interiot/cgi-bin/zedbot,blame
says "root 2 days, 5 HOURS"
What in the world is going on there? ;)
Sounds like a maintance query or so. Would be nice if someone with show processlist could tell us what's that if it's nothing secret, or even better if users could announce such queries.
leon
Sounds like a maintance query or so. Would be nice if someone with show processlist could tell us what's that if it's nothing secret, or even better if users could announce such queries.
This is exactly what I tried to say without finding the right words.
Thanks, Danke Super-Leon ;)
Regards, Aka
Andre Karwath schrieb:
Sounds like a maintance query or so. Would be nice if someone with show processlist could tell us what's that if it's nothing secret, or even better if users could announce such queries.
This is exactly what I tried to say without finding the right words.
Thanks, Danke Super-Leon ;)
LOL -- rob has killed this query now. Thank *him*. Leon
On 16/06/06, Andre Karwath aka@aka-online.de wrote:
we currently have a replication lag of more than one day again.
http://tools.wikimedia.de/~interiot/cgi-bin/zedbot,blame
says "root 2 days, 5 HOURS"
What in the world is going on there? ;)
Root was running the following:
"select rev_timestamp,rev_user_text,rev_comment,rev_id from revision where rev_timestamp >20060608073"
Didn't seem critical, so I killed it. It's not one of mine, so apologies if I inadvertently stabbed something one of the other roots did, but it might be an idea if such queries were announced in future. :)
Rob Church
Hello, Am Freitag, den 16.06.2006, 19:57 +0100 schrieb Rob Church:
Root was running the following:
"select rev_timestamp,rev_user_text,rev_comment,rev_id from revision where rev_timestamp >20060608073"
Didn't seem critical, so I killed it. It's not one of mine, so apologies if I inadvertently stabbed something one of the other roots did, but it might be an idea if such queries were announced in future. :)
sorry, that was a wrong query of mine. I tought, I had killed it.
Rob Church
Sincerly, DaB.
On 6/16/06, DaB. wp@daniel.baur4.info wrote:
sorry, that was a wrong query of mine. I tought, I had killed it.
If you did not know this already: remember to quote strings. Otherwise the casting from integer to string is performed per row and mysql will not use an index.
Yet another reason why MySQL stinks for adhoc queries.
Hi,
sorry, that was a wrong query of mine. I tought, I had killed it.
OK, this query was not the source of the big replication lag. It has reached nearly two days now:
http://tools.wikimedia.de/~leon/stats/replag/de/replag-weekly.png
Does anyone know what the reason is?
Regards, Aka
Hi,
http://tools.wikimedia.de/~leon/stats/replag/de/replag-weekly.png
Does anyone know what the reason is?
Could an admin please check what is going wrong there and let us know the result? It is really annoying ..
Regards, Aka
Hello, Am Sonntag, den 18.06.2006, 13:16 +0200 schrieb Andre Karwath:
Hi,
http://tools.wikimedia.de/~leon/stats/replag/de/replag-weekly.png
Does anyone know what the reason is?
Could an admin please check what is going wrong there and let us know the result? It is really annoying ..
I have no idea at the moment, where the problem can be. There is no process, which need much CPU-time and no longrun-mysql-task and the discs have enought space. The only chance to former times is, that edward runs a huge number of sleeping sql-tasks simulatry. @edward: Perhaps you can decrease the number of your sql-tasks and so you could check, if there is a changing?
Regards, Aka
Sincerly DaB.
toolserver-l@lists.wikimedia.org