--skip-locking is on by default?  I gotta check that but, yes, if I were you
I would try without the skip locking option.  You would then also be able to
do a myisamchk without bringing down the server.

----- Original Message -----
From: "Hardy Merrill" <[EMAIL PROTECTED]>
To: "Rolf Hopkins" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Thursday, February 08, 2001 3:03
Subject: Re: --skip-locking on Redhat 6.1 Linux


> Rolf Hopkins [[EMAIL PROTECTED]] wrote:
> > Firstly, I'm curious as to why you need --skip-locking in the first
place.
>
> I'm not sure that I do - I just thought that if I instead
> used --enable-locking that this problem of update logs
> getting confused with flush-logs might(?) go away.  But I
> haven't been able to find any definite documentation that
> advises whether you can/should run MySQL on Linux without
> the default(on Linux) --skip-locking, and what the issues
> (pros/cons) are surrounding that.
>
> The basic problem is MySQL seems to be running well on Redhat
> 6.1 Linux *with* the default --skip-locking, except for this
> update log confusion problem that I see occassionally.  And now
> that I've put the sleep in after the mysqladmin flush-logs, I
> can't get the confusion to happen any more - maybe I've solved
> the problem???
>
> Here's my basic backup strategy
>   * mysqldump once a week
>   * mysqladmin flush-logs once an hour(?), and save the inactive
>     (older) logs to a backup directory for that week
>   * I'd like to work in a "myisamchk" once a day(?), but the
>     documentation says not to do this while running
>     --skip-locking unless you bring the server down
>         * Again, I thought that --enable-locking might
>           solve this problem, and allow me to run myisamchk
>           when the server is up - would it?
>
> Would you do this differently?  Or does this seem like a
> reasonable strategy?
>
> Please reply - it's great to finally(after posting this 3
> times, and reading all the related documentation I could
> find) get a response.
>
> Thank you very much!
>
> --
> Hardy Merrill
> Mission Critical Linux, Inc.
> http://www.missioncriticallinux.com
>
> >
> > Now that I know what you are trying to achieve, I can honestly say I'm
not
> > sure.  I'd have to read the manual for more detail on how flush-logs
> > interact with table locking etc.
> >
> > I presume your daemon, that's accessing the DB, is a cron job.  Can you
time
> > it so that your flush-logs occur between this daemon process?
> >
> > ----- Original Message -----
> > From: "Hardy Merrill" <[EMAIL PROTECTED]>
> > To: "Rolf Hopkins" <[EMAIL PROTECTED]>
> > Cc: <[EMAIL PROTECTED]>
> > Sent: Wednesday, February 07, 2001 23:15
> > Subject: Re: --skip-locking on Redhat 6.1 Linux
> >
> >
> > > Rolf, I'm invoking safe_mysqld with --skip-locking and
> > > --log-update=update_log, among other options.  If I run
> > > mysqladmin flush-logs while database updates are occurring,
> > > the update logs sometimes get confused - the scheme I have
> > > is basically
> > >
> > >    mysqladmin flush-logs
> > >    mv name_of_old_update_log backup_dir
> > >
> > > and using this scheme I've seen a few different types of
> > > update log confusion, but here was one:
> > >
> > >    current update log name: update_log.100
> > >
> > > when I ran mysqladmin flush-logs while updates were occurring,
> > > the result was that the update log that was moved to backup_dir
> > > had name "update_log.100", and the new update log that got
> > > created in the MySQL data directory had exactly the same
> > > name(update_log.100).
> > >
> > > I have a daemon writing INSERT's and UPDATE's very regularly
> > > to the MySQL database, so I don't want to take the MySQL
> > > server down if I can help it, but I would like to run
> > > flush-logs on a regular basis so I can have checkpoints
> > > of database updates to save off - is there a way for
> > > me to lock the tables(or the whole database) in the
> > > script *before* doing the mysqladmin flush-logs, to
> > > prevent update log confusion?  Do you know of a way to solve
> > > this update log confusion?
> > >
> > > I did notice that when I inserted a sleep 1(or 2) between
> > > the mysqladmin flush-logs and the "mv" that I haven't been
> > > able to "make" the update-logs get confused, but I'm not
> > > very confident that this is "the" right solution.  Please
> > > help.
> > >
> > > Thanks.
> > >
> > > Hardy Merrill
> > > Mission Critical Linux, Inc.
> > > http://www.missioncriticallinux.com
> > >
> > >
> > >
> > >
> > > Rolf Hopkins [[EMAIL PROTECTED]] wrote:
> > > > can: yes
> > > > should: That's up to you but personally I wouldn't
> > > >
> > > > ----- Original Message -----
> > > > From: "Hardy Merrill" <[EMAIL PROTECTED]>
> > > > To: <[EMAIL PROTECTED]>
> > > > Sent: Wednesday, February 07, 2001 3:31
> > > > Subject: --skip-locking on Redhat 6.1 Linux
> > > >
> > > >
> > > > > Can/should MySQL be started *without* --skip-locking on Redhat
> > > > > 6.1 Linux?
> > > > >
> > > > > TIA.
> > > > >
> > > > > --
> > > > > Hardy Merrill
> > > > > Mission Critical Linux, Inc.
> > > > > http://www.missioncriticallinux.com
> > > > >
> > > >
> ---------------------------------------------------------------------
> > > > > Before posting, please check:
> > > > >    http://www.mysql.com/manual.php   (the manual)
> > > > >    http://lists.mysql.com/           (the list archive)
> > > > >
> > > > > To request this thread, e-mail <[EMAIL PROTECTED]>
> > > > > To unsubscribe, e-mail
> > > > <[EMAIL PROTECTED]>
> > > > > Trouble unsubscribing? Try:
http://lists.mysql.com/php/unsubscribe.php
> > >
> > > ---------------------------------------------------------------------
> > > Before posting, please check:
> > >    http://www.mysql.com/manual.php   (the manual)
> > >    http://lists.mysql.com/           (the list archive)
> > >
> > > To request this thread, e-mail <[EMAIL PROTECTED]>
> > > To unsubscribe, e-mail
> > <[EMAIL PROTECTED]>
> > > Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php


---------------------------------------------------------------------
Before posting, please check:
   http://www.mysql.com/manual.php   (the manual)
   http://lists.mysql.com/           (the list archive)

To request this thread, e-mail <[EMAIL PROTECTED]>
To unsubscribe, e-mail <[EMAIL PROTECTED]>
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php

Reply via email to