Links 20090923 - LiVES, Mixxx, PgFincore
It LiVES! Video Editing For FOSS Movie Makers - Ein Artikel über den Linux Videoeditor LiVES der kürzlich in Version 1.0 erschienen ist.
The LiVES Video Editor and VJ Tool Turns 1.0 - Ein weiterer Artikel über LiVES als VJ Tool.
Mixxx - OpenSource DJ Software für Linux.
PgFincore - Ein ganz interessantes PostgreSQL Modul mit dem man feststellen kann, ob eine Tabelle oder Index schon im Betriebssystemcache ist oder nicht.
Erstellt am 10:00PM Sep 23, 2009 in Links | Permalink Kommentare[0]
Links 20090812 - pgstat, Wikibooks, Videokonvertierung, Java Dump Analyzer, Linux IO
pgstat - Ein Tools wie sar oder vmstat aber eben nicht für's Betriebssystem sondern für PostgreSQL.
Wikibooks: Die freie Bibliothek - Wikibooks ist eine Bibliothek mit Lehr-, Sach- und Fachbüchern. Jeder kann und darf diese Bücher frei nutzen und bearbeiten. Unsere Lehrbücher spiegeln bereits gesichertes Wissen wider, das heißt die hier vermittelten Kenntnisse sind in ähnlicher Form in anderen tatsächlich publizierten Werken des jeweiligen Fachs bereits dargestellt.
Transmageddon and Arista pursue simple transcoding - Ein ganz guter Artikel über div. Möglichkeiten und Programme zur Videokonvertierung unter Linux.
Which I/O controller is the fairest of them all? - Manchmal in der Tat eine gute Frage... ;-)
How to Diagnose Java Resource Starvation? - Hier geht's um den IBM Thread & Monitor Dump Analyzer für Java.
Erstellt am 10:00PM Aug 12, 2009 in Links | Permalink Kommentare[0]
Links 20090810 - PostgreSQL Replikation, Linux Games, Youtube
Sommertreffen der Demo-Scene - Ein Artikel bei heise über die Evoke 2009
Creating Convincing Images with Blender Internal Renderer - Part 1 / Part 2 - Ein kleines Blender Tutorial
live.linuX-gamers.net - Spielen unter Linux? Diese Live-DVD (8.5 GB) hat alles dabei.
Wen schon immer mal interessiert hat, wie die Serverfarm hinter Wikipedia aussieht, findet hier entsprechende Diagramme.
Testing PostgreSQL replication solutions: Slony-I - Ein gute Anleitung wie man Slony-I für Postgres installiert.
rubyrep - Wie der Name schon sagt, eine neue Möglichkeit MySQL- und PostgreSQL-Datenbanken zu replizieren. Hier liegt der Fokus auf einer möglichst einfachen Installation und einfacher Betrieb.
Basket Note Pads - Wer einen Notizblock für KDE sucht, der sollte mal BasKet anschauen. Man kann hier alle möglichen Texte, Bilder, usw speichern und das Ganze dann z.B. als HTML-Seite ausgeben.
clive is a command line video extraction utility for Youtube and other video-sharing websites - Wer Videos von Youtube & Co. von der Kommandozeile aus runterziehen will, kann das hiermit mal versuchen.
Erstellt am 10:00PM Aug 10, 2009 in Links | Permalink Kommentare[0]
PostgreSQL-Replikation mit Londiste und SkyTools - Teil 1
Warum SkyTools / Londiste? Ich war auf der Suche nach einer Replikationslösung, die mir einfach die Daten von einer Master-DB auf eine Slave-DB kopiert. Die Slave-DB ist read-only. Man muss grundsätzlich vorwegnehmen, das es unter Postgres leider keinen Replikationsmechanismus gibt, wie ihn die MySQL hat. Dort werden die Transaktionslogs auf dem Slave nachgefahren. D.h. das wirklich alle Statements auch auf dem Slave ausgeführt werden inkl. aller DDL-Statements (also sowas wie CREATE TABLE). Das ist bei (fast) keiner Replikationslösung, die es unter Postgres gibt, der Fall. Ich vermute mal, das das PGCluster macht, welcher auch Multimaster-Replikation unterstützt. Zu dieser Lösung habe ich aber kein Vertrauen, da im Supportforum keiner der Entwickler antwortet. Ausserdem ist der PGCluster oder auch PGCluster-II (wird wohl eh nie erscheinen) immer eine speziell angepasste Version von Postgres und hängt der Entwicklung immer hinterher (und aktuell schon ziemlich...). Ich mag keine so reingeschusterten Sachen. Dann gibt es noch den CyberCluster, der in eine ähnliche Kategorie fällt und auf PGCluster aufbaut, aber auch so seine Probleme hat, wie ich mal auf der Postgres-Mailingliste erfahren habe.
Dann gibt es noch Tools, die soz. Statements replizieren auf zwei oder mehrere Datenbanken und wie ein vorgeschalteter Proxy arbeiten, mit dem sich die Clients verbinden. pgpool-II gehört da dazu. Aber was mach ich, wenn eine Node ausfällt? Die Daten bei dieser Art Replikation müssen zwangsläufig auseinander laufen, wenn eine DB ausfällt. Eine Antwort darauf gibt Gerd Koenig in pgpool-II for beginners (PDF). Das ist an sich schon mal nicht schlecht, aber diese Methode benötigt eigentlich fast schon ein komplettes Recovery der DB, damit die Datenbanken wieder konistent werden.
Dann gibt's noch Bucardo. Da ist zwar der Entwickler sehr aktiv, aber mir gefällt das dahinterliegende Konzept gar nicht, mit rsync irgendwelche Daten durch die Gegend zu kopieren. Prinzipiell handelt es sich hierbei um eine Multi-Master-Replikation.
Weiterhin hätten wir noch den Mammoth Replicator. Der war mal kommerziell und ist jetzt OpenSource. Hier kann man auch Support von Enterprise DB kaufen. Bin ich aber auch nicht so wirklich überzeugt von dem Konzept.
Bleiben grob noch zwei Tools: Slony-I und Londiste.
Slony-I ist schon irgendwie das Schweizer Taschenmesser und Urgestein unter den Replikationslösungen - nur ungleich komplizierter zu bedienen. Und das war für mich dann auch der Grund, es mit Londiste/SkyTools zu versuchen, welches die Skype-Entwickler als OpenSource veröffentlich haben und das teilweise in Python geschrieben ist - was gleich noch viel mehr für die Lösung spricht ;-)
Hier mal eine Übersicht über die wichtigsten Links bezügl. Londiste/SkyTools:
SkyTools Download:
Londiste ist ein Teil der SkyTools. Version 2.1.9 ist gerade aktuell. Diese Version kann man sich auf pgFoundry downloaden. Da ich aber einen Teil der Funktionalität von Version 3 brauche, lade ich mir das Source-Paket (http://pgfoundry.org/pipermail/skytools-users/2009-April/001029.html) runter, welches Marko Kreen in einem Posting der SkyTools-Mailingliste erwähnt hat. Version 3 ist aktuell noch Alpha - wobei ich mir ziemlich sicher bin, das das Skye intern schon länger im Einsatz ist und sicherlich weit weniger Alpha ist, als so manches andere Prgramm ;-) Bei mir läuft das jetzt auf jeden Fall schon mal seit 3 Monaten ganz gut durch.
SkyTools @ PostgreSQL Wiki
http://wiki.postgresql.org/wiki/SkyTools
Londiste Tutorial (Version 2)
http://pgsql.tapoueh.org/site/html/londiste/londiste.html
SkyTools Users Archives Mailingliste
http://pgfoundry.org/pipermail/skytools-users/
Manpage für londiste (Version 2)
http://manpages.ubuntu.com/manpages/jaunty/man1/londiste.1.html
Whats you favourite PostgreSQL Replication Tool:
1. Slony-I
2. pgpool2
3. londiste
http://www.postgresql.org/community/survey.61
PostgreSQL Replication using Slony-I
http://jayant7k.blogspot.com/2008/11/postgresql-replication-using-slony-i.html
Database management tools from Skype: WAL shipping, queueing, replication. The tools are named walmgr, PgQ and Londiste, respectively
http://pgfoundry.org/projects/skytools/
Und in Teil 2 erklär ich dann, wie ich es eingerichtet habe...
Erstellt am 03:22PM Jul 06, 2009 in Tipps | Permalink Kommentare[0]
Links 20090530 - PostgreSQL, Database Unit Tests und VCS, Trainingsvideos
Post Facto: Version Control System (VCS) for PostgreSQL: Nachdem CVS oder Subversion in der Programmierwelt ja schon lange existieren. Post Facto wiederum protokolliert Schemaänderungen in einer Datenbank in Form von SQL-Dateien.
Unit Test Your Database - Und wenn wir schon bei VCS bei Datenbanken sind, warum nicht auch noch Unit Tests für die DB schreiben? Dazu gab es auf der PostgreSQL Conference 09 eine Vortrag. Auf dieser Seite findet man div. Links zum Thema u.a. zu pgTAP und PGUnit. Das PDF-Dokument vom Vortrag gibt es hier.
PostgreSQL on Vimeo - Aktuell über 34 Videos über das Thema Postgres gibt es bei Vimeo anzuschauen. U.a. finden sich hier Vorträge der PgCon-Konferenz wie z.B. PostgreSQL HA mit Linux and DRBD.
PostgreSQL Experts - Hier findet man u.a. das Performance Whack-a-Mole Tutorial (pgCon 2009) PDF (download). Letzteres sollte man unbedingt gelesen haben. Dieses 109 seitige PDF ist wirklich interessant.
PostgreSQL Lightning Talks pgCon 2009 (ca. 2 Std. Video und Slideshow).
Erstellt am 10:00PM Mai 30, 2009 in Links | Permalink Kommentare[0]
Links 20090529 - Firefox, openresolv, postgresqlfs
Lifehacker: Top 10 Must-Have Firefox Extensions, 2009 Edition
openresolv: the DNS management framework - Das ist eine recht praktische Sache, wenn man verschiedene DNS-Server verwendet. Die /etc/resolv.conf ist ja normalerweise recht statisch. So kann es aber eventl. notwendig sein, das man für das VPN, Wireless, Ethernet oder andere Subnetze andere DNS-Server ansprechen möchte. Mit openresolv ist das machbar.
postgresqlfs: FUSE driver to access PostgreSQL databases as a file system - Peter Eisentraut hat ein etwas ungewöhnliches Filesystem entwickelt ;-)
Erstellt am 10:00PM Mai 29, 2009 in Links | Permalink Kommentare[0]
Links 20090429 - pyjamas, python-ldap, python-postgresql, Tahoe, Linux Grafik
pyjamas - Ein Python AJAX-Framework ähnlich GWT. Man erstellt hier seinen AJAX Code in Python, den das Framework dann in JavaScript konvertiert.
GreasySpoon - Inspiriert von der Firefox Extension GreaseMonkey kann man mit dem Teil hier Traffic an einem ICAP Server abfangen und manipulieren per Java/JavaScript. Ein möglicher ICAP Server wäre z.B. der Squid Proxy.
python-ldap - LDAP client API for Python
py-postgresql - Stellt ein PG-API, postgresql.api und DB-API 2.0 Interface zur Verfügung, um unter Python einfach mit einer PostgreSQL-Datenbank arbeiten zu können.
Tahoe, the Least-Authority Filesystem - Ein dezentrales, ausfallsicheres und verschlüsseltes Dateisystem, das ähnlich einem Peer-to-Peer Netz arbeitet.
Linux Graphics Users Forum - Wie der Name schon sagt... ;-)
Erstellt am 10:00PM Apr 29, 2009 in Links | Permalink Kommentare[0]
Links 20090424 - PostgreSQL-Migration, Gentoo Overlays, bindfs, lsyncd, Breakpoint 2009
pg_migrator - Wer sich schon mal auf das Upgrade von PostgreSQL 8.3 auf 8.4 vorbereiten möchte, kann sich dieses Tool mal anschauen. Es soll das berühmt, berüchtigte Dump/Restore-Prozedere bei einem Postgres-Upgrade obsolet machen. Bruce Momjian bereitet gerade das Upgrade von pg_migrator vor.
Ycarus Gentoo ebuild - Eine gute Übersicht, welche zusätzlichen Gentoo Overlays es gibt und welche ebuild's man darin findet, gibt es hier.
bindfs - Ein FUSE filesystem das Verzeichnisse in andere Verzeichnisse reinspiegelt, ähnlich "mount --bind". Es kann aber Verzeichnis- und Dateirechte ändern und gespiegelte nur für bestimmte Prozesse freigeben.
Live Sync with lsyncd und lsyncd Live Syncing (Mirror) Daemon - lsyncd kann Verzeichnisse überwachen und Änderungen sofort mit Hilfe von rsync auf einen anderen Rechner kopieren. Im Gegensatz zu incron arbeitet lsyncd auch rekursiv.
Breakpoint 2009 Results - Über Ostern fand ja mal wieder die bekannte Demoparty statt. Hier findet man alle Demo's, Musik und Grafiken zum Download. Das offizielle Einladungsvideo findet man übrigends auf Youtube.
Erstellt am 09:00PM Apr 24, 2009 in Links | Permalink Kommentare[0]
Links 20090409 - Radio CSS Posfix Courier DRBD MySQL Redundanz Backup Buecher Performancemessung HTTP
KRadio4 - Das Programm für KDE4 unterstützt Internet- und AM/FM-Stationen, die per V4L/V4L2 von einer Radio-Karte kommen. Weiterhin wird LIRC und RDS unterstützt.
cssutils - CSS Cascading Style Sheets parser and library for Python
Virtual Users und Domains mit Postfix, Courier, MySQL und SquirrelMail (Debian Lenny)
Use DRBD to Provide Rock-Solid MySQL Redundancy - Gut... MySQL jetzt "Rock-Solid" zu nennen, ist vielleicht etwas übertrieben ;-) Aber DRBD ist wirklich eine tolle und zuverlässige Sache. Ich hoffe, das die Jungs das mit 2.6.30 in den Kernel bekommen.
Provide Robust Clustered Storage with Linux and GFS
Install Bacula for Open Source Backups - Ich bin ja mehr ein Fan von Backuppc, aber Bacula hat sicherlich auch seine Berechtigung.
Configure Bacula for Open Source Backups
20 of the Best Free Linux Books
PostgreSQL Code Snippets - Hier findet man div. Skripte für Postgres im PostgreSQL Wiki, u.a. um raus zu finden, wieviel Speicher div. Tabellen auf der Platte belegen, Zeit- und Datumskonvertierung, EMail-Parsing, usw.
TikiWiki - TikiWiki ist so ziemlich alles, was man von einer Groupware/Content Management System (CMS) so erwartet. Es hat eigentlich alles, was man man für eine Social-Site braucht vom Wiki, Blogs, über Photoalben bis zu Foren.
Pylot: Web Performance Tool - Ein Tools ähnlich zu Apaches Jmeter mit dem man Last auf Webservern erzeugen kann. Jmeter ist allerdings wesenlich umfangreicher.
Xpra - Xpra ist screen für X. Man kann sich damit mit einem Host verbinden, ein X-Programm starten, die Verbindung unterbrechen und später die Verbindung wieder an der Stelle vorführen, wo man aufgehört hat.
Paver is a Python-based software project scripting tool - Ähnlich wie make oder rake.
Erstellt am 10:00PM Apr 09, 2009 in Links | Permalink Kommentare[0]
Links 20090406 - PLPython VMM KVM Golconde psutil Jajuk FlvToMp3
PLPython Part 2: Control Flow and Returning Sets
PLPython Part 3: Using custom classes, pulling data from PostgreSQL
PLPython Part 4: PLPython meets aggregates
PLPython Part 5: PLPython meets PostgreSQL Multi-column aggregates and SVG plots
Virtual Machine Manager - Damit kann man u.a. XEN und QEMU bzw. KVM virtuelle Maschinen verwalten. Der Manager enthält div. Tools u.a. Virt Install, Virt Clone, Virt Image und Virtual Machine Viewer.
Installing KVM Guests With virt-install On Ubuntu 8.10 Server
Golconde - Eine in Python geschriebene, lose gekoppelte Replikationslösung für PostgreSQL. Das Ganze arbeitet mit Queues und ist etwas flexibler als andere Lösungen. So müssen Quell- und Zieltabellen z.B. nicht unbedingt gleich sein.
psutil - Eine Python Library die Auskunft über laufende Prozesse gibt und für Linux, OS X, FreeBSD und Windows eine einheitliche API zur Verfügung stellt.
Jajuk Advanced Jukebox - Wer eine große oder etwas verstreute Musiksammlung hat, dem kann diese Jukebox vielleicht etwas beim Verwalten helfen.
FlvToMp3 - Eine KDE Applikation die ohne Qualitätsverlust aus einer Flash-Datei den Sound als MP3 speichert.
Erstellt am 10:00PM Apr 06, 2009 in Links | Permalink Kommentare[1]
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 ;-)
Erstellt am 07:51AM Mrz 10, 2009 in Tipps | Permalink 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 ;-)
Erstellt am 12:00AM Mrz 05, 2009 in Tipps | Permalink Kommentare[0]
Links 20090303 - Eric IDE Python Reference Munin IO Diskstats Postgresql FFmpeg FFprobe
Eric - Eric ist eine ziemlich umfangreiche Python IDE mit Debugger, Subversion-Integration und alles was man so braucht.
Python Quick Reference - Quick ist etwas untertrieben ;-) Auf 40-50 Seiten hat Richard Gruet eine gute Python-Referenz zusammengetragen. Sehr praktisch!
The Manga Guide to Databases - Auf die Idee muss man erst mal kommen, ein doch etwas schwieriges Thema im Comic-Stil aufzubereiten...
Graphing Linux Disk I/O statistics with Munin - Michael Renner hat ihr ganze Arbeit geleistet. Sein Munin linux_diskstats Plugin zeichnet neben Festplatten-Datendurchsatz auch I/O pro Sekunde und und Latenzzeit auf. Dieses Plugin hat wirklich noch gefehlt in der Sammlung der Plugins dieses wunderbaren Monitoring-Tools.
PostreSQL 8.4 Features - Bruce Momjian von EnterpriseDB gibt in diesem PDF einen guten Überblick, was mit Postgres 8.4 an neuen Features kommen wird.
FFprobe is a simple multimedia streams analyzer with a command-line interface based on the FFmpeg project libraries.
Erstellt am 12:00AM Mrz 03, 2009 in Links | Permalink Kommentare[0]
Links 20090205
Introduction into Java VisualVM - Dieses Video hier (Link geht direkt auf das Video) zeigt, wie man mit der VVM in Java 1.6 (Performance-)Probleme aller Art verhältnismäßig einfach debuggen kann.
Songbird 1.0 Review - Wer iTunes auf Linux vermisst hat, wird in Songbird eine gute Alternative finden (ohne iTunes-Store natürlich)...
EnterpriseDB Webcasts - Auf der Webseite von der kommerziellen Version von PostgreSQL finden sich einige interessante Videos bzw. Webcasts über Themen wie Replikation, Administration, usw.
Substance Java look & feel - Ein sehr schönes Theme für Java Programme.
Flamingo Swing component suite - Eine Java Swing Implementation der Office 2007 Ribbon Container und weitere Komponenten.
Better YouTube Firefox Extension - Fügt u.a. einen Download-Link ein, um das Video gleich runterladen zu können. Ausserdem verwendet es einen Flash-Player, der nicht gleich das Video abspielt.
YouTube HQ + 720p - Ein Greasemonkey Skript für Firefox damit man gleich die hochauflösenden YouTube Videos präsentiert bekommt.
Dyne's Legendary Hackers List - Was soll man mehr dazu sagen ;-) Aber wohlgemerkt: Es geht um Hacker und nicht um Cracker.
Music Player Daemon - Ein etwas ungewöhnlicher Player der als Daemon fungiert und über div. Biblotheken eine ganze Reihe von Formaten abspielen kann. Kontrolliert wird das Ganze über div. Clients.
Erstellt am 10:00PM Feb 05, 2009 in Links | Permalink 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';
Erstellt am 02:53PM Jan 23, 2009 in Tipps | Permalink Kommentare[0]