DRBD and PostgreSQL - high load performance?

[Barry Price]

Hi,

We're looking at DRBD as a way to get a live-backup going on our database
server. It's an 8cpu SCSI-fired RAID1+0 monster with 16Gb RAM, and it's usually
very, very busy.

The database server is PostgreSQL 8, and consists of over 10,000 tables with up
to 2,000 connections, processing several hundred queries per second. DRBD looks
like exactly what we need, but the testimonials I've seen have all been on
rather smaller systems.

Has anyone stress-tested DRBD on this level of system? I'm concerned that even
over gigabit, it simply won't be able to keep up with the speed of writes that
we get over the SCSI controllers. What happens when a backlog occurs? Does the
secondary machine simply queue the changes, or can it lock up? Are there any
other issues we should be concerned about?

Thanks,

Barry Price

[Lars Ellenberg]

/ 2005-09-12 15:09:22 +0000

Post by Barry Price
Hi,
We're looking at DRBD as a way to get a live-backup going on our database
server. It's an 8cpu SCSI-fired RAID1+0 monster with 16Gb RAM, and it's usually
very, very busy.
The database server is PostgreSQL 8, and consists of over 10,000 tables with up
to 2,000 connections, processing several hundred queries per second. DRBD looks
like exactly what we need, but the testimonials I've seen have all been on
rather smaller systems.
Has anyone stress-tested DRBD on this level of system?

...

I think we once tested it on some 8way in the suse testlabs...

Post by Barry Price
I'm concerned that even over gigabit, it simply won't be able to keep
up with the speed of writes that we get over the SCSI controllers.

what (mean sustained/max) throughput do you actually have?
what latency do you need?
which percentage of your data base access is in fact _writes_ ?

Post by Barry Price
What happens when a backlog occurs? Does the secondary machine simply
queue the changes, or can it lock up? Are there any other issues we
should be concerned about?

you want to use "drbd protocol C", maybe, but really think about it and
then benchmark it "B".
there is no backlog. this is not rsync.
from the point of view of the data base or filesystem or whatever, the
write is finished when both local backend and remote backend
acknowledged that this write is on stable storage.

and in case you need special features, optimizations, or other support,
just contact office at linbit...

cheers,

[Philipp Reisner]

Post by Barry Price
Hi,
We're looking at DRBD as a way to get a live-backup going on our database
server. It's an 8cpu SCSI-fired RAID1+0 monster with 16Gb RAM, and it's
usually very, very busy.
The database server is PostgreSQL 8, and consists of over 10,000 tables
with up to 2,000 connections, processing several hundred queries per
second. DRBD looks like exactly what we need, but the testimonials I've
seen have all been on rather smaller systems.
Has anyone stress-tested DRBD on this level of system? I'm concerned that
even over gigabit, it simply won't be able to keep up with the speed of
writes that we get over the SCSI controllers. What happens when a backlog
occurs? Does the secondary machine simply queue the changes, or can it
lock up? Are there any other issues we should be concerned about?

...

Hi Barry,

Two of the more interesting clusters we run at Linbit

PostgreSQL on a quad Opteron / 8 GB RAM Cluster
Oracle on a quad HyperThreading enabled Xeons (=8 virtual CPUs) with
8GB RAM Cluster.

Regarding Performance, look for the "Need for speed" subject in the
mailing list archives.

Ask your self:
Can my SCSI controllers / disks write more than 100MByte/second ?
That is what GBit Ethernet delivers you.

If the secondary machine can not keep up with the writing speed
of the primary it will slow-down the primary in the end.

=> The machines should have about the same performance.

-Philipp