KVM, Qemu: Welche I/O-Scheduler verwenden
Update 20110831: Weitere Informationen zu dem Thema gab es auf dem KVM Forum 2011 in dem PDF Optimizing Your KVM Instances von Mark Wagner. Auch hier zeigt sich, das der Deadline Scheduler aktuell der Optimalste für eine KVM ist.
Update 20100318: Mehr Tuning-Informationen für die KVM gibt es hier: http://www.linux-kvm.org/page/Tuning_KVM .
Update 20090403: Ich denke, das sich das unten stehende, so nicht halten läßt. Die Sache mit dem noop-Scheduler verhält sich teilweise sehr gut, teilweise aber auch ziemlich übel, in dem z.B. der pgflush-Daemon ziemlich viel Systemzeit beansprucht und der I/O-Durchsatz ziemlich in die Knie geht. Das ändert sich schlagartig, sobald man auf den Deadline-Scheduler umschaltet. Auf den getesteten Systemen scheint die Benutzung des Deadline-Schedulers in Host und Guest die beste Kombination zu sein. Man kann das ja selber mal ausprobieren, in dem man den I/O-Scheduler im laufenden Betrieb wechselt z.B.
echo "deadline" > /sys/block/vda/queue/scheduler
Man sollte dann aber schon eine Anwendung oder einen Test fahren, der gut was auf die Platte schreibt und das auch möglichst konstant macht. Oder besser: Man verwendet bonnie++ . Ein eher syntetischer Test für I/O-Durchsatz aber ein guter Ausgangspunkt.
Text vom 20090330: Diese gar nicht so uninteressante Frage kam jetzt schon des Öfteren auf der KVM Mailingliste hoch. Letztendlich ist man sich einig, das das Gastsystem mit elevator=noop gestartet werden sollte. Per Default setzen ja heute die meisten Distributionen den Completely Fair Scheduler-I/O (CFQ) ein. Für den Host selbst ist das vielleicht ok, wenn im Gast elevator=noop als Kernelparameter z.B. im Grub übergibt. Es macht auch nicht wirklich Sinn, wenn sich die I/O-Scheduler im Gast und im Host Gedanken machen müssen, wie denn die Daten am Besten auf die Platte kommen sollen. Wenn ich die Mails der KVM-Entwickler/-User aber richtig interpretiere, dann bevorzugen sie doch eher den deadline Scheduler für den Host. Mit dem habe ich auch sehr gute Erfahrungen gemacht im Serverbereich. Ich finde - aber das ist jetzt meine subjektive Meinung - das der CFQ sich besser für den Desktopbereich eignet als für Serveranwendungen.
Posted at 10:00nachm. März 30, 2009 by cetixx in Tipps | Kommentare [0]
VLC: Segfault in libc
Wenn mal der VLC nicht mehr startet und in /var/log/messages eine Meldung wie diese zu finden ist
vlc[23006]: segfault at afe80fc4 ip b7d0b19c sp afe80fc8 error 6 in libc-2.8.so[b7c9f000+134000]
dann sollte man mal VLC wie folgt aufrufen von der Kommandozeile aus:
vlc --reset-config
Posted at 11:00nachm. März 19, 2009 by cetixx in Tipps | Kommentare [0]
Kabel BW und Linksys WRT160N Wireless Router
Der vom Kabel BW mitgelieferte WLAN-Router D-Link DI-524 ist ja jetzt nicht so unbedingt der Hit, wenn man eine 32 MBit-Leitung hat. Mehr wie 500-600 KB/sec. war da nicht zu holen, obwohl man nur 3 Meter vom Router und freier Sicht mit dem Laptop weg ist.
Musste was Schnelleres her. Der Linksys WRT160N arbeitet perfekt mit Kabel BW. Ich habe ihn unter Linux eingerichtet. Die Windows-Software habe ich gar nicht ausprobiert. Den Laptop erstmal per Ethernet mit dem Router verbunden. Die Adresse des Routers ist 192.168.1.1. DHCP ist aktiviert, so das man auch gleich eine IP vom Router bekommt. Den dann erstmal einrichten. Dann im ausgeschalteten Zustand an das schwarze Motorola Kabelmodem anstöpseln. Dazu verbindet man einfach per Ethernet-Kabel den Ausgang mit der Bezeichnung "Internet" vom Router mit dem Modem. Dann das Modem vom Stromnetz trennen, 5 Sek. warten, das Modem erstmal hochkommen lassen und dann den Router einschalten. Das ist nötig, da sonst das Modem sich weigert, mit dem Router zu sprechen, da sich die MAC-Adresse geändert hat. Das sollte dann schon gewesen sein.
Und jetzt sieht's mit der Speed schon besser aus. Gleiche Entfernung wie vorher und 2.0-2.4 MByte/sec. und ohne Draft-N (kann mein Laptop nicht :-( ). Das macht aber schon mehr Spaß ;-)
Posted at 01:27vorm. März 19, 2009 by cetixx in Tipps | Kommentare [0]
Linux - Dateien aufteilen mit split
Will man eine Datei in mehrere kleinere Teile aufteilen, um sie z.B. irgendwo hochladen zu können und dort nur Dateien z.B. mit max. 200MB errlaubt sind, dann kann man split verwenden:
split -a 3 -d -b 199M file_to_split.bin splitted.bin.
Wenn die Ausgangsdatei file_to_split.bin also z.B. 600 MByte groß war, dann erhält man jetzt folgende Dateien mit jeweils 199 MByte Größe:
splitted.bin.000
splitted.bin.001
splitted.bin.002
Die Option -a 3 gibt an, das man einen dreistelligen Suffix anhängen möchte. -d gibt an, das dieser Suffix nummerisch sein soll und -b 199M würde in diesem Beispiel die aufgeteilten Dateien max. 199 MByte gross werden lassen. Dann gibt man noch die Datei an die man aufteilen möchte und wie die aufgeteilten Dateien heissen sollen - also den Prefix soz.
Posted at 12:35nachm. März 17, 2009 by cetixx in Tipps | Kommentare [0]
xorg.conf - Umstieg von 1.3 auf 1.5
Ein Gentoo-Entwickler hat hier ein Python-Skript abgelegt, mit dem man seine xorg.conf in eine HAL FDI Policy Datei umwandeln kann. Probleme gibt es hierbei hauptsächlich bezügl. Tastatur und Maus. Nachdem der X-Server jetzt HAL/EVDEV verwendet, um Tastatur und Maus automatisch zu erkennen, hatte ich erstmal das Problem, das das Tastaturlayout gar nicht mehr stimmte. Auch mit dem KDE Keyboard Manager war da nix zu machen. Erst als ich eine Policy in /etc/hal/fdi/policy/10-x11-input.fdi angelegt hatte und in der /etc/X11/xorg.conf alle InputSection's die was mit Tastatur, Maus oder Touchpad zu tun hatten, entfernt habe, lief die Sache wieder rund. Die 10-x11-input.fdi für meinen Dell D630 Laptop sieht z.B. so aus:
<?xml version="1.0" encoding="utf-8"?>
<deviceinfo version="0.2">
<match key="info.capabilities" contains="input.keys">
<merge key="input.xkb.rules" type="string">xorg</merge>
<!-- Option "XkbModel" "pc105" -->
<merge key="input.xkb.model" type="string">evdev</merge>
<merge key="input.xkb.layout" type="string">de</merge>
<merge key="input.xkb.options" type="strlist">grp:alt_shift_toggle</merge>
<append key="input.xkb.options" type="strlist">grp_led:scroll</append>
<merge key="input.xkb.variant" type="string">,nodeadkeys,</merge>
</match>
</deviceinfo>
Posted at 11:00nachm. März 12, 2009 by cetixx in Tipps | Kommentare [0]
KVM/Qemu: Wie konvertiert man eine VMware VMDK Datei zu einem KVM Image
Die Lösung ist relativ einfach. Entweder verwendet man qemu-img oder kvm-img (je nachdem welches Tool der Distribution beiliegt):
qemu-img convert -f vmdk -O qcow2 vmware-image.vmdk kvm-image.qcow2
Update 20090511: Das funktioniert aber nur solange man nur ein vmdk-File hat. Wenn das VMWare-Image auf mehrere Dateien aufgesplittet ist wie s001.vmdk, s002.vmdk, usw., dann muss man anders vorgehen. Man konvertiert alle diese Dateien ins RAW-Format und kopiert diese dann zusammen in ein File:
for I in *[0-9].vmdk; do kvm-img convert -f vmdk "$I" -O raw "tempdir/$I"; done
cat *.vmdk >> final_image.raw
Das final_image.raw kann man dann mit der KVM starten.
Posted at 08:44vorm. März 11, 2009 by cetixx in Tipps | Kommentare [0]
PostgreSQL - Warm-Standby Datenbank Recovery
Nachdem ich ja kürzlich beschrieben habe, wie man eine Warm-Standby Datenbank mit PostgreSQL einrichtet, hier nun der Teil wie man die Standby Datenbank in Betrieb nimmt, wenn die primäre Datenbank ausgefallen ist.
Gehen wir mal davon aus, das der Rechner mit der primären Datenbank ausgefallen ist und die Standby Datenbank soll übernehmen. Die Slave-DB (Standby) hängt der Master-DB 60 Sek. hinterher. Es fallen also auf jeden Fall alle Transaktionen unterm Tisch, die in den letzten 60 Sek. gelaufen und nicht abgeschlossen wurden!
Die Slave-DB befindet sich ja im Dauerrecoverymodus und spielt laufend die Transaktionslogs ein, die von der Master-DB rübergeschoben werden. Um die DB aus dem Recoverymodus zu bringen, wurde in /data/pgsql/data/$DBNAME/recovery.conf ein Trigger festgelegt im recovery_command und der sieht so aus: -t /tmp/pgsql.fin.$DBNAME ($DBNAME wie immer im vorhergehenden Artikel schon beschrieben durch den Instanznamen ersetzen).
D.h. wenn wir jetzt als User postgres(!) per touch /tmp/pgsql.fin.$DBNAME diesen Trigger anlegen, beendet das pg_standby Programm den Recovery-Modus und fährt die DB hoch. Das kann eine Weile dauern, bis die Transaktionslogs nachgefahren wurden. Am Besten beobachtet man dabei das Postgres-Logfile. Die Ausgabe sieht dann in etwa so aus:
LOG: could not open file "pg_xlog/000000010000003F000000A3"
(log file 63, segment 163): No such file or directory
LOG: redo done at 3F/A2007F80
LOG: last completed transaction was at log time 2009-03-03 14:23:30.134095+01
LOG: restored log file "000000010000003F000000A2" from archive
LOG: selected new timeline ID: 2
LOG: archive recovery complete
LOG: checkpoint starting: shutdown immediate
LOG: checkpoint complete: wrote 10 buffers (0.0%); 0 transaction log
file(s) added, 0 removed, 0 recycled; write=0.015 s, sync=0.001s, total=0.092 s
DEBUG: transaction ID wrap limit is 2147484026, limited by database "template1"
LOG: database system is ready to accept connections
LOG: autovacuum launcher started
Die Meldung could not open file ... ist ok. Die Slave-DB hätte jetzt eigentlich das nächste Transaktionslog erwartet. Aber da die Master-DB das noch nicht geliefert hat, ist auch keines da und die DB macht einen Rollback auf das letzte Log 000000010000003F000000A2. Das Recovery selbst kann auch nochmal etwas dauern (ca. 1-2 Min.). Wenn database system is ready to accept connections im Log erscheint, ist die DB oben - aber noch nicht erreichbar über eine IP-Adresse.
Da in der Slave-DB in der postgresql.conf die listen_addresses vermutlich nur auf localhost stehen, kann man die DB auch nur vom DB-Rechner selbst aus erreichen. Man muss also nun erstmal ein Interface hochziehen, das die gleiche IP hat wie die Master-DB hatte (aber auch nur wenn der Master-Rechner wirklich nicht mehr am Netz hängt) und dann den Eintrag in der postgresql.conf entsprechend abändern. Dann die DB durchstarten und das war's dann eigentlich.
Sollte die DB auf dem Rechner bleiben, muss natürlich das Backup-Skript nachgezogen werden und was man sonst noch so Adimistratives braucht.
Nicht unerwähnt bleiben soll, das man diese Standby-Sache hier natürlich auch automatisieren kann und mittels Heartbeat dafür sorgen kann, das der Failover automatisch stattfindet, wenn die Master-DB ausfallen sollte. Aber das ist ein anderes Kapitel ;-)
Posted at 08:51vorm. März 10, 2009 by cetixx in Tipps | Kommentare [0]
Gentoo: KDE 4.2 beendet sich einfach nach ein paar Klicks
Schon toll, was so passiert, wenn man historische Sachen mit sich rumschleppt. Nachdem KDE 4.2 eine ganze Weile ohne Probleme lief, hatte ich plötzlich das Problem, das sich KDE einfach mal so beendete, nachdem ich z.B. auf File -> New Tab in Konsole geklickt hatte oder im Konquerer ein paar Buchstaben der URL eingegeben habe. Da kam dann irgendwas von wegen xprop und so (weiß die genaue Meldung nicht mehr).
Des Rätsels Lösung: /etc/X11/xorg.conf anpassen und folgende Option rausschmeissen:
Option "Backingstore" "true"
Diese Option war bei meiner Nvidia 8600 GTS gar nix gut. Drum raus damit. Dann tut's.
Posted at 03:15nachm. März 06, 2009 by cetixx in Tipps | Kommentare [0]
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]