| From: | Ben <bench(at)silentmedia(dot)com> |
|---|---|
| To: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
| Cc: | Thomas Lopatic <thomas(at)lopatic(dot)de>, pgsql-general(at)postgresql(dot)org |
| Subject: | Re: Data replication through disk replication |
| Date: | 2007-05-19 01:26:54 |
| Message-ID: | E03C64A6-55AC-4EF3-981E-42C6A5F72FDF@silentmedia.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
You pay a price writes, but with write caching enabled on your
(battery-backed, of course) RAID card and using gigabit, it's easy to
get >100MB/s throughput. It's also easy to replicate different block
devices over separate network links, if that becomes your bottleneck.
On May 18, 2007, at 6:14 PM, Alvaro Herrera wrote:
> Ben wrote:
>> If you're just looking for a way to have high availability and
>> you're ok
>> being tied to linux, DRBD is a good way to go. It keeps things
>> simple in
>> that all changes are replicated, it won't say an fsync is finished
>> until
>> it's finished on the remote host too,
>
> Oh, so that's how it works. I assume performance must be, huh, not
> stellar?
>
> --
> Alvaro Herrera http://
> www.CommandPrompt.com/
> The PostgreSQL Company - Command Prompt, Inc.
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 9: In versions below 8.0, the planner will ignore your desire to
> choose an index scan if your joining column's datatypes do not
> match
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alvaro Herrera | 2007-05-19 03:51:51 | Re: Large Database Restore |
| Previous Message | Alvaro Herrera | 2007-05-19 01:14:27 | Re: Data replication through disk replication |