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| <https://dev.mysql.com/doc/refman/5.1/en/privileges-provided.html#priv_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)