RE: Problems with MySQL 4.0.20
Thank you very much for your bug report! And sorry if I doubted your report at the beginning; I hadn't thought of the rpm script. No problem. I sometimes get bug reports that I know are impossible! Yet they weren't. This one I would have barely noticed if it had not knocked the slaves all offline. Mysql query just in case. -steve- -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: Problems with MySQL 4.0.20
Hi! On May 25, Steven Roussey wrote: We had some servers that were upgraded from 4.0.17/18 to 4.0.20 and had several problems thereafter: 1. Tables with FTS indices became corrupted, with queries on them causing segfaults on the servers. Hmm, I don't see any changes in ft-related files since 4.0.18 that could cause it (there were bugfixes, but they affect only *searching* - that is MATCH - and not *updating*). Can you create a test case ? 2. BinLog files were getting created with ownership of root, not mysql. Then Mysql complains that it can not read the file and so goes and creates another (which is fine and owned by mysql). All slaves to the master then die with corruption warnings about the master. I don't really understand how it can happen - I'll let others comment on it. 3. All servers suddenly have a lot of connection errors: Aborted connection 109 to db: 'xyz' user: 'aaa' host: `something.i' (Got timeout reading communication packets) I think, this is because --log-warnings was changed to be ON by default. Disable with --skip-log-warnings 4. Thread stack warnings: Warning: Asked for 196608 thread stack, but got 126976 Same here. 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 with MySQL 4.0.20
From: Sergei Golubchik [EMAIL PROTECTED] 4. Thread stack warnings: Warning: Asked for 196608 thread stack, but got 126976 Same here. OK, we can disable the warnings in the log file, but what's really behind this warning? A brand new, plain vanilla Fedora Core2 (aka RedHat FC2) installation with MySQL 4.0.20 produced this warning immediately. Does MySQL want more thread stack space? How badly does it need it? How can one make the OS to give it more? Regards, Jigal. -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
RE: Problems with MySQL 4.0.20
We start mysql with 'service mysql start' (we install from the RPM for
linux).
I've never seen mysql create binlog files under the name root before, and
after reverting to an old version, it doesn't again. It created a big mess
with all the slaves stuck at the end of an older binlog and not advancing to
the next one and complaining about corruption. Unfortunately, I don't have
the contents of the log (I think the size of the file was 79 bytes) since a
script here checks that all the slaves are at a certain point and then
deletes the logs on the master.
Log:
040519 17:53:41 mysqld started
/usr/sbin/mysqld: ready for connections.
Version: '4.0.18-standard-log' socket: '/tmp/mysql.sock' port: 3306
040520 16:58:54 /usr/sbin/mysqld: Normal shutdown
040520 16:58:56 /usr/sbin/mysqld: Shutdown Complete
040520 16:58:56 mysqld ended
040520 16:59:10 mysqld started
040520 16:59:10 Warning: Asked for 196608 thread stack, but got 126976
/usr/sbin/mysqld: ready for connections.
Version: '4.0.20-standard-log' socket: '/tmp/mysql.sock' port: 3306
040520 16:59:14 Failed to open log (file '/binlogs/binlog.032', errno 13)
040520 16:59:34 Aborted connection 134 to db: 'db' user: 'aaa' host:
`something.i' (Got an error writing communication packets)
040520 16:59:36 Aborted connection 544 to db: 'db' user: 'aaa' host:
`something.i' (Got an error writing communication packets)
040520 16:59:36 Aborted connection 541 to db: 'db' user: 'aaa' host:
`something.i' (Got an error writing communication packets)
Binary logs are created by the mysqld daemon (after mysqld possibly
changes to uid of 'mysql' if --user=mysql was used). So in any case,
if mysqld is running as user mysql (no matter if it was 'mysql' which
started mysqld or if it was 'root' which did 'mysqld --user=mysql'),
the binary logs are created by 'mysql'.
If you have some binary logs created by 'root', it means 'mysqld' was
run as 'root'; this is what you should really check (if you can
provide us with the way you started mysqld ('service mysql start',
whatever) and a listing of 'ps -elf | grep mysqld', we may be able to
check if it is a MySQL bug but this is quite unlikely, from the above
reasoning).
Thank you!
--
__ ___ ___ __
/ |/ /_ __/ __/ __ \/ /Mr. Guilhem Bichot [EMAIL PROTECTED]
/ /|_/ / // /\ \/ /_/ / /__ MySQL AB, Full-Time Software Developer
/_/ /_/\_, /___/\___\_\___/ Bordeaux, France
___/ 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 with MySQL 4.0.20
Hmm, I don't see any changes in ft-related files since 4.0.18 that could cause it (there were bugfixes, but they affect only *searching* - that is MATCH - and not *updating*). Can you create a test case ? Well, I put up a file in the secret folder a few days ago as referenced in a bug report: http://bugs.mysql.com/?id=3870 There is a select statement that crashes the server found in the log file. I put the files up and posted the bug from a remote computer and couldn't write much about it at the time. The table is fine according to 'check table the_table_name'. The select crashes it. The select also crashes it in older versions of myslq!! Doing a repair in the old version and then doing the select in the old version is OK. That is why I came to the conclusion that the file is corrupt. CHECK TABLE does not find the corruption, however. Another note on this: The tables I had the most problems with had FTS indicies. I can't say that it is more than coincidental just yet. I am not conclusive that it is a cause and effect relationship at this time. Even returning to the older versions of mysql is not getting rid of all our problems (we are seeing extremely high loads on the same stream of queries as usual). Selectively repairing tables has helped. It may be that it is not FTS related and we should repair all tables. We are going to try that tonight. -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
