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). Cheers, -- 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