[DRBD-user] Use secondary for read I/O too ?

Casey Allen Shobe cshobe at bepress.com
Mon Aug 25 20:06:21 CEST 2008

Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.

On Aug 25, 2008, at 7:12 AM, Robert wrote:
> I was thinking about read optimization a bit more. Especially for  
> database loads two things are important for performance (besides  
> scema optimization :) ) secure async writes (=HW RAID + BBU) and  
> short access times for reads (SSD or many fast disks). Simply  
> speaking a DRBD device is something like a raid1 over the network  
> where reads are done from one side ONLY. If reads would be done on  
> both sided - it would in theory be possible to double the read rate.  
> This would also warm up the buffer cache on the standby side.

Depending on what "database" you're using and how tied to it...

PostgreSQL 8.4 is intended to support a standby configuration whereas  
the secondary is queryable in read-only mode (but it would be up to  
your application or middleware to determine which database to connect  
to for which query).  Currently 8.2+ can be used with pg_standby for  
asynchronous replication based on write-ahead log shipping, but the  
secondary is not usable similar to a DRBD secondary.

I notice when watching iostat on our production database that writes  
per second outweigh reads per second by an average of ten times.   
Write speed is far more impontant - what DRBD adds is reliability  
rather than performance increase.  If you are using disk heavily for  
reads, you should consider adding more memory to your database server  
and/or using memcached.  The network latency involved with querying  
both nodes, even with a crossover cable gigabit network, is  
significant enough that it would only be useful for queries that are  
going to be slow anyways due to large amounts of data being retrieved,  
and even then, the complexity of retrieving half of the records is not  
really any less complex than retrieving them all, so trying to read  
from the secondary would probably never help.  The only conceivable  
place this might be useful is if you store a lot of large objects in  
your database (images, movies, other files) and cannot affordably  
store them in cache, where the lookup cost is fetching the blocks from  
disk rather than locating the record(s).

Casey Allen Shobe
Database Architect, The Berkeley Electronic Press
cshobe at bepress.com (email/jabber/aim/msn)
http://www.bepress.com | +1 (510) 665-1200 x163

More information about the drbd-user mailing list