-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Replikation läuft wieder und ich habe gleich noch ein Backup angestossen. Am 21.05.2013 01:43, schrieb Tilo Werner:
Hallo,
Am 18.05.2013 12:32, schrieb Tobias Stein:
Hallo liebe Kollegen,
Ich hab einfach mal im Zitat kommentiert und hoffe das findet keinen Anstoss.
Nö, ganz im Gegenteil.
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 /"
Das werde ich in ca. 1,5h machen.
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.
Danke!
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?
Gab es nicht, deshalb: Gebt acht auf den FPC!
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.
Konserver löschen wir, ok.
Leider ist aber der backup01.lmx eine VM die nicht so einfach erweitert werden kann, sie muss folglich erst neu aufgesetzt werden, was mir bei der BS-Version einfach zu doof ist.
Weshalb ich den binär-Dump auf den db02.lmx laufen lassen werde. Das wirft uns zwar nur ein kleines Stück vorwärts, aber immerhin - Wir leben hier schließlich von Krümeln...
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 ...
*NO COMMENT*
_______________________________________________ team mailing list team@lists.activate.de https://lists.activate.de/listinfo/team
- -- Tilo Werner - - Systemadministration - activate communication systems GmbH G.-Schumann-Str. 294 04159 Leipzig email: t.werner@activate.de Geschäftsführer: Markus Hartwig, Rainer Jansen Handelsregister: Amtsgericht Leipzig (HRB 21850) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBAgAGBQJRmwARAAoJEFfjOJdKpi1EQqsP/0AhFtE+hw5YvM7dYhWDbapM /HG1ZLONnh+EsA2zwejdSX1Ykjenm4mDsR/LK03Y5HhospVy28aW/s8kSJG20inw olPPQtSaINdZnOsba/xxubL72lcGEvFRGGdB6ZsxHoRxupL1tEb9x/CIeGW2wf28 3nP4u8OMB7Lor4gUn+HGIFfrRJzwM+OTPgn990Po8/O7zID3wKOADAsoj/htlEN1 Z/g8tgvVF9xqTXrXiZtOa2vNNt7TSdPunbq+O01HHpFhgp7r5l3Vt8cy4maX+qtL a8GC7YqNnPzCtulKlOM7atg3//ecFKQK3qFgiU6ObvzTlC6gcNBdGmwhVzcjBv+h c6XcMmlNaLV1qHVWyNZ1VuzYVX1y/qVTvzwuKvoFkyDBNFDTZ+ghIbKttKGlX0A+ st7yFMRwffb/OfrL7VKQpyLptfGdEOmGyOXMcqdaxEV0vcU2ttj0R4kn7TyRuXTn 7KnwohAs0T7hxcBdKFmmrS+Um0LDqrxN5feNvX9riesEHTdQ2+PmPhjIfKGXQ9XJ PRXguo3okogkAymYrgkZPhgNoqw6zJAmpSHckxBaf0FuKyvps56TwIDcd07vl3Nw BqY/WhJor5nw6HCT9gBJdTPY9PU1ogf2KG711HneR6/Ajak98keBEbmm6BeomS4D 3F7E/gIPTenPKV0fArk5 =5FBC -----END PGP SIGNATURE-----