ius-coredev team mailing list archive

[Sean <sean.dennis@xxxxxxxxx>]

Hey Ben,

Thanks for checking it out. That would explain why we're not seeing it
happen very often.

I double checked the second server and the shutdown duration was also greater that 60 seconds:
130905  4:55:17 [Note] Event Scheduler: Purging the queue. 0 events
130905  4:55:17 [Note] Error reading relay log event: slave SQL thread was killed
130905  4:55:17 [Note] Slave I/O thread killed during or after a reconnect done to recover from failed read
130905  4:55:17 [Note] Slave I/O thread exiting, read up to log 'bin-log.000107', position 507847775
130905  4:55:18  InnoDB: Starting shutdown...
130905 04:56:19 mysqld_safe A mysqld process already exists
130905  4:56:38  InnoDB: Shutdown completed; log sequence number 229261981132
130905  4:56:38 [Note] /usr/libexec/mysqld: Shutdown complete
130905 04:56:39 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended

I was looking through the code for the init script and I suspect that if a "restart" was sent, even with the timeout, it would still attempt a "start" after the "stop" even though the "stop" didn't complete successfully. After checking the logs more carefully I saw that it tried to restart it based on the line that says [ mysqld_safe A mysqld process already exists
 ] which is just over a minute after initiating the shutdown request. 

This means that you are correct and increasing the shutdown timeout
should help as it was trying to restart mysql before the service
finished shutting down properly. The master database server took just
under 5 minutes to shutdown based on the logs and the slave took just
over a minute to shutdown.

I'm not sure what a reasonable shutdown timeout would be but I suspect
that servers that have a large data set or have replication running
could take a little longer than a minute to shutdown gracefully.

Thanks for the info!

-Sean

-- 
You received this bug notification because you are a member of IUS Core
Development, which is subscribed to IUS Community Project.
https://bugs.launchpad.net/bugs/1221261

Title:
  CentOS/RedHat 6.4 MySQL Server update not starting the MySQL service

Status in IUS Community Project:
  New
Status in CentOS:
  New

Bug description:
  I have two RHEL 6.4 servers in a master slave setup and both
  successfully updated the MySQL Server package [
  mysql55-server-5.5.33-1.ius.el6.x86_64 ] and other MySQL packages and
  gracefully stopped the MySQL service but doesn't restart it.

  -------------------------
  Extract from [ /var/log/yum.log ]:
  Sep 05 04:06:01 Updated: mysql55-libs-5.5.33-1.ius.el6.x86_64
  Sep 05 04:06:03 Updated: mysqlclient16-5.1.61-2.ius.el6.x86_64
  Sep 05 04:06:07 Updated: mysql55-5.5.33-1.ius.el6.x86_64
  Sep 05 04:06:11 Updated: mysql55-server-5.5.33-1.ius.el6.x86_64
  Sep 05 04:06:12 Updated: mysql55-devel-5.5.33-1.ius.el6.x86_64

  -------------------------
  [ Extract from /var/log/mysqld.log ]:
  130905  4:06:12 [Note] /usr/libexec/mysqld: Normal shutdown
  130905  4:06:13 [Note] Event Scheduler: Purging the queue. 0 events
  130905 04:07:15 mysqld_safe A mysqld process already exists
  130905  4:07:37  InnoDB: Starting shutdown...
  130905  4:07:38  InnoDB: Waiting for 200 pages to be flushed
  130905  4:11:03  InnoDB: Shutdown completed; log sequence number 250713953621
  130905  4:11:03 [Note] /usr/libexec/mysqld: Shutdown complete
  130905 04:11:04 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended
  #--Manually started by me hours later:
  130905 08:19:28 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql

  -------------------------
  Both servers started up with no issues when I did it manually, but it just seems that the update never triggered a restart as it did in all other previous mysql55-server updates throughout the year.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ius/+bug/1221261/+subscriptions