Ich musste wegen eines Projekts die irgendwann neu eingeführte Direktive "strict_trans_tables" in mysql deaktivieren, da sie dazu führte, dass einige MySQL-Queries nicht ausgeführt wurden.
Normalerweise geht man in die /etc/my.cnf , sucht nach "sql_mode=NO_ENGINE_SUBSTITUTION,STRICT_TRANS_TABLES" und kommentiert diese Zeile aus.
Hat aber nicht gereicht. Nach etwas Recherche suchte ich my.cnf die im /usr Verzeichnis sein sollte. Und tatsächlich, sie existierte. Dort gab es auch nur die Zeile "sql_mode=NO_ENGINE_SUBSTITUTION,STRICT_TRANS_TABLES", welche auskommentiert werden musste.
Mittwoch, 29. Oktober 2014
MySQL Datenbank von einem Server zum anderen kopieren mittels ssh und mysqldump
Um eine Datenbank per SSH zu einem anderen Server zu kopieren kann man folgenden Befehl verwenden:
Ja: nach -u und -p kommt KEIN Leerzeichen. Hier ein Beispiel, wenn
User gleich root
Passwort gleich 123sonnenschein
Datenbank gleich MyDB
Ziel-Host: 192.168.2.1
Es sollte beachtet werden, dass auf dem Zielhost entsprechende Rechte des Users vorhanden sind. Also, dass er auch außerhalb von localhost auf den Server verbinden kann.
Zudem sollte die Datenbank (in diesem Fall MyDB) bereits angelegt worden sein.
Das Beispiel geht davon aus, dass User und Passwort auf beiden Servern gleich ist (was keine gute Idee ist).
mysqldump -uuser -ppassword db1 | mysql -h desthost -uuser -ppassword destdb
Ja: nach -u und -p kommt KEIN Leerzeichen. Hier ein Beispiel, wenn
User gleich root
Passwort gleich 123sonnenschein
Datenbank gleich MyDB
Ziel-Host: 192.168.2.1
mysqldump -uroot -p123sonnenschein MyDB | mysql -h 192.168.2.1 -uroot -p123sonnenschein MyDB
Es sollte beachtet werden, dass auf dem Zielhost entsprechende Rechte des Users vorhanden sind. Also, dass er auch außerhalb von localhost auf den Server verbinden kann.
Zudem sollte die Datenbank (in diesem Fall MyDB) bereits angelegt worden sein.
Das Beispiel geht davon aus, dass User und Passwort auf beiden Servern gleich ist (was keine gute Idee ist).
Dienstag, 7. Oktober 2014
[linux] SSH-Befehl im Hintergrund ausführen bzw. nicht beenden, wenn die Verbindung abbricht.
Manchmal möchte man im Remote - SSH einen Befehl eingeben, dessen Ausführung ziemlich lange dauern kann. zum Beispiel das Packen vieler Dateien oder weiß der Fuchs was.
Diese Aktion wird Standardmäßig abgebrochen, wenn die SSH Verbindung beendet wird. Das kann zum Beispiel durch den 24h - Reconnect des Providers sein oder irgendeinen anderen Grund haben. In jedem Fall ist das dann sehr ärgerlich.
Man kann das Ganze aber auch im Hintergrund ausführen - mit "screen".
Um genau das Problem zu lösen benutzt man folgenden Befehl:
"myscreen" ist dabei einfach eine Bezeichnung für den geöffneten neuen Screen.
Beendet man nun die Verbindung zum Server, werden die Befehle weiterhin ausgeführt.
Diese Aktion wird Standardmäßig abgebrochen, wenn die SSH Verbindung beendet wird. Das kann zum Beispiel durch den 24h - Reconnect des Providers sein oder irgendeinen anderen Grund haben. In jedem Fall ist das dann sehr ärgerlich.
Man kann das Ganze aber auch im Hintergrund ausführen - mit "screen".
Um genau das Problem zu lösen benutzt man folgenden Befehl:
screen -dmSL myscreen
"myscreen" ist dabei einfach eine Bezeichnung für den geöffneten neuen Screen.
Beendet man nun die Verbindung zum Server, werden die Befehle weiterhin ausgeführt.
[linux] rsync Performance verbessern. Mehr CPU Kerne.
Ich stand vor dem Problem viele kleine (3 Millionen) Bilddateien von einem Server zum anderen kopieren zu müssen, da der Bildauslagerungsserver gewechselt werden sollte.
Was ich noch nicht probiert habe, ist tar mit einer Erweiterung zu versehen, die mehrere Threads zum Schreiben verwenden kann.
Das gibts hier: http://www.maier-komor.de/mtwrite.html
Syntax für Nutzung mit mtwrite:
Ich habe mich dann aber erstmal für die Nutzung von rsync entschieden. Vorteile: Ich muss den laufenden Betrieb (Bildupload) nicht stoppen; Abgebrochene Aktionen können wieder aufgenommen werden; Ich habe nur eine Aktion auszuführen, denn die Daten werden direkt via ssh übertragen.
Leider dauert dieser Vorgang wegen der vielen kleinen Dateien auch ziemlich lange. Nach 24 Stunden waren knapp 70GB übertragen.
Nun gibt es noch einige Dinge die ich demnächst ausprobieren möchte. Und damit ich Sie nicht vergesse gibt es diesen Post :)
Zum Beispiel lässt sich der CPU - Kern den rsync verwendet auf den Maximalwert hochtakten.
Das kann man so machen:
Mehr dazu auf http://lwn.net/Articles/400489/
Noch etwas mehr verspreche ich mir jedoch von mehreren parallel laufenden rsync- Prozessen.
Mit Hilfe eines Scripts werden die Dateien auf die Prozesse verteilt.
Das Script gibts dort: https://wiki.ncsa.illinois.edu/display/~wglick/Parallel+Rsync
Falls der Link irgendwann mal down sein sollte, hier zum Kopieren:
Nachteil hierbei: Bei diesem Script werden alle Dateien des Hauptverzeichnisses mit nur einem Prozess übertragen. In den Kommentaren gab es eine alternative Lösung:
Für beide Fälle gilt: Soll per ssh übertragen werden - also von Server zu Server - müssen die rsync Befehle abgeändert werden:
Und noch ein wichtiger Parameter: Soll das Verzeichnis lediglich geupdated werden und nicht alle Dateien überschrieben werden, unbedingt die Option "-u"verwenden.
Quellen:
http://www.maier-komor.de/mtwrite.html
http://lwn.net/Articles/400489/
https://wiki.ncsa.illinois.edu/display/~wglick/Parallel+Rsync
http://wiki.ubuntuusers.de/rsync
Das Packen und Archivieren mit tar und gzip war leider unbefriedigend langsam.
Auch die Alternative mit pigz (gzip mit Mehrkern-Unterstützung) brachte keine großartige Besserung.
Syntax für pigz:
tar -cv –use-compress-program=pigz -f meinarchiv.tar /srv/www/img
Was ich noch nicht probiert habe, ist tar mit einer Erweiterung zu versehen, die mehrere Threads zum Schreiben verwenden kann.
Das gibts hier: http://www.maier-komor.de/mtwrite.html
Syntax für Nutzung mit mtwrite:
mttar xf mytarfile.tar
Ich habe mich dann aber erstmal für die Nutzung von rsync entschieden. Vorteile: Ich muss den laufenden Betrieb (Bildupload) nicht stoppen; Abgebrochene Aktionen können wieder aufgenommen werden; Ich habe nur eine Aktion auszuführen, denn die Daten werden direkt via ssh übertragen.
Leider dauert dieser Vorgang wegen der vielen kleinen Dateien auch ziemlich lange. Nach 24 Stunden waren knapp 70GB übertragen.
Nun gibt es noch einige Dinge die ich demnächst ausprobieren möchte. Und damit ich Sie nicht vergesse gibt es diesen Post :)
Zum Beispiel lässt sich der CPU - Kern den rsync verwendet auf den Maximalwert hochtakten.
Das kann man so machen:
for i in 0 ; doecho performance > /sys/devices/system/cpu/cpu$i/cpufreq/scaling_governordone
Mehr dazu auf http://lwn.net/Articles/400489/
Noch etwas mehr verspreche ich mir jedoch von mehreren parallel laufenden rsync- Prozessen.
Mit Hilfe eines Scripts werden die Dateien auf die Prozesse verteilt.
Das Script gibts dort: https://wiki.ncsa.illinois.edu/display/~wglick/Parallel+Rsync
Falls der Link irgendwann mal down sein sollte, hier zum Kopieren:
/bin/bash# SETUP OPTIONSexport SRCDIR="/folder/path"export DESTDIR="/folder2/path"export THREADS="8"# RSYNC TOP LEVEL FILES AND DIRECTORY STRUCTURErsync -lptgoDzd $SRCDIR/ /$DESTDIR/# FIND ALL FILES AND PASS THEM TO MULTIPLE RSYNC PROCESSEScd $SRCDIR; find . -type f | xargs -n1 -P$THREADS -I% rsync -az % /$DESTDIR/%# IF YOU WANT TO LIMIT THE IO PRIORITY,# PREPEND THE FOLLOWING TO THE rsync & cd/find COMMANDS ABOVE:# ionice -c2
Nachteil hierbei: Bei diesem Script werden alle Dateien des Hauptverzeichnisses mit nur einem Prozess übertragen. In den Kommentaren gab es eine alternative Lösung:
#!/bin/bash# SETUP OPTIONSexport SRCDIR="/Storage/data1"export DESTDIR="/Storage/data2"export THREADS="32"# FIND ALL FILES AND PASS THEM TO MULTIPLE RSYNC PROCESSEScd $SRCDIRif [[ $? -eq 0 ]]; thenfind . -type d | xargs -I% mkdir -p /$DESTDIR/%find . -type f | xargs -n1 -P$THREADS -I% rsync -a % /$DESTDIR/%fi
Für beide Fälle gilt: Soll per ssh übertragen werden - also von Server zu Server - müssen die rsync Befehle abgeändert werden:
rsync -lptgoDzd -e 'ssh -c arcfour' $SRCDIR/ remotehost:/$DESTDIR/cd $SRCDIR; find . -type f | xargs -n1 -P$THREADS -I% rsync -az -e 'ssh -c arcfour' % remotehost:/$DESTDIR/%
Und noch ein wichtiger Parameter: Soll das Verzeichnis lediglich geupdated werden und nicht alle Dateien überschrieben werden, unbedingt die Option "-u"verwenden.
Quellen:
http://www.maier-komor.de/mtwrite.html
http://lwn.net/Articles/400489/
https://wiki.ncsa.illinois.edu/display/~wglick/Parallel+Rsync
http://wiki.ubuntuusers.de/rsync
Abonnieren
Posts (Atom)