mysql client aborts connection on terminal resize

Bug #925343 reported by ViNiL
42
This bug affects 7 people
Affects Status Importance Assigned to Milestone
MySQL Server
Unknown
Unknown
Percona Server moved to https://jira.percona.com/projects/PS
Fix Released
Medium
Sergei Glushchenko
5.1
Invalid
Undecided
Unassigned
5.5
Fix Released
Medium
Sergei Glushchenko
5.6
Fix Released
Medium
Sergei Glushchenko

Bug Description

While running various sql scripts we hit "Lost connection to MySQL server during query" frequently.
Have tried both, network and unix socket for connection => same result. We have increased all timeout variables as well.

We use mysqld_multi for multiple percona installs.
OS: CentOS 6
Pkgs:
Percona-Server-client-55-5.5.19-rel24.0.204.rhel6.x86_64
Percona-Server-shared-55-5.5.19-rel24.0.204.rhel6.x86_64
Percona-Server-shared-compat-5.5.19-rel24.0.204.rhel6.x86_64
percona-toolkit-2.0.2-1.noarch
Percona-Server-server-55-5.5.19-rel24.0.204.rhel6.x86_64

The database itself is quite large: 72G (du -sh)
All "InnoDB" tables.

[mysqld5]
socket = /var/lib/mysql-db/mysql.sock
port = 3311
datadir = /var/lib/mysql-db
max_connections = 300
innodb_buffer_pool_size = 10G
query_cache_size = 500M
log-bin = server-db-bin
relay-log = server-db-relay-bin
log-slave-updates
log_slow_queries = server-db-slow.log
long_query_time = 5
log-warnings
expire_logs_days = 7
binlog_format = MIXED

[mysqld]
basedir = /usr
datadir = /var/lib/mysql
port = 3306
socket = /var/lib/mysql/mysql.sock
max_allowed_packet = 64M
table_cache = 2048
max_heap_table_size = 256M
tmp_table_size = 256M
join_buffer_size = 3M
sort_buffer_size = 4M
read_buffer_size = 1M
read_rnd_buffer_size = 1M
myisam_sort_buffer_size = 64M
thread_cache_size = 256
query_cache_limit = 4M
low_priority_updates = 1
innodb_log_file_size = 512M
innodb_flush_log_at_trx_commit = 2
innodb_log_buffer_size = 8M
innodb_thread_concurrency = 16
innodb_flush_method = O_DIRECT
innodb_file_per_table = 1
server-id = 10
skip-slave-start
old_passwords = 1
character-set-server = utf8
net_read_timeout = 240
net_write_timeout = 240
connect_timeout = 240
tmpdir = /data/mysqltmp/

[mysqld_multi]
mysqld = /usr/bin/mysqld_safe
mysqladmin = /usr/bin/mysqladmin
log = /var/log/mysqld_multi.log

Any hint on what is going wrong here? The frequent "lost connection" makes any db upgrade process very painful.
We have not seen this issue before, using vanilla mysql 5.0 and 5.1.

Tags: i30462

Related branches

Revision history for this message
Alexey Kopytov (akopytov) wrote :

Might be related to bug #805805. Any chance that gdb or strace are being used against the server process when this issue occurs?

Revision history for this message
ViNiL (vinil) wrote :

I'll try when this occurs on our test db.

Do you have any specific command or cookbook I should try?

Revision history for this message
Alexey Kopytov (akopytov) wrote :

I meant to say it is a known issue that clients get disconnected when gdb or strace is attached to the server, which has been reported as bug #805805. So I'm wondering if you are using some monitoring tools like pt-pmp or pt-stalk, or running gdb/strace manually. In which case it would most likely be a duplicate of bug #805805.

Revision history for this message
ViNiL (vinil) wrote :

Ah, I see.
No, we are not running gdb, nor strace. The only way we monitor the database is via mysql client (ie. nagios / check_mysql_health)

Stewart Smith (stewart)
Changed in percona-server:
importance: Undecided → Medium
Revision history for this message
Ryan Brothers (ryan-brothers) wrote :

I am running into a similar issue that I just described here - not sure if it is related:

http://forum.percona.com/index.php?t=msg&th=2721&start=0

Revision history for this message
Jervin R (revin) wrote :

@ViNiL @Ryan - how are you guys running your scripts? This could be a bug with the mysql client I reported before although it should also be reproduceable upstream http://bugs.mysql.com/bug.php?id=62578

Revision history for this message
Ryan Brothers (ryan-brothers) wrote :

Jervin - thanks so much. That's exactly the problem I'm running into - I can now reproduce it anytime. I am running putty on Windows connecting to a CentOS machine, and if I resize the putty window while the query is running, I get the error "Lost connection to MySQL server during query" every single time. I can only reproduce though using Percona 5.5.27-28.1. I just tried it with MySQL 5.5.27 from mysql.com and I cannot reproduce it.

Revision history for this message
Alexey Kopytov (akopytov) wrote :

This is most likely a regression introduced upstream in 5.5 with the fix for http://bugs.mysql.com/bug.php?id=26780.

Revision history for this message
Alexey Kopytov (akopytov) wrote :

Bug #1055641 was marked as a duplicate of this one.

Revision history for this message
Raghavendra D Prabhu (raghavendra-prabhu) wrote :

Cannot repeat this with "5.1.65-rel14.0-log".

summary: - Timeouts during long running scripts
+ mysql client aborts connection on terminal resize
Revision history for this message
Raghavendra D Prabhu (raghavendra-prabhu) wrote :

Also, I tested this on mysql/percona server 55 built with system readline than the bundled libedit (with -DWITH_READLINE=ON ) and it is not aborting from SIGWINCH.

Revision history for this message
Jervin R (revin) wrote :

This is still repeatable on binary release of PS 5.5.30.

tags: added: i30462
Revision history for this message
Przemek (pmalkowski) wrote :

I can confirm the bug still happening in binary release of Percona Server version 5.5.30, but it's fixed in 5.5.31 and 5.5.32.

Revision history for this message
Laurynas Biveinis (laurynas-biveinis) wrote :

Sergei -

Please consider submitting your patch under OCA to Oracle. See the upstream bug comments, they are worried about backporting some frameworks from 5.6 to 5.5, maybe they will have comments on this patch.

Revision history for this message
Shahriyar Rzayev (rzayev-sehriyar) wrote :

Percona now uses JIRA for bug reports so this bug report is migrated to: https://jira.percona.com/browse/PS-84

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.