mysql⽇志⽂件开启及详解：General_log和Binlog
转⾃：blog.csdn/Abysscarry/article/details/79949480
General_log 详解
1.介绍
开启 general log 将所有到达MySQL Server的SQL语句记录下来。
⼀般不会开启开功能，因为log的量会⾮常庞⼤。但个别情况下可能会临时的开⼀会⼉general log以供排障使⽤。
相关参数⼀共有3：general_log、log_output、general_log_file
show variables like'general_log';  -- 查看⽇志是否开启
set global general_log=on; -- 开启⽇志功能
show variables like'general_log_file';  -- 看看⽇志⽂件保存位置
set global general_log_file='tmp/general.lg'; -- 设置⽇志⽂件保存位置
show variables like'log_output';  -- 看看⽇志输出类型  table或file
set global log_output='table'; -- 设置输出类型为 table
set global log_output='file';  -- 设置输出类型为file
log_output=’FILE’ 表⽰将⽇志存⼊⽂件，默认值是FILE　
log_output=’TABLE’表⽰将⽇志存⼊数据库，这样⽇志信息就会被写⼊到mysql.slow_log表中.
mysql数据库⽀持同时两种⽇志存储⽅式，配置的时候以逗号隔开即可，如:log_output=‘FILE,TABLE‘.⽇志记录到系统专⽤⽇志表中，要⽐记录到⽂件耗费更多的系统资源，因此对于需要启⽤慢查⽇志,⼜需要⽐够获得更⾼的系统性能，那么建议优先记录到⽂件.
2.开启数据库general_log步骤
先执⾏sql指令：show variables like ‘%log%’;
css透明度可以看到默认general_log是OFF的，我们直接开启：set global general_log = ON;（永久修改需要在myf的【mysqld】中添加：general_log = 1
）
OK，现在mysql就会在general_log_file 显⽰的路径⽂件⾥记录general⽇志了！（从现在开始记录）我默认的路径是
/usr/local/mysql/data/VM_0_17_redhat.log
Binlog 详解
1.介绍
MySQL的⼆进制⽇志可以说是MySQL最重要的⽇志了，它记录了所有的DDL和DML(除了数据查询语句)语句（记录mysql内部增删改等对mysql数据库有更新的内容的记录（对数据库的改动），对数据库的查询select或show等不会被binlog⽇志记录），以事件形式记录，还包含语句所执⾏的消耗的时间，MySQL的⼆进制⽇志是事务安全型的。
⼀般来说开启⼆进制⽇志⼤概会有1%的性能损耗。
两个最重要的使⽤场景:
其⼀：MySQL Replication在Master端开启binlog，Mster把它的⼆进制⽇志传递给slaves来达到master-slave数据⼀致的⽬的。 其⼆：⾃然就是数据恢复了，通过使⽤mysqlbinlog⼯具来使恢复数据。
⼆进制⽇志包括两类⽂件：
⼆进制⽇志索引⽂件（⽂件名后缀为.index）⽤于记录所有的⼆进制⽂件；
⼆进制⽇志⽂件（⽂件名后缀为.00000*）记录数据库所有的DDL和DML(除了数据查询语句)语句事件。
2.开启binlog ⽇志
查看binlog开启状态：vim编辑打开mysql配置⽂件myf：
mysql> show variables like 'log_bin';
java获取网页源代码
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| log_bin      | OFF  |
+---------------+-------+
1 row in set (0.01 sec)
vim /etc/myf
在【mysqld】中添加：
log-bin=/home/data/mysql-log/mysql-bin
server-id=12345
⽹上很多教程都只是添加log-bin⼀⾏就⾏了，此处我们为什么要加 server-id？
因为我们⽤的是5.7及以上版本的话，不加server-id重启mysql服务会报错，5.7以下版本就不⽤加了。
所以必须添加server-id这个参数！随机指定⼀个不能和其他集中机器重名的字符串，如果只有⼀台机器，那就可以随便指定了。
注意！修改配置⽂件后重启报错最好定位到mysql的errlog，查看具体错误，我出现过⼀个错误就是⽤root⾃定义创建bin-log所在的⽬录，没给mysql⽤户权限。
还有⼀种配置⽅式（指定三个参数）：
log_bin=ON
log_bin_basename=/var/lib/mysql/mysql-bin
log_bin_index=/var/lib/mysql/mysql-bin.index
第⼀个参数是打开binlog⽇志
门户模板的第⼆个参数是binlog⽇志的基本⽂件名，后⾯会追加标识来表⽰每⼀个⽂件
第三个参数指定的是binlog⽂件的索引⽂件，这个⽂件管理了所有的binlog⽂件的⽬录
重启后查看：
3.常⽤binlog⽇志操作命令
1.查看所有binlog⽇志列表
硬件工程师转软件
mysql> show master logs;
2.查看master状态，即最后(最新)⼀个binlog⽇志的编号名称，及其最后⼀个操作事件pos结束点(Position)值
mysql> show master status;
3.刷新log⽇志，⾃此刻开始产⽣⼀个新编号的binlog⽇志⽂件
mysql> flush logs;
注：每当mysqld服务重启时，会⾃动执⾏此命令，刷新binlog⽇志；在mysqldump备份数据时加 -F 选项也会刷新binlog⽇志；
4.重置(清空)所有binlog⽇志
mysql> reset master;
5.查看binlog⽇志内容（以表格形式）
mysql>  show binlog events in'mysql-bin.000002';
  mysqlbinlog功能是将mysql的binlog⽇志转换成Mysql语句，默认情况下binlog⽇志是⼆进制⽂件，⽆法直接查看。我们直接在mysql⽬录的bin⽬录下启动该命令。（在MySQL5.5以下版本使⽤mysqlbinlog命令时如果报错，就加上 “–no-defaults”选项）  　
mysqlbinlog命令部分参数：
clustertruck补丁
-d  //指定库的binlog
-r  //相当于重定向到指定⽂件
--start-position--stop-position //按照指定位置精确解析binlog⽇志（精确），如不接--stop-positiion则⼀直到binlog⽇志结尾
--start-datetime--stop-datetime //按照指定时间解析binlog⽇志（模糊，不准确），如不接--stop-datetime则⼀直到binlog⽇志结尾
备注：myslqlbinlog分库导出binlog，如使⽤-d参数，更新数据时必须使⽤use database。
例：解析yj-test数据库的binlog⽇志并写⼊my.sql⽂件
./mysqlbinlog -d yj-test /home/data/mysql-log/mysql-bin.000003 -r my.sql
//使⽤位置精确解析binlog⽇志
./mysqlbinlog mysql-bin.000003 --start-position=100  --stop-position=200 -r my.sql
可以直接查看所有binlog信息：
mysql> show master logs;
+------------------+-----------+
| Log_name        | File_size |
+------------------+-----------+
| mysql-bin.000001 |      177 |
| mysql-bin.000002 |      154 |
+------------------+-----------+
2 rows in set (0.00 sec)
5.binlog的三种⼯作模式
查看binlog⽇志格式：
show variables like"binlog_format";mysql查看所有存储过程
注：我的默认为 ROW 模式，和⽹上说的默认不⼀样（Statement）
（1）Row level
  ROW是基于⾏级别的，他会记录每⼀⾏记录的变化，就是将每⼀⾏的修改都记录到binlog⾥⾯，记录的⾮常详细，但sql语句并没有在binlog⾥。
  ⽇志中会记录每⼀⾏数据被修改的情况，然后在slave端对相同的数据进⾏修改。在replication⾥⾯也不会因为存储过程触发器等造成Master-Slave数据不⼀致的问题，但是有个致命的缺点⽇志量⽐较⼤.由于要记录每⼀⾏的数据变化，当执⾏update语句后⾯不加where条件的时候或alter table的时候，产⽣的⽇志量是相当的⼤。
（2）Statement level（默认）
  每⼀条被修改数据的sql都会记录到master的bin-log中，slave在复制的时候sql进程会解析成和原来master端执⾏过的相同的sql再次执⾏
  优点：解决了 Row level下的缺点，不需要记录每⼀⾏的数据变化，减少bin-log⽇志量，节约磁盘IO，提⾼新能
（3）Mixed（混合模式）
  结合了Row level和Statement level的优点。
  在默认情况下是statement，但是在某些情况下会切换到row状态，如当⼀个DML更新⼀个ndb引擎表，或者是与时间⽤户相关的函数等。在主从的情况下，在主机上如果是STATEMENT模式，那么binlog就是直接写now()，然⽽如果这样的话，那么从机进⾏操作的时间，也执⾏now()，但明显这两个时间不会是⼀样的，所以对于这种情况就必须把STATEMENT模式更改为ROW模式，因为ROW模式会直接写值⽽不是写语句（该案例是错误的，即使是STATEMENT模式也可以使⽤now()函数，具体原因以后再分析）。同样ROW模式还可以减少从机的相关计算，如在主机中存在统计写⼊等操作时，从机就可以免掉该计算把值直接写⼊从机。
⼀般企业binlog模式的选择：
互联⽹公司使⽤MySQL的功能较少（不⽤存储过程、触发器、函数），选择默认的Statement level；
⽤到MySQL的特殊功能（存储过程、触发器、函数）则选择Mixed模式；
⽤到MySQL的特殊功能（存储过程、触发器、函数），⼜希望数据最⼤化⼀直则选择Row模式；
先记录这么多吧，后⾯使⽤时再进⼀步记录。
<link rel="stylesheet" href="csdnimg/release/phoenix/template/css/markdown_views-ea0013b516.css">
</div>

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。