MySQL service启动脚本浅析(r12笔记第59天)

我们在搭建MySQL环境的时候,一般都会按照建议的标准规范来做,比如拷贝mysql.server到自启动目录下。

cp -rf $basedir/support-files/mysql.server /etc/init.d/mysql

然后设置MySQL自启动的服务,配置完成之后就可以运行命令service mysql.server start 来启动MySQL了。

/sbin/chkconfig --add mysql
/sbin/chkconfig --level 2345 mysql on

    当然这个是自动挡的操作,我们也可以手动档完成。我们来看看这个神奇的脚本在做些什么。脚本的内容较长,我就列出一部分内容来。

首先这个文件的名字没有直接的影响了,我们可以用mysql mysql.server等等,在这个目录下注册都可以正常识别。

# service mysql status
 SUCCESS! MySQL (Percona Server) running (15924)在/etc/inid.d这个目录下,这个mysql命名的脚本文件其实也不大,大概10K的内容,不到400行的脚本量。   # ll mysql
-rwxr-xr-x 1 root root 11056 Aug 28  2013 mysql我们取出重点的部分来解析。

首先这个脚本支持start,stop,restart,reload(或者是force-reload),status这个几个选项。

start的部分核心部分即为:

# may be overwritten at next upgrade.
      $bindir/mysqld_safe --datadir="$datadir" --pid-file="$mysqld_pid_file_path" $other_args >/dev/null 2>&1 &
      wait_for_pid created "$!" "$mysqld_pid_file_path"; return_value=$?

   其实这个选项很容易理解了,就是mysqld_safe来启动,需要制定几个启动参数,有些参数虽然为空,但是会从/etc/my.cnf中获取,也可以支持额外的扩展参数。

  我们修改下脚本,把这几个参数值手工打印出来。

分别是$bindir  $datadir  $mysqld_pid_file_path $other_args

# service mysql  start
Starting MySQL (Percona Server)
/usr//bin
/U01/mysql
/U01/mysql/mysql.pid

...... SUCCESS!datadir会有一系列校验,但是也会以/etc/my.cnf的优先

# cat /etc/my.cnf|grep datadir
datadir = /U01/mysql

另外basedir也是类似,你看my.cnf里设置的如果不够规范,也在应用的时候就是/usr//bin了。

# cat /etc/my.cnf|grep basedir
basedir = /usr/

接下来mysqld_safe的脚本下面会有较多的校验。

wait_for_pid created "$!" "$mysqld_pid_file_path"; return_value=$?启动的过程中,会在/var/lock/subsys下生成一个锁定文件,就是一个进程号的标记。    
# ll /var/lock/subsys/mysql
-rw-r--r-- 1 root root 0 May  9 23:03 /var/lock/subsys/mysqlwait_for_pid这个函数会调用created(start模式),removed(stop模式)来处理pid文件。

 而stop模式的实现相对更直接一些,它是使用kill -0的方式来检测进程是否存在,如果存在则使用kill的命令来杀掉mysqld进程。

 if test -s "$mysqld_pid_file_path"
    then
      mysqld_pid=`cat "$mysqld_pid_file_path"`
      if (kill -0 $mysqld_pid 2>/dev/null)
      then
        echo $echo_n "Shutting down MySQL (Percona Server)"
        kill $mysqld_pid
        # mysqld should remove the pid file when it exits, so wait for it.
        wait_for_pid removed "$mysqld_pid" "$mysqld_pid_file_path"; return_value=$?
      else
        log_failure_msg "MySQL (Percona Server) server process #$mysqld_pid is not running!"
        rm "$mysqld_pid_file_path"
      fi这个过程中,后台日志会逐步输出,然后释放锁定文件。

reload的过程使用的相对和缓,使用了kill -HUP的选项,如果想要更改配置而不需停止并重新启动服务,可以使用这个选项。

'reload'|'force-reload')
    if test -s "$mysqld_pid_file_path" ; then
      read mysqld_pid <  "$mysqld_pid_file_path"
      kill -HUP $mysqld_pid && log_success_msg "Reloading service MySQL (Percona Server)"
      touch "$mysqld_pid_file_path"
    else
      log_failure_msg "MySQL (Percona Server) PID file could not be found!"
      exit 1
    fi

 restart的部分就是间接调用stop和start选项。

'restart')
    # Stop the service and regardless of whether it was
    # running or not, start it again.
    if $0 stop  $other_args; then
      $0 start $other_args
    else
      log_failure_msg "Failed to stop running server, so refusing to try to start."
      exit 1
    fistatus的部分更简单,就是读取pid文件中的进程号信息。

 不要小看这个脚本,里面涉及不少逻辑校验,也可以在这个基础上根据自己的需求来做一些改变。至少在这一点上,这个脚本是可以根据我们的需求来定制的。

时间: 2024-10-02 21:18:11

MySQL service启动脚本浅析(r12笔记第59天)的相关文章

MySQL中的binlog和redo浅析(r12笔记第5天)

   有一个小问题可能很多人都想起过,那就是MySQL中既然已经有了binlog,为什么还需要redo,这个问题看起来好像很简单,但是细细品来,还是有不少值得注意的地方.     对于数据恢复,尤其是异常宕机的情况下,再次启动的时候,如何恢复,恢复的数据依据,这个尤为重要,在MySQL中是有checkpoint的技术来做一个基本的检查点控制,也就是常说的LSN,对于事务性数据库,大都会采用write ahead log的策略,即当前事务提交的时候,先写redo,在修改相应的页,如果发生宕机导致数

【Mysql 学习】mysqld_safe:MySQL服务器启动脚本

      在Unix和NetWare中推荐使用mysqld_safe来启动mysqld服务器.mysqld_safe增加了一些安全特性,例如当出现错误时重启服务器并向错误日志文件写入运行时间信息. 注释:为了保持同旧版本MySQL的向后兼容性,MySQL二进制分发版仍然包括safe_mysqld作为mysqld_safe的符号链接.但是,你不应再依赖它,因为再将来将删掉它.默认情况下,mysqld_safe尝试启动可执行mysqld-max(如果存在),否则启动mysqld. 该行为的含义是:

mysql安全启动脚本mysqld_safe详细介绍_Mysql

在Unix和NetWare中推荐使用mysqld_safe来启动mysqld服务器.mysqld_safe增加了一些安全特性,例如当出现错误时重启服务器并向错误日志文件写入运行时间信息.本节后面列出了NetWare的特定行为. 注释:为了保持同旧版本MySQL的向后兼容性,MySQL二进制分发版仍然包括safe_mysqld作为mysqld_safe的符号链接.但是,你不应再依赖它,因为再将来将删掉它. 默认情况下,mysqld_safe尝试启动可执行mysqld-max(如果存在),否则启动m

MySQL源码安装总结(r12笔记第12天)

作为一个DBA, MySQL源码安装还是要做做的,虽然不是推荐线上批量安装部署,但是自己作为了解MySQL的一个学习过程,还是值得的. 相比商业软件来说,开源的这一点上就让人很羡慕,商业软件我们总是使用各种工具和底层原理去反推,探测,但是离代码还是有一定的距离.当然商业有商业的好,开源有开源的乐,不能一概而论. 值得推荐的安装镜像 对于MySQL的安装部署来说,总是存在各种版本和子版本,其实整理起来非常繁杂,今天看到竟然我狐已经提供了非常的镜像站点 http://mirrors.sohu.com

Oracle 12c DBCA浅析(r12笔记第48天)

   我们知道在11g的环境中我们可以通过一些分析来得到DBCA的一些后台处理工作,有一点需要说明的是,如果一个12c的单实例数据库需要转换为12c的容器数据库,你去查看官方文档,会发现这是一个空白,不是做不了,而是里面有一些地方会干扰到你.   所以在11g手工探究脚本过程的基础上,12c的部分你需要再进一步.常规来说,我们可以通过如下的命令得到一个12c的数据库创建的脚本. dbca -silent  -templateName $ORACLE_HOME/assistants/dbca/te

MySQL中的反连接(r12笔记第45天)

  关于Oracle的半连接,反连接,我一直认为这是一个能讲很长时间的话题,所以在我的新书<Oracle DBA工作笔记>中讲性能优化的时候,我花了不少的笔墨做了阐述,结果在做MySQL性能优化的时候,优化思路切换到MySQL层面,我发现要说的东西要更多.总体来看,这部分的优化细节MySQL还在路上,不同的版本中都能够一窥其中的变化,可以看到在不断改进.    在表的连接上,半连接,反连接本身很平常,但是统计信息的不够丰富导致执行计划的评估中可能会出现较大差别,会很可能把半连接,反连接的实现方

MySQL传输表空间小结(r12笔记第2天)

  在MySQL中如果要迁移一个表导另外一个服务器/环境中,常规的做法就是使用备份工具备份,比如mysqldump,然后拷贝备份到目标服务器或者环境导入.如果某一个表数据量很大,导出dump文件很大的情况下,使用导出导入工具其实会花费不少的时间.    怎么样提高效率呢,可以有一种想法就是直接拷贝数据文件到目标环境,当然在早期版本中这么做是不可取的,因为会有很多关联数据在ibdata中,InnoDB的数据存在对应的数据字典信息,是存放在共享表空间中,无法直接剥离出来,而在5.6/5.7中,就推出

MySQL中的derived table(r12笔记第47天)

初始MySQL中的derived table还是在一个偶然的问题场景中. 下面的语句在执行的时候抛出了错误. UPDATE payment_data rr    SET rr.penalty_date = '2017-4-12'  where rr.id =        (SELECT min(r.id)           FROM payment_data r          where data_no =                (SELECT data_no          

MySQL中GTID和自增列的数据测试(r12笔记第38天)

  昨天的一篇文章,今天有不少网友向我确认一些细节,我想最近正好在看GTID的东西,可以揉在一起来说说.    GTID这个概念看似简单,实际上还是有不少的门道. 我们来从架构的设计角度来看看存在哪些场景需要考虑GTID的变化.   一主两从的架构模式下GTID的变化   我们就以一主两从的架构为基准进行阐述.在这个架构模式下我们会用到MHA的方案.    如果这个时候Master节点宕机了,MHA就会开启检查机制. 这个时候Slave 1节点就会变为新的Master,Slave 2会从Slav