-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
We're going to be doing some network maintenance this afternoon, which
might cause some intermittent (but hopefully short) service
interruption.
- river.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (HP-UX)
iEYEARECAAYFAkvBxWYACgkQIXd7fCuc5vK+dQCdGUfVd1lqh0LBpMix/eEciWm8
jSYAoLSYEFK2Kabku2JlXzz3dCcy/wf/
=ILRy
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
JIRA has been upgraded to 4.1. Please report any issues in the TS
project, or to ts-admins@ if that's not possible.
- river.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (HP-UX)
iEYEARECAAYFAku+vdAACgkQIXd7fCuc5vKWWgCfXDtlidwdL+PmCitDPrtv0dY3
inwAn1uiEo7iVTWABsZGWBrPfg4glT92
=2WzG
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
To resolve the previously announced problems with s4, we will be
switching these clusters to a different server on Tuesday morning UTC
(in a few hours). This will involve a period of read-only while user
databases are moved, but access to replicated databases should not be
interrupted.
After this is complete, we will reimport the databases on the current
s3/s4/s6 server and use this as the redundant/fast server for s3/s4/s6.
These issues are being tracked in JIRA as MNT-444 (server switch) and
MNT-445 (fast server).
- river.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (HP-UX)
iEYEARECAAYFAku6Z2oACgkQIXd7fCuc5vLxZACfdhNbIu76a7/ZTQZ3SjLEKUuW
3IgAoJBVhQsnFi010G+ouujJ85pocGl1
=pNoZ
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
We're about to do some hardware maintenance on cassia, which will cause
about 20 minutes of downtime, during which s3/s4/s6 will be unavailable.
Sorry for the short notice.
- river.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (HP-UX)
iEYEARECAAYFAku2Mw8ACgkQIXd7fCuc5vLrPACgiae4PKcdzYFMcF8lx0pr4JxY
nngAnAj+3Y/tOcTXA46podNmAp3MBWxz
=9RSa
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
Yesterday we noticed an issue with the ruwiki database similar to the
previous issue with commons (specifically, missing rows in
ruwiki.revision). It's not clear what causes this, but the most likely
candidate seems to be mydumper, the tool we use to produce database
dumps. We will therefore be reimporting s3, s4 and s6 (which were all
recently imported with mydumper) to hyacinth using mysqldump instead,
then switching these clusters from the current server (cassia) to
hyacinth.
This issue is being tracked in JIRA is MNT-438.
- river.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (HP-UX)
iEYEARECAAYFAku1tLMACgkQIXd7fCuc5vINkQCePP4qMqYzGBEmUdSliagoscr5
ZpAAnjGOLq6M5e7z9RDBmN3rEYci371Y
=9lf2
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
As our master copy of s4 is missing parts of the database (TS-583), I
will reimport the database today. While this is in progress, there will
be no commonswiki_p database on cassia, the server for s3 and s6. The
import should only take an hour or two. After the import, s4 will be
switched back to cassia, which will fix the problem with user databases
being on the wrong server.
This issue is being tracked in JIRA as MNT-436.
- river.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (HP-UX)
iEYEARECAAYFAkuzN2gACgkQIXd7fCuc5vIGNACgwHNE6wqPA6KuYk+BDtXjoCzL
nQIAn1ymlXYcU+0T2EUyhSKZrFdQ/k7R
=xVyB
-----END PGP SIGNATURE-----