Hallo liebe Kollegen,

Ich hab einfach mal im Zitat kommentiert und
hoffe das findet keinen Anstoss.

Am 18.05.2013 07:49, schrieb Tilo Werner:
Hallo,

ich gebe jetzt auf. Mir ist das gleiche passiert wie Tobias letztens,
es gibt anscheinend irgendein Statement, welches den Read-Lock
zerstört. Siehe auch [1].
Die Konfigurationsoption "read-only = true" funktioniert auf dem Master (für mich) nicht,
der master Status zählte weiter hoch ... in der Docu steht:
"The server permits no updates except from users that have the SUPER privilege ..."
mir ist so also stünde dazu etwas zu dem Thema in der xResConf.xml.
Bleiben demzufolge noch:
  1. Abschaltung des MySQL
  2. mysql-client in tmux session mit:
    SET global interactive_timeout = 36000;
    FLUSH TABLES WITH READLOCK;
Die 2. Möglichkeit den DB-Server abzuschalten und die Daten via rsync
zu kopieren scheiterten an den kläglich 8 MB/s Durchsatz (ca. 8-9 h
Laufzeit).
Ich weiss nicht genau warum, jedoch ist das lenny rsync tatsächlich viel zu langsam.
Die 8-9MB/s während dem 170GB großen ib_data file habe ich auch beobachtet
und sind unzureichend um das Vorhaben in möglichst kurzer Zeit abschließen zu können.

Scp kopiert im Klartext-Modus mit ~30MB/s etwas schneller. Die scp interne
single-core Implementation der Kompression ist auch zu lahm.

Noch weiter beschleunigen lässt sich das durch parallele Kompression in Kombination mit
ssh-magic a la Björn. Das nachfolgende Statement funktioniert:
tar -cf - -- /var/lib/mysql/{dbs,ib_data,ib_logs} |\
	pv -s $(du -s /var/lib/mysql/{dbs,ib_data,ib_logs}|\
	awk '{sum+=$1} END {print sum}') | pigz -c |\
	ssh db02.rz1.lmx.xres.de -- "pigz -d | tar xf - -C /"
Damit ist ein Durchsatz von 60-100MB/s unkomprimierter Daten möglich.
Diese Tools standen dir heute morgen noch nicht zur Verfügung.
Ich hab die entsprechenden Repositories hinzugefügt und einiges nachinstalliert.

Die 3. Möglichkeit die Daten per SQL-Dump zu kopieren scheiterte an
der unzuverlässigen Datenleitung.

Ein neuer Versuch wird dann am Dienstag früh geschehen. @Nicole Veto?

<---Anmerkung--->

# mysql -e 'SELECT table_schema "Data Base Name", SUM( data_length +
index_length) / 1024 / 1024  "Data Base Size in MB" FROM
information_schema.TABLES GROUP BY table_schema;'
+--------------------------+----------------------+
| Data Base Name           | Data Base Size in MB |
+--------------------------+----------------------+
...
xres_lmx_logs            |       14097.61469269
xres_lts_logs            |      131461.52751923
...

Wir haben bei LMX/LTS knapp 75GB an Nutzdaten, der Rest sind Logs (LMX
15GB und LTS die 130GB). Macht zusammen 220GB. Auf der Platte werden
z.Zt. 250GB benutzt, die Differenz erklärt sich durch InnoDB. Es sind
noch 60GB frei.

Mein Vorschlag:

1. Wir können mit einem SQL-Dump auf den db02.lmx ca. 30GB gewinnen,
da dann das InnoDB-Problem geschwächt wird. Der wird dann Master.
Ein SQL-Dump dauert ca. 3 Stunden mit READ LOCK.
Dafür wurde backup01.lmx einmal konzipiert, dessen Storage schon seit Monaten nicht
nicht mehr reicht, die LMX/LTS-DBs zu halten. Wir löschen also ein paar Daten auf
vmhost01.lmx und geben backup01.lmx wieder Storage zurück
-> "konserver" kann wieder weg. Dann werden Dumps wieder von
backup01.lmx gezogen. Diese werden in DB02 mit innodb_file_per_table
einspielt, die Änderungen zu DB01 per Replikation aufgeholt und
abschließend eine Binärkopie von db01 nach db02 geschoben.
Dies kann glücklicherweise auch unabhängig von Percona/MariaDB erfolgen.
2. Wir können danach dem db01.lmx ca. 150GB zusätzlich durch
Umpartitionieren verschaffen
Halte ich für eine sinnvolle Idee.
3. Ein Percona/MariaDB 5.5 Upgrade machen
Percona/MariaDB ist leider erst möglich, nachdem es eine Abnahme der Entwicklung gibt.
Das dauert noch locker 3 Wochen, wenn tatsächlich Zeit dafür zur Verfügung steht ...
-> Das dauert alles zusammen ca. 1d

-> Dann haben wir ca. 180GB mehr Platz für xres_*_logs, können also in
Summe ca. 385GB Logs schreiben und das mit Percona/MariaDB sogar noch
schneller als bisher!

<---Ende--->

lg,
Tilo


Am 17.05.2013 13:49, schrieb Tilo Werner:
> Hallo,

> wie mit n.schnick & r.jansen besprochen werde ich die ausgefallene
> Replikation für LMX/LTS wieder aufsetzen.

> Der Zeitraum wird sich von 03:00 bis 07:00 erstrecken. In dieser
> Zeit ist weder LMX noch LTS buchbar!

> Viele Grüße, Tilo Werner

> _______________________________________________ team mailing list
> team@lists.activate.de https://lists.activate.de/listinfo/team


> _______________________________________________
> team mailing list
> team@lists.activate.de
> https://lists.activate.de/listinfo/team

--
Mit freundlichen Grüßen


Tobias Stein
- Systemadministration -

activate communication systems GmbH
G.-Schumann-Str. 294
04159 Leipzig

Tel:    +49 341 90 98 7 508
Fax:    +49 341 90 98 7 49
email:    t.stein@activate.de

Geschäftsführer: Markus Hartwig, Rainer Jansen
Handelsregister: Amtsgericht Leipzig (HRB 21850)