初始化选项文件
默认文件位置
Windows
- WINDIRmy.ini : WINDIR指的是Windows的目录,一版是C:WINDOWS,可以通过
echo $WINDIR$查看该变量的实际值 - 系统盘的根目录保存的文件,即`C:my.ini
- INSTALLDIRmy.ini : INSTALLDIR指的是MySQL安装目录,一版是在C:Program FilesFilesMySQLMySQL 5.6 Server目录
UNIX/Linux平台
- /etc/my.cnf
- /etc/mysql/my.cnf
- SYSCONFDIR/my.cnf : 通过CMake源码编译时指定的SYSCONFDIR参数指定的路径
- $MYSQL_HOME/my.cnf : 到MYSQL_HOME环境变量所在的路径
- ~/my.cnf : ~代表当前用户的家目录
启动时指定配置文件路径
- default-file : 从本参数指定的文件中读取选项
- default-extra-file : 在加载其他方式指定的选项后,再读取本参数指定的选项
配置文件示例
[mysqld]
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
# 还有很多就不一一写了
[mysqldump]
quick
[mysqld_safe]
log-error=/data/3306/oldboy_3306.err
配置文件分为几个部分
- # : 注释符
- [group_name] : 这个区块用于定义对应命令行的选项,以上面的选项文件为例,有[client],[mysqld],[mysqldump],[mysqlhotcopy]等,名称看起来眼熟,其实就是mysql命令行工具名称。要知道MySQL中的命令行工具是比较多的,可是因为功能的不同,因此每个命令所支持的参数也会有差异,那么单个my.cnf选项文件中怎么去指定呢?就是通过[group_name]这个区块,其实相当于指定了一个作用域。当然,也可以用defaults-file参数来给每一个命令建立对应的参数
[mysqld],[mysql]等都可以找到对应的命令,但[client]对应哪个命令呢?所有的客户端命令都属于[client]区块,作用域范围,包括mysqldump/mysqlhotcopy/mysqladmin等,哪个不属于客户端命令呢?只有一个:mysqld。由于[client]块能作用于所有命令行程序,因此注意了,该区块中指定的选项要确保能被所有调用的命令行支持,否则可能会导致命令行执行报错
- Option name : 指定具体的选项,MySQL支持的选项很多,这里就不一一列举了
- Option value : 指定选项值。很多选项值都有范围和默认值,如果指定了选项而未指定值,那么该选项就继承默认值,当然这种情况下指不指定选项都没区别。另外就是MySQL中的选项非常灵活,对于布尔型选项,指定值可以为1或0,也可以为ON或OFF
MySQL的参数除了在启动时进行指定外,其中还有相当一部分可以在MySQL服务运行过程中实时进行修改,运行过程中有两个作用域,全局(global)和当前会话(session),但是,不管是哪个作用域,如果没有同步修改my.cnf的话,MySQL服务一旦重启,运行过程中所做的修改就会自动撤销,因此一般设置的全局有效的选项,还需要同时修改my.cnf文件。
错误日志文件
错误日志是在启用mysqld时,通过log-error选项(或配置log-error系统参数)指定错误日志的路径及文件名,如果没有指定文件名,则默认文件名为[host_name].err,保存在mysql的%datadir%文件夹下。
错误日志中信息分为三类 : [Note],[Warning],[Error]。
- [Note] : 正常的MySQL服务启动或关闭信息
- [Warning] : 警告,记录一些可能影响正常功能但是有没有影响正常功能的信息,可以使用--log-warnings参数来控制是否启用(1为默认值,代表启用,0为禁用)
- [Error] : 错误信息
某些信息也会被计入系统时间日志,其实对于Linux/UNIX系统也是一样的,错误日志也可以被写入到系统日志syslog中,在执行mysqld_safe命令启动MySQL服务时,可以附加--syslog参数,使MySQL的日志信息也会被输出到系统中。对于记录到系统日志中的消息,来自mysqld_safe和mysqld的消息会分别打上"mysqld_safe"或"mysql"的标签。用户也可以通过--syslod-tag=[tag]参数指定标签名称,修改后实际记录的标签心事会变成"mysql_safe-[tag]"和"mysql-[tag]"
查询日志文件
日志文件分类
- 慢查询日志(Slow Query Log),记录执行慢的查询
- 通用查询日志(General Query Log),所有的执行的查询语句都睡记录下来
MySQL的查询日志不仅能记录到文件,还能自动保存到MySQL数据库中的表对象里。
慢查询日志
会记录所有查询语句执行时间超过系统变量long_query_time(默认值为10秒)指定的参数值,并且访问的记录数超过系统变量min_examined_row_limit(默认为0条)的数量的语句。注意SQL语句执行时间不包括初始化表锁的开销。
SQL语句执行完毕后并且完成对其锁定资源的释放后,mysqld进程会将符合条件的SQL语句写入慢查询日志,因此慢查询日志中语句记录和顺序有可能跟执行顺序不同(因为每条语句的执行时间不同)
默认情况下慢查询日志功能是被禁用的,启用和禁用慢查询日志文件都是通过MySQL的系统参数控制,主要有以下两个
- slow_query_log : 指定是否输出慢查询日志,指定为1标识输出,指定为0则标识不输出
- slow_query_log_file : 指定日志文件存储路径和文件名,如果没有指定的话,则默认文件名为[host_name]-slow.log,保存在MySQL数据库data目录下
在5.1.6之前的版本,是通过--log-slow-queries控制慢查询日志文件输出路径
上面两个参数可以在MySQL运行时实时修改
set global slow_query_log = 'OFF';
set global slow_query_log_file = 'ON';
其他相关参数
- long_query_time : 指定慢查询执行时间的阈值,以秒为单位,但最小可以指定到微秒,默认为10秒
- long_short_format : 用来控制输出到慢查询日志文件的信息,指定改选项后,会减少向慢查询日志中输出信息
- log_slow_admin_statements : 用来控制是否将一些执行时间较长的管理类型语句,如
optimize table,analyze table,alter table语句输出到慢查询日志中 - log_queries_not_using_indexes : 用来控制是否将未使用索引的语句输出到慢查询日志中
- log_throttle_queries_not_using_indexes : 一般会与log_queries_not_using_indexes参数组合使用,他的功能是控制每分钟输出到慢查询日志的未使用索引的记录条数,默认值是0,这个0不是说不输出,而是不限制
- log_slow_slave_statements : MySQL复制环境专用的参数,用来控制是否将复制的慢查询日志输出到慢查询日志
因为慢查询相关的参数有好几个,所以MySQL在处理慢查询日志输出时会有逻辑
- 执行的必须是查询语句,而非管理性语句(除非启用了log_slow_admin_statements)
- 查询语句执行的时间达到或超过了long_query_time参数指定的值,或者是符合log_queries_not_using_indexes条件
- 查询的记录量达到了min_examined_row_limit参数指定的值
- 查询语句不违反log_throttle_queries_not_using_indexes参数设置
需要注意的是,慢查询日志中有可能记录到用户权限或密码的相关的语句,比如更改mysql.user表中的数据时,如果执行速度很慢,该语句也会被记录到慢查询日志中,因此慢查询日志文件的保存也要注意安全。只不过一般来说这种授权相关的语句只有极低的概率才会出现在慢查询日志中(除非将long_query_time参数指定的极小)。
查看一个比较大的慢查询日志极为不便,可以考虑使用MySQL自带的mysqldumpslow命令,或者其他第三方工具,对慢查询日志进行抽象分析,便于阅读。
普通查询日志
普通查询日志(General Query Log)名不副实,这个日志不仅记录查询语句,而是能够记录mysqld进程所做的几乎所有操作,不仅仅是客户端发出的SQL语句会被记录到普通查询日志中,对于数据库或对象的管理操作也会记录下来,甚至客户端连接或断开连接,服务器都会向改文件中写入相应的信息。
所有启用普通查询日志最大的功能点是什么?审计!通过浏览这个日志文件中的信息,可以了解到客户端都做了些什么,这点对于DBA很有帮助,可以借此查询用户的操作是否有问题
默认普通查询为不启用,因为他的记录信息太过详尽,安全性是一方面,效率方面的影响也是值得评估的因素。不过,启用或禁用普通查询日志,也是通过MySQL的系统参数控制,如下
- general_log : 可选的参数有0和1(或者ON或OFF),0为禁用,1为启用
- general_log_file : 默认情况下,普通查询日志是保存在MySQL数据库的data目录下,如果没有明确指定文件名,则默认文件名为[host_name].log,通过本参数可以明确定义普通查询日志文件的存储路径和文件名
除了在启动MySQL服务时指定外,这两个参数还都可以在MySQL运行时动态修改
# 全局设置
set global general_log = 'ON';
set global general_log_file = 'ON';
# 当前会话设置
set general_log = 'ON';
set general_log_file = 'ON';
普通查询日志会记录客户端发出的语句(包含更新用户密码的语句),在5.6之前,密码会被明文保存在日志中,如下
grant select on my_test.* to zj_test identified by '123456';
5.6只有MySQL在保存这种语句时,会自动重写密码,如下
grant select on my_test.* to zj_test identified by '*7749C99E3D82E54D2A70FACF94E78E832F861A5F';
如果情况特殊,就是需要记录用户的明文密码,可以用--log-raw来配置,注意这个选项只能在MySQL启动前设置
配置查询日志
MySQL查询日志不仅可以被保存在文件里,同时也能够以表的形式保存在数据库mysql中的同名表中,但是要注意,保存在表中比直接保存在文件中会耗费更多的系统资源,所以还是建议将日志直接放到文件中。
放到表中在后面查询相关记录的话会很方便，两个存放方式各有利弊。
以下是设置查询日志的相关配置
1. 在MySQL服务启动时配置
指定--log-output选项,用来控制查询日志的输出方式,注意是输出方式,不是输出路径,选项如下
- TABLE : 输出信息到数据库中得标,对应general_log和slow_log两个表
- FILE : 输出信息到日志文件,默认为FILE
- NONE : 不输出查询日志
在设置的时候可以相互之间以英文逗号分隔,标识两种方式都输出,如下
# 启用普通查询日志并记录到文件和表中
--log-output=TABLE,FILE --general_log
# 启用查询日志和慢查询日志并记录到文件中
--log-output=TABLE --general_log --slow_query_log
# 启用慢查询日志并记录到文件中
--log-output=FILE --slow_query_log
# 启用慢查询日志并记录到文件中并指定文件路径
--log-output=TABLE --slow_query_log --slow_query_log_file=/data/mysql/logs/slow.log
注意了当--log-output选项为NONE时,general_log和slow_log两个不管设置什么,都不会记录日志了
在5.1.29之前,没有--general_lof_file和--slow_query_log_file这两个参数,控制文件名及输出路径是通过--log和--log-slow_queries两个参数
- --log : 指定普通查询日志的输出路径,并启用日志输出功能,默认文件名为[host_name].log
- --log-slow_queries : 指定慢查询输出路径,并启用日志输出功能,默认文件名为[host_name]-slow.log
2. MySQL服务运行时修改
与查询相关的选项可以在MySQL服务运行时修改,因为这些选项都有对应的同名系统变量。
- log_output
- general_log & slow_query_log
- general_log_file & slow_query_log_file
这几个参数都支持全局动态修改,修改即时生效,参数的功能与前面命令行中同名参数完全相同
- sql_log_off : 可选参数值为1或0(ON/OFF)。用来指定是否启用/禁用当前会话执行的语句记录到通用查询日志,默认值为0即禁用。该参数是个会话级参数,用户必须要有super权限才能设置该选项。
3. 查询日志表的特点
slow_log和general_log两个表对象和普通的表对象有些不同
- 日志表能够支持CREATE TABLE,ALTER TABLE,DROP TABLE,TRUNCATE TABLE
- 默认情况下,日志表使用CSV存储引擎(可以通过SHOW CREATE TABLE slow_log/general_log),因此可以直接复制这个文件到其他位置,或者轻松导入其他数据库。从5.1.12开始,日志表也可以修改成MyISAM引擎。如果要执行ALTYER,DROP等操作,需要首先禁用日志功能,而后修改对象,最后再重新启用日志功能。例如,将普通查询日志表general_log变更存储引擎为MyISAM
set @old_log_state = @@global.general_log;
set global general_log = 'OFF';
alter table mysql.general_log engine = MyISAM;
set global general_log = @old_log_state;
- 日志表能支持RENAME,TRUNCATE,CHECK操作
- 日志表不支持LOCK TABLES,并且也不允许用户在其上进行INSERT,UPDATE,DELETE操作,该表的增删改查都是由MySQL内部操作的。
- FLUSH TABLES WITH READ LOCK以及设置全局系统变量read_only,均对日志表无效,在此期间MySQL仍能向其中写入数据。
- 日志表的写操作不会记入二进制日志,同样,如果有复制环境的话,日志表的内容不会被复制到其他slave节点。
- 刷新日志表或日志文件,可以使用FLUSH TABLES或FLUSH LOGS。注意在5.1.12~5.1.20版本时,FLUSH TABLES语句忽略日志表,而FLUSH LOGS则会刷新日志表及其文件
- 不允许在日志表创建分区
- MySQL5.6版本之前,mysqldump命令行工具在处理数据时,会自动忽略general_log和slow_query_log两张表,不过从5.6.6开始,mysqldump命令能够自动查询日志表,不过导出的数据中只有结构,不包含数据
二进制文件
重中之重
术语
二进制日志(Binary Log) : 记录数据库中的修改事件
二进制日志文件(Binary Log File) : 保存数据库中修改事件的文件
作用
二进制日志不同于上面的其他几种日志,在某些场景下必须要有,尤其是对于Replication特性。
二进制日志中记录对数据库的修改时间。听起来好像和普通查询日志比较像,但是其实差别很大。普通查询日志是文本格式文件,里面可以理解为用户实际执行的操作,而二进制日志文件,是无法直接查看的,里面记录了数据库实际的操作,比如建表操作数据修改等,受众不一样。另外不是说一定有数据被修改才会被记入二进制日志,某些操作,比如像DELETE语句,即使未匹配任何数据,也有可能被记录(视日志格式而定),同时二进制日志还包含事件执行话费的时间。
通过二进制日志可以实现两个重要的功能 :
- 用于复制。将MySQL Master端的二进制日志发送到Slave端,Slave端即可根据二进制日志中的内容,在本地重做,以达到主从同步的目的。
- 用于恢复。二进制日志可用于数据恢复,当使用备份恢复了数据库后,通过应用二进制文件,能够实现将数据库恢复到故障发生前的状态。
与其他日志有所不同,二进制日志不会记录SELECT/SHOW这类不产生修改数据的语句。
二进制日志默认不开启,需要在启动MySQL服务时附件--log-bin[=base_name]选项,该选项就是用来控制MySQL服务端要将数据库的修改操作写入二进制文件,而--log-bin选项值就是用于指定二进制文件的存储路径和文件名,如果不指定选项值,那么二进制日志文件的默认文件名就是[hostname]-bin.[num],文件会保存在MySQL数据库的data路径下。
[num]代表序号，初始是000001,如[hostname]-bin.000001。每次启动MySQL服务或刷新日志时,都会创建新的日志文件
单个文件不可能无限增长,他的最大空间时由系统变量max_binlog_size进行控制,当日志文件大小达到max_binlog_size指定的大小时,就会创建新的二进制文件。不过,即使有了max_binlog_size参数在控制,生成的日志文件仍有可能超出max_binlog_size参数指定的值。比如当二进制文件快要写满时,执行一个超大的事务,由于事务特性决定相关事件必须连续,这种情况下,该事件必须写到同一日志文件,这就有可能造成日志文件超出指定的最大值的现象
为了可以追踪二进制文件的状态,MySQL会创建一个与二进制日志文件同名(但扩展名为.index)的二进制日志索引文件,用户可以通过--log-bin-index[=file_name]参数指定该文件的名称和存储路径,该文件中包含所有可供使用的二进制文件。这个文件是一个文本文件,可以通过任意文本编辑工具打开查看,但注意不要再MySQL服务运行过程中手动修改该文件。
如需要取消记录二进制日志,只需要注释掉log-bin参数(如果还指定了log-slave-updates,binlog_format参数,也要一起注释掉,否则可能会在错误日志中记录一条警告),然后重启MySQL即可。至于已经生成的二进制文件,如果确定不想要了,可以直接在操作系统层删除(复制环境不建议如此)。MySQL当然也提供了命令,RESET MASTER语句将清空所有二进制文件,而PURGE BINARY LOGS语句可以用来删除指定的某个或某些日志文件。删除前记得备份。
对于拥有super权限的数据库用户,可以在执行操作前,首先执行set sql_log_bin=0,禁用其执行的语句生成的二进制日志。
MySQL也提供了--binlog-do-db和--binglog-ignore-db两个选项,可以指定某数据库的修改行为,记录(或不记录)二进制日志。
--binlog-do-db和--binglog-ignore-db两个选项一次只能指定一个值,如果有多个库需要设置,可以附加多个这个参数
information_schema这类没有物理实体的库,不会记录二进制日志
如果需要查看二进制日志可以通过mysqlbinlog
二进制之间也可能有区别,因为记录时间的格式可能不同,从5.1版本开始,记录的事件格式有3种:基于行格式记录(row-based logging),基于语句记录(statement-based logging)和混合模式记录(mixed-based logging)
MySQL中既有支持事务的存储引擎和不支持的,因此在操作基于不同存储引擎的对象时,二进制日志的处理也会有不同。
对于非事务表,语句执行后就会立刻写入二进制文件中,对于事务表,则要等到当前没有任何锁定或未提交信息才会写入到二进制日志,以此来确保日志被记录的始终是其执行的顺序。
对于暂未提交的事务,事务中的更新操作(如UPDATE，DELETE,INSERT支持事务的表对象)会被缓存起来,知道收到COMMIT语句,而后,mysqld进程就会将整个事务在COMMIT执行前全部写到二进制日志。
当线程开始处理事务时,他会按照binlog_cache_size系统变量指定的值分配内存空间,缓存SQL语句,如果语句需要的空间比分配的缓存区要大,那么线程会打开一个临时文件保存这个事务,知道事务结束时再自动删除临时文件。
binlog_cache_use状态变量显示了使用binlog_cache_size系统变量的事务数(含临时文件),binlog_cache_disk_use状态变量则显示了使用临时文件的事务数,这两个参数组合起来可用于binlog_cache_size系统变量设置的调整和优化,以尽可能避免使用磁盘临时文件
max_binlog_cache_size系统变量(默认为4GB,也是最大值)用来限制事务能够使用最大缓存区,如果某个事务超出了限制,则只需将出错,事务会回滚,该变量最小为4096。
系统变量 : 指MySQL数据库中的系统配置,可以用show [global] variables;
环境变量 : 指MySQL服务运行过程中的一些状态信息,可以用show [global] status;
如果二进制以基于行格式记录,并发插入(如CREATE SELECT/INSERT SELECT)会改为普通插入,以确保操作可被重现，如果是基于语句格式记录,那么二进制中记录的就是原始语句。
默认情况下,二进制日志不是实时同步到磁盘的,因此如果操作系统崩溃或者机器故障,是存在丢失数据的可能的。要防止这种情况出现,需要考虑的因素比较多,仅从MySQL的二进制日志同步来说,可以设置二进制日志同步到磁盘的频率,MySQL提供了专用的系统变量sync_binlog。
sync_binlog值设为1(秒)安全级别最高,同时也是最慢的设置,不过即使设置为1,同样有可能丢失数据,只是最坏的情况下,仅丢失最后执行的那条语句或事务。举例来说,使用InnoDB引擎的表通过事务像表中写数据,操作依旧写到二进制日志,但还没来得及提交语句写入日志,这时系统崩溃,那么当数据库服务重新启动时,InnoDB引擎会将未提交的事务回滚,那么这种情况下,必然造成数据丢失。
要解决这个文件,MySQL提供了深度的安全性,MySQL应被配置为以事务为单位同二进制日志和InnoDB日志到磁盘到磁盘。InnoDB日志默认既是同步状态,sync_binlog=1可以同步二进制日志。这样当MySQL服务从崩溃中恢复时,为事务执行回滚后,MySQL服务终端二进制日志中InnoDB事务的回滚,以这种方式确保二进制日志能够考虑InnoDB表中的实际数据,同样,Slave端也会保持同步状态(因为没有收到回滚语句)。
当MySQL服务执行崩溃恢复时发现,二进制日志比期望中要少,比如InnoDB事务缺少commit(当sync_binlog=1时不可能出现这种情况),服务器端就会抛出错误信息 : The binary log file_name is shorter than its expected size, 这种情况下,说明二进制日志文件有误,复制环境有必要重建
中继日志及复制状态文件
在复制过程中,Slave节点会创建若干文件,有些用于保存从Master节点接收到的二进制日志,有些用于记录当前复制环境的状态,还有用户记录日志事件处理进度等相关信息,从文件类型来看分为下面3类
- 中继日志(relay log)文件 : 用于保存读取到的Matser二进制日志,由Slave节点的I/O进程负责数据的维护,这个文件也可以通过mysqlbinlog命令解析和读取其中记录的内容。
- Master信息日志文件(master.info) : 顾名思义,当然就是保存复制环境中连接Master节点的配置信息,比如说Slave节点连接Master使用的用户名,密码,IP,端口等均在其中。随着版本的增长,这个文件中保存的内容也越来越丰富。在5.6之前,这个信息日志总是保存在master.info文件中,默认在MySQL的data路径下,而进入5.6版本后,DBA也可以选择将这些信息保存在mysql.slave_master_info表对象中
- 中继日志信息日志文件(relay-log.info) : 保存处理进度及中继日志文件的位置的位置;与前面的日志信息相似,在MySQL5.6版本之前,也都是保存在文本格式的文件中,位于data路径下的relay-log.info文件中,不过从5.6开始,也可以将这个信息保存在mysql.slave_relay_log_info表对象中。
注意,为了保证宕机后表对象数据的安全性和一致性,后面提到的两个表对象最好使用支持事务的存储引擎,比如InnoDB引擎。之前默认的都是MyISAM存储引擎,不过从5.6.6开始,这两个表对象(如果设置为使用表来保存)默认就会是InnoDB存储引擎。另外,不管是作为文本格式文件,还是表对象,Master信息日志文件和中继信息日志文件都不要手动去编辑和修改,否则极有可能导致出现不可预料的错误。
前面的两个信息日志文件,功能纯粹,内容简单,而中继日志文件,这类文件只存在于MySQL复制(Replication)环境的Slave节点。这个日志文件跟MySQL二进制文件非常类似,并且两者记录的方式是相同的(所有才均可被mysqlbinlog命令读取),只不过,其中记录的时间内容主题可能有差异。二进制日志是记录Master端的修改行为,而中继日志则是记录接收记录自Master端的二进制日志。简单来说,二进制文件是为Master服务的,中继日志文件是为Slave服务的。
默认情况下,中继日志文件会以[host_name]-replay-bin.nnnnnn的命名格式保存在MySQL数据库的data目录下,起始文件序号一版都是000001。当然这类文件的命名规格也可以自定义,对应的初始化选项是--relay-log。
默认情况下,中继日志文件的文件名包含有主机名信息,那么,如果复制环境的Slave运行一段时间后,主机名发生了变更,会发生什么情况呢?毫无疑问,复制将会中断,Slave端的应用会报错。对于已经通过--relay-log选项重新定义了命名规则的系统当然不会出现这种情况,不过即使出现了这种情况也没关系,因为文件毕竟都在,只是他自己找不到了。最简单的办法是把主机名改回去,然后重启Slave服务。如果此时不能改名的话，那么通过中专的途径建立文件软链接等方式,使其能够正确的读取到文件即可。
表对象文件
数据文件可能是数量最多,也最常见到的文件。数据文件的类型是基于存储引擎的,由于MySQL这种插件式存储引擎的设计,在实际环境中,可能会看到各种各样的数据文件。下面罗列一些比较常见的文件类型
- frm : 表对象的结构定义文件,甭管什么存储引擎的表对象,一定拥有这个文件
- ibd : InnoDB引擎专用的数据文件(含索引)
- MYD : MyISAM引擎专用的数据文件
- MYI : MyISAM引擎专用的索引文件
- CSV : CSV引擎专用数据文件
- ARZ : ARCHIVE引擎专用的数据文件
其他文件
进程id文件
如果是使用mysqld_safe启动MySQL数据库,当MySQL服务启动后,可以发现在数据库根目录下发现一个mysql.pid文件。查看该文件内容,可以看到其中保存着遗传数据,貌似这串数字对应的是MySQL服务的进程号。
这个文件用于保存当前MySQL实例的进程号
这个文件保存进程号的主要母的就是方式MySQL实例被多次启动。注意,仅限mysqld_safe命令启动MySQL服务的情况,因为这个文件是由mysqld_safe命令创建和维护的。当使用mysqld_safe命令启动MySQL服务,他会执行一系列检查,其中就包括到MySQL数据库根目录下查看是否存在mysql.pid文件,如果已经发现当前已经存在这个文件,就会抛出一个错误信息,并终止MySQL服务的启动 :
A mysqld process already exists
如果是用mysqld命令启动的,那有没有pid都没有影响,因为他并不检测当前是否要已经有mysqld进程在运行,这就可能导致一个MySQL数据库被多次启动,这也是问什么推荐用mysqld_safe命令启动MySQL数据库,而不是直接用mysqld命令启动
mysql.pid对于mysqld_safe命令的副作用也是有的。比如就是mysqld_safe命令检测MySQL服务是否允许,只是通过mysql.pid文件是否存在来判断,而不会去检测具体的进程是否存在。因此如果再启动数据库时,明明没有任何mysqld进程在运行,但mysqld_safe命令总是返回 "A mysqld process already exists"这样的提示语,没准就是因为数据库根目录下存在着mysql.pid文件。遇到这种情况,首先删除这个文件,而后再尝试重新执行mysqld_safe命令。
套接字文件
在Linux/UNIX环境下,可以使用UNIX域套接字。UNIX域套接字不是网络协议,只有当MySQL客户端和MySQL服务在同一台机器上此案使用。
套接字默认文件名为mysql.sock,默认保存在/tmp目录下,当然用户也可以通过--socket选项指定该文件的具体路径
show variables like "%socket%";
自动配置文件
从5.6开始,每个MySQL实例会拥有一个唯一的UUID,MySQL就是通过这个UUID来避免Slave应用错误的数据。这个文件保存在根目录下的auto.cnf中,这个文件由MySQL自动生成,不要尝试修改。
auto.cnf文件中的内容,从格式来看较为类型my.cnf初始化选项文件,也是拥有区块,在区块中有具体的参数值。从前只有[auto]区块，[auto]区块中只有一行记录,就是server_uuid,其值正式当前服务器的UUID。