From: | Mike Benoit <mikeb(at)netnation(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Alternative replication method. |
Date: | 2003-06-25 15:42:04 |
Message-ID: | 1056555724.8617.57.camel@mikeb.staff.netnation.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
According to section 5 in this:
http://www.complang.tuwien.ac.at/reisner/drbd/publications/drbd_paper_for_LK7.pdf
it looks like it does guarantee write order.
<snip>
5 Write ordering
Some file systems require that certain blocks hit the media in a
determined order, for example a JFS
needs to write a transaction (the commit record must be last) into the
journal before it does any updates
to the home locations.
It does this by postponing the home location updates until it knows that
the writes to the journal are
on stable storage. (This is done with wait_on_buffer() and/or
buffer_uptodate())
>From the DRBD's point of view the question is, which blocks might be
reordered when writing to the
secondary's disk.
To ensure exactly the same write order as on the primary, we must use
the following scheme:
1. Get a block from the network and put it onto the buffer cache.
2. Write that buffer and wait for IO completion.
3. Continue with 1.
...
</snip>
On Wed, 2003-06-25 at 07:44, Tom Lane wrote:
> Mike Benoit <mikeb(at)netnation(dot)com> writes:
> > Has anyone used PostgreSQL with Drbd
> > (http://www.complang.tuwien.ac.at/reisner/drbd/)?
>
> Does it guarantee preservation of write ordering?
>
> regards, tom lane
--
Best Regards,
Mike Benoit
NetNation Communications Inc.
Systems Engineer
Tel: 604-684-6892 or 888-983-6600
---------------------------------------
Disclaimer: Opinions expressed here are my own and not
necessarily those of my employer
From | Date | Subject | |
---|---|---|---|
Next Message | Johnson, Shaunn | 2003-06-25 15:44:29 | how to fix missing chunk number 0? |
Previous Message | Tom Lane | 2003-06-25 15:36:21 | Re: pg_statistic_relid_att_index |