PostgreSQL - Warm-Standby Datenbank mit pg_standby Mini HowTo
Eine Möglichkeit eine relativ aktuelle Kopie einer Postgres-DB auf einen anderem Rechner vorzuhalten, ist die Warm-Standby-DB. Während der Master laufend seine Transaktionslogs archiviert, spielt der Slave die Transaktionslogs ein, sobald sie vorhanden sind. Dafür gibt es das kleine C-Programm pg_standby im contrib-Verzeichnis, wenn man die Postgres-Sourcen installiert hat. Ich empfehle grundsätzlich Postgres selber zu kompilieren. Die Pakete der Distributionen sind meist uralt und es hat sich zwischen 8.1 und 8.3 soviel getan, das man fast grob fahrlässig handelt, wenn man noch 8.1 einsetzt ;-)
Grundvoraussetzung bzw. Empfehlung (die man ernst nehmen sollte) ist, das Master und Slave mit der gleichen Postgres-Version arbeiten und am Besten mit Version 8.3 oder höher. Wenn man die Binaries und Libs vom Master kopiert und für den Slave verwendet, hat man da schon mal eine Sorge weniger (ausser man nimmt eh die Pakete der Distribution). Auch die Verzeichnisstruktur sollte auf beiden Rechnern gleich sein, da z.B. ein CREATE TABLESPACE auf dem Slave die gleichen Pfade vorfinden muss. Bei einem Update der Minor-Relase (also z.B. von 8.3.5 auf 8.3.6) sollte man den Slave zuerst updaten. Die neue Version ist sicherlich besser in der Lage, Logs einer älteren Version zu lesen als umgekehrt.
Zunächst bereitet man am besten Master und Slave mal vor - also Verzeichnisstruktur, Binaries usw. das man beide unabhängig voneinander starten könnte.
Die von mir in dem folgenden Beispiel verwendete Verzeichnisstruktur, mag vielleicht etwas eigenwillig erscheinen und findet sich auch auf keiner Distribution so, aber sie hat den großen Vorteil, das ich beliebig viele unterschiedliche Postgres-Instanzen in unterschiedlichen Versionen parallel auf einem Rechner betreiben kann. Damit sich das Ganze nicht ins Gehege kommt, verwende ich immer einen beliebigen Namesraum. Jede Postgres-Instanz heißt also z.B. so, wie eine Figur aus der Muppetshow oder ein Darsteller aus Star Trek (im Folgenden ist das die Variable $DBNAME)...
In der Master-DB kann man schon mal Folgendes eintragen ($DBNAME ist in den folgenden Abschnitten natürlich durch den jeweiligen Instanz-Namen zu ersetzen!):
# - Archiving -
archive_mode = on # allows archiving to be done
# (change requires restart)
archive_command = '/data/pgsql/bin/$DBNAME/pg_archive_xlog %p %f' # command to use to archive a logfile segment
archive_timeout = 60 # force a logfile segment switch after this
# time; 0 is off
Mit archive_mode=on schalten wir den Archivierungsmodus ein, d.h. Postgres hebt die Transaktionslogs erstmal auf. Nur wenn archive_command erfolgreich war und das Log an die finale Destination kopiert werden konnte, wird das Transaktionslog gelöscht. Es können also mal eine ganze Reihe Transaktionslogs auflaufen, wenn die Netzverbindung z.B. gestört ist und der Zielserver nicht erreicht werden kann. archive_timeout gibt an, wann spätestens ein Logswitch durchgeführt werden soll. Per Default ist ein Logfile 16 MB groß und bei einer Datenbank, in die nicht viel geschrieben wird, kann das schon mal eine ganze Weile dauern, bis die 16 MB voll sind. Man muss hier selbst entscheiden, wie weit man das Zeitfenster öffnen will. 60 Sek. sind ok, wenn man eine schnelle Leitung hat und wenn die Daten auf dem Standby-System einigermaßen aktuell sein sollen. Weniger als 60 Sek. könnten eventl. problematisch werden. Aber Obacht: Die Transaktionslogs sind immer 16 MB groß! Das häuft sich innerhalb von wenigen Stunden ziemlich an, wenn die Dinger nicht wegkommen! Man sollte das deshalb überwachen und per Skript guggen, ob sich die Logs nicht anhäufen und man eventl. eingreifen muss.
Die Master-DB jetzt aber erstmal noch nicht durchstarten.
Das in der postgresql.conf verwendete pg_archive_xlog-Skript sieht so aus:
#!/bin/bash
#
# This script ships the master transaction logs (WAL)
# to the standby database
#
PGINSTANCE=$DBNAME
# Redirect output
exec 1>/data/pgsql/logs/$PGINSTANCE/pg_archive_xlog.log 2>&1
# Some vars
RSYNC_RSH="/usr/bin/ssh -i /home/postgres/.ssh/id_dsa"
XLOG_FROM=$1 # This is the full path to xlog file incl. file name
XLOG_FILENAME=$2 # This is only the file name of the xlog
DEST_XLOG_DIR="/data/pgsql/dumps/$PGINSTANCE/pg_xlog_master"
DEST_USER="postgres"
DEST_HOST="standby.$PGINSTANCE.tauceti.net
# Does source xlog file exist?
if [ ! -f "$XLOG_FROM" ]
then
echo "No such file/path: $XLOG_FROM"
exit 1
fi
# Do we have a dest file name?
if [ -z "$XLOG_FILENAME" ]
then
echo "No destination file name! Please provide one!"
exit 1
fi
# Tranfer file
/usr/bin/rsync -av --rsh=ssh $XLOG_FROM $DEST_USER@$DEST_HOST:"$DEST_XLOG_DIR/$XLOG_FILENAME"
if [ $? -ne 0 ]
then
echo "rsync not successfull!"
exit 1
fi
# Always return exit status 0 if log transfer finished successfully
exit 0
Das Skript an sich ist nicht sonderlich schwierig. Sobald ein Transkationslog voll ist oder der archive_timeout zuschlägt, ruft Postgres dieses Skript auf und übergibt den vollen Pfad inkl. Dateinamen %p und nur den Dateinamen %f an das Skript. Dieses kopiert dann das Transaktionslog auf den Destination-Server. Das Skript verwendet rsync über ssh, um das Log auf den Zielhost zu kopieren. Dazu habe ich mit ssh-keygen -t dsa ein Schlüsselpaar ohne Passwort für den User postgres erstellt (unter dem die Postgres-Instanz i.d.R. läuft). Den Public-Key kopiert man in die authorized_keys vom User postgres (oder wie auch immer der User für die Postgres heißen mag) auf dem Slave-Rechner. Dann loggt man sich einmal als User postgres vom Master aus auf den Slave ein mit dem Key also z.B. /usr/bin/ssh -i /home/postgres/.ssh/id_dsa postgres@standby.$DBNAME.tauceti.net. Das ist nötig, damit man den Host-Key bestätigen kann. Das Ganze kann man auch über NFS machen. Aber NFS ist oft nicht so zuverlässig, wie man sich das wünschen würde. Muss jeder selber entscheiden...
Dann machen wir in der /etc/hosts vom Master einen Eintrag für den Slave. Man kann das natürlich auch per DNS machen, aber mit der hosts geht man auf Nummer sicher, wenn der DNS mal weg sein sollte (XXX natürlich durch die IP des Slave-Rechners ersetzen und tauceti.net natürlich auch durch die eigene Domain ersetzen):
# Database standby
XXX.XXX.XXX.XXX standby.$DBNAME.tauceti.net
Auf dem Slave legen wir jetzt ein Verzeichnis an, in dem das pg_archive_xlog-Skript die Transaktionslogs kopieren soll:
mkdir /data/pgsql/dumps/$DBNAME/pg_xlog_master
chown postgres.postgres /data/pgsql/dumps/$DBNAME/pg_xlog_master
chmod 700 /data/pgsql/dumps/$DBNAME/pg_xlog_master
Sollte sich die Master DB schon im Archive-Modus befinden (also die DB produziert Transaktionslogs), ist's ok ;-) Ansonsten sollte man die Master DB jetzt durchstarten, damit der Archive-Modus (archive_mode = on) aktiv wird (Gut... Durchstarten sollte man natürlich nur, wenn die Instanz nicht gerade benutzt wird und der Cheffe anschließend kommt, weil seine Reports hinüber sind, die gerade 8 Std. gelaufen sind ;-) ).
Nun loggt man sich in die Master-DB ein und führt einen manuellen Logswitch aus. Damit kann man testen, ob die Transaktionslogs dann auf dem Slave-Rechner landen unter /data/pgsql/dumps/$DBNAME/pg_xlog_master
psql -d template1
select pg_switch_xlog();
Sollte das nicht tun, muss man sich wohl oder übel auf Fehlersuche begeben... Als nächstes machen wir uns eine Kopie der Master-DB auf den Slave-Rechner. Dazu loggt man sich wieder auf der Master-DB ein und versetzt die Datenbank in den Backupmodus (Für label kann man irgendwas angeben. Das ist nur ein Marker.):
psql -d template1
SELECT pg_start_backup('label');
Dann kopiert man am Besten auf der Shell mit rsync alle Postgres-Daten auf den Slave-Rechner ($DBNAME und $ZIELRECHNER natürlich entsprechend ersetzen). Der folgende Befehl geht davon aus, das das Datenverzeichnis auf dem Slave noch leer ist (also keine pg_hba.conf, postgresql.conf, usw. vorhanden ist):
cd /data/pgsql/data
rsync -av --rsh=ssh $DBNAME root@$ZIELRECHNER:/data/pgsql/data/
Dann können wir auf der Master-DB den Backupmodus wieder beenden, wenn alle Daten kopiert sind:
SELECT pg_stop_backup();
Nun wechseln wir auf den Slave-Server. Dort haben wir ja unter /data/pgsql/data/$DBNAME jetzt auch die Transaktionslogs der Master-DB liegen (die haben wir oben beim Backup mitkopiert). Die müssen wir erstmal löschen:
cd /data/pgsql/data/$DBNAME/pg_xlog
find . -type f -exec rm {} \;
Mit dem rsync oben haben wir auch die postgresql.conf der Master-DB kopiert. Die sollte man jetzt etwas anpassen. Z.B. wird wahrscheinlich die IP (listen_addresses) nicht stimmen auf dem Slave und den Archive-Modus sollte man auch ausschalten. Also editieren wir die Datei und ändern Folgendes z.B. entsprechend ab:
listen_addresses = 'localhost'
archive_mode = off
Auch wenn Master- und Slave-Rechner eigentlich ungefähr gleich ausgestattet sein sollten, sollte man eventl. noch die Speicherparameter wie shared_buffers oder effective_cache_size runtersetzen, wenn der Slave vielleicht doch nicht soviel Speicher (RAM) hat wie der Master.
Als nächstes bereiten wir eine Datei namens recovery.conf auf dem Slave vor. Wenn diese Datei im Postgres-Datenverzeichnis liegt und Postgres findet diese Datei beim Starten vor, dann wechselt die DB in den Recoverymodus. Dort drin ist dann beim restore_command das oben erwähnte Programm pg_standby hinterlegt. Dieses liesst dann laufend die Transaktionslogs ein, die die Master-Instanz auf den Slave-Rechner unter /data/pgsql/dumps/$DBNAME/pg_xlog_master ablegt. Eine Vorlage liegt dem Postgres-Source bei z.B.:
cp /server/pgsql/8.3.6/share/recovery.conf.sample /data/pgsql/data/$DBNAME/recovery.conf
chown postgres.postgres /data/pgsql/data/$DBNAME/recovery.conf
Die recovery.conf editieren wir dann wie folgt und ändern nur restore_command:
restore_command = '/server/pgsql/8.3.6/bin/pg_standby -t /tmp/pgsql.fin.$DBNAME /data/pgsql/dumps/$DBNAME/pg_xlog_master %f %p %r 2>>/data/pgsql/logs/$DBNAME/standby.log'
-t wenn diese Datei existiert, wird der Recoveryprozess unterbrochen und die DB fährt hoch.
/data/pgsql/dumps/$DBNAME/pg_xlog_master hier sind die Transaktionslogs der Master-DB zu finden.
%f wird von Postgres ersetzt durch den Filenamen des Transaktionslogs, das es benötigt.
%p wird von Postgres ersetzt durch den Pfadnamen, wo die Transaktionslogs hinkopiert werden sollen.
%r wird ersetzt durch den Namen des Files, das den letzten Restartpunkt enthält. Das führt auch dazu, das ältere Transaktionslogs, die nicht mehr gebraucht werden, auch wieder gelöscht werden können, da mit dieser Information pg_standby ja weiß, welche Transaktionslogs nötig sind, um die DB sauber hochfahren zu können. Ansonsten würden die Logs dort bleiben, wo sie sind und man muss sie von Hand wegkopieren.
2>>/data/pgsql/logs/$DBNAME/standby.log hier leiten wir alle Fehlermeldungen in ein Logfile um.
Dann können wir die Standby-DB starten. Wenn man sich nun auf der Master-DB einloggt und wieder einen manuellen Logswitch ausführt, dann müsste man im Logfile der Slave-DB sehen, das dieses Transaktionslog eingespielt also recovered wird. Im Verzeichnis /data/pgsql/dumps/$DBNAME/pg_xlog_master auf dem Slave-Rechner müssten dann nach einer Weile die Logfiles verschwinden (hängt natürlich von verschiedenen Faktoren ab, wenn die Dinger da verschwinden und kann etwas dauern).
Zu beachten ist zum Schluss noch Folgendes: Wenn man in der Master-DB Änderungen in der pg_hba.conf oder postgresql.conf macht, dann muss man diese Änderungen natürlich auch auf der Slave-DB in den entsprechenden Dateien machen!
Die Wiederherstellungsprozedur dann demnächst in diesem Blog ;-)
Posted at 01:00vorm. März 05, 2009 by cetixx in Tipps | Kommentare [0]
KVM: Welchen cpu Parameter verwenden
Die KVM (Kernel Virtual Machine) bietet ja div. Parameter an, was die CPU anbelangt:
scotty ~ $ kvm -cpu ?
x86 qemu64
x86 core2duo
x86 qemu32
x86 coreduo
x86 486
x86 pentium
x86 pentium2
x86 pentium3
x86 athlon
x86 n270
Eine interessante Frage tauchte dazu kürzlich in der KVM Mailing Liste auf. Welchen soll man denn nun verwenden? Insbesondere wenn man Gentoo als Gastsystem am Laufen hat. Da macht es ja doch Sinn, das der Compiler alle Möglichkeiten nutzt, die der Host-Prozesser zur Verfügung stellt (cat /proc/cpuinfo).
Das Ergebnis war schließlich, das man eigentlich nichts angeben muss. -cpu modifiziert nur die CPUID-Flags. Wenn aber die CPU SSE3 z.B. unterstützt, dann profitiert auch der Gast davon.
Posted at 04:52nachm. Feb. 27, 2009 by cetixx in Tipps | Kommentare [0]
K3B und KDE 4.2
Nach dem Upgrade von KDE 3.5 auf 4.2 unter Gentoo tut leider K3B nicht mehr. Das benötigt leider unbedingt die alten kdelibs. Es gibt wohl im kde-testing Overlay (Stichwort Layman) eine Version, die unter KDE 4 läuft, aber das wollte ich mir jetzt nicht antun.
Deshalb habe ich mir jetzt Brasero installiert. Das ist zwar eine Gnome-Applikation, läuft aber auch unter KDE einwandfrei und fällt eigentlich auch nicht auf, das es normalerweise unter Gnome läuft.
Posted at 01:00vorm. Feb. 20, 2009 by cetixx in Tipps | Kommentare [0]
Linux: IOMMU: Setting identity map for device
Falls euch beim Booten vom Linux-Kernel mit einem Intel Quad Core eine Meldung wie diese hier
IOMMU: Setting identity map for device 0000:00:1a.1 [xdefd6000 - 0xdefd7000]
um die Ohren fliegt, sollte man in der /boot/grub/grub.conf (oder menu.lst) folgenden Parameter in der kernel-Zeile setzen:
intel_iommu=off
Das kann man auch temporär tun, wenn Grub das Bootmenü anzeigt, den entsprechenden Eintrag mit e auswählt und dann einfach hinter der Zeile mit kernel ... anhängt
Posted at 02:43nachm. Feb. 10, 2009 by cetixx in Tipps | Kommentare [0]
KDE 4.2
Nach dem nun am 27.1.2009 KDE 4.2 released wurde, war es kurz darauf auch schon im Gentoo Portage. Respekt an die KDE- und Gentoo-Entwickler!
KDE 4.2 ist schon ein tolles Release. Habe jetzt auch meinen eigentlichen Desktoprechner von KDE 3.5 auf 4.2 upgedated. Da Portage 2.2 noch hardmasked ist und nur diese Version Slots unterstützt, habe ich das kde-meta-Paket installiert.
Grundsätzlich ist die KDE-Doku auf der Gentoo-Seite ganz gut. Zusätzlich zu den KDE-4.2-Pakete die in die /etc/portage/package.keywords eingetragen werden müssen, damit man 4.2 überhaupt installiert werden kann (die Liste kann man hier downloaden), musste ich noch
dev-util/cmake
kde-base/qimageblitz
dev-libs/soprano
app-misc/strigi
kde-base/automoc
app-office/akonadi-server
dev-libs/libical
x11-apps/xinit
sci-mathematics/gmm
dev-libs/libzip
unmasken. Weiterhin hatte ich das Problem, das das phonon-xine-Paket ständig verhindert hat, das phonon-4.3.0 installiert werden konnte. Schließlich habe ich kde-base/kdebase (V 3.5), krusader, krename, smplayer und vlc deinstalliert und dann lief auch die Installation von kde-base/kde-meta:4.2 durch. Die genannten Pakete hatten alle Abhängigkeiten zu KDE 3.5 Libs, die wiederum die Installation von 4.2 verhinderten. Die deinstallierten Pakete kann man nach der Installation einfach wieder installiert.
Der Befehl emerge -ptuDN world hilft ganz gut, um zu sehen, welche Pakete von welchen Paketen abhängen und kann so leichter Blocker auflösen.
Nachdem KDE 4 jetzt auch sehr schöne und vor allem auch schnelle Effekte schon mit bringt u.a. auch den berühmten Cube, habe ich Compiz-Fusion auch gleich deinstalliert. Ebenso habe ich auch alles Mögliche deinstalliert, was noch nach KDE 3.5 aussah. Allerdings spielen die o.g. Paket und auch z.B. das CD Brennprogramm k3b wieder einige KDE 3.5 Pakete ein. Das ist aber kein Problem.
Nach der ganzen Deinstallstionsorgie funktionierten dann nach einem Restart von KDE die Effekte nicht mehr. Hier hat dann eine Neuinstallation der Nvidia-Treiber geholfen. Dieser Installer meckerte dann auch gleich, das einige Pakete seit der letzten Installation geändert wurden. Nach der Neuinstallation der Treiber liefen dann auch die Effekte wieder.
Fall es jemand hilft: Konkret deinstalliert habe ich (Pakete werden dann teilweise später wieder reingezogen, wenn sich KDE 4.2 installiert) folgende Pakete:
libkexiv2 libkipi libkdcraw kde-base/kde-3.5.9 kde-base/arts-3.5.9 kde-base/kdewebdev-3.5.9 kde-base/kdetoys-3.5.9 de-base/kdepim-3.5.9-r1 kde-base/kdemultimedia-3.5.9 kde-base/kdeedu-3.5.9 kde-base/kdeaddons-3.5.9 kde-base/kdeadmin-3.5.9 kde-base/kdeartwork-3.5.9 kde-base/kdegames-3.5.9 kde-base/kdegraphics-3.5.9 kde-base/kdelibs-3.5.9-r4 kde-base/kdenetwork-3.5.9 kde-base/kdepim-3.5.9-r1 kde-base/kdeutils-3.5.9-r1 kde-base/kdeadmin-3.5.9 kde-base/kdeartwork-3.5.9 kde-base/kdegames-3.5.9 kde-base/kdegraphics-3.5.9 kde-base/kdelibs-3.5.9-r4 kde-base/kdenetwork-3.5.9 kde-base/kdepim-3.5.9-r1 kde-base/kdeutils-3.5.9-r1 x11-wm/compiz-0.6.2-r1 x11-wm/compiz-fusion-0.6.0 x11-plugins/compiz-fusion-plugins-unsupported-0.6.0 dev-python/compizconfig-python-0.6.0.1 11-libs/compiz-bcop-0.6.0 x11-libs/compizconfig-backend-gconf-0.6.0 x11-libs/compizconfig-backend-kconfig-0.6.0 x11-libs/libcompizconfig-0.6.0 x11-plugins/compiz-fusion-plugins-extra-0.6.0 x11-plugins/compiz-fusion-plugins-main-0.6.0 x11-themes/emerald-themes x11-wm/emerald ktorrent x11-themes/domino-0.4-r1 tork krusader krename x11-apps/ccsm-0.6.0 media-libs/libkdcraw
Posted at 07:00vorm. Feb. 06, 2009 by cetixx in Tipps | Kommentare [0]
Oracle 10g Client und Gentoo 2008.0
Falls mal jemand auf die Idee kommt, den Oracle 10g Client zu installieren und Gentoo 2008.0 (x86_64 bzw. amd64) zu verwenden, dem könnte folgende Meldung um die Ohren fliegen nach der Installation und beim Aufruf von oemapp dbastudio:
Exception java.lang.UnsatisfiedLinkError: /tmp/OraInstall2009-02-05_11-28-04AM/jre/1.4.2/lib/i386/libawt.so: libXp.so.6: wrong ELF class: ELFCLASS64 occurred..
java.lang.UnsatisfiedLinkError: /tmp/OraInstall2009-02-05_11-28-04AM/jre/1.4.2/lib/i386/libawt.so: libXp.so.6: wrong ELF class: ELFCLASS64
Bei mir hat dann Folgendes weitergeholfen:
emerge -av glibc binutils app-emulation/emul-linux-x86-baselibs app-emulation/emul-linux-x86-xlibs
Zusätzlich habe ich noch
emerge -av ksk rpm
installiert.
Posted at 02:03nachm. Feb. 05, 2009 by cetixx in Tipps | Kommentare [0]
KVM, Qemu und XFS Filesystem
So sehr ich ja XFS als Filesystem schätze, muss ich doch ziemlich davon abraten, es in einer KVM (Kernel Virtual Maschine) zu verwenden. Normalerweise richte ich das Root-FS (also /) immer als ext3-Filesystem ein und /boot als ext2. /var, /tmp, /usr, /opt, /home, usw. immer als XFS. Das war all die Jahre auch eine gute und einwandfrei funktionierende Kombination. Falls was ist, kann man mit den Standardtools Root-FS und /boot eventl. reparieren. Solange / und /boot noch tun, hat man ja ohnehin alle Tools drauf, um eventl. die XFS-Partitionen zu reparieren. Den Bedarf hatte ich aber noch nie - bis auf 3 mal in den letzten Monaten in Zusammenhang mit einer KVM.
Da XFS ja ziemlich aggressives Write-Caching betreibt, ist die allgemeine Empfehlung XFS hauptsächlich dann zu verwenden, wenn man eine USV vor dem Rechner hat oder einen Contoller, dessen Cache und Festplatte mit einer Batterie gegen plötzlichen Stromausfall gesichert ist.
So betrachtet, gelten beide Bedingungen nicht für die KVM. Ich kann die KVM ja jeder Zeit mit einem kill vom Host aus abschießen. Oder eine Kernel-Panic des Hosts würde auch die KVM killen. Das ist dann, als ob ich den Stecker für die KVM ziehen würde. Obwohl ich damit auf einem physikalischen Rechner noch nie Probleme hatte, scheint das in einer KVM gravierendere Auswirkungen zu haben. Das Ganze gilt insbesondere dann, wenn man das Virtio Block Device (VIRTIO_BLK) verwendet (das ist der Virtio Plattentreiber, der nicht emuliert werden muss, sondern soz. näher am Host-IO-Treiber sitzt und dadurch schneller arbeiten kann - fällt u.a. dadurch auf, das man ein /dev/vda Device hat).
Ich kann aufgrund meiner Erfahrungen aktuell nur empfehlen, ext3 in einer KVM zu verwenden. Die Probleme mit XFS traten dann und wann auf, wenn die KVM (aus welchen Gründen auch immer), unerwarteter Weise beendet wurde. I.d.R. konnte man das Filesystem wieder herstellen, aber mir hat es auch schon Zwei komplett zerlegt. Mit ext3 ist mir das noch auf keinem KVM-System passiert. Komisch... Normalerweise kenne ich das immer umgekehrt ;-)
Ich vermute mal, das einer der Gründe für die Probleme die fehlende Unterstützung in VIRT_BLK für Barriers ist. Das sieht dann mit dmesg z.B. so aus:
Filesystem "vda7": Disabling barriers, trial barrier write failed
XFS mounting filesystem vda7
Wenn ich die Sache mit den Barriers richtig verstanden habe, dann sind die dafür zuständig, das das Filesystem das darunterliegende Device informieren kann, wenn es Daten flushen, d.h. also wegschreiben soll. Wenn das nicht passiert und die Kiste säuft ab, dann kann das ziemliche Folgen für das Filesystem haben. Oft wird empfohlen, bei XFS die Option nobarrier zu setzen, um die Performance zu steigern. Das sollte man sich aber genau überlegen...
Update 20090206:
Zu dem Thema u.a. qcow2 vs. raw Format für KVM Images siehe auch hier:
Poor Write I/O Performance on KVM-79
Use writeback caching by default with qcow2
Re: Use writeback caching by default with qcow2
XFS FAQ
Interessant finde ich auch die Möglichkeit, LVM direkt als Laufwerk für eine KVM zu nutzen, wie in einem der Postings erwähnt wird (-drive file=/dev/vg/volume). War mir noch gar nicht bekannt...
Update 20090329:
Die XFS FAQ empfiehlt bei Qemu/KVM bei der -drive Option cache=none anzugeben, da hier anscheinend nicht mal auf einen fsync Verlass ist. Ich werde trotzdem bei ext3 als Filesystem in einer KVM bleiben.
Posted at 09:41nachm. Feb. 04, 2009 by cetixx in Tipps | Kommentare [0]
PostgreSQL: Query Logging
Um Queries nur von einer Datenbank zu loggen, kann man folgendes Kommando ausführen:
ALTER <databasename> SET log_statement = 'all';
Posted at 03:53nachm. Jan. 23, 2009 by cetixx in Tipps | Kommentare [0]
VMWare: Uhrzeit hinkt hinterher oder laeuft voraus
Ich bin ja gar kein Fan von VMWare (mir ist die KVM tausend mal lieber...), aber nachdem alle Welt das Teil benutzt, kommt man nicht drum rum :-( Kürzlich hatte ich das Problem, das in einem Gentoo Linux Host ein Red Hat Enterprise 5.2 Gast lief und im Gast ständig die Uhrzeit dem Hostsystem hinterherlief. Da dauerte dann eine Sekunde schon mal zwei oder so ;-)
Nun... Ganz hab ich das Problem noch nicht gelöst aber ansatzweise. Zum einen war die Kernel-Timer-Frequenz unterschiedlich. Gentoo lief mit 250 Hz (wie das für ein Server-System angebracht ist) und RHEL mit 1000 Hz. Was eingestellt ist, sieht man unter Gentoo, wenn man nach /usr/src/linux wechselt (ja, es gibt noch andere Möglichkeiten...) und dort
linux # cat .config | grep CONFIG_HZ
# CONFIG_HZ_100 is not set
# CONFIG_HZ_250 is not set
# CONFIG_HZ_300 is not set
CONFIG_HZ_1000=y
CONFIG_HZ=1000
eingibt. Unter RHEL 5.2 geht man unter /usr/src/kernels/2.6.18-92.el5-x86_64/ rein und mancht das Gleiche. Nachdem das eingestellt war unter Gentoo, Kernel neu kompiliert und durchgestartet. Das war dann schon besser. Aber immer noch lief die Zeit langsam auseinander.
Ich habe dann im zugehörigen .vmx-File noch folgende Option eingetragen:
tools.syncTime = "TRUE"
Das sollen angeblich auch die VMWare Tools machen. Das half aber auch nicht so richtig weiter. Jetzt könnte man natürlich auch ein ntpdate pool.ntp.org jede Minute per Cron laufen lassen, aber das ist auch Schwachsinn.
Also hab ich mir die open-vm-tools installiert. Das sind die VMWare Tools nur als Opensource. Diese Tools müssen im Gast-System installiert werden. Man lädt sich dazu das .tar.gz-File runter. Den configure hab ich mit
./configure --without-x --without-procps --without-dnet --without-icu
aufgerufen. Dann make; make install. Jetzt kann man mit
vmware-guestd --background /tmp/ovm.pid
den VMWare Guest-Daemon starten. Anschließend kann man mit
vmware-toolbox-cmd timesync enable
die Zeitsyncronisierung einschalten und mit
vmware-toolbox-cmd timesync enable
abfragen. Mit
vmware-toolbox-cmd stat hosttime
kann man dann noch die Host-Zeit abfragen. Die Zeit der beiden System läuft jetzt zwar immer noch nicht ganz syncron, aber es ist akzeptabel.
Posted at 12:00vorm. Sep. 17, 2008 by cetixx in Tipps | Kommentare [0]
Freie IP finden mit fping
Man kennt das Problem: Man braucht eine freie IP in einem Class C Netz. Praktisch wäre jetzt mal kurz alle IP-Adressen durchzutesten. Da hilft fping:
fping -g 172.18.72.0/24
Wenige Sekunden später sieht man dann, was noch frei ist. Unter Gentoo einfach mit
emerge fping
installieren. Ich vermute, andere Distributionen haben das Tool auch an Board.
Posted at 12:00vorm. Sep. 11, 2008 by cetixx in Tipps | Kommentare [0]
Enhanced CTorrent - Ein BitTorrent Client unter Linux für die Kommandozeile
Bisher hatte ich immer MLDonkey verwendet, um Torrents downzuloaden.
Zum Downloaden von Linux Distributionen, ISO-Images oder Remixes von
remix.kwed.org/slayradio.org ganz praktisch. Läuft als Daemon im Hintergrund und man kann darauf komfortabel per Weboberfläche zugreifen. Zu dem kennt MLDonkey noch viele weitere Protokolle/Netze u.a. auch das Donkey-Netz. Wenn man aber nur Torrents down- oder uploaden möchte, dann gibt's was Besseres für Freunde der Kommandozeile. Ausserdem erspart man es sich, den MLDonkey-Daemon zu konfigurieren.
Enhanced CTorrent nennt sich das Tool. Funktioniert denkbar einfach. Soweit kein Paket bei der verwendeten Linux-Distribution dabei ist, kompiliert man das einfach selber mit dem üblichen configure, make, make install. Will man jetzt ein Torrent downloaden, braucht man natürlich das Torrent selbst und dann folgenden Befehl:
ctorrent -d datei.torrent
Zusätzlich interessant sind noch die Optionen
-I <nach_aussen_sichtbare_ip>
-e 500
-S localhost:2780 -e 500
Wenn man hinter einem Router mit NAT sitzt, dann kann man mit -I die IP-Adresse angeben, mit denen andere Torrent-Clients sich verbinden können, um eine Peer-Connection aufzubauen. Macht den Download schneller. Funktioniert natürlich nicht bei privaten Torrents.
-e gibt an, wie lange man den runtergeladenen Torrent noch seed'en möchte, also wie lange andere User den Torrent auf dem eigenen Rechner noch erreichen können. Man sollte hier schon noch 2-3 Tage seeden, damit viele andere User möglichst schnell downloaden können und viele Quellen zur Verfügung stehen.
Mit -S gibt man die IP und Port-Nummer des CTCS-Servers an. Dieser CTorrent Control Server stellt eine Weboberfläche zur Verfügung, mit dem man alle Torrents kontrollieren kann. Das macht die Sache komfortabler und übersichtlicher.
Den CTorrent Control Server kann man hier downloaden: CTorrent Control Server Auch hier gilt: Liegt kein Paket vor, einfach downloaden und mit dem o.g. Dreisatz übersetzen und installieren. Und dann einfach starten:
ctcs -d 250 -u 20
In diesem Fall geben wir eine Download-Rate von 250 KByte/s vor und eine Upload-Rate von 20 KByte/s. Per Default hört der ctcs-Daemon auf localhost:2780. Dort hin kann man sich mit dem Webbrowser verbinden und sieht dann alle laufenden Torrents und kann deren Status ändern und noch viele weitere Änderungen komfortabel vornehmen.
Wenn man ctorrent mit der Option -S localhost:2780 startet, dann verschwindet ctorrent in den Hintergrund und meldet den eigenen Status an den ctcs-Daemon.
Möchte man einen eigenen Torrent über einen externen Tracker anbieten, kann man mit folgendem Kommando einen eigenen Torrent erstellen:
ctorrent -t -u "http://externe.tracker.url" -s datei.torrent dateiname_zum_downloaden
Posted at 01:59vorm. Aug. 29, 2008 by cetixx in Tipps | Kommentare [0]
Linux: I/O pro Prozess anzeigen
Oh wie lange habe ich auf dieses Feature gewartet! Wer einen Kernel 2.6.20 oder höher einsetzt, der kann sich mit dem Tool pidstat aus dem sysstat (> V 7.1.5) Paket sich jetzt anzeigen lassen, was welcher Prozess denn da gerade auf der Platte rummacht. Leider hat selbst Redhat Enterprice 5.2 nur einen 2.6.18 Kernel und dieses Kernel Feature nicht zurückportiert, wo doch gerade bei diesen Enterprise Plattformen solche Informationen sehr wichtig sind. Nun ja... So sieht das dann jedenfalls aus (pidstat -d 5 10):
3:06:24 PID kB_rd/s kB_wr/s kB_ccwr/s Command
13:06:29 7224 6.40 0.00 0.00 make
13:06:29 9150 0.00 22.40 22.40 postgres
13:06:29 9207 0.80 0.80 0.00 logd
13:06:29 9410 13.60 0.00 0.00 xgcc
13:06:29 9411 352.80 12.00 0.00 cc1
13:06:29 9412 44.00 0.00 0.00 x86_64-pc-linux
13:06:29 11793 0.00 3.20 0.80 thunderbird-bin
13:06:29 12751 4.00 24.80 0.00 firefox-bin
13:06:29 30591 10771.20 0.00 0.00 rsync
13:06:29 30593 0.00 10752.00 0.00 rsync
13:06:29 32469 3.20 1.60 0.00 emerge
Hier sieht man sehr schön, das rsync ganz gut unterwegs ist. Damit das funktioniert, müssen im Kernel folgende Optionen aktiviert sein:
CONFIG_TASKSTATS=y
CONFIG_TASK_DELAY_ACCT=y
CONFIG_TASK_XACCT=y
CONFIG_TASK_IO_ACCOUNTING=y
Posted at 09:00nachm. Aug. 22, 2008 by cetixx in Tipps | Kommentare [0]
Western Digital Mybook und Linux
Speicherplatz zu Ende, Backup muss auch sein, also USB-Platte her. Die WD MyBook gefiel mir ganz gut. Sehr leise im Übrigen und die 1 TByte Edition bringt auch viel Speicher mit und ist auch unter Linux ausreichend schnell für Backup- oder Archivierungszwecke. Was ich ganz gut finde, wenn man mit der Platte nicht ständig arbeitet ist, das sich die Platte selber runterfährt, wenn sie für einige Zeit nicht in Gebrauch. Solange sie gemountet ist, fährt sie auch wieder hoch, wenn man darauf zugreift. Bei mir dauert das ca. 5-7 Sek.
Man kann das Ausschalten auch per Kommando unter Linux bewerkstelligen:
sdparm --command=stop /dev/sdb
/dev/sdb ist in meinem Fall die MyBook USB-Platte. Das ist ganz praktisch, um Strom zu sparen, wenn man nur kurz darauf zugreifen will oder muss. Mit --comand=start startet man die Platte wieder.
Ich vermute mal, das das vielleicht auch mit anderen USB-Platten funktioniert, die sich als USB Massenspeicher melden und eingebunden werden. Ausprobiert habe ich es aber noch nicht.
Posted at 09:54nachm. Aug. 19, 2008 by cetixx in Tipps | Kommentare [0]
Qemu, KVM, Anaconda - lvm: Cannot allocate memory
Nachdem ich gerade am Testen von Red Hat Enterprise 5 mit Qemu/KVM bin und mir Anaconda beim Initialisieren der Festplattenpartitionen die Meldung
lvm: Cannot allocate memory
um die Ohren gehauen hat, wollte ich die Welt teilhaben lassen an der Lösung ;-) Ich hatte Qemu gestartet mit
/opt/kvm/current/bin/qemu-system-x86_64 -hda rhel52.img -cdrom /opt/cds/rhel-5-server-x86_64-dvd.iso -boot d -m 256
Der Witz ist, 256 MB Speicher reichen nicht! Es müssen mindestens 512 MB sein. Ich hab's dann probiert mit
/opt/kvm/current/bin/qemu-system-x86_64 -hda rhel52.img -cdrom /opt/cds/rhel-5-server-x86_64-dvd.iso -boot d -m 640
und das funktioniert dann.
Posted at 04:59nachm. Aug. 01, 2008 by cetixx in Tipps | Kommentare [0]
configure - Invalid configuration
Wenn ihr beim Kompilieren bzw. beim Ausführen von configure folgende Meldung seht
checking build system type... Invalid configuration
x86_64-unknown-linux-gnu: machine x86_64-unknown not recognized
configure: error: /bin/sh ./config.sub x86_64-unknown-linux-gnu failed
dann tauscht mal die Dateien configure.guess und configure.sub aus. Diese holt man
sich z.B. von Sourcecode eines neueren Apaches. Meistens ist die Software, die man
da kompilieren möchte schon etwas älter, wenn die Meldung kommt.
Posted at 10:01vorm. Mai 20, 2008 by cetixx in Tipps | Kommentare [0]