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, Niall Kavanagh wrote:

> This is why during a backup procedure you READ LOCK the mysql database.
> Clients will still be able to query the database,. The better way would be
> to do a local lock, which would also allow INSERTS during the process, and
> then dump the SQL data from the database (which is not what you folks are
> talking about).

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.

Derek Martin
System Administrator
Mission Critical Linux
martin at 

Subcription/unsubscription/info requests: send e-mail with
"subscribe", "unsubscribe", or "info" on the first line of the
message body to discuss-request at (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 /