-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Nachdem ich heute mit Hilfe von Krisztian den MySQL-Dump von gestern wieder eingespielt habe und gewartet habe bis die Replikation wieder aufgeholt hat - sie war über 20h hinterher - haben wir nun eine Differenz von *185 GB* zwischen dem db01.lmx und db02.lmx. Task: INFRA-159 Das heißt nun: * Wir können den db02.lmx zum Master machen und den db01.lmx komplett neuaufsetzen * Wir brauchen - Dank den Löschscripten - nur einen Bruchteil der Datenmenge als bisher angenommen * Sämtliche Backup/Recovery Strategien werden nun wesentlich schneller sein * Ich habe bewiesen, dass der bisherige Ansatz alles mit Hardware zu erschlagen nicht immer sinnvoll ist. zu testen: * Querys gegen den db01.lmx vs. db02.lmx schicken und Zeitdifferenz messen Was folgt: * Wechsel zu InnoDB (Test bei hocl?) * Wechsel zu MySQl 5.5 (MariaDB/Percona) mit Galera-Cluster Verbesserung: * Weniger sinnlose Daten in die DBs schreiben (Logs, die alsbald ungesehen gelöscht werden) * MySQL Backup/Recovery Scripte/Ansatz (INFRA-160) * Nutzdaten welche schnell verfügbar sein müssen auf SSDs auslagern lg, Tilo Am 21.05.2013 07:03, schrieb Tilo Werner:
Replikation läuft wieder und ich hab e 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
_______________________________________________ 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) iQIcBAEBAgAGBQJRnp8fAAoJEFfjOJdKpi1EZlYQAJPunkxE/qeke+iLZn5kq2gT GXTuq2sjNSkMIZZcUX122jKrjOtrUVN7NJ/O3A9ctEHDj3U+06CBxsArRZoBLjqq Tl1mi5kk2ShYETs8qNz8GIVXrp/U6F4azy/fgy/ApTgH2CuVuSYXL6ocGmKjDhml akUJgQKY9bpfgSOIijxrG9asH9HTcZpVgZqfRCWnjgJVejikSbJIUpsVWrrytLZz 94mL5uFLBIhI68V+M8mwJ4hphVrFcj3PKhB+3NsWLoid4vbz90BYD1ctPBRn5dxj RSTXYvXuiim5+inJDe7O5BPFjVCMW1fMLhJPS4bu4GjFtJgnuZ7Ywwy6XscNc6WL MMYe6jFIJI1er5in9TxExfyfpvSwcgVvEwOMa5NSR8fChkHP0o77ZroAhkYIQkAR eveXmxmDbnda5NN5f2yvPGafFzHduGmxIMRC/jUh8eA9bGuaD0VX2+AbX8R5tT0L oM5s7400C7ciXJmV+Whtsqv8oEe+MQmO60+RldpwKmgJIf7jY3R4k4VtrmH9Kvcx CtTtvIbVs5foDzawuNkQq76xicoyyIYuf96UvWUj8Sc37Moen/VpfsxkSHDTXj2w zLwSBgUPwbpRNoASlf3hE/FmpW9xg32IcscGTokLQG4ODB9uiUAq4syQCQzMAPyK X1HJuRSO5GOH0oiotGX1 =D3rs -----END PGP SIGNATURE-----