[atomic] mysql 5.1.57 Released

Atomic repository announcements, new release notifications and other news regarding the atomic yum repository.
scott
Atomicorp Staff - Site Admin
Atomicorp Staff - Site Admin
Posts: 8355
Joined: Wed Dec 31, 1969 8:00 pm
Location: earth
Contact:

[atomic] mysql 5.1.57 Released

Unread post by scott »

Changelog
* When invoked with the --auto-generate-sql option, mysqlslap dropped the schema specified with the --create-schema option at the end of the test run, which may have been unexpected by the user. mysqlslap no longer drops the schema, but has a new --create-and-drop-schema schema that both creates and drops a schema. (Bug #58090, Bug #11765157)
* A new system variable, max_long_data_size, now controls the maximum size of parameter values that can be sent with the mysql_stmt_send_long_data() C API function. If not set at server startup, the default is the value of the max_allowed_packet system variable. This variable is deprecated. In MySQL 5.6, it is removed and the maximum parameter size is controlled by max_allowed_packet.

Bugs fixed:

* InnoDB Storage Engine: Replication: Trying to update a column, previously set to NULL, of an InnoDB table with no primary key caused replication to fail with Can't find record in 'table' on the slave. (Bug #11766865, Bug #60091)
* InnoDB Storage Engine: The server could halt if InnoDB interpreted a very heavy I/O load for 15 minutes or more as an indication that the server was hung. This change fixes the logic that measures how long InnoDB threads were waiting, which formerly could produce false positives. (Bug #11877216, Bug #11755413, Bug #47183)
* Replication: Using the --server-id option with mysqlbinlog could cause format description log events to be filtered out of the binary log, leaving mysqlbinlog unable to read the remainder of the log. Now such events are always read without regard to the value of this option.

As part of the the fix for this problem, mysqlbinlog now also reads rotate log events without regard to the value of --server-id. (Bug #11766427, Bug #59530)
* Partitioning: A problem with a previous fix for poor performance of INSERT ON DUPLICATE KEY UPDATE statements on tables having many partitions caused the handler function for reading a row from a specific index to fail to store the ID of the partition last used. This caused some statements to fail with Can't find record errors. (Bug #59297, Bug #11766232)
* InnoDB invoked some zlib functions without proper initialization. (Bug #11849231)
* Two unused test files in storage/ndb/test/sql contained incorrect versions of the GNU Lesser General Public License. The files and the directory containing them have been removed. (Bug #11810224)

See also Bug #11810156.
* Selecting from a view for which the definition included a HAVING clause failed with an error:

1356: View '...' references invalid table(s) or column(s)
or function(s) or definer/invoker of view lack rights to use them

(Bug #60295, Bug #11829681)
* The server permitted max_allowed_packet to be set lower than net_buffer_length, which does not make sense because max_allowed_packet is the upper limit on net_buffer_length values. Now a warning occurs and the value remains unchanged. (Bug #59959, Bug #11766769)
* The server read one byte too many when trying to process an XML string lacking a closing quote (') or double quote (") character used as an argument for UpdateXML() or ExtractValue(). (Bug #59901, Bug #11766725)

See also Bug #44332, Bug #11752979.
* Attempting to create a spatial index on a CHAR column longer than 31 bytes led to an assertion failure if the server was compiled with safemutex support. (Bug #59888, Bug #11766714)
* Aggregation followed by a subquery could produce an incorrect result. (Bug #59839, Bug #11766675)
* An incorrect character set pointer passed to my_strtoll10_mb2() caused an assertion to be raised. (Bug #59648, Bug #11766519)
* A missing variable initialization for Item_func_set_user_var objects could cause an assertion to be raised. (Bug #59527, Bug #11766424)
* mysqldump did not quote database names in ALTER DATABASE statements in its output, which could cause an error at reload time for database names containing a dash. (Bug #59398, Bug #11766310)
* In Item_func_month::val_str(), a Valgrind warning for a too-late NULL value check was corrected. (Bug #59166, Bug #11766126)
* In Item::get_date, a Valgrind warning for a missing NULL value check was corrected. (Bug #59164, Bug #11766124)
* In extract_date_time(), a Valgrind warning for a missing end-of-string check was corrected. (Bug #59151, Bug #11766112)
* In string context, the MIN() and MAX() functions did not take into account the unsignedness of a BIGINT UNSIGNED argument. (Bug #59132, Bug #11766094)
* In Item_func::val_decimal, a Valgrind warning for a missing NULL value check was corrected. (Bug #59125, Bug #11766087)
* In Item_func_str_to_date::val_str, a Valgrind warning for an uninitialized variable was corrected. (Bug #58154, Bug #11765216)
* The code for PROCEDURE ANALYSE() had a missing DBUG_RETURN statement, which could cause a server crash in debug builds. (Bug #58140, Bug #11765202)
* An assertion could be raised in Item_func_int_val::fix_num_length_and_dec() due to overflow for geometry functions. (Bug #57900, Bug #11764994)
* An assertion could be raised if a statement that required a name lock on a table (for example, DROP TRIGGER) executed concurrently with an INFORMATION_SCHEMA query that also used the table. (Bug #56541, Bug #11763784)
* For a client connected using SSL, the Ssl_cipher_list status variable was empty and did not show the possible cipher types. (Bug #52596, Bug #11760210)
* With lower_case_table_names=2, resolution of objects qualified by database names could fail. (Bug #50924, Bug #11758687)
* A potential invalid memory access discovered by Valgrind was fixed. (Bug #48053, Bug #11756169)
* Bitmap functions used in one thread could change bitmaps used by other threads, causing an assertion to be raised. (Bug #43152, Bug #11752069)
* SHOW EVENTS did not always show events from the correct database. (Bug #41907, Bug #11751148)

To Upgrade:
yum upgrade mysql
Funboy
Forum User
Forum User
Posts: 54
Joined: Wed Aug 05, 2009 4:33 am

Re: [atomic] mysql 5.1.57 Released

Unread post by Funboy »

Hi Scott,

Just updated my Centos x64 ASL server with this MySQL 5.1.57 release and now cannot get my ASL admin page to load?
Warning: mysql_connect() [function.mysql-connect]: Can't connect to MySQL server on '127.0.0.1' (4) in /var/asl/www/index.php on line 23
Couldn't get a db connection. Sorry!
I did the obvious /etc/init.d/mysqld restart and asl -s -f which did not help, oddly all websites using MySQL are still running without issue only the ASL admin panel on port 30000

Checking _http://www.atomicorp.com/wiki/index.php/ASL_FAQ has not yielded any help so far regarding anything obvious for MySQL as all seems OK?

Could I please ask for some guidance as what to try.

Regards
Mark


UPDATE

I have just been informed that users can no longer access their Horde webmail:
Login failed because your username or password was entered incorrectly.
Plesk seems to work OK with no issues re access and loggin.
# ps auxwww | grep mysql
root 29551 0.0 0.0 65936 1296 ? S 12:00 0:00 /bin/sh /usr/bin/mysqld_safe --datadir=/var/lib/mysql --socket=/var/lib/mysql/mysql.sock --pid-file=/var/run/mysqld/mysqld.pid --basedir=/usr --user=mysql
mysql 29641 3.2 0.9 233808 37448 ? Sl 12:00 2:48 /usr/libexec/mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --log-error=/var/log/mysqld.log --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/lib/mysql/mysql.sock
root 29779 0.0 0.0 61208 744 pts/0 R+ 13:26 0:00 grep mysql

# netstat -anp | grep 3306
tcp 0 0 0.0.0.0:3306 0.0.0.0:* LISTEN 29641/mysqld
tcp 0 0 127.0.0.1:3306 127.0.0.1:38318 ESTABLISHED 29641/mysqld
tcp 0 1 127.0.0.1:55536 127.0.0.1:3306 SYN_SENT 28930/ossec-dbd

# /etc/init.d/mysqld restart
Stopping mysqld: [ OK ]
Starting mysqld: [ OK ]
scott
Atomicorp Staff - Site Admin
Atomicorp Staff - Site Admin
Posts: 8355
Joined: Wed Dec 31, 1969 8:00 pm
Location: earth
Contact:

Re: [atomic] mysql 5.1.57 Released

Unread post by scott »

Its definitely not a compatibility problem, since we use that internally just fine. Did you try restarting mysql?
Funboy
Forum User
Forum User
Posts: 54
Joined: Wed Aug 05, 2009 4:33 am

Re: [atomic] mysql 5.1.57 Released

Unread post by Funboy »

Hi Scott,

Yes restarted MySQL several times with no effect. very puzzled and not sure what to try.
Funboy
Forum User
Forum User
Posts: 54
Joined: Wed Aug 05, 2009 4:33 am

Re: [atomic] mysql 5.1.57 Released

Unread post by Funboy »

Ok just done another restart and this time I am seeing the following within the MySQL log.
110512 13:46:05 [Note] Event Scheduler: Purging the queue. 0 events
110512 13:46:05 InnoDB: Starting shutdown...
110512 13:46:07 InnoDB: Shutdown completed; log sequence number 0 314772593
110512 13:46:07 [Note] /usr/libexec/mysqld: Shutdown complete

110512 13:46:07 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended
110512 13:46:07 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
110512 13:46:07 [Warning] /usr/libexec/mysqld: Option '--set-variable' is deprecated. Use --variable-name=value instead.
110512 13:46:07 [Note] Plugin 'ndbcluster' is disabled.
110512 13:46:07 InnoDB: Initializing buffer pool, size = 8.0M
110512 13:46:07 InnoDB: Completed initialization of buffer pool
110512 13:46:08 InnoDB: Started; log sequence number 0 314772593
110512 13:46:08 [Note] Event Scheduler: Loaded 0 events
110512 13:46:08 [Note] /usr/libexec/mysqld: ready for connections.
Version: '5.1.57' socket: '/var/lib/mysql/mysql.sock' port: 3306 Source distribution
110512 14:05:45 [ERROR] /usr/libexec/mysqld: Table './tortix/alert' is marked as crashed and should be repaired
110512 14:05:45 [ERROR] /usr/libexec/mysqld: Table './tortix/alert' is marked as crashed and should be repaired
110512 14:06:15 [ERROR] /usr/libexec/mysqld: Table './tortix/alert' is marked as crashed and should be repaired
110512 14:06:16 [ERROR] /usr/libexec/mysqld: Table './tortix/alert' is marked as crashed and should be repaired
110512 14:06:16 [ERROR] /usr/libexec/mysqld: Table './tortix/alert' is marked as crashed and should be repaired
110512 14:06:17 [ERROR] /usr/libexec/mysqld: Table './tortix/alert' is marked as crashed and should be repaired
110512 14:06:17 [ERROR] /usr/libexec/mysqld: Table './tortix/alert' is marked as crashed and should be repaired
110512 14:06:18 [ERROR] /usr/libexec/mysqld: Table './tortix/alert' is marked as crashed and should be repaired
110512 14:06:19 [ERROR] /usr/libexec/mysqld: Table './tortix/alert' is marked as crashed and should be repaired
110512 14:06:19 [ERROR] /usr/libexec/mysqld: Table './tortix/alert' is marked as crashed and should be repaired
110512 14:06:19 [ERROR] /usr/libexec/mysqld: Table './tortix/alert' is marked as crashed and should be repaired
110512 14:06:20 [ERROR] /usr/libexec/mysqld: Table './tortix/alert' is marked as crashed and should be repaired
110512 14:44:48 [Note] /usr/libexec/mysqld: Normal shutdown

110512 14:44:48 [Note] Event Scheduler: Purging the queue. 0 events
110512 14:44:48 InnoDB: Starting shutdown...
110512 14:44:53 InnoDB: Shutdown completed; log sequence number 0 314891158
110512 14:44:53 [Note] /usr/libexec/mysqld: Shutdown complete

110512 14:44:53 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended
110512 14:44:59 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
110512 14:44:59 [Warning] /usr/libexec/mysqld: Option '--set-variable' is deprecated. Use --variable-name=value instead.
110512 14:44:59 [Note] Plugin 'ndbcluster' is disabled.
110512 14:44:59 InnoDB: Initializing buffer pool, size = 8.0M
110512 14:44:59 InnoDB: Completed initialization of buffer pool
110512 14:44:59 InnoDB: Started; log sequence number 0 314891158
110512 14:44:59 [Note] Event Scheduler: Loaded 0 events
110512 14:44:59 [Note] /usr/libexec/mysqld: ready for connections.
Version: '5.1.57' socket: '/var/lib/mysql/mysql.sock' port: 3306 Source distribution
UPDATE after tortix repair.
Version: '5.1.57' socket: '/var/lib/mysql/mysql.sock' port: 3306 Source distribution
110512 15:59:42 [ERROR] /usr/libexec/mysqld: Table './tortix/alert' is marked as crashed and should be repaired
110512 15:59:42 [ERROR] /usr/libexec/mysqld: Table './tortix/alert' is marked as crashed and should be repaired
110512 16:00:21 [Note] Found 715390 of 715536 rows when repairing './tortix/alert'
110512 16:00:45 [Note] Found 715495 of 715589 rows when repairing './tortix/data'
110512 16:30:39 [Note] /usr/libexec/mysqld: Normal shutdown

110512 16:30:39 [Note] Event Scheduler: Purging the queue. 0 events
110512 16:30:39 InnoDB: Starting shutdown...
110512 16:30:41 InnoDB: Shutdown completed; log sequence number 0 315051101
110512 16:30:41 [Note] /usr/libexec/mysqld: Shutdown complete

110512 16:30:41 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended
110512 16:30:52 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
110512 16:30:52 [Warning] /usr/libexec/mysqld: Option '--set-variable' is deprecated. Use --variable-name=value instead.
110512 16:30:52 [Note] Plugin 'ndbcluster' is disabled.
110512 16:30:52 InnoDB: Initializing buffer pool, size = 8.0M
110512 16:30:52 InnoDB: Completed initialization of buffer pool
110512 16:30:52 InnoDB: Started; log sequence number 0 315051101
110512 16:30:52 [Note] /usr/libexec/mysqld: ready for connections.
Version: '5.1.57' socket: '/var/lib/mysql/mysql.sock' port: 3306 Source distribution
Still no access, could it be that MySQL has somehow not fully installed correctly? if so what's the best way to try a repair WITHOUT a yum remove command.
scott
Atomicorp Staff - Site Admin
Atomicorp Staff - Site Admin
Posts: 8355
Joined: Wed Dec 31, 1969 8:00 pm
Location: earth
Contact:

Re: [atomic] mysql 5.1.57 Released

Unread post by scott »

Looks like it still needs to be repaired to me, I don't know if an update could cause that or just something that happened during a restart.
Funboy
Forum User
Forum User
Posts: 54
Joined: Wed Aug 05, 2009 4:33 am

Re: [atomic] mysql 5.1.57 Released

Unread post by Funboy »

Just run the following commands to see what's happening, with the last two giving error?

mysqladmin version
# mysqladmin version
mysqladmin Ver 8.42 Distrib 5.1.57, for redhat-linux-gnu on x86_64
Copyright 2000-2008 MySQL AB, 2008 Sun Microsystems, Inc.
This software comes with ABSOLUTELY NO WARRANTY. This is free software,
and you are welcome to modify and redistribute it under the GPL license

Server version 5.1.57
Protocol version 10
Connection Localhost via UNIX socket
UNIX socket /var/lib/mysql/mysql.sock
Uptime: 35 min 30 sec

Threads: 1 Questions: 13650 Slow queries: 0 Opens: 2007 Flush tables: 1 Open tables: 64 Queries per second avg: 6.408
mysqladmin -h `hostname` --port=3306 version
# mysqladmin -h `hostname` --port=3306 version
mysqladmin Ver 8.42 Distrib 5.1.57, for redhat-linux-gnu on x86_64
Copyright 2000-2008 MySQL AB, 2008 Sun Microsystems, Inc.
This software comes with ABSOLUTELY NO WARRANTY. This is free software,
and you are welcome to modify and redistribute it under the GPL license

Server version 5.1.57
Protocol version 10
Connection MY HOST NAME via TCP/IP
TCP port 3306
Uptime: 40 min 41 sec

Threads: 1 Questions: 14929 Slow queries: 0 Opens: 2039 Flush tables: 1 Open tables: 62 Queries per second avg: 6.115
mysqladmin -h host_ip version
# mysqladmin -h host_ip version
mysqladmin: connect to server at 'host_ip' failed
error: 'Unknown MySQL server host 'host_ip' (1)'
Check that mysqld is running on host_ip and that the port is 3306.
You can check this by doing 'telnet host_ip 3306'
mysqladmin --protocol=SOCKET --socket=/tmp/mysql.sock version
# mysqladmin --protocol=SOCKET --socket=/tmp/mysql.sock version
mysqladmin: connect to server at 'localhost' failed
error: 'Can't connect to local MySQL server through socket '/tmp/mysql.sock' (2)'
Check that mysqld is running and that the socket: '/tmp/mysql.sock' exists!
UPDATE

Well was defiantly missing /tmp/mysql.sock ?

So have recreated by doing the following AFTER a backup:
# cp -fr /var/lib/mysql /var/lib/mysql.old
Recreate the symbolic link to the .sock file:
# ln -s /var/lib/mysql/mysql.sock /tmp/mysql.sock
Check the permissions of the /var/lib/mysql
# chmod 0755 /var/lib/mysql
# chown mysql:root /var/lib/mysql
Now to find out what else seems to have gone wrong, just my luck. :roll:
scott
Atomicorp Staff - Site Admin
Atomicorp Staff - Site Admin
Posts: 8355
Joined: Wed Dec 31, 1969 8:00 pm
Location: earth
Contact:

Re: [atomic] mysql 5.1.57 Released

Unread post by scott »

Thats definitely not right, the default socket is /var/lib/mysql/mysql.sock. I cant think of anything that uses /tmp/mysql.sock by default
Post Reply