Tuesday, August 16, 2011

Postgresql-WAL / inodes/ Disk Journaling System/ diskchecker /more on pgpool

Postgresql- WAL

The write ahead log, might be the solution I'm looking for to guarantee data integrity in a replication scenario.



inodes

Inodes are data structures that hold information about files except their name and data. The thing that startled me regarding this concept is that there's a fixed number of files that a unix system can handle, based on a set disk-percentage (one percent, need to find a good source related to this number) that the inodes can occupy. It could be the case that your server is stuffed with a bunch of small files, that have cause the inodes to run out and even though there might be disk space left, you won't be able to create more files. I don't know either what's the probability of this happening, but might be a fact worth taking into account...

http://en.wikipedia.org/wiki/Inode

Disk Journaling System

DJS is very similar to the WAL concept reviewed on this post. Changes are applied first to a log or journal and then commited to the main file system, so in case of a failure the system can be brought back to operation with virtually no loss of data.

Having enabled the postgresql WAL inside a system that uses disk journaling can decrease performance. We can disable journaling on a file system through mount options. The advantage of using journaled file systems is that they improve boot speed after a crash.

http://en.wikipedia.org/wiki/Journaling_file_system

Disk checker

There's an utility to measure what is the rate of errors once a disk failure occurs. The concern here is that most consumer and some SCSI drives come with the hardware write-caching option enabled, which results on risk of loosing data when a power outage, or unexpected failure takes place.

http://brad.livejournal.com/2116715.html

More on Pgpool

There's a really interesting article here:

http://www.sraoss.co.jp/event_seminar/2010/20100702-03char10.pdf

Another advantage of using pgpool is that you can achieve an authentic "automatic failover" as all nodes are in perfect sync  no transactions are left out. (Well it also depends of the configuration you're using)

No comments:

Post a Comment