On Sat, Apr 12, 2008 at 11:00 PM, Dawid Kuroczko <qnex42@gmail.com> 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
