On Sat, Apr 12, 2008 at 11:00 PM, Dawid Kuroczko <qnex42@xxxxxxxxx> wrote: > > Not quite workable. Remember that table data is not always available on > the block device -- there are pages modified in the buffer cache (shared > memory), and other machines have no access to the other's shared memory > (and it would be a lot of work to do it efficiently). Remember also about the > MVCC -- if your "read only copy machine" starts a complicated query on > some big_table, and in the meanwhile "read-write machine" decides the > big_table's pages can be reused... well your "read-only" machine doesn't > even have a way of knowing its returning garbage data. ;-) > I am not suggesting one read-write and many read-only architecture. I am rather suggesting all read-only systems. I would be interested in this setup if I run large read-only queries on historical data and need easy scalability. With read-only setup, you can easily add another machine to increase computing power. Also, we may come up with cache-sharing systems so that if a buffer is cached on some other node, that can be transfered on a high speed interconnect, rather than reading from a relatively slower disk. > Noow, if you really really want a read-only copy of the read write data > available over the network, many NAS/SAN devices will allow you to > make a snapshot of the database -- and you can use that snapshot as > a read-only copy of the database. But then again, if you want a read-only > copy of a days/weeks old database, there are chaper and better ways of > doing it. > > Yes. I was mostly assuming read-only scalability. What are the other better ways to do so ? > > A known implementation of such a set up would be Oracle RAC, where > you have a shared storage and N machines using it. > Oracle RAC is a multi-master kind of architecture where each node has access to the shared storage and can directly read/write data. Thanks, Pavan -- Pavan Deolasee EnterpriseDB http://www.enterprisedb.com
