On Sat, Apr 12, 2008 at 8:11 PM, Pavan Deolasee
<pavan.deolasee@gmail.com> wrote:
> 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.
For example, it coulde be done by an ability to start a cleanly shutdown
database in read-only mode. I would see it as a very helpful companion
for a PITR recovery.
So in recover.conf you could say you want a recovery done until '10:00',
and then do some read-only queries, decide you want to recover until '10:15',
and so on until you find a place where someone did a big mistake.
Hmm, would be helpful to ask recovery process to create "write before logs",
i.e. logs which would allow you to 'roll back' whole recovery of the database
to '10:05', should you decide '10:15' is too late.
Possible TODO entry? ;-)
[...]
> Yes. I was mostly assuming read-only scalability. What are the other
> better ways to do so ?
I was thinking you were saying... Let's drop the issue, I misunderstood. :-)
Regards,
Dawid
