Rod Taylor wrote:

>
>>I was thinking about the eventual corruption of a database, not of
>>PostgreSQL.
>>If a database happens to be corrupted, only this one need failover. In
>>the case of a huge database,
>>everything is concerned by the failure (and by the failover
>>procedure !), which is a pain...
>>    
>>
>
>I see. The reasonable thing to do is have each users worth of tables
>replicated independently using multiple sets. Sets work individually and
>can be failed over or replicated independently of each-other.
>  
>
That's not *precisely* the case...

FAILOVER (id = 1, backup node = 2);

Causes node #1 to be treated as failed, which will affect *ALL*
replication sets on that node.

However, I don't think this changes the overall implications.

If a database is corrupted, I don't see how this can evade the
implication that the entire cluster is corrupt, and must be treated as
destroyed.

If there isn't that degree of separation, then anything that could
corrupt one database would have every reason to be corrupting *ALL* of
the databases simultaneously. 

Consider major ways that a database might be corrupted:
- Suppose a disk goes bad; this adversely affects *ALL* data on that
filesystem
- Suppose a disk controller starts scribbling on its disks; this
adversely affects *ALL* the disks/partitions/filesystems
- Suppose a user script goes mad and starts scribbling around in
$PGDATA; this adversely affects *ALL* files in the "data area" that are
writable by the user that runs that script

In all three scenarios of database corruption, it will be difficult to
have any confidence that *any* of the databases on the local
disk/filesystem/controller/user account have not been corrupted.

In order to avoid that implication, I would want to see some pretty
significant separations, including ALL of the following:
 - Each database cluster needs to be on its own separate filesystem on a
physically separate set of disk space.  (In a disk array context, I'd
relax that to "separate LUN")
 - Each database cluster needs to run as a separate Unix user (distinct
user for each cluster)