RE: crash
At 01:23 AM 2/13/2008, you wrote: Unfortuantely the server crashed and I had to manually boost it It happened before and I would like to know why so it doesn't again I don't have any innodb database on the system, only mysiam So why not disable InnoDb in my.cnf by uncommenting skip-innodb? It will free up some memory. Do you think adding ram might help ? How much ram do you have now? If you are accessing a lot of merge tables or large tables (millions of rows), then adding more ram will certainly help especially if you are only using 1-2gb. Mike From: Krishna Chandra Prajapati [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 13, 2008 8:05 AM To: Eli Shemer Subject: Re: crash Hi, The below information shows that innodb data get crashed and then started the recovery of data. During recovery of data there was a memory shortage (Out of memory). At last recovery gets completed. Thanks, Prajapati On Feb 13, 2008 12:44 AM, Eli Shemer HYPERLINK mailto:[EMAIL PROTECTED][EMAIL PROTECTED] wrote: Can someone explain this? Thanks. 080212 15:54:39 mysqld started 080212 15:54:39 InnoDB: Started; log sequence number 0 43743 080212 15:54:40 [Note] /usr/libexec/mysqld: ready for connections. Version: '5.0.54-log' socket: '/var/lib/mysql/mysql.sock' port: 3306 Source distribution Number of processes running now: 0 080212 17:23:24 mysqld restarted 080212 17:23:25 InnoDB: Started; log sequence number 0 43743 080212 17:23:25 [Note] Recovering after a crash using mysql-bin 080212 17:23:25 [Note] Starting crash recovery... 080212 17:23:25 [Note] Crash recovery finished. /usr/libexec/mysqld: Out of memory (Needed 463827968 bytes) /usr/libexec/mysqld: Out of memory (Needed 347870208 bytes) /usr/libexec/mysqld: Out of memory (Needed 260901888 bytes) /usr/libexec/mysqld: Out of memory (Needed 195674112 bytes) /usr/libexec/mysqld: Out of memory (Needed 146755584 bytes) 080212 17:23:26 [Note] /usr/libexec/mysqld: ready for connections. Version: '5.0.54-log' socket: '/var/lib/mysql/mysql.sock' port: 3306 Source distribution Number of processes running now: 0 080212 20:45:03 mysqld restarted 080212 20:45:04 InnoDB: Started; log sequence number 0 43743 080212 20:45:04 [Note] Recovering after a crash using mysql-bin 080212 20:45:08 mysqld ended 080212 21:08:21 mysqld started 080212 21:08:22 InnoDB: Started; log sequence number 0 43743 080212 21:08:22 [Note] Recovering after a crash using mysql-bin 080212 21:08:23 [Note] Starting crash recovery... 080212 21:08:23 [Note] Crash recovery finished. 080212 21:08:23 [Note] /usr/libexec/mysqld: ready for connections. Version: '5.0.54-log' socket: '/var/lib/mysql/mysql.sock' port: 3306 Source distribution [EMAIL PROTECTED] ~]# date Tue Feb 12 21:09:19 IST 2008 [EMAIL PROTECTED] ~]# Internal Virus Database is out-of-date. Checked by AVG Free Edition. Version: 7.5.503 / Virus Database: 269.16.4/1146 - Release Date: 22/11/2007 18:55 -- Krishna Chandra Prajapati MySQL DBA, Ed Ventures e-Learning Pvt.Ltd. 1-8-303/48/15, Sindhi Colony P.G.Road, Secunderabad. Pin Code: 53 Office Number: 040-66489771 Mob: 9912924044 URL: HYPERLINK http://ed-ventures-online.comed-ventures-online.com Email-id: HYPERLINK mailto:[EMAIL PROTECTED][EMAIL PROTECTED] Internal Virus Database is out-of-date. Checked by AVG Free Edition. Version: 7.5.503 / Virus Database: 269.16.4/1146 - Release Date: 22/11/2007 18:55 Internal Virus Database is out-of-date. Checked by AVG Free Edition. Version: 7.5.503 / Virus Database: 269.16.4/1146 - Release Date: 22/11/2007 18:55 -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: view irregularities
Lev Lvovsky wrote: I'm running into a difficult to reproduce problem with a view which is similar to the following: CREATE TABLE Common ( COMMON_ID INT UNSIGNED AUTO_INCREMENT PRIMARY KEY, COMMON_NAME VARCHAR(50), UNIQUE(COMMON_NAME) ) ENGINE = InnoDB; CREATE TABLE Parent ( PARENT_ID VARCHAR(50) NOT NULL, PARENT_NAME VARCHAR(50) NOT NULL, PARENT_COMMON_ID INT UNSIGNED, PRIMARY KEY (PARENT_ID, PARENT_COMMON_ID), FOREIGN KEY (PARENT_COMMON_ID) REFERENCES Common(COMMON_ID) ) ENGINE = InnoDB; CREATE TABLE Child ( CHILD_IDBINARY(20) NOT NULL PRIMARY KEY, PARENT_ID VARCHAR(50) NOT NULL, CHILD_NAME VARCHAR(50), CHILD_COMMON_ID INT UNSIGNED, FOREIGN KEY (PARENT_ID) REFERENCES Parent(PARENT_ID), FOREIGN KEY (CHILD_COMMON_ID) REFERENCES Common(COMMON_ID) ) ENGINE = InnoDB; DROP VIEW IF EXISTS BrokenView; CREATE VIEW BrokenView AS SELECT Child.* FROM Child LEFT JOIN Parent USING(PARENT_ID) WHERE Child.CHILD_COMMON_ID = Parent.PARENT_COMMON_ID; DROP VIEW IF EXISTS WorkingView; CREATE VIEW WorkingView AS SELECT Child.*, Parent.PARENT_NAME, Parent.PARENT_COMMON_ID FROM Child LEFT JOIN Parent ON (Child.PARENT_ID = Parent.PARENT_ID AND Child.CHILD_COMMON_ID = Parent.PARENT_COMMON_ID); Though the example cited above does not cause the problems that I'm running into, the table structure is similar. Specifically the fact that I'm doing a WHERE ... in the BrokenView vs WorkingView is seemingly the difference between getting rows returned and not. And this is exactly the cause of your problems. When you build a query that optionally includes a table, you get your results back in stages. The one stage of the query takes your LEFT JOIN and builds a list of matching rows. A later stage evaluates the terms in your WHERE clause. In this case in order to evaluate the WHERE clause, you force the existence of the rows from the `Parent` table just as if you had written an INNER JOIN. If there were no rows (no values) from the `Parent` table then the WHERE clause will evaluate as FALSE and those rows will not be returned. By putting both terms into the ON clause of your LEFT JOIN, you make it possible to have non-matched rows in your final result. -- Shawn Green, Support Engineer MySQL Inc., USA, www.mysql.com Office: Blountville, TN __ ___ ___ __ / |/ /_ __/ __/ __ \/ / / /|_/ / // /\ \/ /_/ / /__ /_/ /_/\_, /___/\___\_\___/ ___/ Join the Quality Contribution Program Today! http://dev.mysql.com/qualitycontribution.html -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
RE: Crashed InnoDB
No input on this one? -Original Message- From: Bryan Cantwell [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 12, 2008 11:51 AM To: mysql@lists.mysql.com Subject: Crashed InnoDB We had a power outage, now the mysql wont start at all. Here is the err file output... Any help on how to recover? 080212 11:35:50 mysqld started 080212 11:35:50 InnoDB: Database was not shut down normally! InnoDB: Starting crash recovery. InnoDB: Reading tablespace information from the .ibd files... InnoDB: Restoring possible half-written data pages from the doublewrite InnoDB: buffer... 080212 11:35:50 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 115 2637413615. InnoDB: Doing recovery: scanned up to log sequence number 115 2637626081 080212 11:35:50 InnoDB: Starting an apply batch of log records to the database... InnoDB: Progress in percents: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 080212 11:35:51 - mysqld got signal 11; This could be because you hit a bug. It is also possible that this binary or one of the libraries it was linked against is corrupt, improperly built, or misconfigured. This error can also be caused by malfunctioning hardware. We will try our best to scrape up some info that will hopefully help diagnose the problem, but since we have already crashed, something is definitely wrong and this may fail. key_buffer_size=0 read_buffer_size=2093056 max_used_connections=0 max_connections=2500 threads_connected=0 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 3012828 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=(nil) Attempting backtrace. You can use the following information to find out where mysqld died. If you see no messages after this, something went terribly wrong... Cannot determine thread, fp=0xbf3feaf8, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x80d4205 0x835537c 0x82c8b43 0x82c97dc 0x8294835 0x8295489 0x82851fd 0x82b02cd 0x8203f89 0x834fcb5 0x8388daa New value of fp=(nil) failed sanity check, terminating stack trace! Please read http://dev.mysql.com/doc/mysql/en/using-stack-trace.html and follow instructions on how to resolve the stack trace. Resolved stack trace is much more helpful in diagnosing the problem, so please do resolve it The manual page at http://www.mysql.com/doc/en/Crashing.html contains information that should help you find out what is causing the crash. You are running a statically-linked LinuxThreads binary on an NPTL system. This can result in crashes on some distributions due to LT/NPTL conflicts. You should either build a dynamically-linked binary, or force LinuxThreads to be used with the LD_ASSUME_KERNEL environment variable. Please consult the documentation for your distribution on how to do that. 080212 11:35:51 mysqld ended
Re: Crashed InnoDB
Have you tried starting mysqld with innodb_force_recovery = x ? (where x = values defined below) http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html That might get you past the corruption that's killing startup. -Dan On 2/13/08 12:32 PM, Bryan Cantwell [EMAIL PROTECTED] wrote: No input on this one? -Original Message- From: Bryan Cantwell [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 12, 2008 11:51 AM To: mysql@lists.mysql.com Subject: Crashed InnoDB We had a power outage, now the mysql wont start at all. Here is the err file output... Any help on how to recover? 080212 11:35:50 mysqld started 080212 11:35:50 InnoDB: Database was not shut down normally! InnoDB: Starting crash recovery. InnoDB: Reading tablespace information from the .ibd files... InnoDB: Restoring possible half-written data pages from the doublewrite InnoDB: buffer... 080212 11:35:50 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 115 2637413615. InnoDB: Doing recovery: scanned up to log sequence number 115 2637626081 080212 11:35:50 InnoDB: Starting an apply batch of log records to the database... InnoDB: Progress in percents: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 080212 11:35:51 - mysqld got signal 11; This could be because you hit a bug. It is also possible that this binary or one of the libraries it was linked against is corrupt, improperly built, or misconfigured. This error can also be caused by malfunctioning hardware. We will try our best to scrape up some info that will hopefully help diagnose the problem, but since we have already crashed, something is definitely wrong and this may fail. key_buffer_size=0 read_buffer_size=2093056 max_used_connections=0 max_connections=2500 threads_connected=0 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 3012828 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=(nil) Attempting backtrace. You can use the following information to find out where mysqld died. If you see no messages after this, something went terribly wrong... Cannot determine thread, fp=0xbf3feaf8, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x80d4205 0x835537c 0x82c8b43 0x82c97dc 0x8294835 0x8295489 0x82851fd 0x82b02cd 0x8203f89 0x834fcb5 0x8388daa New value of fp=(nil) failed sanity check, terminating stack trace! Please read http://dev.mysql.com/doc/mysql/en/using-stack-trace.html and follow instructions on how to resolve the stack trace. Resolved stack trace is much more helpful in diagnosing the problem, so please do resolve it The manual page at http://www.mysql.com/doc/en/Crashing.html contains information that should help you find out what is causing the crash. You are running a statically-linked LinuxThreads binary on an NPTL system. This can result in crashes on some distributions due to LT/NPTL conflicts. You should either build a dynamically-linked binary, or force LinuxThreads to be used with the LD_ASSUME_KERNEL environment variable. Please consult the documentation for your distribution on how to do that. 080212 11:35:51 mysqld ended
RE: Crashed InnoDB
I can get mysql to start with that but still complains about corruption... If I try to do optimize table for instance, it crashes again... I get this now: 080213 14:32:16 InnoDB: Error: page 4246078 log sequence number 53 188440667 InnoDB: is in the future! Current system log sequence number 0 10477. InnoDB: Your database may be corrupt or you may have copied the InnoDB InnoDB: tablespace but not the InnoDB log files. See InnoDB: http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html InnoDB: for more information. InnoDB: Dump of the tablespace extent descriptor: len 40; hex 00010040caee0004 aafe; asc @ ; InnoDB: Serious error! InnoDB is trying to free page 4246077 InnoDB: though it is already marked as free in the tablespace! InnoDB: The tablespace free space info is corrupt. InnoDB: You may need to dump your InnoDB tables and recreate the whole InnoDB: database! InnoDB: Please refer to InnoDB: http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html InnoDB: about forcing recovery. 080213 14:32:16InnoDB: Assertion failure in thread 163851 in file fsp0fsp.c line 2980 InnoDB: We intentionally generate a memory trap. InnoDB: Submit a detailed bug report to http://bugs.mysql.com. InnoDB: If you get repeated assertion failures or crashes, even InnoDB: immediately after the mysqld startup, there may be InnoDB: corruption in the InnoDB tablespace. Please refer to InnoDB: http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html InnoDB: about forcing recovery. 080213 14:32:16 - mysqld got signal 11; This could be because you hit a bug. It is also possible that this binary or one of the libraries it was linked against is corrupt, improperly built, or misconfigured. This error can also be caused by malfunctioning hardware. We will try our best to scrape up some info that will hopefully help diagnose the problem, but since we have already crashed, something is definitely wrong and this may fail. key_buffer_size=1073741824 read_buffer_size=2093056 max_used_connections=1 max_connections=2500 threads_connected=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 4061404 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0xac68930 Attempting backtrace. You can use the following information to find out where mysqld died. If you see no messages after this, something went terribly wrong... Cannot determine thread, fp=0xbe5f9f88, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x80d4205 0x835537c 0x829e8ca 0x8220478 0x829e2c1 0x829e5b1 0x824d6d9 0x8208702 0x821c16a 0x823077e 0x819f81c 0x81a00d7 0x8193cea 0x8178a32 0x81acb2b 0x81ae855 0x81b0787 0x81b1282 0x81b19f8 0x80f16ea 0x80f359a 0x80f46cb 0x80f5747 0x834fcb5 0x8388daa New value of fp=(nil) failed sanity check, terminating stack trace! Please read http://dev.mysql.com/doc/mysql/en/using-stack-trace.html and follow instructions on how to resolve the stack trace. Resolved stack trace is much more helpful in diagnosing the problem, so please do resolve it Trying to get some variables. Some pointers may be invalid and cause the dump to abort... thd-query at 0xaca10c8 = optimize table hosts thd-thread_id=2 The manual page at http://www.mysql.com/doc/en/Crashing.html contains information that should help you find out what is causing the crash. You are running a statically-linked LinuxThreads binary on an NPTL system. This can result in crashes on some distributions due to LT/NPTL conflicts. You should either build a dynamically-linked binary, or force LinuxThreads to be used with the LD_ASSUME_KERNEL environment variable. Please consult the documentation for your distribution on how to do that. Number of processes running now: 0 From: Dan Rogart [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 13, 2008 12:27 PM To: Bryan Cantwell; mysql list Subject: Re: Crashed InnoDB Have you tried starting mysqld with innodb_force_recovery = x ? (where x = values defined below) http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html That might get you past the corruption that's killing startup. -Dan On 2/13/08 12:32 PM, Bryan Cantwell [EMAIL PROTECTED] wrote: No input on this one? -Original Message- From: Bryan Cantwell [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 12, 2008 11:51 AM To: mysql@lists.mysql.com Subject: Crashed InnoDB We had a power outage, now the mysql wont start at all. Here is the err file output... Any help on how to recover? 080212 11:35:50 mysqld started 080212 11:35:50 InnoDB: Database was not shut down normally! InnoDB: Starting crash recovery. InnoDB: Reading tablespace information from the .ibd files... InnoDB: Restoring possible half-written data pages from the
Re: Crashed InnoDB
Does it start up in a stable enough state to run a mysqldump of the tables? -Dan On 2/13/08 3:54 PM, Bryan Cantwell [EMAIL PROTECTED] wrote: I can get mysql to start with that but still complains about corruption If I try to do optimize table for instance, it crashes again I get this now: 080213 14:32:16 InnoDB: Error: page 4246078 log sequence number 53 188440667 InnoDB: is in the future! Current system log sequence number 0 10477. InnoDB: Your database may be corrupt or you may have copied the InnoDB InnoDB: tablespace but not the InnoDB log files. See InnoDB: http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html InnoDB: for more information. InnoDB: Dump of the tablespace extent descriptor: len 40; hex 00010040caee0004aa fe; asc @ ; InnoDB: Serious error! InnoDB is trying to free page 4246077 InnoDB: though it is already marked as free in the tablespace! InnoDB: The tablespace free space info is corrupt. InnoDB: You may need to dump your InnoDB tables and recreate the whole InnoDB: database! InnoDB: Please refer to InnoDB: http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html InnoDB: about forcing recovery. 080213 14:32:16InnoDB: Assertion failure in thread 163851 in file fsp0fsp.c line 2980 InnoDB: We intentionally generate a memory trap. InnoDB: Submit a detailed bug report to http://bugs.mysql.com. InnoDB: If you get repeated assertion failures or crashes, even InnoDB: immediately after the mysqld startup, there may be InnoDB: corruption in the InnoDB tablespace. Please refer to InnoDB: http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html InnoDB: about forcing recovery. 080213 14:32:16 - mysqld got signal 11; This could be because you hit a bug. It is also possible that this binary or one of the libraries it was linked against is corrupt, improperly built, or misconfigured. This error can also be caused by malfunctioning hardware. We will try our best to scrape up some info that will hopefully help diagnose the problem, but since we have already crashed, something is definitely wrong and this may fail. key_buffer_size=1073741824 read_buffer_size=2093056 max_used_connections=1 max_connections=2500 threads_connected=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 4061404 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0xac68930 Attempting backtrace. You can use the following information to find out where mysqld died. If you see no messages after this, something went terribly wrong... Cannot determine thread, fp=0xbe5f9f88, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x80d4205 0x835537c 0x829e8ca 0x8220478 0x829e2c1 0x829e5b1 0x824d6d9 0x8208702 0x821c16a 0x823077e 0x819f81c 0x81a00d7 0x8193cea 0x8178a32 0x81acb2b 0x81ae855 0x81b0787 0x81b1282 0x81b19f8 0x80f16ea 0x80f359a 0x80f46cb 0x80f5747 0x834fcb5 0x8388daa New value of fp=(nil) failed sanity check, terminating stack trace! Please read http://dev.mysql.com/doc/mysql/en/using-stack-trace.html and follow instructions on how to resolve the stack trace. Resolved stack trace is much more helpful in diagnosing the problem, so please do resolve it Trying to get some variables. Some pointers may be invalid and cause the dump to abort... thd-query at 0xaca10c8 = optimize table hosts thd-thread_id=2 The manual page at http://www.mysql.com/doc/en/Crashing.html contains information that should help you find out what is causing the crash. You are running a statically-linked LinuxThreads binary on an NPTL system. This can result in crashes on some distributions due to LT/NPTL conflicts. You should either build a dynamically-linked binary, or force LinuxThreads to be used with the LD_ASSUME_KERNEL environment variable. Please consult the documentation for your distribution on how to do that. Number of processes running now: 0 From: Dan Rogart [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 13, 2008 12:27 PM To: Bryan Cantwell; mysql list Subject: Re: Crashed InnoDB Have you tried starting mysqld with innodb_force_recovery = x ? (where x = values defined below) http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html That might get you past the corruption that's killing startup. -Dan On 2/13/08 12:32 PM, Bryan Cantwell [EMAIL PROTECTED] wrote: No input on this one? -Original Message- From: Bryan Cantwell [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 12, 2008 11:51 AM To: mysql@lists.mysql.com Subject: Crashed InnoDB We had a power outage, now the mysql wont start at all. Here is the err file output... Any help on how to recover? 080212 11:35:50 mysqld started 080212 11:35:50 InnoDB: Database was not shut
MySQL 5.1.23-rc has been released (part 2)
Dear MySQL users, We are proud to present to you the MySQL Server 5.1.23-rc release, a new release candidate version of the popular open source database. Bear in mind that this is still a candidate release, and as with any other pre-production release, caution should be taken when installing on production level systems or systems with critical data. For production level systems using 5.0, we would like to direct your attention to the product description of MySQL Enterprise at: http://mysql.com/products/enterprise/ The MySQL 5.1.23-rc release is now available in source and binary form for a number of platforms from our download pages at http://dev.mysql.com/downloads/ and mirror sites. Note that not all mirror sites may be up to date at this point in time, so if you can't find this version on some mirror, please try again later or choose another download site. Please also note that some of our mirrors are currently experiencing problems that may result in serving corrupted files. We are working with the mirror maintainers to resolve this. We welcome and appreciate your feedback, bug reports, bug fixes, patches etc.: http://forge.mysql.com/wiki/Contributing The description of the changes from version 5.1.22-rc to this 5.1.23-rc is some 1,800 lines long, that is about 96 kB. As some mail systems are bound to truncate long mail at 64 kB, I split the announcement into three parts - this is part 2 only. To ensure these important items do not get lost, I repeat the notes about functionality changes, the security fixes, and other changes labeled important. All these were also listed in part 1. If you want to skip this duplication, search for the text This ends the duplicated part. Following this, there is the next set of changes from version to version in the MySQL source code since the latest released version of MySQL 5.1, the MySQL 5.1.22-rc release. It can also be viewed online at http://dev.mysql.com/doc/refman/5.1/en/news-5-1-23.html Functionality added or changed: * Important Change: Partitioning: Security Fix: It was possible, by creating a partitioned table using the DATA DIRECTORY and INDEX DIRECTORY options to gain privileges on other tables having the same name as the partitioned table. As a result of this fix, any table-level DATA DIRECTORY or INDEX DIRECTORY options are now ignored for partitioned tables. (Bug#32091: http://bugs.mysql.com/32091, CVE-2007-5970 (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5970)) See also Bug#29325: http://bugs.mysql.com/29325, Bug#32111: http://bugs.mysql.com/32111 * Incompatible Change: In MySQL 5.1.6, when log tables were implemented, the default log destination for the general query and slow query log was TABLE. This default has been changed to FILE, which is compatible with MySQL 5.0, but incompatible with earlier releases of MySQL 5.1 from 5.1.6 to 5.1.20. If you are upgrading from MySQL 5.0 to this release, no logging option changes should be necessary. However, if you are upgrading from 5.1.6 through 5.1.20 to this release and were using TABLE logging, use the --log-output=TABLE option explicitly to preserve your server's table-logging behavior. In MySQL 5.1.x, this bug was addressed twice because it turned out that the default was set in two places, only one of which was fixed the first time. (Bug#29993: http://bugs.mysql.com/29993) * Incompatible Change The parser accepted statements that contained /* ... */ that were not properly closed with */, such as SELECT 1 /* + 2. Statements that contain unclosed /*-comments now are rejected with a syntax error. This fix has the potential to cause incompatibilities. Because of Bug#26302: http://bugs.mysql.com/26302, which caused the trailing */ to be truncated from comments in views, stored routines, triggers, and events, it is possible that objects of those types may have been stored with definitions that now will be rejected as syntactically invalid. Such objects should be dropped and re-created so that their definitions do not contain truncated comments. (Bug#28779: http://bugs.mysql.com/28779) * MySQL Cluster: The following improvements have been made in the ndb_size.pl utility: + The script can now be used with multiple databases; lists of databases and tables can also be excluded from analysis. + Schema name information has been added to index table calculations. + The database name is now an optional parameter, the exclusion of which causes all databases to be examined. + If selecting from INFORMATION_SCHEMA fails, the script now attempts to fall back to SHOW TABLES. + A --real_table_name option has been added; this designates a table to handle unique index size
MySQL 5.1.23-rc has been released (part 1)
Dear MySQL users, We are proud to present to you the MySQL Server 5.1.23-rc release, a new release candidate version of the popular open source database. Bear in mind that this is still a candidate release, and as with any other pre-production release, caution should be taken when installing on production level systems or systems with critical data. For production level systems using 5.0, we would like to direct your attention to the product description of MySQL Enterprise at: http://mysql.com/products/enterprise/ The MySQL 5.1.23-rc release is now available in source and binary form for a number of platforms from our download pages at http://dev.mysql.com/downloads/ and mirror sites. Note that not all mirror sites may be up to date at this point in time, so if you can't find this version on some mirror, please try again later or choose another download site. Please also note that some of our mirrors are currently experiencing problems that may result in serving corrupted files. We are working with the mirror maintainers to resolve this. We welcome and appreciate your feedback, bug reports, bug fixes, patches etc.: http://forge.mysql.com/wiki/Contributing The description of the changes from version 5.1.22-rc to this 5.1.23-rc is some 1,800 lines long, that is about 96 kB. As some mail systems are bound to truncate long mail at 64 kB, I split the announcement into two parts - this is part 1 only. The following section lists the (first part of the) changes from version to version in the MySQL source code since the latest released version of MySQL 5.1, the MySQL 5.1.22-rc release. It can also be viewed online at http://dev.mysql.com/doc/refman/5.1/en/news-5-1-23.html Functionality added or changed: * Important Change: Partitioning: Security Fix: It was possible, by creating a partitioned table using the DATA DIRECTORY and INDEX DIRECTORY options to gain privileges on other tables having the same name as the partitioned table. As a result of this fix, any table-level DATA DIRECTORY or INDEX DIRECTORY options are now ignored for partitioned tables. (Bug#32091: http://bugs.mysql.com/32091, CVE-2007-5970 (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5970)) See also Bug#29325: http://bugs.mysql.com/29325, Bug#32111: http://bugs.mysql.com/32111 * Incompatible Change: In MySQL 5.1.6, when log tables were implemented, the default log destination for the general query and slow query log was TABLE. This default has been changed to FILE, which is compatible with MySQL 5.0, but incompatible with earlier releases of MySQL 5.1 from 5.1.6 to 5.1.20. If you are upgrading from MySQL 5.0 to this release, no logging option changes should be necessary. However, if you are upgrading from 5.1.6 through 5.1.20 to this release and were using TABLE logging, use the --log-output=TABLE option explicitly to preserve your server's table-logging behavior. In MySQL 5.1.x, this bug was addressed twice because it turned out that the default was set in two places, only one of which was fixed the first time. (Bug#29993: http://bugs.mysql.com/29993) * Incompatible Change The parser accepted statements that contained /* ... */ that were not properly closed with */, such as SELECT 1 /* + 2. Statements that contain unclosed /*-comments now are rejected with a syntax error. This fix has the potential to cause incompatibilities. Because of Bug#26302: http://bugs.mysql.com/26302, which caused the trailing */ to be truncated from comments in views, stored routines, triggers, and events, it is possible that objects of those types may have been stored with definitions that now will be rejected as syntactically invalid. Such objects should be dropped and re-created so that their definitions do not contain truncated comments. (Bug#28779: http://bugs.mysql.com/28779) * MySQL Cluster: The following improvements have been made in the ndb_size.pl utility: + The script can now be used with multiple databases; lists of databases and tables can also be excluded from analysis. + Schema name information has been added to index table calculations. + The database name is now an optional parameter, the exclusion of which causes all databases to be examined. + If selecting from INFORMATION_SCHEMA fails, the script now attempts to fall back to SHOW TABLES. + A --real_table_name option has been added; this designates a table to handle unique index size calculations. + The report title has been amended to cover cases where more than one database is being analyzed. Support for a --socket option was also added. For more information, see Section 15.9.15, ndb_size.pl --- NDBCluster Size Requirement Estimator.
MySQL 5.1.23-rc has been released (part 3)
Dear MySQL users, We are proud to present to you the MySQL Server 5.1.23-rc release, a new release candidate version of the popular open source database. Bear in mind that this is still a candidate release, and as with any other pre-production release, caution should be taken when installing on production level systems or systems with critical data. For production level systems using 5.0, we would like to direct your attention to the product description of MySQL Enterprise at: http://mysql.com/products/enterprise/ The MySQL 5.1.23-rc release is now available in source and binary form for a number of platforms from our download pages at http://dev.mysql.com/downloads/ and mirror sites. Note that not all mirror sites may be up to date at this point in time, so if you can't find this version on some mirror, please try again later or choose another download site. Please also note that some of our mirrors are currently experiencing problems that may result in serving corrupted files. We are working with the mirror maintainers to resolve this. We welcome and appreciate your feedback, bug reports, bug fixes, patches etc.: http://forge.mysql.com/wiki/Contributing The description of the changes from version 5.1.22-rc to this 5.1.23-rc is some 1,800 lines long, that is about 96 kB. As some mail systems are bound to truncate long mail at 64 kB, I split the announcement into three parts - this is part 3 only. To ensure these important items do not get lost, I repeat the notes about functionality changes, the security fixes, and other changes labeled important. All these were also listed in part 1 and 2. If you want to skip this duplication, search for the text This ends the duplicated part. Following this, there are the remaining changes from version to version in the MySQL source code since the latest released version of MySQL 5.1, the MySQL 5.1.22-rc release. It can also be viewed online at http://dev.mysql.com/doc/refman/5.1/en/news-5-1-23.html Functionality added or changed: * Important Change: Partitioning: Security Fix: It was possible, by creating a partitioned table using the DATA DIRECTORY and INDEX DIRECTORY options to gain privileges on other tables having the same name as the partitioned table. As a result of this fix, any table-level DATA DIRECTORY or INDEX DIRECTORY options are now ignored for partitioned tables. (Bug#32091: http://bugs.mysql.com/32091, CVE-2007-5970 (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5970)) See also Bug#29325: http://bugs.mysql.com/29325, Bug#32111: http://bugs.mysql.com/32111 * Incompatible Change: In MySQL 5.1.6, when log tables were implemented, the default log destination for the general query and slow query log was TABLE. This default has been changed to FILE, which is compatible with MySQL 5.0, but incompatible with earlier releases of MySQL 5.1 from 5.1.6 to 5.1.20. If you are upgrading from MySQL 5.0 to this release, no logging option changes should be necessary. However, if you are upgrading from 5.1.6 through 5.1.20 to this release and were using TABLE logging, use the --log-output=TABLE option explicitly to preserve your server's table-logging behavior. In MySQL 5.1.x, this bug was addressed twice because it turned out that the default was set in two places, only one of which was fixed the first time. (Bug#29993: http://bugs.mysql.com/29993) * Incompatible Change The parser accepted statements that contained /* ... */ that were not properly closed with */, such as SELECT 1 /* + 2. Statements that contain unclosed /*-comments now are rejected with a syntax error. This fix has the potential to cause incompatibilities. Because of Bug#26302: http://bugs.mysql.com/26302, which caused the trailing */ to be truncated from comments in views, stored routines, triggers, and events, it is possible that objects of those types may have been stored with definitions that now will be rejected as syntactically invalid. Such objects should be dropped and re-created so that their definitions do not contain truncated comments. (Bug#28779: http://bugs.mysql.com/28779) * MySQL Cluster: The following improvements have been made in the ndb_size.pl utility: + The script can now be used with multiple databases; lists of databases and tables can also be excluded from analysis. + Schema name information has been added to index table calculations. + The database name is now an optional parameter, the exclusion of which causes all databases to be examined. + If selecting from INFORMATION_SCHEMA fails, the script now attempts to fall back to SHOW TABLES. + A --real_table_name option has been added; this designates a table to handle unique index size
MS SQL emulator for MySQL in order to support MS Project Server, Sharepoint...
I apologize for asking this question. I am somewhat confused by Microsoft's Licensing and I personally can not justify to senior management why MS SQL should be procured instead of procuring software more urgent requirements. I had the not so bright idea that maybe a MS SQL emulator or compatibility mode existed for/in MySQL. Does such a beast exist? In particular, I wanted to use MySQL as backend database for MS Project Server and Sharepoint, and other applications that use MS SQL as their backend database. Again, I apologize for asking this question. I could not figure out the correct string to search for such software. thank you
RE: [SPAM] - MS SQL emulator for MySQL in order to support MS Project Server, Sharepoint... - Email found in subject
http://blogs.ittoolbox.com/km/sharepoint/archives/sharepoint-and-mysql-2 2051 hmm.. but I think you might have problems getting support from sharepoint's vendor... IIRC they always push to use SQL server for this.. (we know the reason why.. :) ) -Original Message- From: Jacob, Raymond A Jr [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 13, 2008 7:22 PM To: mysql@lists.mysql.com Subject: [SPAM] - MS SQL emulator for MySQL in order to support MS Project Server, Sharepoint... - Email found in subject I apologize for asking this question. I am somewhat confused by Microsoft's Licensing and I personally can not justify to senior management why MS SQL should be procured instead of procuring software more urgent requirements. I had the not so bright idea that maybe a MS SQL emulator or compatibility mode existed for/in MySQL. Does such a beast exist? In particular, I wanted to use MySQL as backend database for MS Project Server and Sharepoint, and other applications that use MS SQL as their backend database. Again, I apologize for asking this question. I could not figure out the correct string to search for such software. thank you This message and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom it is addressed. It may contain sensitive and private proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you are not the intended recipient, please immediately delete it and all copies of it from your system, destroy any hard copies of it and notify the sender. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. FXDirectDealer, LLC reserves the right to monitor all e-mail communications through its networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorized to state them. Unless otherwise stated, any pricing information given in this message is indicative only, is subject to change and does not constitute an offer to deal at any price quoted. Any reference to the terms of executed transactions should be treated as preliminary only and subject to our formal confirmation. FXDirectDealer, LLC is not responsible for any recommendation, solicitation, offer or agreement or any information about any transaction, customer account or account activity contained in this communication. -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
innodb crash
Hi List, I got crash when i was creating procedure and it listed the following error *** glibc detected *** /usr/local/mysql2/libexec/mysqld: corrupted double-linked list: 0x0b4ae810 *** === Backtrace: = /lib/libc.so.6[0x8949be] /lib/libc.so.6(cfree+0x90)[0x897fc0] /usr/lib/libstdc++.so.6(_ZdlPv+0x21)[0xb35671] /usr/local/mysql2/libexec/mysqld(_ZN20sp_instr_jump_if_notD0Ev+0x5d)[0x82c4e0d] /usr/local/mysql2/libexec/mysqld(_ZN7sp_head7destroyEv+0x2f)[0x82be99f] /usr/local/mysql2/libexec/mysqld(_ZN7sp_headD0Ev+0x20)[0x82c0e10] /usr/local/mysql2/libexec/mysqld(_Z11mysql_parseP3THDPKcjPS2_+0x286)[0x81ac6a6] /usr/local/mysql2/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x4db)[0x81acc6b] /usr/local/mysql2/libexec/mysqld(_Z10do_commandP3THD+0xa7)[0x81ae317] /usr/local/mysql2/libexec/mysqld(handle_one_connection+0x9fa)[0x81aee5a] /lib/libpthread.so.0[0x97b45b] /lib/libc.so.6(clone+0x5e)[0x8fc24e] I tried to start the server using the daemon path and i got the following errors 080213 16:37:26 [Warning] Ignoring user change to 'mysql2' because the user was set to 'mysql' earlier on the command line 080213 16:37:27 InnoDB: Operating system error number 13 in a file operation. InnoDB: The error means mysqld does not have the access rights to InnoDB: the directory. InnoDB: File name ./ibdata1 InnoDB: File operation call: 'open'. InnoDB: Cannot continue operation. Saravanan Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
memory usage - mysql tuning!!
Hi.. Fairly new to mysql, in particular tuning. I have a test mysql db, on a test server. I've got a test app that runs on multiple servers, with each test app, firing/accessing data from the central db server. the central server is on a 2GHz, 1GMem, 100G system. MySQL is the basic app. the remote/test apps are doing basic selects/inserts, with a few basic select.. group/order by. the db schema appears to be pretty straight forward, with primary/unique fields. keep in mind, i'm not a dba!!! the my.cnf file is pretty basic. there has been a modification for the key_buffer_table entry... my issue, is that when i examine the central mysql (show processlist) i see a number of connections (~10) with the majority being in a sleep status.. However, when i then check the OS, using top, i see that mysql is running, consuming ~ 80-90% of the cpu cycles... so, i'm trying to figure out how to diagnose/solve this issue. any pointers, comments, suggestions will be greatly appreciated. this instance of mysql, is 5.x, and is running on a virtual rhel5 os, under vmware... thanks -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: innodb crash
Check the permission on mysql database realted files, it shoud be owned by mysql user. regards anandkl On Feb 13, 2008 4:42 PM, Saravanan [EMAIL PROTECTED] wrote: Hi List, I got crash when i was creating procedure and it listed the following error *** glibc detected *** /usr/local/mysql2/libexec/mysqld: corrupted double-linked list: 0x0b4ae810 *** === Backtrace: = /lib/libc.so.6[0x8949be] /lib/libc.so.6(cfree+0x90)[0x897fc0] /usr/lib/libstdc++.so.6(_ZdlPv+0x21)[0xb35671] /usr/local/mysql2/libexec/mysqld(_ZN20sp_instr_jump_if_notD0Ev+0x5d)[0x82c4e0d] /usr/local/mysql2/libexec/mysqld(_ZN7sp_head7destroyEv+0x2f)[0x82be99f] /usr/local/mysql2/libexec/mysqld(_ZN7sp_headD0Ev+0x20)[0x82c0e10] /usr/local/mysql2/libexec/mysqld(_Z11mysql_parseP3THDPKcjPS2_+0x286)[0x81ac6a6] /usr/local/mysql2/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x4db)[0x81acc6b] /usr/local/mysql2/libexec/mysqld(_Z10do_commandP3THD+0xa7)[0x81ae317] /usr/local/mysql2/libexec/mysqld(handle_one_connection+0x9fa)[0x81aee5a] /lib/libpthread.so.0[0x97b45b] /lib/libc.so.6(clone+0x5e)[0x8fc24e] I tried to start the server using the daemon path and i got the following errors 080213 16:37:26 [Warning] Ignoring user change to 'mysql2' because the user was set to 'mysql' earlier on the command line 080213 16:37:27 InnoDB: Operating system error number 13 in a file operation. InnoDB: The error means mysqld does not have the access rights to InnoDB: the directory. InnoDB: File name ./ibdata1 InnoDB: File operation call: 'open'. InnoDB: Cannot continue operation. Saravanan Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: memory usage - mysql tuning!!
bruce a écrit : Hi.. Fairly new to mysql, in particular tuning. I have a test mysql db, on a test server. I've got a test app that runs on multiple servers, with each test app, firing/accessing data from the central db server. the central server is on a 2GHz, 1GMem, 100G system. MySQL is the basic app. the remote/test apps are doing basic selects/inserts, with a few basic select.. group/order by. the db schema appears to be pretty straight forward, with primary/unique fields. keep in mind, i'm not a dba!!! the my.cnf file is pretty basic. there has been a modification for the key_buffer_table entry... my issue, is that when i examine the central mysql (show processlist) i see a number of connections (~10) with the majority being in a sleep status.. However, when i then check the OS, using top, i see that mysql is running, consuming ~ 80-90% of the cpu cycles... so, i'm trying to figure out how to diagnose/solve this issue. any pointers, comments, suggestions will be greatly appreciated. this instance of mysql, is 5.x, and is running on a virtual rhel5 os, under vmware... thanks Hi, if mysql is the only program running on your test server it's normal that it's using 80-90% of the used cpu cycles ... Is it using 80% of the total CPU cycles or juste 80% of the used Cpu cyles? If your Cpu is running at 0.05 and mysql at 80% it means that mysql is just using 4% of the system's CPU, mysql has to listen to new incomming queries even when there are none so it's normal that it uses up some CPU ... -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
