Re: PostgreSQL clustering with DRBD

From: Tim Uckun <timuckun(at)gmail(dot)com>
To: Serge Fonville <serge(dot)fonville(at)gmail(dot)com>
Cc: pgsql-general <pgsql-general(at)postgresql(dot)org>
Subject: Re: PostgreSQL clustering with DRBD
Date: 2009-02-23 04:16:18
Message-ID: 855e4dcf0902222016v315d10a6nb45bf5c4d106e08d@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Wed, Feb 11, 2009 at 11:24 PM, Serge Fonville
<serge(dot)fonville(at)gmail(dot)com>wrote:

> Hi,
> I am in the process of setting up a two node cluster.
> Can PostgreSQL use DRBD as its storage?
> Since the in-memory database would be synchronized with the on-disk
> database.
> If this would be done with every query, this would greatly impact
> performance.
> Since the cluster will be multi-master/dual-primary, do I need to have a
> separate block device for each PostgreSQL instance or can it use the DRBD
> device?
> I read mostly about MySQL clustering with DRBD and there the query cache
> should be disabled to make sure data is in-sync.
> To me it seems something similar would apply to PostgreSQL.
> I believe cybercluster is the most active and complete PostgreSQL
> clustering solution.
> My endgoal is a two node cluster with load sharing and fail over where both
> nodes can perform reads and writes.
>

After reading your post I decided to check out cybercluster. In PgFoundry
there is a cybercluster project
http://pgfoundry.org/projects/cybercluster/but it hasn't been updated
since 2007.

Is that the one you are talking about or is there another cybercluster I
should be looking at.

Also....

Is there an article or something that compares the different HA solutions
for postgres? What are the differences between pgpool, pgcluster,
cybercluster etc?

Any HOWTOs anywhere?

Thanks.

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Jordan Tomkinson 2009-02-23 06:55:46 High cpu usage after many inserts
Previous Message Bryan Murphy 2009-02-23 01:56:55 Re: Backup Strategy Second Opinion