MySQL内核月报 2015.03-MySQL · 捉虫动态· pid file丢失问题分析

现象

mysql5.5,通过命令show variables like '%pid_file%'; 可以查到pid文件位置,例如/home/mysql/xx.pid。但发现在此目录下找不到此pid文件。

背景知识

mysql pid文件记录的是当前mysqld进程的pid。

通过mysqld_safe启动mysqld时,mysqld_safe会检查PID文件,未指定PID文件时,pid文件默认名为$DATADIR/`hostname`.pid

  • pid文件不存在,不做处理
  • 文件存在,且pid已占用则报错"A mysqld process already exists";文件存在,但pid未占用,则删除pid文件。

mysqld启动后会通过create_pid_file函数新建pid文件,通过getpid()获取当前进程pid并将pid写入pid文件。

因此,通过mysqld_safe启动时,pid文件的作用是为了防止同一个数据库被启动多次(数据文件是同一份,但端口不同的情况)。

另一个事实是mysqld在正常关闭时或通过SIGQUIT,SIGKILL,SIGTERM信号来kill mysqld时,会调用clean_up函数将pid文件删除。而mysqld异常crash时,pid文件是保留的。

另外mysqld_safe有一个功能是当mysqld异常crash时,后台会自动重启mysqld。mysqld关闭后,mysqld_safe会检查pid文件是否存在。如果存在则认为mysqld是异常crash, 需要自动重启;如果不存在则认为是正常关闭的,不需要自动重启,mysqld_safe程序也退出。

原因分析

查看error log发现数据库在相近的时间内启动了两次


前面说到mysqld_safe启动mysqld时,会根据pid文件来判断避免重复启动mysqld.然而,由于两次启动时间较近,导致第一次mysqld启动生成pid文件之前,第二个mysqld就已开始启动了,从而绕过了这个判断。第一次mysqld启动会成功,而第二次mysqld启动会因为文件锁而导致启动失败。


第二次启动的mysqld关闭时会将第一次启动时产生的pid文件删除,从而导致pid文件丢失。

通过mysqld_safe启动mysqld来重现pid文件丢失有一定的概率性,必须是同时启动mysqld_safe。 如果是直接通过mysqld启动,同时指定相同的参数启动两次,那么就很容易重现了。

修复

参考5.6 官方的修复方法,在上述场景下删除pid文件时,需判断是否是自己新建的pid文件,同时文件中的pid是否和自身pid一致,否则不能删除。参考补丁

MySQL · 答疑释惑· using filesort VS using temporary

背景

MySQL 执行查询语句, 对于order by谓词,可能会使用filesort或者temporary。比如explain一条语句的时候,会看到Extra字段中可能会出现,using filesort和using temporary。下面我们就来探讨下两个的区别和适用场景。

解释

1. using filesort

filesort主要用于查询数据结果集的排序操作,首先MySQL会使用sort_buffer_size大小的内存进行排序,如果结果集超过了sort_buffer_size大小,会把这一个排序后的chunk转移到file上,最后使用多路归并排序完成所有数据的排序操作。

MySQL filesort有两种使用模式:

模式1: sort的item保存了所需要的所有字段,排序完成后,没有必要再回表扫描。
模式2: sort的item仅包括<sort_key, rowid>,待排序完成后,根据rowid查询所需要的columns。

很明显,模式1能够极大的减少回表的随机IO。

2. using temporary

MySQL使用临时表保存临时的结构,以用于后续的处理,MySQL首先创建heap引擎的临时表,如果临时的数据过多,超过max_heap_table_size的大小,会自动把临时表转换成MyISAM引擎的表来使用。

从上面的解释上来看,filesort和temporary的使用场景的区别并不是很明显,不过,有以下的原则:

filesort只能应用在单个表上,如果有多个表的数据需要排序,那么MySQL会先使用using temporary保存临时数据,然后再在临时表上使用filesort进行排序,最后输出结果。

适用场景

我们看一下下面的三个case:



case 1:


case1: order by字段能够使用index的有序性,所以没有使用filesort,也没有使用temporary。

case 2:


case2: order by谓词,是在第一个表t1上完成,所以只需要在t1表上使用filesort,然后排序后的结果集join t2表。

case 3:


case 3: order by的字段在t2表上,所以需要把t1,t2表join的结果保存到temporary表上,然后对临时表进行filesort,最后输出结果。

特别优化

MySQL对order by + limit的filesort做了特别优化,使用Priority queue来保存结果,即一个堆的结构,只保留top n的数据满足limit条件。

另外

filesort和temporary都会在tmp目录下创建文件,temporary创建的是MYI,MYD文件。但filesort的文件, 因为MySQL使用了create->open->unlink->使用->close的方式,隐藏了文件,以便进程异常结束的时候,临时文件能够自动回收掉,所以在评估tmp目录空间的时候,需要特别注意。

时间: 2024-08-03 08:36:11

MySQL内核月报 2015.03-MySQL · 捉虫动态· pid file丢失问题分析的相关文章

MySQL内核月报 2014.11-MySQL· 捉虫动态·SIGHUP 导致 binlog 写错

bug描述 这是5.6中和gtid相关的一个bug,当 mysqld 收到 sighup 信号 (比如 kill -1) 的时候,会 flush binlog,但是新生成binlog开头没写 Previous_gtids_log_event,这会导致下面 2 个问题: 这个时候 mysqld 重启的话,会发现再也起不来了,error log 里有这样的错 The binary log file 'mysql/mysql-bin.000020' is logically corrupted: Th

MySQL内核月报 2014.09-MySQL· 捉虫动态·GTID 和 DELAYED

描述 这是一个MySQL 5.6才有的bug,影响包含最新版本.涉及到的概念有GTID.DELAYED. 现象 在5.6主备都开启GTID-MODE的时候,备库同步线程停止,且Last_SQL_Error显示"When @@SESSION.GTID_NEXT is set to a GTID, you must explicitly set it to a different value after a COMMIT or ROLLBACK. Please check GTID_NEXT var

MySQL内核月报 2014.09-MySQL· 捉虫动态·auto_increment

背景: Innodb引擎使用B_tree结构保存表数据,这样就需要一个唯一键表示每一行记录(比如二级索引记录引用). Innodb表定义中处理主键的逻辑是: 1.如果表定义了主键,就使用主键唯一定位一条记录 2.如果没有定义主键,Innodb就生成一个全局唯一的rowid来定位一条记录 auto_increment的由来: 1.Innodb强烈推荐在设计表中自定义一个主键,因为rowid是全局唯一的,所以如果有很多表没有定义主键,就会在生成rowid上产生争用. row_id由mutex保护,并

MySQL内核月报 2014.08-MySQL· 捉虫动态·Count(Distinct) ERROR

背景 MySQL现行版本中存在一个count(distinct)语句返回结果错误的bug,表现为,实际结果存在值,但是用count(distinct)统计后返回的是0. 原因分析 Count(distinct f)的语义就是计算字段f的去重总数,计算流程大致如下: 流程一: 1. 构造一个unique集合A1(用tree实现) 2. 对每个值都试图插入集合A1中 3. 若和A1中现有item重复则直接跳过,不重复则插入并+1 4. 完成后计算集合中元素个数. 细心的同学会看到上面的语句中有一个s

MySQL内核月报 2014.10-MySQL· 捉虫动态·binlog重放失败

背景 在 MySQL 日常维护中,要回滚或者恢复数据,我们经常会用 binlog 来在数据库上重放,执行类似下面的语句: mysqlbinlog mysql-bin.000001 | mysql -hxxxx -Pxx -u 最近遇到了这样一个问题,在重放 binlog 时,mysqld 报这样的错 ERROR 1064 (42000) at line 25: You have an error in your SQL syntax; check the manual that correspo

MySQL内核月报 2014.10-MySQL· 捉虫动态·从库OOM

bug背景 官方最近发布的版本(5.7.5)修复了这样一个bug,主备复制场景下,如果主库和备库对应的表结构中有数据类型不一致,并且主库的 binlog 是 row 格式的,这时候如果主库对不一致的表做了一个大事务更新,备库在应用 relay-log 的时候报OOM(Out of Memory).bug地址在这里,主备数据类型不一致主要发生在这2种情况下: 主备库版本不一致,不同版本之间的数据类型可能存在不一致.用户在报这个bug时,就是在5.5到5.6的复制场景下,用到了时间类型,时间类型在5

MySQL内核月报 2014.12-MySQL· 捉虫动态·Opened tables block read only

背景 MySQL通过read_only参数来设置DB只读,这样MySQL实例就可以作为slave角色,只应用binlog,不接受用户修改数据.这样就可以保护master-slave结构中的数据一致性,防止双写风险. global read_only的实现方式 MySQL5.5版本通过三个步骤来设置read_only: 步骤1:获取global read lock,阻塞所有的写入请求 步骤2:flush opened table cache,阻塞所有的显示读写锁 步骤3:获取commit lock

MySQL内核月报 2014.09-MySQL· 捉虫动态·GTID 和 binlog_checksum

现象描述 在5.6主备环境下,主备都开启GTID-MODE,备库开启crc校验,主库不开.重启备库sql线程后,备库sql线程停止Last_Error显示:Relay log read failure: Could not parse relay log event entry. The possible reasons are: the master's binary log is corrupted(you can check this by running 'mysqlbinlog' on

MySQL内核月报 2014.10-MySQL· 捉虫动态·崩溃恢复失败

现象 5.6版本,在创建InnoDB表过程中,若发生crash,会导致服务无法启动. 背景 每个InnoDB表A创建成功后有两个文件A.frm和A.ibd.建表流程如下: 1.创建A.frm 2.创建A.ibd 3.初始化A.ibd 4.将表A加入InnoDB字典 若crash发生在步骤2之后,则只保留一个完整的A.frm和一个空文件A.idb. 崩溃恢复 在上述的crash发生后,下一次启动则需要做崩溃恢复.崩溃恢复的一个逻辑是需要遍历数据目录下的所有.ibd文件,验证文件与字典的一致性. 对