problems upgrading from 4.0 to 4.1 with TIMESTAMPS
Hi! I'm a hosting provider with several thousands of Mysql Databases under 4.0 version. I'm specially worried about TIMESTAMP format changes you did in 4.1. I'll have to update database server soon to have my systems updated. I think that if i update my server version thousands of tables are going to have problems with TIMESTAMP types. I was looking for solutions as to put +0 when selecting TIMESTAMP fields. But I can't imagine to change that in thousands lines of PHP code by hand, I'm sure lots of my customers will have no idea about how to fix that mistake so I'll have to fix their PHP code!. I'm almost sure that all ISP hosting providers are having or will have this problem soon. Anyone have a good idea to upgrade servers to 4.1? Do you think that should I update my servers, wait for a better solution in another version... What do you think I must to do? _ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: Problems upgrading from 4.0 to 4.1
Hi! On Apr 11, Christian Hammers wrote: > Hello Sergei > > On Thu, Apr 07, 2005 at 03:14:10PM +0200, Sergei Golubchik wrote: > > > I've just run into deep troubles while upgrading from 4.0.24 to 4.1.10a > > > using precomiled Debian packages on Debian Woody although I read the > > > comments regarding upgrading on dev.mysql.com. > > > > > After starting the new server and running "mysqlcheck -r -v -A", I > > > experienced the following problems on about 15% of my tables (seemed > > > to be quite random, i.e. not only the biggest or most used ones): > > > > Christian, do you have any of that tables ? Can you upload one of them > > (preferably, the smallest one) to our ftp ? > > > > > beta_hardware_verwaltung.hardware_log > > > info : Found wrong packed record at 0 > > > info : Found wrong packed record at 56 > > > info : Found wrong packed record at 112 > > Did you found the files on the incoming/ dir and do you have any news on > this case? If it's not something extremly stupid from my side, can you > open a bug report to make the issue easier to track? Yes, I found the file and repeated this problem, thanks. I opened a bugreport #9824 for it. about "15% of my tables (seemed be quite random" - it happens on the tables that have live checksum enabled (CHECKUM=1 in CREATE TABLE). workarounds - disable checksum (in 4.0, before upgrade) or copy the table with create ... select. Regards, Sergei -- __ ___ ___ __ / |/ /_ __/ __/ __ \/ / Sergei Golubchik <[EMAIL PROTECTED]> / /|_/ / // /\ \/ /_/ / /__ MySQL AB, Senior Software Developer /_/ /_/\_, /___/\___\_\___/ Osnabrueck, Germany <___/ www.mysql.com -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: Problems upgrading from 4.0 to 4.1
Hello Sergei On Thu, Apr 07, 2005 at 03:14:10PM +0200, Sergei Golubchik wrote: > > I've just run into deep troubles while upgrading from 4.0.24 to 4.1.10a > > using precomiled Debian packages on Debian Woody although I read the > > comments regarding upgrading on dev.mysql.com. > > > After starting the new server and running "mysqlcheck -r -v -A", I > > experienced the following problems on about 15% of my tables (seemed > > to be quite random, i.e. not only the biggest or most used ones): > > Christian, do you have any of that tables ? Can you upload one of them > (preferably, the smallest one) to our ftp ? > > > beta_hardware_verwaltung.hardware_log > > info : Found wrong packed record at 0 > > info : Found wrong packed record at 56 > > info : Found wrong packed record at 112 Did you found the files on the incoming/ dir and do you have any news on this case? If it's not something extremly stupid from my side, can you open a bug report to make the issue easier to track? bye, -christian- -- Christian Hammers WESTEND GmbH | Internet-Business-Provider Technik CISCO Systems Partner - Authorized Reseller Lütticher Straße 10 Tel 0241/701333-11 ch@westend.comD-52064 Aachen Fax 0241/911879 -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: Problems upgrading from 4.0 to 4.1
Hello Sergei On Thu, Apr 07, 2005 at 03:14:10PM +0200, Sergei Golubchik wrote: > > I've just run into deep troubles while upgrading from 4.0.24 to 4.1.10a > > using precomiled Debian packages on Debian Woody although I read the > > comments regarding upgrading on dev.mysql.com. > > > After starting the new server and running "mysqlcheck -r -v -A", I > > experienced the following problems on about 15% of my tables (seemed > > to be quite random, i.e. not only the biggest or most used ones): > > Christian, do you have any of that tables ? Can you upload one of them > (preferably, the smallest one) to our ftp ? I've uploaded the file into your write-only ftp.mysql.com:/pub/mysql/upload/ directory as Christian_Hammers_Tablecorruption_40to41.tar.gz The included table is correct according to a CHECK TABLE with MySQL-4.0.24 but reproducible gets emptied during a REPAIR TABLE on MySQL-4.1.10a. bye, -christian- -- Christian Hammers WESTEND GmbH | Internet-Business-Provider Technik CISCO Systems Partner - Authorized Reseller Lütticher Straße 10 Tel 0241/701333-11 ch@westend.comD-52064 Aachen Fax 0241/911879 -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Problems upgrading from 4.0 to 4.1
Hello I've just run into deep troubles while upgrading from 4.0.24 to 4.1.10a using precomiled Debian packages on Debian Woody although I read the comments regarding upgrading on dev.mysql.com. After starting the new server and running "mysqlcheck -r -v -A", I experienced the following problems on about 15% of my tables (seemed to be quite random, i.e. not only the biggest or most used ones): beta_hardware_verwaltung.hardware_log info : Found wrong packed record at 0 info : Found wrong packed record at 56 info : Found wrong packed record at 112 info : Found wrong packed record at 168 info : Found wrong packed record at 244 ... info : Found block that points outside data file at 47476 info : Found wrong packed record at 47736 info : Found block with too small length at 47748; Skipped info : Found wrong packed record at 48020 ... warning : Number of rows changed from 883 to 4 status : OK Luckily I made dumps before. Interesting to see was, that I could copy a table with /bin/cp still do a "SELECT *" from it but it, too, got emptied by a REPAIR statement. In the incompatibility list in the documentation some cases are mentioned where one has to do a REPAIR. But in which cases a repair does have such problems? Of course I did do a CHECK TABLE on all tables before upgrading, and I never used something different than latin1 nor table sizes near 4GB. All tables were checked and dumped on a regular basis without problems. After recreating them I had no further problems so far. bye, -christian- -- Christian Hammers WESTEND GmbH | Internet-Business-Provider Technik CISCO Systems Partner - Authorized Reseller Lütticher Straße 10 Tel 0241/701333-11 ch@westend.comD-52064 Aachen Fax 0241/911879 -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
