错误日志 error log
MySQL错误日志记录MySQL服务进程mysqld在启动/关闭或运行过程中遇到的错误信息
错误日志配置
在配置文件中调整方法,当然可以在启动时加入启动参数
|
|
启动MySQL命令里加入
|
|
遇到数据库启动不了
先把日志文件备份并清空启动一下mysql服务后再查看日志文件,看报有什么错误
bash1 2 3
InnoDB: The error means mysqld does not have the access rights to InnoDB: the directory
然后查看mysql3306目录下文件权限
普通查询日志 general query log
普通查询日志 (general query log):记录客户端链接信息和执行的SQL语句信息。
普通查询日志配置
|
|
临时生效
|
|
永久生效
|
|
日志示例
|
|
慢查询日志 slow query log
慢查询日志 (slow query log):记录执行时间超出指定值 long_query_time的SQL语句
慢查询日志调整
|
|
慢查询的设置,对于数据库SQL的优化非常重要
|
|
利用慢查询进行优化解决方案
开启慢查询
|
|
慢查询日志切割
|
|
使用mysqlsla分析慢查询,定时发给相关人员信箱
使用explain优化SQL语句(select)
抓SQL慢查询语句
|
|
explain语句检查索引执行情况
|
|
对需要建立索引的条件列建立索引
大表不能高峰期建立索引,300w记录
分析慢查询的工具mysqlsla
二进制日志 binary log
二进制日志 (binary log):用来记录mysql内部增删改等对mysql数据库有更新的内容的记录(对数据库的改动),对数据库查询的语句如:show、select开头的语句,不会被binlog日志记录,用于数据库的增量恢复,以及主从复制
|
|
面试题:在MySQL数据库中,关于binlog日志,下列说法正确的是 ___ ?( A )
A. 依靠足够长度的binlog日志和定期的全备,我们可以恢复任何时间点的单表数据。
B. 以mysql主从同步为例,binlog中会记录主数据库进行的所有操作。
C. 以mysql主从同步为例,binlog中会记录主数据库进行的所有查询操作。
D. binlog通过cat和vi无法查看,但可以通过gedit查看
开启mysql的binlog功能
|
|
mysqlbinlog工具解析binlog日志
默认情况binlog日志是二进制格式的,不能使用查看文本工具的命令查看,例如 cat vi等
|
|
解析指定库的binlog
范例:利用 mysqlbinlog -d
参数解析指定库的binlog日志
|
|
结论:mysqlbinlog 工具分库导出 binlog,如果使用 -d 参数
,那更新数据时,必须有use database,才能分出指定库的binlog,例如:
|
|
官方资料:mysqlbinlog — Utility for Processing Binary Log Files
|
|
按照位置截取:精准,时间长
|
|
按时间截取:模糊、不准,会丢失数据
|
|
mysqlbinlog命令
- 把 binlog 解析为sql语句(包含位置和时间点)
-d
参数根据指定库拆分binlog(拆分单表binlog可通过SQL关键字过滤)- 通过位置参数截取部分binlog:
--start-position=111 --stop-position=500
,精确定位取部分内容。 - 通过时间参数截取部分binglog:
--start-datetime='2016-10-10 10:10:10'
-r fileName
,相当于重定向 “>”- 解析 row 级别 binlog 日志方法
mysqlbinlog --base64-output=decode-rows -v mysql-bin.000004
binlog三种模式
Row Level
不记录sql语句上下文相关信息,仅保存哪条记录被修改。
优点:binlog中可以不记录执行的sql语句的上下文相关的信息,仅需要记录那一条记录被修改成什么了。所以rowlevel的日志内容会非常清楚的记录下每一行数据修改的细节。而且不会出现某些特定情况下的存储过程,或function,以及trigger的调用和触发无法被正确复制的问题
缺点:所有的执行的语句当记录到日志中的时候,都将以每行记录的修改来记录,这样可能会产生大量的日志内容,比如一条update语句,修改多条记录,则binlog中每一条修改都会有记录,这样造成binlog日志量会很大,特别是当执行alter table之类的语句的时候,由于表结构修改,每条记录都发生改变,那么该表每一条记录都会记录到日志中。
Statement Level
每一条会修改数据的sql都会记录在binlog中。
优点:不需要记录每一行的变化,减少了binlog日志量,节约了IO,提高性能。(相比row能节约多少性能与日志量,这个取决于应用的SQL情况,正常同一条记录修改或者插入row格式所产生的日志量还小于Statement产生的日志量,但是考虑到如果带条件的update操作,以及整表删除,alter表等操作,ROW格式会产生大量日志,因此在考虑是否使用ROW格式日志时应该跟据应用的实际情况,其所产生的日志量会增加多少,以及带来的IO性能问题。)
缺点:由于记录的只是执行语句,为了这些语句能在slave上正确运行,因此还必须记录每条语句在执行的时候的一些相关信息,以保证所有语句能在slave得到和在master端执行时候相同 的结果。另外mysql 的复制,像一些特定函数功能,slave可与master上要保持一致会有很多相关问题(如sleep()函数, last_insert_id(),以及user-defined functions(udf)会出现问题).
Mixed Level
是以上两种level的混合使用,一般的语句修改使用statment格式保存binlog,如一些函数,statement无法完成主从复制的操作,则采用 row 格式保存binlog,MySQL会根据执行的每一条具体的sql语句来区分对待记录的日志形式,也就是在Statement和Row之间选择一种。新版本的MySQL中队row level模式也被做了优化,并不是所有的修改都会以row level来记录,像遇到表结构变更的时候就会以statement模式来记录。至于update或者delete等修改数据的语句,还是会记录所有行的变更。
生产环境如何选择binlog的模式
- 互联网公司,使用MySQL的功能相对少(存储过程、触发器、函数),选择默认的语句模式。
- 公司如果用到使用MySQL的特殊功能(存储过程、触发器、函数)。则选择Mixed。
- 公司如果公道使用MySQL的特殊功能(存储过程、触发器、函数),又希望数据最大化一致,此时最好用row模式
设置MySQL binlog的格式
|
|
永久生效
|
|
测试ROW模式下的binlog记录日志情况
|
|
statement日志记录
|
|
1197
|
|
原因:row 格式的 binlog 的特点:在 row 模式下,所有的执行的语句当记录到日志中的时候,都将以每行记录的修改来记录,这样可能会产生大量的日志内容。所以会造成binlog cache因为过小而中断。
解决设置大的cache