Re: --skip-locking on Redhat 6.1 Linux
--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 "ma
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 *
Re: --skip-locking on Redhat 6.1 Linux
Firstly, I'm curious as to why you need --skip-locking in the first place. 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
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
Re: --skip-locking on Redhat 6.1 Linux
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
--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
skip-locking on Redhat 6.1 Linux
I'm fairly new to MySQL, and I've read some documentation that says that "skip-locking" is the default on Linux. I'm trying to set up a table maintenance/backup strategy, and I'd like to use "myisamchk" and "mysqldump". 1. Can I run myisamchk *without* shutting mysql down? I don't want to have to bring mysql down unless absolutely necessary. 2. Can I start mysqld(safe_mysqld) with "--enable-locking"? - would this allow me to use myisamchk without having to shut down mysql? 3. Since I would use --opt with mysqldump, which does "--add-locks" and "--lock-tables", I think that I don't have to worry about the "skip-locking" issue, right? I'm interested to hear what other people have as their maintenance/backup strategy for MySQL databases/tables. Nightly, I'd like to 1. run myisamchk to check all databases (not sure if this is necessary every night) 2. backup --all-databases using mysqldump 3. do flush-logs(probably with mysqldump) so that a new update log is started 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
