Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

shells and bells



Today, Niall Kavanagh gleaned this insight:

> > Transaction support is absolutely essential.  Without it, things like ODBC
> > access to the data will not work reliably.  Locking will not work
> > reliably.  What you get, in fact, without transaction support is a
> > database suitable for reading but not writing.  If this is what you want,
> > then more power to you, but this is not what I consider a database server.
> >
> 
> It certainly is not. There are other methods of backing up a database, and
> other ways of ensuring data integrity.

While I can't speak to Mike's assertions about ODBC or locking, the only
alternative I know of to DBMS-supported on-line back up is to shut down
the database and dump it to text files, which can then be backed up.  
Otherwise, as Mike said, you have no guarantee that the data on the disk
is in a form which is useful to back up, and it's rather likely that it
won't be.

As I understand the problem (and I'll admit up front that my understanding
may be flawed), this is due to the fact that a database write, while
"atomic" from the database's perspective, is not an atomic operation from
the kernel's perspective, unless the whole operation can be done with
exactly one system call (system calls are guaranteed to be atomic, IIRC).
Otherwise, the dbms may finish its time slice while a record update is in
progress, at which time the back-up program may read the database's files,
yeilding spaghetti data on your backup tape.

> 
> Mysql uses a locking method they call "atomic operations" (I'm not
> sure if this is a mysql-ism?) which results in
> a database server which is 2-4 times faster than a finely tuned
> transactional setup.

The term "atomic operation" is certainly not a MySQL-ism... it refers to
an operation that must complete before any other operation can begin.  It
is certainly possible for MySQL to consider its record updates atomic,
while in the framework of the OS they are not.  Wether or not that is
actually the case, I can't say...


-- 
PGP/GPG Public key at http://cerberus.ne.mediaone.net/~derek/pubkey.txt
------------------------------------------------------
Derek D. Martin      |  Unix/Linux Geek
derekm at mediaone.net  |  derek at cerberus.ne.mediaone.net
------------------------------------------------------

-
Subcription/unsubscription/info requests: send e-mail with
"subscribe", "unsubscribe", or "info" on the first line of the
message body to discuss-request at blu.org (Subject line is ignored).




BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org