Blogging and building live from MySQL Conf 09… If you want more details about what happens here (technical sessions, MySQL 5.4, InnoDB improvements, MySQL Cluster, Sun/Oracle fusion…) or want to enjoy a drink in the Valley, please let me know…
[caption id=“attachment_214” align=“aligncenter” width=“500” caption=“credits : Duncan Davidson”] 
[/caption]
Back to the Dotdeb business : MySQL 5.1.34 has been published with its lot of bugfixes. It is now built and available on Dotdeb for your Lenny/Etch amd64/i386 Debian servers. No change in the packaging, just apt-get upgrade…
After upgrading to 5.1.34 I ran into some trouble with stored procedures. The default config value for thread_stack is to low (128K) to do even empty procedures. Raising it to the default 196K should fix this.
See: http://forums.mysql.com/read.php?98,256564,256564#msg-256564
The message: Thread stack overrun: %ld bytes used of a %ld byte stack, and %ld bytes needed. Use ‘mysqld -O thread_stack=#’ to specify a bigger stack.
I upgraded from mysql 5.0 to mysql 5.1 on etch, and I get the same error during post-installation:
ERROR: 1064 You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ‘ALTER T ABLE user ADD column Show_view_priv enum(‘N’,‘Y’) CHARACTER SET utf8 NOT ’ at line 1
But mysql 5.1 appears to be running fine. I did manually ran mysql_upgrade to be on the safe side. I checked, and the user table already has this column in it. I am just trying to figure out a way to tell aptitude that the package is fully installed so it won’t keep trying. Perhaps there is something els I can do to make things better?
I think I found the issue, there is a syntax error in the mysql-server-5.1postinst file that I got when I did a apt-get install mysql-server-5.1, when I was running at the time mysql-5.0 (5.0.77). There is a missing comma:
" Show_view_priv=‘Y’, Create_routine_priv=‘Y’, Alter_routine_priv=‘Y’ “\
You will notice the missing comma at the end. After I fixed that, it seemed to somehow tried to create the plugin table twice. I dropped the table and ran it again and it still gave me a ‘plugin’ table already exists. I just commented that part out. Then it had some sort of issue with the ‘# Automatically added by dh_installinit’ section where it would give a return code of 1. I then decided to run “update-rc.d mysql defaults 19 21 >/dev/null” manually, and then I put in a “exit 0” right before that section. This allowed it to appear to be fully installed to apt-get. And as far as I can tell, mysql is working perfectly fine.
I am not sure if there really is an issue, or just something I did wrong.
Thanks for providing these wonderful packages over the years.
Hi,
I just done with a clean install of LAMP, but when I try to stop or restart the MySQL server this is what I get:
/etc/init.d/mysql stop
Stopping MySQL database server: mysqld failed!
/etc/init.d/mysql restart
Stopping MySQL database server: mysqld failed! Starting MySQL database server: mysqld already running.
Version: ‘5.1.34-0.dotdeb.1-log’ socket: ‘/var/run/mysqld/mysqld.sock’ port: 3306 (Debian)
What am I missing? thanks in advance
ok, but do I have to do this, and not able to restart the server normally?
killall -9 mysqld_safe mysqld
After killing the services and tried to start it, here’s what I got:
#/etc/init.d/mysql start Starting MySQL database server: mysqld. Checking for corrupt, not cleanly closed and upgrade needing tables.. EC2-WebHost:~# ERROR 1045 (28000): Access denied for user ‘debian-sys-maint’@’localhost’ (using password: YES)
Thanks in advance
Do I still need to run mysqld_safe and not just the mysqld?
ps aux |grep mysql
root 14975 0.0 0.0 10336 1428 pts/1 S 18:51 0:00 /bin/sh /usr/bin/mysqld_safe mysql 15101 0.0 0.2 180848 23044 pts/1 Sl 18:51 0:00 /usr/sbin/mysqld –basedir=/usr –datadir=/var/lib/mysql –user=mysql –log-error=/var/lib/mysql/MyDomain.err –pid-file=/var/run/mysqld/mysqld.pid –socket=/var/run/mysqld/mysqld.sock –port=3306 root 15183 0.0 0.0 5292 788 pts/1 R+ 18:53 0:00 grep mysql
Thanks again
Sorry but how do I reset the debian-sys-maint?
here is the content of /etc/mysql/debian.cnf:
Automatically generated for Debian scripts. DO NOT TOUCH!
[client] host = localhost user = debian-sys-maint password = ***************** socket = /var/run/mysqld/mysqld.sock [mysql_upgrade] host = localhost user = debian-sys-maint password = ***************** socket = /var/run/mysqld/mysqld.sock basedir = /usr
thanks
@Raleigh : Just change the ********** with a good password (for - bad - example “yourpassword”) then execute this query :
SET PASSWORD FOR ‘debian-sys-maint’@’localhost’ = PASSWORD(‘yourpassword’);
@Raleigh : You shouldn’t have deleted this user, he’s needed for the Debian administrative tasks. To re-create it, execute this query :
GRANT ALL PRIVILEGES ON . TO ‘debian-sys-maint’@’localhost’ IDENTIFIED BY ‘yourpassword’ WITH GRANT OPTION;
I didn’t deleted it and also didn’t touched the file, I only learned those things here.
I’m somewhat a newbie with debian and mysql
Ok, I’m going to create a new user debian-sys-maint, is it ok to use the same password in the file debian.cnf or safe to change it and set to mysql?
thanks
after that I stopped the mysql
/etc/init.d/mysql stop
Stopping MySQL database server: mysqld.
then checked the status
/etc/init.d/mysql status
MySQL is stopped..
then started it again
/etc/init.d/mysql start
Starting MySQL database server: mysqld. Checking for corrupt, not cleanly closed and upgrade needing tables..
does that one ok? not cleanly closed and upgrade needing tables? I have no new database yet other than mysql and information_schema.
thanks
Thank you so much! ^:)^
btw, do you have any documentation about your MySQL debian package?
thanks again
Hi Guillaume, I just upgraded to mysql-server-5.1 (5.1.34-0.dotdeb.0-log) with Etch on one server and Innodb is not available (parameter have innodb = NO).
On another server that I updated some days ago with the same version (Etch and 5.1.34) it’s ok. Though they have exactly the same my.cnf.
On the net, they say that “have innodb = NO” means that innodb is not compiled with mysql. What can I do (if I can do something …) ?
@Jean-Michel : all my packages have InnoDB activated (disabling it is insane). Please check that the MySQL related packages are the same on the two servers and that they come from Dotdeb :
dpkg -l ‘mysql’ | grep ‘^ii’
Yes the packages are the same on both machines, that is : > dpkg -l ‘mysql’ | grep ‘^ii’ ii libdbd-mysql-perl 3.0008-1 A Perl5 database interface to the MySQL data ii libmysqlclient15off 5.0.81-0.dotdeb.0 MySQL database client library ii libmysqlclient16 5.1.34-0.dotdeb.0 MySQL database client library ii mysql-client-5.1 5.1.34-0.dotdeb.0 MySQL database client binaries ii mysql-common 5.1.34-0.dotdeb.0 MySQL database common files (e.g. /etc/mysql ii mysql-server-5.1 5.1.34-0.dotdeb.0 MySQL database server binaries ii php5-mysql 5.2.9-0.dotdeb.1 MySQL module for php5
On the machine which have ‘have Innodb’ = YES, I have an additionnal package : ii libmysqlclient15-dev 5.0.67-0.dotdeb.1 MySQL database development files
I don’t think if could have an incidence but I have to mention that on the machine with NO Innodb, I have got a problem at upgrade with the acpid package with the error : Paramétrage de acpid (1.0.4-5etch1) … Starting Advanced Configuration and Power Interface daemon: acpid: can’t open /p roc/acpi/event: No such file or directory invoke-rc.d: initscript acpid, action “start” failed.
I found some web pages related to this issue but nothing worked for me. But since Mysql is working at least for MyISAM, I don’t think the problems are correlated, are they ?
With the same config as yours :
Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 74 Server version: 5.1.34-0.dotdeb.0 (Debian)Type ‘help;’ or ‘\h’ for help. Type ‘\c’ to clear the current input statement.
mysql> SHOW ENGINES; +————+———+—————————————————————-+————–+——+————+ | Engine | Support | Comment | Transactions | XA | Savepoints | +————+———+—————————————————————-+————–+——+————+ | InnoDB | YES | Supports transactions, row-level locking, and foreign keys | YES | YES | YES | | MRG_MYISAM | YES | Collection of identical MyISAM tables | NO | NO | NO | | BLACKHOLE | YES | /dev/null storage engine (anything you write to it disappears) | NO | NO | NO | | CSV | YES | CSV storage engine | NO | NO | NO | | MEMORY | YES | Hash based, stored in memory, useful for temporary tables | NO | NO | NO | | FEDERATED | NO | Federated MySQL storage engine | NULL | NULL | NULL | | ARCHIVE | YES | Archive storage engine | NO | NO | NO | | MyISAM | DEFAULT | Default engine as of MySQL 3.23 with great performance | NO | NO | NO | +————+———+—————————————————————-+————–+——+————+ 8 rows in set (0.01 sec)
Be sure that “skip-innodb” is commented in /etc/mysql/my.cnf and please restart your MySQL server : /etc/init.d/mysql/restart
Here is my “SHOW ENGINES” :
mysql> SHOW ENGINES; +————+———+—————————————————————-+————–+——+————+ | Engine | Support | Comment | Transactions | XA | Savepoints | +————+———+—————————————————————-+————–+——+————+ | MyISAM | DEFAULT | Default engine as of MySQL 3.23 with great performance | NO | NO | NO | | MRG_MYISAM | YES | Collection of identical MyISAM tables | NO | NO | NO | | BLACKHOLE | YES | /dev/null storage engine (anything you write to it disappears) | NO | NO | NO | | CSV | YES | CSV storage engine | NO | NO | NO | | MEMORY | YES | Hash based, stored in memory, useful for temporary tables | NO | NO | NO | | FEDERATED | NO | Federated MySQL storage engine | NULL | NULL | NULL | | ARCHIVE | YES | Archive storage engine | NO | NO | NO | +————+———+—————————————————————-+————–+——+————+ 7 rows in set (0.00 sec)The INNODB row is missing.
And yes, I have #skip-innodb in my.cnf
On my other server (with the same my.cnf - I took the same file to be sure), I have the 8 rows listed by SHOW ENGINES;
mysql> SELECT VERSION(); +——————-+ | VERSION() | +——————-+ | 5.1.34-0.dotdeb.0 | +——————-+ 1 row in set (0.01 sec)here is my source.list :
deb http://mir1.ovh.net/debian/ etch main deb-src http://mir1.ovh.net/debian/ etch main
deb http://security.debian.org/ etch/updates main contrib deb-src http://security.debian.org/ etch/updates main contrib
deb http://packages.dotdeb.org etch all deb-src http://packages.dotdeb.org etch all
Thanks Guillaume, you saved me (with some exchanges of emails).
Finally adding some lines to my.cnf solved this issue :
innodb_data_file_path = ibdata1:1G:autoextend innodb_autoextend_increment=128M innodb_log_group_home_dir = /home/mysql
innodb_buffer_pool_size = 2G innodb_additional_mem_pool_size = 20M
Set .._log_file_size to 25 % of buffer pool size
innodb_log_file_size = 500M innodb_log_buffer_size = 8M innodb_flush_log_at_trx_commit = 1
origin : innodb_lock_wait_timeout = 50 (changed by JMA on 2009-03-06)
innodb_lock_wait_timeout = 100
(take care : my server has 8GB of RAM - the above figures are not for a server with 1GB RAM)
Jean-Michel’s problem came from his need to change the InnoDB files’ default location. To do this, you have to set BOTH the innodb_data_home_dir and innodb_data_file_path variables.
About the memory settings, these apply only on a 64bits machine too. A 32bits server will never address more than 3GB of RAM (depending on your kernel configuration, even with HIGHMEM) by process. Then, running MySQL on Linux on a amd64 or equivalent machine is a good idea if you have more than 2GB of RAM. The performance boost is noticeable (>=40%).
hi Guillaume,
we have a problem with mysql crashes, is there a way to get support for that ?
we are willing to pay if someone solve our problem …
On Debian edit /etc/mysql/debian.cnf:
Replaces automatically generated for Debian scripts
[client] host = localhost user = root password = socket = /var/run/mysqld/mysqld.sock [mysql_upgrade] host = localhost user = root password = socket = /var/run/mysqld/mysqld.sock basedir = /usr
@name to you mean me ?
you can see a crash report on http://forums.mysql.com/read.php?132,264044,264044#msg-264044
@“name” : Feel free to submit decent bug reports and to give a real name/email address. Please note that replacing “debian-sys-maint” by root in /etc/mysql/debian.cnf (especially with an empty password) is a very bad idea. Don’t be surprised if something goes wrong :)
@Daniel Anliker : I’ll email you very soon. Waiting this, please gather some information about your system :
Hi, i am getting this error on debian lenny
May 28 00:52:51 server-new /etc/init.d/mysql[21093]: 0 processes alive and ‘/usr/bin/mysqladmin –defaults-file=/etc/mysql/debian.cnf ping’ resulted in May 28 00:52:51 server-new /etc/init.d/mysql[21093]: #007/usr/bin/mysqladmin: connect to server at ’localhost’ failed May 28 00:52:51 server-new /etc/init.d/mysql[21093]: error: ‘Can’t connect to local MySQL server through socket ‘/usr/lib/dovecot/var/run/mysqld/mysqld.sock’ (2)’ May 28 00:52:51 server-new /etc/init.d/mysql[21093]: Check that mysqld is running and that the socket: ‘/usr/lib/dovecot/var/run/mysqld/mysqld.sock’ exists! May 28 00:52:51 server-new /etc/init.d/mysql[21093]:
This is what i have don
btw in this case i have install mysql-cleint and mysql server after putting dotdeb in the /etc/apt/sourcefile.list
In order to run Postfix and Dovecot chrooted, we need to make some changes to the configuration of MySQL
We are going to store the MySQL socket file inside Dovecot chroot :
#* mkdir -p /usr/lib/dovecot/var/run/mysqld cd /usr/lib/dovecot/var/run chown mysql:root mysqld #*
We are now symlinking the directory back into /var/run, DSPAM will use mysql socket file and expect it to be located under /var/run/mysqld/mysqld.sock
#* invoke-rc.d mysql stop rm -fr /var/run/mysqld cd /var/run/ ln -s /usr/lib/dovecot/var/run/mysqld/ #*
You should change /etc/mysql/my.cnf and fix the paths :
#* nano /etc/mysql/my.cnf #*
[client] port = 3306 socket = /usr/lib/dovecot/var/run/mysqld/mysqld.sock
[mysqld_safe] socket = /usr/lib/dovecot/var/run/mysqld/mysqld.sock nice = 0
[mysqld] user = mysql pid-file = /usr/lib/dovecot/var/run/mysqld/mysqld.pid socket = /usr/lib/dovecot/var/run/mysqld/mysqld.sock
And finally also edit /etc/mysql/debian.cnf and fix the paths :
#* nano /etc/mysql/debian.cnf #*
[client] host = localhost user = debian-sys-maint password = xxx socket = /usr/lib/dovecot/var/run/mysqld/mysqld.sock [mysql_upgrade] user = debian-sys-maint password = xxx socket = /usr/lib/dovecot/var/run/mysqld/mysqld.sock basedir = /usr
Restart MySQL :
#* invoke-rc.d mysql restart #*
If i install mysql first and change the sourcefie.list whit dotdeb and make de change as above. i get the same error but when i then mark #skip-bdb in the /etc/mysql/my.cnf which is default unmarkt i get is working again
Regrades Jan Kruis
Hi, I’ve installed the dotdeb packages, on xen vm Lenny-amd64 with 4 cpus, 8G Ram, for a lamp server(apache2, php5, mysql and ezpublish). All seems to be ok, until connexions starts. I’ve tested with ab and siege, the innodb thread crash and start automatic recovery. The debian1.err look like this:
090612 9:00:46 [Note] /usr/sbin/mysqld: ready for connections. Version: ‘5.1.34-0.dotdeb.1-log’ socket: ‘/var/run/mysqld/mysqld.sock’ port: 3306 (Debian)
090612 9:01: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=16777216 read_buffer_size=131072 max_used_connections=9 max_threads=75 threads_connected=9 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 641148 K bytes of memory Hope that’s ok; if not, decrease some variables in the equation.
thd: 0x1717200 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… stack_bottom = 0x44209100 thread_stack 0x20000 /usr/sbin/mysqld(my_print_stacktrace+0x29) [0x8abab9] /usr/sbin/mysqld(handle_segfault+0x34b) [0x5f841b] /lib/libpthread.so.0 [0x7fb9bfe78a80] /lib/libunwind.so.7 [0x7fb9be6f6874] /lib/libunwind.so.7(_ULx86_64_is_signal_frame+0x44) [0x7fb9be6f6dd4] /lib/libunwind.so.7(_ULx86_64_step+0x36) [0x7fb9be6f7156] /usr/lib/libtcmalloc.so.0(GetStackTrace(void**, int, int)+0x134) [0x7fb9c00af814] /usr/lib/libtcmalloc.so.0 [0x7fb9c009d885] /usr/lib/libtcmalloc.so.0(__libc_malloc+0x205) [0x7fb9c00b1d25] /usr/sbin/mysqld(my_malloc+0x32) [0x898602] /usr/sbin/mysqld(ha_innobase::records_in_range(unsigned int, st_key_range*, st_key_range*)+0x3d) [0x779d2d] /usr/sbin/mysqld [0x6c4b4f] /usr/sbin/mysqld [0x6c4bb1] /usr/sbin/mysqld [0x6c4bb1] /usr/sbin/mysqld [0x6c48c6] /usr/sbin/mysqld [0x6c52d4] /usr/sbin/mysqld [0x6c5558] /usr/sbin/mysqld(SQL_SELECT::test_quick_select(THD*, Bitmap, unsigned long long, unsigned long long, bool)+0x11b7) [0x6ce8f7] /usr/sbin/mysqld [0x665831] /usr/sbin/mysqld(JOIN::optimize()+0x5f1) [0x666a31] /usr/sbin/mysqld(mysql_select(THD*, Item***, TABLE_LIST*, unsigned int, List&, Item*, unsigned int, st_order*, st_order*, Item*, st_order*, unsigned long long, select_result*, st_select_lex_unit*, st_select_lex*)+0x98) [0x66a068] /usr/sbin/mysqld(handle_select(THD*, st_lex*, select_result*, unsigned long)+0x16c) [0x66fc5c] /usr/sbin/mysqld [0x6044ec] /usr/sbin/mysqld(mysql_execute_command(THD*)+0x3b60) [0x609930] /usr/sbin/mysqld(mysql_parse(THD*, char const*, unsigned int, char const**)+0x210) [0x60b800] /usr/sbin/mysqld(dispatch_command(enum_server_command, THD*, char*, unsigned int)+0x692) [0x60beb2] /usr/sbin/mysqld(do_command(THD*)+0xe8) [0x60ce38] /usr/sbin/mysqld(handle_one_connection+0x21e) [0x6007ae] /lib/libpthread.so.0 [0x7fb9bfe70fc7] /lib/libc.so.6(clone+0x6d) [0x7fb9be9cc5ad] Trying to get some variables. Some pointers may be invalid and cause the dump to abort… thd->query at 0x7fb92048e410 is an invalid pointer thd->thread_id=2 thd->killed=NOT_KILLED The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains information that should help you find out what is causing the crash. 090612 09:01:16 mysqld_safe Number of processes running now: 0 090612 09:01:16 mysqld_safe mysqld restarted InnoDB: The log sequence number in ibdata files does not match InnoDB: the log sequence number in the ib_logfiles! 090612 9:01:17 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…19 paquets vont être installés, et 2 retirés. 54,5Mo d’espace disque vont être libérés InnoDB: Last MySQL binlog file position 0 318, file name /var/log/mysql/mysql-bin.000714 090612 9:01:17 InnoDB: Started; log sequence number 0 769649599 090612 9:01:17 [Note] Recovering after a crash using /var/log/mysql/mysql-bin 090612 9:01:17 [Note] Starting crash recovery… 090612 9:01:17 [Note] Crash recovery finished. 090612 9:01:17 [Note] Event Scheduler: Loaded 0 events 090612 9:01:17 [Note] /usr/sbin/mysqld: ready for connections. Version: ‘5.1.34-0.dotdeb.1-log’ socket: ‘/var/run/mysqld/mysqld.sock’ port: 3306 (Debian)
Hello,
My name is Doru. Yes, I have activated Google Perftools. Well, i have to go back to lenny’s default mysql version now, but this one use all memory (8Go) and sometimes crashes the server. The dotdeb version correct the memory leaks (with the same config uses only 4G of 8) but when the number of connexions increases I have the bug.
Thanks for your answer
Bonjour Doru,
Google Perftools seem to be buggy on amd64. Please disable them and let me know if the problem still occurs.
Hi, thank you very much. It would be perfect.
Doru
Hi Guillaume, I’ve updated with this new google-perftools, but now mysqld don’t start (i’ve inserted the LD_PRELOAD line in /etc/init.d/mysql). The logged error is: Jun 18 12:07:30 debian1 /etc/init.d/mysql[2436]: Jun 18 12:08:06 debian1 kernel: [593293.212217] mysqld_safe[2472]: segfault at 20 ip 7fe5beab9216 sp 7fffc6f1c560 error 4 in libtcmalloc.so.0.0.0[7fe5bea99000+3c000]
and the script error answer: /etc/init.d/mysql start Starting MySQL database server: mysqld/etc/init.d/mysql: line 108: 2472 Erreur de segmentation /usr/bin/mysqld_safe > /dev/null 2>&1
I don’t knok if this helps you, I hope so.
Doru
Hi, 5.1.34-0.dotdeb.1 just crashed on my amd64 server. http://dev.mysql.com/doc/refman/5.1/en/news-5-1-35.html shows it fixes a number of crashes. When can we expect a 5.1.35 dotdeb package? Thanks!
090620 8:52:30 - 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=536870912 read_buffer_size=131072 max_used_connections=709 max_threads=1000 threads_connected=31 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 4758475 K bytes of memory Hope that’s ok; if not, decrease some variables in the equation.
thd: 0x7f039c0f5f30 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… stack_bottom = 0x7f039ac580d0 thread_stack 0x80000 /usr/sbin/mysqld(my_print_stacktrace+0x29) [0x8abab9] /usr/sbin/mysqld(handle_segfault+0x34b) [0x5f841b] /lib/libpthread.so.0 [0x7f0b16bc7080] /usr/sbin/mysqld(lock_sec_rec_cons_read_sees+0x25) [0x7c8345] /usr/sbin/mysqld(row_search_for_mysql+0x1920) [0x8092d0] /usr/sbin/mysqld(ha_innobase::general_fetch(unsigned char*, unsigned int, unsigned int)+0x7c) [0x7784fc] /usr/sbin/mysqld [0x64fc3a] /usr/sbin/mysqld(sub_select(JOIN*, st_join_table*, bool)+0x89) [0x6562c9] /usr/sbin/mysqld [0x650185] /usr/sbin/mysqld(sub_select(JOIN*, st_join_table*, bool)+0x78) [0x6562b8] /usr/sbin/mysqld [0x6592fd] /usr/sbin/mysqld(JOIN::exec()+0x51d) [0x66de5d] /usr/sbin/mysqld(mysql_select(THD*, Item***, TABLE_LIST*, unsigned int, List&, Item*, unsigned int, st_order*, st_order*, Item*, st_order*, unsigned long long, select_result*, st_select_lex_unit*, st_select_lex*)+0x124) [0x66a0f4] /usr/sbin/mysqld(handle_select(THD*, st_lex*, select_result*, unsigned long)+0x16c) [0x66fc5c] /usr/sbin/mysqld [0x6044ec] /usr/sbin/mysqld(mysql_execute_command(THD*)+0x3b60) [0x609930] /usr/sbin/mysqld(mysql_parse(THD*, char const*, unsigned int, char const**)+0x210) [0x60b800] /usr/sbin/mysqld(dispatch_command(enum_server_command, THD*, char*, unsigned int)+0x692) [0x60beb2] /usr/sbin/mysqld(do_command(THD*)+0xe8) [0x60ce38] /usr/sbin/mysqld(handle_one_connection+0x21e) [0x6007ae] /lib/libpthread.so.0 [0x7f0b16bbf3ba] /lib/libc.so.6(clone+0x6d) [0x7f0b15708fcd] Trying to get some variables. Some pointers may be invalid and cause the dump to abort… thd->query at 0x7f03a85be190 is an invalid pointer thd->thread_id=10637885 thd->killed=NOT_KILLED The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains information that should help you find out what is causing the crash. pure virtual method called terminate called without an active exception Fatal signal 6 while backtracing
Hello,
After having upgraded Mysql, service began and crash… Sometimes, Mysql just does not live more than few seconds.
I went to 5.1.35 provided by Mysql (binary package), deleted everything, and recreate everything. I don’t have any crash yet. We’ll see wether they come backup or not.
I don’t use libgoogle…
For information, this is a big mysql server
mysqladmin status ; sleep 60 ; mysqladmin status
Uptime: 134474 Threads: 37 Questions: 490612571 Slow queries: 13068 Opens: 26014 Flush tables: 1 Open tables: 24925 Queries per second avg: 3648.382 Uptime: 134534 Threads: 19 Questions: 491088014 Slow queries: 13068 Opens: 26014 Flush tables: 1 Open tables: 24925 Queries per second avg: 3650.289
echo $(( (491088014 - 490612571) / 60 ))
7924
http://bugs.mysql.com/bug.php?id=45489
@Sebastian Harnau : I don’t know why the official Debian maintainer does not update the mysql-dfsg-5.1 packages (my packages are just backports from experimental to stable) : http://packages.qa.debian.org/m/mysql-dfsg-5.1.html I’ll backport a newer release as soon as it’s available on Debian experimental
@David Yan : No problem. If you have a “faster” repository than Debian experimental with clean Debian packages, let me know.
Hi,
after apt-get installation i get a error in phpMyAdmin: “Your PHP MySQL library version 5.0.51a differs from your MySQL server version 5.1.34. This may cause unpredictable behavior.”.
php5-mysql and libapache2-mod-php5 are allready “up to date”.
What should i do?
Tanks. :)
@Qwertz : as said in many comments on this site, that’s just a warning and there’s no incompatibility between 5.0 libraries and a 5.1 server in the PHPMyAdmin case. It should be fixed in PHP 5.3 with the inclusion of the MySQL native driver.
Try to comment this warning in PHPMyAdmin (main.php).