But it is procedure that the MySQL documentation states MySQL uses themselves without any problems. Perhaps the documentation isn't stated clear enough.
Quote 4.4.7 Setting Up a Table Maintenance Regimen ---------- You should also check your tables regularly during normal system operation. At MySQL AB, we run a cron job to check all our important tables once a week, using a line like this in a `crontab' file: 35 0 * * 0 /path/to/myisamchk --fast --silent /path/to/datadir/*/*.MYI This prints out information about crashed tables so we can examine and repair them when needed. As we haven't had any unexpectedly crashed tables (tables that become corrupted for reasons other than hardware trouble) for a couple of years now (this is really true), once a week is more than enough for us. We recommend that to start with, you execute myisamchk -s each night on all tables that have been updated during the last 24 hours, until you come to trust MySQL as much as we do. ---------- Regardless of any warnings on other documentation pages, I see no "FLUSH TABLES" happening here. That looks like a recomended procedure to me. Is there additional "hidden" documentation that should be part of this? We are looking at all the options at this time. And I am sad to tell you that one of our servers is still running 3.23.32 (which does not have CHECK TABLE). We will be upgrading it, some people are under the notion, if its not broken, don't fix it and possibly introduce other bugs that crop up. Why, because its happened before on other servers :) Also, I want to make darn sure about what the possible outcomes of this would be. Someone went forward with running myisamchk on a daily basis. I want to know if we have possibly broken something. I am not fighting to use any particular method at this time :) What my suggestion was, was to use a "PROCESS" permitted user and run these "CHECK TABLE" from the command line. The problem with "CHECK TABLE" that I can see? Thats a large process to check multiple databases with 20 or 30 tables each. myisamchk is a great deal more easier to use. -----Original Message----- From: Paul DuBois [mailto:[EMAIL PROTECTED] Sent: Thursday, August 21, 2003 5:00 PM To: Luc Foisy; MYSQL-List (E-mail) Subject: RE: myisamchk question (important) At 16:32 -0400 8/21/03, Luc Foisy wrote: >Thank you Paul. >whew! So just checking will not do anything to the database, in an case? >I am not really caring if it returns the "# users still connected/ >or table not closed right" warning. I am not really looking for that. >I am looking for warnings telling my that tables are corrupted... Well, the thing is, if you don't tell the server to flush changes, I believe there may be partially flushed changes that can cause myisamchk to get confused and believe that there is corruption. I don't recall that I have ever seen this in practice when trying to see what breaks by performing this unrecommended procedure :-) -- but I'm reluctant to say that it can *never* happen. Any reason not to use CHECK TABLE? You may find it a better alternative. > > > >-----Original Message----- >From: Paul DuBois [mailto:[EMAIL PROTECTED] >Sent: Thursday, August 21, 2003 3:08 PM >To: Luc Foisy; MYSQL-List (E-mail) >Subject: RE: myisamchk question (important) > > >I should qualify my answer, to indicate something that may not apply >to the situation you have in mind. > >If you're using myisamchk only to *check* tables, it operates in read-only >fashion. The problems occur if you're using it to repair tables, because >then if you have both myisamchk and the server writing to the table >files, you're not going to like the results. > >However, even with checking, if you don't flush the tables, you >may see spurious warnings of inconsistencies. (Due to unflushed changes, >for example.) These do not result in table damage. > >At 14:37 -0400 8/21/03, Luc Foisy wrote: >>If you read http://www.mysql.com/doc/en/Maintenance_regimen.html >>they say something interesting that would contracdict other places >>in the documentation >>They actually recomend running myisamchk on a running instance of >>mysqld. The method on that page (a method they use themselves) would >>not even allow a flush tables to be called before. >> >>Strange... How many answers can I find to this, does anyone know? >>I have several conflicting sources now >> >>-----Original Message----- >>From: Paul DuBois [mailto:[EMAIL PROTECTED] >>Sent: Wednesday, August 20, 2003 10:06 PM >>To: Luc Foisy; MYSQL-List (E-mail) >>Subject: Re: myisamchk question (important) >> >> >>At 9:54 -0400 8/19/03, Luc Foisy wrote: >>>Would anything happen to the database if I ran "myisamchk --silent >>>/usr/data/mysql/*/*.MYI" when I havent run "FLUSH TABLES" first? >> >>Yes, you may have unflushed changes still in the server's buffers. >>Running myisamchk in that case can make the tables *in*consistent >>because the tables won't have in them what the server thinks. >> >>Don't do it. >> >>> >>>As it states in the documentation: >>>If mysqld is running, you must force a sync/close of all tables with >>>FLUSH TABLES and ensure that no one is using the tables while you >>>are running myisamchk. In MySQL Version 3.23 the easiest way to >>>avoid this problem is to use CHECK TABLE instead of myisamchk to >>>check tables. >>> >>>Or is that only to avoid seeing: >>>myisamchk: warning: 1 clients is using or hasn't closed the table properly >>> > >>Its very important that I get an answer soon... Please and Thank you -- Paul DuBois, Senior Technical Writer Madison, Wisconsin, USA MySQL AB, www.mysql.com Are you MySQL certified? http://www.mysql.com/certification/ -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
