MySQL Service Running But Unable to Connect

Hi ,

Looks we are facing something weird. We have recently upgraded from MySQL 5.6 to Percona 5.7, Since that time when we restart MySQL service or system reboot. MySQL service is starting but unable to login and it does not say any error.

MySQL status:

[root@******* ~]# ps -ef | grep mysql
root 1894 1 0 07:00 ? 00:00:00 /bin/sh /usr/bin/mysqld_safe --datadir=/test/mysql --socket=/var/lib/mysql/mysql.sock --pid-file=/var/run/mysqld/mysqld.pid --basedir=/usr --user=mysql
mysql 2487 1894 46 07:00 ? 00:33:25 /usr/sbin/mysqld --basedir=/usr --datadir=/test/mysql --plugin-dir=/usr/lib64/mysql/plugin --user=mysql --log-error=/test/mysql/mysql.err --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/lib/mysql/mysql.sock --port=3306
root 3937 3928 0 07:24 pts/2 00:00:00 mysql -p
root 4655 4634 0 08:12 pts/1 00:00:00 grep mysql
[root@******* ~]# /etc/init.d/mysql status
mysqld (pid 2487) is running…

Connection Status: Got Struck after entering password.
[root@********* ~]# mysql -p
Enter password:

Error Log Information:
016-06-16T12:00:36.173239Z 0 [Note] /usr/sbin/mysqld (mysqld 5.7.11-4-log) starting as process 2487 …
2016-06-16T12:00:36.429590Z 0 [Note] InnoDB: PUNCH HOLE support available
2016-06-16T12:00:36.429667Z 0 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2016-06-16T12:00:36.429688Z 0 [Note] InnoDB: Uses event mutexes
2016-06-16T12:00:36.429708Z 0 [Note] InnoDB: GCC builtin __atomic_thread_fence() is used for memory barrier
2016-06-16T12:00:36.429727Z 0 [Note] InnoDB: Compressed tables use zlib 1.2.3
2016-06-16T12:00:36.429746Z 0 [Note] InnoDB: Using Linux native AIO
2016-06-16T12:00:36.447743Z 0 [Note] InnoDB: Number of pools: 1
2016-06-16T12:00:36.453814Z 0 [Note] InnoDB: Not using CPU crc32 instructions
2016-06-16T12:00:36.487268Z 0 [Note] InnoDB: Initializing buffer pool, total size = 46G, instances = 8, chunk size = 128M
2016-06-16T12:00:44.282103Z 0 [Note] InnoDB: Completed initialization of buffer pool
2016-06-16T12:00:45.006136Z 0 [Note] InnoDB: If the mysqld execution user is authorized, page cleaner thread priority can be changed. See the man page of setpriority().
2016-06-16T12:00:45.081708Z 0 [Note] InnoDB: Recovering partial pages from the parallel doublewrite buffer at /test/mysql/xb_doublewrite
2016-06-16T12:00:45.288844Z 0 [Note] InnoDB: Highest supported file format is Barracuda.
2016-06-16T12:00:46.168862Z 0 [Note] InnoDB: Log scan progressed past the checkpoint lsn 12467296801657
2016-06-16T12:00:50.694889Z 0 [Note] InnoDB: Doing recovery: scanned up to log sequence number 12467302044160
2016-06-16T12:00:51.247056Z 0 [Note] InnoDB: Doing recovery: scanned up to log sequence number 12467307287040
2016-06-16T12:00:51.752208Z 0 [Note] InnoDB: Doing recovery: scanned up to log sequence number 12467312529920
2016-06-16T12:00:52.273366Z 0 [Note] InnoDB: Doing recovery: scanned up to log sequence number 12467317772800
2016-06-16T12:00:56.122673Z 0 [Note] InnoDB: Doing recovery: scanned up to log sequence number 12467354472960
2016-06-16T12:00:56.585687Z 0 [Note] InnoDB: Doing recovery: scanned up to log sequence number 12467359715840
2016-06-16T12:00:57.052940Z 0 [Note] InnoDB: Doing recovery: scanned up to log sequence number 12467364958720
2016-06-16T12:00:57.521907Z 0 [Note] InnoDB: Doing recovery: scanned up to log sequence number 12467370201600
2016-06-16T12:00:58.082405Z 0 [Note] InnoDB: Doing recovery: scanned up to log sequence number 12467375444480
2016-06-16T12:00:58.534194Z 0 [Note] InnoDB: Doing recovery: scanned up to log sequence number 12467380687360
2016-06-16T12:00:59.070548Z 0 [Note] InnoDB: Doing recovery: scanned up to log sequence number 12467385930240
2016-06-16T12:00:59.489896Z 0 [Note] InnoDB: Doing recovery: scanned up to log sequence number 12467391173120
2016-06-16T12:01:00.024039Z 0 [Note] InnoDB: Doing recovery: scanned up to log sequence number 12467396416000
2016-06-16T12:01:00.611008Z 0 [Note] InnoDB: Doing recovery: scanned up to log sequence number 12467401658880
2016-06-16T12:01:01.133693Z 0 [Note] InnoDB: Doing recovery: scanned up to log sequence number 12467406901760
2016-06-16T12:01:01.620245Z 0 [Note] InnoDB: Doing recovery: scanned up to log sequence number 12467412144640
2016-06-16T12:01:02.132354Z 0 [Note] InnoDB: Doing recovery: scanned up to log sequence number 12467417387520
2016-06-16T12:01:02.731034Z 0 [Note] InnoDB: Doing recovery: scanned up to log sequence number 12467422630400
2016-06-16T12:01:03.237224Z 0 [Note] InnoDB: Doing recovery: scanned up to log sequence number 12467427873280
2016-06-16T12:01:04.867713Z 0 [Note] InnoDB: Doing recovery: scanned up to log sequence number 12467443601920
2016-06-16T12:01:05.382507Z 0 [Note] InnoDB: Doing recovery: scanned up to log sequence number 12467448844800
2016-06-16T12:01:08.061284Z 0 [Note] InnoDB: Doing recovery: scanned up to log sequence number 12467475059200
2016-06-16T12:01:08.543405Z 0 [Note] InnoDB: Doing recovery: scanned up to log sequence number 12467480302080
2016-06-16T12:01:09.047150Z 0 [Note] InnoDB: Doing recovery: scanned up to log sequence number 12467485544960
2016-06-16T12:01:09.537615Z 0 [Note] InnoDB: Doing recovery: scanned up to log sequence number 12467490787840
2016-06-16T12:01:15.046780Z 0 [Note] InnoDB: Doing recovery: scanned up to log sequence number 12467558945280
2016-06-16T12:01:15.438353Z 0 [Note] InnoDB: Doing recovery: scanned up to log sequence number 12467564188160
2016-06-16T12:01:15.950878Z 0 [Note] InnoDB: Doing recovery: scanned up to log sequence number 12467569431040
2016-06-16T12:01:16.541727Z 0 [Note] InnoDB: Doing recovery: scanned up to log sequence number 12467574673920
2016-06-16T12:01:17.134392Z 0 [Note] InnoDB: Doing recovery: scanned up to log sequence number 12467579916800
2016-06-16T12:01:17.691725Z 0 [Note] InnoDB: Doing recovery: scanned up to log sequence number 12467585159680
2016-06-16T12:01:18.196833Z 0 [Note] InnoDB: Doing recovery: scanned up to log sequence number 12467590402560
2016-06-16T12:01:18.703155Z 0 [Note] InnoDB: Doing recovery: scanned up to log sequence number 12467595645440
2016-06-16T12:01:19.261710Z 0 [Note] InnoDB: Doing recovery: scanned up to log sequence number 12467600888320
2016-06-16T12:01:50.733406Z 0 [Note] InnoDB: Database was not shutdown normally!
2016-06-16T12:01:50.733419Z 0 [Note] InnoDB: Starting crash recovery.
2016-06-16T12:01:51.836176Z 0 [Note] InnoDB: Created parallel doublewrite buffer at /cradius-db/mysql/xb_doublewrite, size 31457280 bytes
2016-06-16T12:01:54.011493Z 0 [Note] InnoDB: Starting an apply batch of log records to the database…
InnoDB: Progress in percent: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99
2016-06-16T12:05:48.002265Z 0 [Note] InnoDB: Apply batch completed
2016-06-16T12:05:48.002367Z 0 [Note] InnoDB: Last MySQL binlog file position 0 652608750, file name mysql-bin.000408
2016-06-16T12:06:04.738697Z 0 [Note] InnoDB: Removed temporary tablespace data file: “ibtmp1”
2016-06-16T12:06:04.738822Z 0 [Note] InnoDB: Creating shared tablespace for temporary tables
2016-06-16T12:06:04.738941Z 0 [Note] InnoDB: Setting file ‘./ibtmp1’ size to 12 MB. Physically writing the file full; Please wait …
2016-06-16T12:06:07.509061Z 0 [Note] InnoDB: File ‘./ibtmp1’ size is now 12 MB.
2016-06-16T12:06:07.512476Z 0 [Note] InnoDB: 96 redo rollback segment(s) found. 96 redo rollback segment(s) are active.
2016-06-16T12:06:07.512585Z 0 [Note] InnoDB: 32 non-redo rollback segment(s) are active.
2016-06-16T12:06:07.513704Z 0 [Note] InnoDB: page_cleaner: 1000ms intended loop took 322510ms. The settings might not be optimal. (flushed=0, during the time.)
2016-06-16T12:06:07.539480Z 0 [Note] InnoDB: Waiting for purge to start
2016-06-16T12:06:07.589933Z 0 [Note] InnoDB: Percona XtraDB (http://www.percona.com) 5.7.11-4 started; log sequence number 12467610798503
2016-06-16T12:06:07.591787Z 0 [Note] InnoDB: Loading buffer pool(s) from /test/mysql/ib_buffer_pool
2016-06-16T12:06:07.615231Z 0 [Note] Plugin ‘FEDERATED’ is disabled.
2016-06-16T12:06:08.102756Z 0 [Note] Found ca.pem, server-cert.pem and server-key.pem in data directory. Trying to enable SSL support using them.
2016-06-16T12:06:08.102862Z 0 [Note] Skipping generation of SSL certificates as certificate files are present in data directory.
2016-06-16T12:06:08.226811Z 0 [Warning] CA certificate ca.pem is self signed.
2016-06-16T12:06:08.227260Z 0 [Note] Skipping generation of RSA key pair as key files are present in data directory.
2016-06-16T12:06:08.262168Z 0 [Note] Server hostname (bind-address): ‘'; port: 3306
2016-06-16T12:06:08.273533Z 0 [Note] IPv6 is not available.
2016-06-16T12:06:08.273676Z 0 [Note] - ‘0.0.0.0’ resolves to ‘0.0.0.0’;
2016-06-16T12:06:08.273706Z 0 [Note] Server socket created on IP: ‘0.0.0.0’.
2016-06-16T12:06:11.606869Z 0 [Warning] Neither --relay-log nor --relay-log-index were used; so replication may break when this MySQL server acts as a slave and has his hostname changed!! Please use '–relay-log=
*****-relay-bin’ to avoid this problem.
2016-06-16T12:33:56.911959Z 0 [Note] InnoDB: page_cleaner: 1000ms intended loop took 4059ms. The settings might not be optimal. (flushed=200, during the time.)
2016-06-16T12:38:02.844271Z 0 [Note] InnoDB: page_cleaner: 1000ms intended loop took 4877ms. The settings might not be optimal. (flushed=164, during the time.)
2016-06-16T12:59:38.545256Z 0 [Note] InnoDB: page_cleaner: 1000ms intended loop took 4171ms. The settings might not be optimal. (flushed=47, during the time.)
2016-06-16T13:00:51.987687Z 0 [Note] InnoDB: Buffer pool(s) load completed at 160616 8:00:51

After this there is not log writing. Did anyone face the same issue.