-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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 - -- 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) iQIcBAEBAgAGBQJRlhkpAAoJEFfjOJdKpi1EGB0P/iEvCU6suY6sZ7eSU2HUOSvl uYgdqnEdc4NRzBtrWl/8DDKZSU+FE+v2cIhMA8too5CcIjDSG2Z8dmfJhxPeZ0T6 E9hPfCNuJ0TfKMSUk4Jrojch1aA+xSyfXFR4hFm4wriSInnnlfhPTQ5SWndC+ak/ wbuVWYUedYj2a/xXnrgw9Dv9pbErzwYauHNKmyYikRp1SUqOjk/sRXFJVWo2tD9Y Jan4FB5OYXxxQO/7sYXdETqxZkwmXkN5k9Hm4VpJ5ShPH8bUUMfD7JsOCa8KxgTP +08EdqbrkIEdHbVWkPuji6g2hwLSeUs7og3GZzb2c1XFdjylydM+eLK6EN35r0W/ ksdGvTFtDb/yEQnmWayM0Zq1/5pxW6PvTFRhb68Q4YvF9+XDjwlDdLUAtt2plKAg AlrPDqtyY84TAJo5otPl1Axbfd3k7JfBrIu6p13Gr4i9cRL5CzGQKNClHOx86UAf tmPUQl53/XXYogc/gADDs/tPegyj0DvprXrJYN8/3kmKmTKAE4wxjsE6MvdpO11J 338eRuylqc1llcstvfhZGVsTD0qEXuSOsVzQnxRmMpYSmQcgR+YcHVLd8wnxXnaa AO/5bl1q0jg/yoO7uTQM+W6FpTMulbvkWW4ZPaJAozuvWVIwdthdQZ4unerGMqSw aAVNnjfGyX6OUtFqt0pp =MfgI -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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 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). 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. 2. Wir können danach dem db01.lmx ca. 150GB zusätzlich durch Umpartitionieren verschaffen 3. Ein Percona/MariaDB 5.5 Upgrade machen - -> 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
- -- 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) iQIcBAEBAgAGBQJRlxZgAAoJEFfjOJdKpi1Eab8P/0FmdLGxqtOl8VQCXPgqtSos X4NbU/H8znGO37FBk/0hHBcSpZBy2KQgf4R9hwpnoDwALCDOZZcGg6DnSePm2TGq DuG2DEFUcJP0J2UbiNz92xtAw4FjxC9+NQWk0A+bkweHPW5eUZZ7bpl9bQ2xaTJe WNPNcBrVIjJheYWV+uyxbbsNd+xdGV21Lc93mUhQRZwY3rF3NFqNc0hPOPVHVSr6 r1t9mmd932d4G+zbU5OIdCl1/Lj/fIsFtAcmrwOVtbA6ATMnCK0jVaJeSRwbcN8t n3/fZMsYKw6ippYXGkZGrbGSAGWfwadCAaxZd3VDOuqtbSxZpDtoaHnb1fWAFtF3 u+MIg6admpUSDDkghqKdhqcX9kEU8O25HN1B2mt6tEfNJSrnJNhLpGxfDMOql00U KcjIET6KYcyoexrAFpVeYsrt2fYYXBZR1w+NdcaNnDFJqo0Ufw9q99s6+7igdeXS utg+o4futghcINDyNbvSRMgJGQypDoEjhtvROKUfiQ55fEtVnPA+8Ah22ciUuVrr JvRFPN4Y1qQMPtA1FcEtNY+d/APqQAR6gKJkxq28OfcrdtnzflnODESXQVd8e8EI Kf5n7zXxmYr8UroTwJmcOR9DObZITsDf/jh7ZCe+o+4dS/bLZMKYb+xIkYmDVgWq iAugaty5v3E4490/BqAD =cb6o -----END PGP SIGNATURE-----
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)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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* - -- 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) iQIcBAEBAgAGBQJRmrUMAAoJEFfjOJdKpi1ECJQP/RER4x/JvGGZ0xbKUQXktgZg g2bUNrZh+smHFHCBkyx2K5DNma30stWqOxvsS1u1AtF9LYvGkTxygOzxr9BkpITn 45A2WHe1llDbTpT0KwmhNmbSXEnzjFL7N5LMwShqgEcOj/2FvQmUh8h5qdhJOOdt i8yJH8QgjTKWKUc0v/ZZ4INwUhdHPA0j+roGKYLBJLDyimBzUlYFDgGCOzdF6XpY 4RtZIUI7xEYoB0QjZLZc9T3+SjWcuvB50Cr1cz6r94ajIPqB5YAY4KOqzj2ikNVg vuMljXBQY/mMQoU1oO1o5OaDCNTiT2mNLOwuHrhXvpIiSdLhHW0xj0rNZfe2B0ub FxGbDqDpeqICrsU8ugXNiXzTIx9BxT9z5XaqJHu8Er4fZXX/vPHTI77FwYzjxaRz Wvi8gd5M8FEmyz5gBiJFh3ySr+1jatvCito2nDlZyRfMsxhGMlL+3iEmYUxbiMuZ 8HB1KjoHTJYP0dM+NRtoWpe5Tmwz9dltoKjECRj8bCR8WfcUToBOGwdepRFwYhIU d4MAGwR0+q1wnhpnY8heQYxPqsaHwE+B8RqYnhTRw03algW9e90zoY/7onWOVXRC 0272bcmxhbsaWyRHEXhV5uHIe6+Tq0rG8d0xuY/dtMIGLKFf4tNKbGR1r6Cjmldq vx9Bf71QRvcMk+8T/jzZ =E4Gn -----END PGP SIGNATURE-----
-----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-----
-----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-----
-----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-----
participants (2)
-
Tilo Werner -
Tobias Stein