-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Die Datenmenge unterschieden sich zwar auf den Systemen aus Sicht von MySQL: * db01.lmx ca. 90GB * db02.lmx ca. 63GB ABER: Nach Stichproben auf die booking,logs,hotels,flights DBs stellt sich heraus, dass alles da ist - zumindest die Zeilenmenge (count(*)) Nach Absprache mit n.schnick wird Montag entschieden, den db02.lmx als Read-Only einzusetzen um ihn später zum Master zu machen. Hintergrund: * Platzbedarf erheblich gesenkt * Queries brauchen im Schnitt nur noch halb so lang, einige sind sogar Faktor 20x schneller - -> Damit werden wir locker über die Hochsaison kommen. lg, Tilo Am 24.05.2013 00:58, schrieb Tilo Werner:
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
_______________________________________________ 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) iQIcBAEBAgAGBQJRn2oeAAoJEFfjOJdKpi1EHToP/2fouSbPM/O8Rp/g4Jtl2RDf bl8EwqlwRcHy2OJZZ9lJOxeShrlm1W3uxS6Bccm8vZav80OWqGeQZlhT/wn18Lk2 637/WJTe437A605z5Ahw2xswM7K0viTZyFk7X3hoJLANo4L3sz2UM8vSZLT69/zK SOrX4uEWWu9jFvVymNCwbvsro7Ia2uud4BURwAP15DM5OTY9lWW6NJJ0Azhc5YMj 2E3M1OBpfORqNybSI4p3oIknPP0UdK6xnZ4WPJaJLVy2U3WyUISaB4TusSvCU2Lp 9i+kCBehORKZBdXndwm3UMilP0zN52m24MKF2bbXRJ4i9AjHliBBwzVozvBSSkoY gKQ97UOFTQ0+ycq3nRfz5BuW2bMQyj+m615NYTeONcyaOmrmBLNP2xl3/mabucSO jAR7F5apwca4f4JmTMcCeRt195XzAyc1ytJKrUtbij1DDhFwbmTx7tr1ccsLWUka ParE//2p52DjSp84zv/5KR9kKPC6IxQrjAJXQI6/2XXNllBdlAZ7/g9FSCJgBMas P4kxHLR3dJWyAWJPhRl7h+IUsTphzqh7JfLZQmJjk+NVxG7XJw2jzuJcSKycimPP +TLOjNKBbBvQWRe79/K101X+v+X0ndj0Am0K0jO9ex8mb6rwnLELV4zf5mRldCsH trSKhf//uxM0aLjOdNyH =Ef2d -----END PGP SIGNATURE-----