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



On Thu, 4 May 2000, Derek Martin wrote:

> 
> I'm not sure what this accomplishes... what happens when someone sends a
> request to the database daemon to update a record?
> 
> I'm envisioning this scenario:  You're using mysql as the back end of your
> web store.  You need to back up your database, which is large, so it takes
> 1 1/2 hours.  You lock your tables and begin the backup process.  Someone
> buys something. They check the status of their purchase, and get an error
> because the database wasn't able to insert a record for their purchase,
> since the tables are locked. This condition persists until the backup is
> done and the tables are unlocked.
> 
> Is this accurate?  If so, this isn't really any different than taking the
> database down for an hour to do the backup.
> 

In mysql-land you'd probably use mysqldump to dump your database out to a
file, and then back that up. No locking required, no interuptions. This
may not work for all situations, which is why we have different
DBMSes/cardfiles.

If I issued a read-lock before simply tarring up the files, you would
indeed have the problem you describeed. You can't use a read-local-lock
because you're playing with the database outside of mysql-land.

It's not for everyone, and I certainly hope anyone not familiar with it
thinks I'm saying it is. I just think it's a very stable, fast, and
generally all-round great product that meets my needs for a wide variety
of tasks. ;)

--
Niall Kavanagh, niall at kst.com
News, articles, and resources for web professionals and developers:
http://www.kst.com

-
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