Hello all,
mysql on z-dat-s4-a (that's the host that serves sql-s4 (aka commons) at the
moment) crashed and does not recover as far as I see. So I switched sql-s4-rr
and sql-s4-user to ther hosts which have also a copy of commons. The problem
is now that the host that now serves sql-s4-user have no user-databases at the
moment. I switched the server read/write so you can create databases there if
you like.
For details see [1].
Sincerly,
DaB.
[1] https://jira.toolserver.org/browse/MNT-1074
--
Userpage: [[:w:de:User:DaB.]] — PGP: 2B255885
Hello all,
z-dat-s7-a also crashed arround morning, but the reason looks different to me.
We have no other host which carries s7 so I can't switch over. I managed to
start s7 again, but I will leave it read-only (and without replication)
because I fear the further writes will crash it totaly.
I'm dumping the data of s7 at the moment so I can re-import it later (I hope
that will fix it). The reimport will cause a downtime of unknown lenght – I
will send a email before I start.
Sincerly,
DaB.
--
Userpage: [[:w:de:User:DaB.]] — PGP: 2B255885
Hello all,
the following message is only interesting for people who uses the MySQL-CLI
(the "mysql"-command on the command-line) or the "sql"-script. It doesn't
matter if you use php, perl, phyton, java or other languages.
The problem is that the mysql-cli strips out comments by default (see
bugreport [1]). That is bad for us, because it strips all SLOW_OK or LIMIT:
too; so if you add a SLOW_OK at the mysql-cli it will stript out and the
query-killer will kill it sooner. To prevent this, I changed the mysql-config
in a way that comments will NOT be stripted yesterday [2] .
In the last hour a user told me, that this has a problematic side-effect: if
you use /* foobar */ in a mysql-file OUTSIDE of a query, the file will fail; the
user was angry because I changed the default without telling.
I still think that the mysql-default (to strip comments) is stupid (because in
my eyes the user doesn't expect that comments he/she inserts will be removed).
So here is my plan: I will revert my changes for now (so the mysql-cli will
strip comments again). And I hereby announce that I'm going to change the
default at wednesday, the 31. August, in a way that comments will NOT the
striped out.
You what that means for you:
-If you don't use comments at the mysql-cli: nothing.
-If you use comments at the mysql-cli: You have to add the following lines to
,your .my.cnf-file (you can find this hidden file in your home – please notice
the "." at the start):
--snip--
[mysql]
comments
--snap--
-If you need the default of the mysql-cli after the 31. August, you have to
add the following lines to your .my.cnf:
--snip--
[mysql]
skip-comments
--snap--
My revert will not affect the "sql"-script (our recommend way to uise myql on
the command-line): It will still not strip the comments.
Please feel free to discuss this and ask for details on the mailinglist.
Sincerly,
DaB.
[1] http://bugs.mysql.com/bug.php?id=26215
[2] https://jira.toolserver.org/browse/MNT-1072
--
Userpage: [[:w:de:User:DaB.]] — PGP: 2B255885
Hello all,
the hole toolserver-cluster was away between (circa) 19:12 and 20:30 UTC. The
main-problem was that nfs stoped working and so no login, no web-apps and no
command-line-command could have run. It looks that nfs stoped working because
DNS-resolving stoped working (and AFAIS DNS stoped working because of low
memory or a network-problem). The roots will investigate where the problem
exactly was.
Just as information.
Sincerly,
DaB.
--
Userpage: [[:w:de:User:DaB.]] — PGP: 2B255885
Hello all,
during the last week I kept an eye on the database-servers and killed queries
which had run for too long. In the past we had a programm for that, but
somewhen it stoped working and nobody fixed it AFAIK.
Because watching the mytop is a boring thing and I have to sleep too, I used
the last 2-3 days to write a substitute of the old query-kiler. This program
is working now. It does more or less the same as I did, but it send you an
eMail when it killed one of your query. I think that is an improvment and I
can spend my time with other things.
You can find the parameters of when and if the killer works at [1]. Of corse
there is always the possiblity of adjustments. Feel free to open bugs at JIRA
or discuss on teh mailinglist.
Sincerly,
DaB.
[1]
https://wiki.toolserver.org/view/Database_access#Slow_queries_and_the_query…
--
Userpage: [[:w:de:User:DaB.]] — PGP: 2B255885
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
One of the database servers for these clusters (cassia) has a disk
failure of some kind. All databases should be accessible now, but user
databases will be missing until the problem is resolved.
- river.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (NetBSD)
iEYEARECAAYFAk41cOoACgkQIXd7fCuc5vKekwCgnhvooTgdXbUXZ7dWotpAAX/R
vikAn0ITA4pRfpG+8TFLEnzuLnUV48K3
=kzUq
-----END PGP SIGNATURE-----