[elephant-devel] Re: Live backup

[Ian Eslick]

On Dec 11, 2007, at 10:41 AM, Alex Mizrahi wrote:

> IE>   If you do it at the application level within a transaction  
> (even if
> IE> it did fit in memory) you would either implicitly halt all  
> activity or
> IE> constantly be aborted by any write operation anywhere in the db.
>
> ah, indeed, this way bdb works.. PostgreSQL uses MVCC by default, so  
> reading activity doesn't block writting.
>
> documentation says you can also get MVCC in bdb via "snapshot  
> isolation" --  it would implement copy-on-write on database level.
> see here:
> http://www.oracle.com/technology/documentation/berkeley-db/db/ref/transapp/read.html
> http://www.oracle.com/technology/documentation/berkeley-db/db/api_cxx/txn_begin.html
> DB_TXN_SNAPSHOT
> This transaction will execute with snapshot isolation. For databases  
> with the DB_MULTIVERSION flag set, data values will be read as they  
> are when the transaction begins, without taking read locks. Silently  
> ignored for operations on databases with DB_MULTIVERSION not set on  
> the underlying database (read locks are acquired).
>
> or that's what you meant when said "Implement a  copy-on-write  
> policy in your transactions"?

I was thinking about something pretty similar, but at the application  
level.  Perhaps my original response was too off-the-cuff.  I think  
the only problem that may come up in the MVCC model is whether you run  
out of storage for keeping the write versions of committing  
transactions that start after the read operation snapshot was taken.   
It can take a long time to read the entire DB within a single  
transaction!

> IE> Berkeley DB also supports low-level hot backups if you know that  
> your
> IE> OS reads file pages atomically.
> IE> (http://www.oracle.com/technology/documentation/berkeley-db/db/ref/tran
> IE> sapp/archival.html )  For an example see the source code for
> IE> db_hotbackup in the BDB  distribution.
>
> that's probably preffered way indeed.

Indeed.  This puts the future transaction storage burden in the log  
files instead of a shared memory region which is much more scalable.

> _______________________________________________
> elephant-devel site list
> elephant-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/elephant-devel