Re: Postcrash

Hallo Zusammen,

mir gehe inzwischen leider die Ideen aus, aber zu nächst mal mein Problem:

Ich habe PostgreSQL 9.2.4 installiert. Das System ist dem Beagle Board recht
ähnlich (Linux Kernel 3.2.0). Jedenfalls wird eine SD-Karte als exklusiver
Datenspeicher für Postgresql verwendet. Ich habe es so gestaltet, dass die
Karte in /media/sdcard1 eingehängt wird, damit die Pfade nicht so
ungewöhnlich sind, existieren einige Symlinks die auf den entsprechenden
Ordner zeigen, Beispiel /etc/postgresql ist ein Symlink auf
/media/sdcard1/etc/postgresql. Das Ganze funktioniert auch prima.

Nun habe ich aber die Situation, das am Freitag Fensterputzer versehentlich
ein System vom Strom getrennt haben und ich seit dem nicht mehr auf die DB
zugreifen kann. Ich hatte gehofft, dass ein fsck.ext2 die Sache lösen würde.
Tut es aber nur bedingt, zwar startet PostgreSQL, ich kann dann aber auf
keine der DBs zu greifen. Dies liegt daran, dass die Symlinks auf die
Tabelspaces fehlen. Leider komme ich da manuell auch nicht weiter (fühlt
sich auch total falsch an), da wohl auch Sachen in den verlinkten Ordner
fehlen.

Nun bin ich wie gesagt ratlos:

Kann ich Daten überhaupt noch retten?

Wie kriege ich es hin das PostgreSQL wirklich ACID konform wird, kann man
noch was an der Partitionierung der SD-Karte verbessern (aktuell ist es eine
große Parition für Konfiguration und Daten)?

Gibt es ein bessers FS als ext2 dafür?

Viele Grüße

Lars

Lars Grundei <l(dot)grundei(at)meteocontrol(dot)de> wrote:

> Ich habe PostgreSQL 9.2.4 installiert. Das System ist dem Beagle Board recht
> ähnlich (Linux Kernel 3.2.0). Jedenfalls wird eine SD-Karte als exklusiver
> Datenspeicher für Postgresql verwendet. Ich habe es so gestaltet, dass die
> Karte in /media/sdcard1 eingehängt wird, damit die Pfade nicht so ungewöhnlich
> sind, existieren einige Symlinks die auf den entsprechenden Ordner zeigen,
> Beispiel /etc/postgresql ist ein Symlink auf /media/sdcard1/etc/postgresql. Das
> Ganze funktioniert auch prima.
>
>
>
> Nun habe ich aber die Situation, das am Freitag Fensterputzer versehentlich ein
> System vom Strom getrennt haben und ich seit dem nicht mehr auf die DB
> zugreifen kann. Ich hatte gehofft, dass ein fsck.ext2 die Sache lösen würde.
> Tut es aber nur bedingt, zwar startet PostgreSQL, ich kann dann aber auf keine
> der DBs zu greifen. Dies liegt daran, dass die Symlinks auf die Tabelspaces
> fehlen. Leider komme ich da manuell auch nicht weiter (fühlt sich auch total
> falsch an), da wohl auch Sachen in den verlinkten Ordner fehlen.
>
>
>
>
>
> Nun bin ich wie gesagt ratlos:
>
> Kann ich Daten überhaupt noch retten?

von remote schwer zu beurteilen. Ist denn noch was drauf? Was steht im
Log von PG?

>
> Wie kriege ich es hin das PostgreSQL wirklich ACID konform wird, kann man noch
> was an der Partitionierung der SD-Karte verbessern (aktuell ist es eine große
> Parition für Konfiguration und Daten)?
>
> Gibt es ein bessers FS als ext2 dafür?

ext3, ext4, xfs, ...

Andreas
--
Really, I'm not out to destroy Microsoft. That will just be a completely
unintentional side effect. (Linus Torvalds)
"If I was god, I would recompile penguin with --enable-fly." (unknown)
Kaufbach, Saxony, Germany, Europe. N 51.05082°, E 13.56889°

Hallo Lars,

On 09/30/2013 10:42 AM, Lars Grundei wrote:
> Nun habe ich aber die Situation, das am Freitag Fensterputzer

Ja, ja, immer die arme Putze an allem Schuld... ;-)

> versehentlich ein System vom Strom getrennt haben und ich seit dem nicht
> mehr auf die DB zugreifen kann. Ich hatte gehofft, dass ein fsck.ext2
> die Sache lösen würde. Tut es aber nur bedingt, zwar startet PostgreSQL,
> ich kann dann aber auf keine der DBs zu greifen. Dies liegt daran, dass
> die Symlinks auf die Tabelspaces fehlen. Leider komme ich da manuell
> auch nicht weiter (fühlt sich auch total falsch an), da wohl auch Sachen
> in den verlinkten Ordner fehlen.

Ich befürchte, die SD card und/oder das System schummeln gewaltig was
fsync() angeht. In diesem Fall hat Postgres wenig Chance auf
Crash-Resilience.

Prüf das System doch mal mit dem pg_test_fsync tool aus contrib.

> Kann ich Daten überhaupt noch retten?

Dazu hast Du ja das Backup. :-)

pg_resetxlog kann evtl. helfen, die Datenbank wieder anzuwerfen.
Hinterlässt wahrscheinlich aber korrupte Daten.

pg_dbcheck gibt's. Viel mehr als: "Ja, die Daten sind korrupt, go get
your backup" darfst Du da aber nicht erwarten.

> Wie kriege ich es hin das PostgreSQL wirklich ACID konform wird, kann
> man noch was an der Partitionierung der SD-Karte verbessern (aktuell ist
> es eine große Parition für Konfiguration und Daten)?
>
> Gibt es ein bessers FS als ext2 dafür?

Weder Partitionierung noch FS können helfen, wenn die Hardware unbemerkt
write caching macht. Und speziell auf Embedded- oder Consumer-Systemen
lässt sich diese "Optimierung" (i.e. Caching) manchmal nicht einmal
abschalten.

Gruss

Markus Wanner

> Ich befürchte, die SD card und/oder das System schummeln gewaltig was
> fsync() angeht. In diesem Fall hat Postgres wenig Chance auf
> Crash-Resilience.
> Prüf das System doch mal mit dem pg_test_fsync tool aus contrib.

Habe ich inzwischen hinbekommen (ich habe außerdem eine nun SLC SD-Karte
eingelegt, das FS auf EXT3 umgestellt und auch selber die Rolle des
Fensterputzer übernommen :-))
Leider sagen mir die Ausgabe von pg_test_fsync nichts, also kann ich auch
nicht bewerten, ob das System schummelt:
-----------------
#pg_test_fsync --version
pg_test_fsync (PostgreSQL) 9.2.4

#su -c "pg_test_fsync -f /var/postgresql/fsync.test" -s /bin/sh postgres
2 seconds per test
O_DIRECT supported on this platform for open_datasync and open_sync.

Compare file sync methods using one 8kB write:
(in wal_sync_method preference order, except fdatasync
is Linux's default)
open_datasync 24.879 ops/sec
fdatasync 24.471 ops/sec
fsync 25.075 ops/sec
fsync_writethrough n/a
open_sync 24.364 ops/sec

Compare file sync methods using two 8kB writes:
(in wal_sync_method preference order, except fdatasync
is Linux's default)
open_datasync 21.702 ops/sec
fdatasync 21.849 ops/sec
fsync 21.671 ops/sec
fsync_writethrough n/a
open_sync 20.889 ops/sec

Compare open_sync with different write sizes:
(This is designed to compare the cost of writing 16kB
in different write open_sync sizes.)
1 * 16kB open_sync write 21.626 ops/sec
2 * 8kB open_sync writes 7.353 ops/sec
4 * 4kB open_sync writes 19.326 ops/sec
8 * 2kB open_sync writes 18.309 ops/sec
16 * 1kB open_sync writes 15.349 ops/sec

Test if fsync on non-write file descriptor is honored:
(If the times are similar, fsync() can sync data written
on a different descriptor.)
write, fsync, close 23.698 ops/sec
write, close, fsync 24.600 ops/sec

Non-Sync'ed 8kB writes:
write 24028.662 ops/sec

#su -c "pg_test_fsync -f /var/postgresql/fsync.test -s 10" -s /bin/sh
postgres
10 seconds per test
O_DIRECT supported on this platform for open_datasync and open_sync.

Compare file sync methods using one 8kB write:
(in wal_sync_method preference order, except fdatasync
is Linux's default)
open_datasync 258.480 ops/sec
fdatasync 249.492 ops/sec
fsync 180.480 ops/sec
fsync_writethrough n/a
open_sync 255.945 ops/sec

Compare file sync methods using two 8kB writes:
(in wal_sync_method preference order, except fdatasync
is Linux's default)
open_datasync 102.687 ops/sec
fdatasync 127.296 ops/sec
fsync 129.286 ops/sec
fsync_writethrough n/a
open_sync 104.276 ops/sec

Compare open_sync with different write sizes:
(This is designed to compare the cost of writing 16kB
in different write open_sync sizes.)
1 * 16kB open_sync write 133.724 ops/sec
2 * 8kB open_sync writes 104.398 ops/sec
4 * 4kB open_sync writes 83.926 ops/sec
8 * 2kB open_sync writes 51.112 ops/sec
16 * 1kB open_sync writes 29.085 ops/sec

Test if fsync on non-write file descriptor is honored:
(If the times are similar, fsync() can sync data written
on a different descriptor.)
write, fsync, close 241.880 ops/sec
write, close, fsync 241.513 ops/sec

Non-Sync'ed 8kB writes:
write 25772.686 ops/sec

-----------------

Viele Grüße
Lars

Lars Grundei schrieb:
>> Ich befürchte, die SD card und/oder das System schummeln gewaltig was
>> fsync() angeht. In diesem Fall hat Postgres wenig Chance auf
>> Crash-Resilience.
>> Prüf das System doch mal mit dem pg_test_fsync tool aus contrib.
>
> Habe ich inzwischen hinbekommen (ich habe außerdem eine nun SLC SD-Karte
> eingelegt, das FS auf EXT3 umgestellt und auch selber die Rolle des
> Fensterputzer übernommen :-))
> Leider sagen mir die Ausgabe von pg_test_fsync nichts, also kann ich auch
> nicht bewerten, ob das System schummelt:

> #su -c "pg_test_fsync -f /var/postgresql/fsync.test -s 10" -s /bin/sh postgres
> 10 seconds per test
> O_DIRECT supported on this platform for open_datasync and open_sync.
>
> Compare file sync methods using one 8kB write:
> (in wal_sync_method preference order, except fdatasync
> is Linux's default)
> open_datasync 258.480 ops/sec
> fdatasync 249.492 ops/sec
> fsync 180.480 ops/sec
> fsync_writethrough n/a
> open_sync 255.945 ops/sec
[...]
> Non-Sync'ed 8kB writes:
> write 25772.686 ops/sec

Das würde nahelegen, daß das sync tatsächlich passiert,
sonst würden writes ohne sync nicht so viel schneller gehen.

Liebe Grüße,
Laurenz Albe