MySQL Bugs: #78434: Connection to server fails for a particular table

Bug #78434	Connection to server fails for a particular table
Submitted:	15 Sep 2015 5:23	Modified:	2 Oct 2015 4:04
Reporter:	Joydeep Dey	Email Updates:
Status:	Can't repeat	Impact on me:	None
Category:	MySQL Workbench: SQL Editor	Severity:	S2 (Serious)
Version:	6.3.4.0	OS:	Windows (7 x86 Service Pack 1)
Assigned to:		CPU Architecture:	Any
Tags:	ssh connection, workbench

Description:
From MySQL Workbench, the DB connection is setup to remote server via SSH. The connection is tested and executed successfully. Even, any kind of database operation can be performed on the available tables. But, there is one particular table, on which, while performing any operation, it shows the following error-

Error Code: 2013 Lost connection to MySQL server at 'waiting for initial communication packet', system error: 10060

There is a very rare case, when that table was successfully accessed. This is really very confusing situation. Because, that table is accessible from any other tool, without a single fail. 

The table info is given as below-

Details:
---------
Engine: InnoDB
Row format: Compact
Column count: 9
Table rows: 2906
AVG row length: 101
Data length: 288.0 KiB
Index length: 64.0 KiB
Max data length: 0.0 bytes
Data free: 0.0 bytes
Table size(estimate): 352.0 KiB
File Format: Antelope
Data path: /var/lib/mysql/xxx/conn_infos.ibd
Table collation: utf8_general_ci

Structure:
-----------
CREATE TABLE `conn_infos` (
  `info_id` int(11) NOT NULL,
  `dist_id` int(11) NOT NULL,
  `t_kind` varchar(12) DEFAULT NULL,
  `dest_name` varchar(18) DEFAULT NULL,
  `home_no` int(11) DEFAULT NULL,
  `dept_time` varchar(15) DEFAULT NULL,
  `delay` int(11) DEFAULT NULL,
  `z_station` varchar(12) DEFAULT NULL,
  `t_no` varchar(18) DEFAULT NULL,
  PRIMARY KEY (`info_id`),
  KEY `FK_conn_infos` (`dist_id`),
  CONSTRAINT `FK_conn_infos` FOREIGN KEY (`dist_id`) REFERENCES `conn_dists` (`dist_id`) ON DELETE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8

Version Details-

Server OS: centos-release-6-5.el6.centos.11.1.x86_64
Client OS: Microsoft Windows 7 x86 Service Pack 1
MySQL: 5.6.26 MySQL Community Server (GPL)
Workbench: 6.3.4.0 build 828 (32 bit) Community Edition

Note: The other tables are still operable, even after this failure.

How to repeat:
Not known, since there was no special steps followed.

If you use the command line mysql.exe it works?. Thanks.

I haven't tested yet in command line. I'll test and inform. However, through other tool or from a Database program, the table is accessible.

I haven't tested yet in command line. I'll test and inform. However, through other tool or from a Database program, the table is accessible.

Well! I have tried to connect it from command line using mysql.exe and it was connected successfully. With other tables, that table is also accessible (checked by a SELECT query). No problem, at all.

I tried it on Ubuntu, Win7 but I'm not seeing this issue with dummy data, could you please provide complete repeatable test case i.e table definition(only conn_dists, since you have already provided conn_infos), subset of data of below tables to reproduce the issue at our end(you may mark it as private after uploading)-

conn_infos
conn_dists

Thanks,
Umesh

Hi! Sorry for the delay. Here I'm giving 2 more connected tables definitions.

CREATE TABLE `conn_dists` (
  `dist_id` int(11) NOT NULL,
  `a_route_id` int(11) NOT NULL,
  `dist_name` varchar(3) DEFAULT NULL,
  `route_id` int(11) NOT NULL,
  `self_id` int(11) NOT NULL,
  PRIMARY KEY (`dist_id`),
  KEY `FK_route_id` (`route_id`),
  KEY `FK_a_conndists` (`a_route_id`),
  CONSTRAINT `FK_a_conndists` FOREIGN KEY (`a_route_id`) REFERENCES `a_conn_routes` (`a_route_id`) ON DELETE CASCADE,
  CONSTRAINT `FK_route_id` FOREIGN KEY (`route_id`) REFERENCES `conn_routes` (`route_id`) ON DELETE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

CREATE TABLE `a_conn_routes` (
  `a_route_id` int(11) NOT NULL,
  `station_id` int(11) NOT NULL,
  `route_name` varchar(12) DEFAULT NULL,
  PRIMARY KEY (`a_route_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

I haven't tried with any linux environment, since I'm bounded with some limited privileges. However, the server is on a Cent OS machine, and the database was exported from one Linux machine to another (current server and both are Cent OS). But it was imported via Workbench in Win7.

I couldn't repeat too so I assume is something on your/server environment.

I don't understanding actually. If the server had a problem then probably other applications (e.g. SQLYog, or Java/Hibernate application) were not be able to access the all the tables of same DB. All are situated in same client environment targeting to same server environment. Then why is it only happening with Workbench?