1、插入缓冲 insert buffer
2、两次写 Double Write
3、自适应哈希索引 Adaptive Hash Indexx
4、异步IO Async IO
5、刷新邻接页 Flush Neighbor Page
错误日志 error log
二进制日志 binlog
慢查询日志 slow query log
查询日志 log
错误日志:
应该尽量在测试环境下开启慢查询。
如果非要在生产环境中开启的话,那么尽量找一个没有业务的时间段,夜间或者周末去拿到日志
查询日志记录了所有对MySQL数据库请求的信息,无论这些请求是否得到了正确的执行。默认文件为:主机名.log。
1、恢复:某些数据的恢复需要binlog,比如在一个数据库全备文件恢复后,用户可以通过二进制日志进行point-in-time的恢复
2、复制:原理和恢复类似,通过复制和执行二进制日志使一台远程的MySQL数据库,slave与一台master进行实时同步。
3、审计:用户可以通过二进制日志中的信息来进行审计,判断是否对数据库进行注入攻击。
当使用innodb存储引擎的时候,事务未提交的binlog会被记录到一个缓冲中去,等该事务提交的时候,直接将缓冲中的binlog写入binlog文件中。
在默认情况下,binlog并不是每次写的时候都同步到磁盘(用户可以理解为缓冲写),因此,当DB宕机的时候,可能会有最后一部分数据没有写入binlog文件中,这会给恢复和复制带来问题。参数 sync_binlog = [N] 表示每写缓冲多少次就同步到磁盘。如果将N设置为1,那么就是每次写缓冲都同步到磁盘,即同步写磁盘的方式来写binlog,这时写操作不使用OS的缓冲来写binlog。N的默认值是0,如果使用innodb存储引擎来进行复制,并且想得到最大的高可用性,建议将该值设置为ON。不过设置为ON时,确实会对DB的IO系统带来一定的影响。
上面说了当N =1 的时候是每次写缓冲都同步磁盘,即使这样也会带来问题,当事务还没提交的时候,由于sync_binlog = [N] = 1,因此会将binlog立即写入磁盘。如果这时候已经写入了磁盘,但是事务提交还没有发生,并且此时发生了宕机,那么MySQL下次启动的时,由于commit操作并没有发生,这个事务会被回滚掉。但是binlog已经记录了该事务信息,不能被回滚。这个问题可以通过参数 innodb_support_xa 设置为 1 来解决,虽然innodb_support_xa与XA事务有关,但它同时也确保了binlog和innodb存储引擎数据文件的同步。
如果当前db是slave则它不会从master取得并执行binlog写入自己的binlog文件中去。如果需要写,要设置log-slave-update。如果需要搭建maser=>slave=>slave架构的复制,则必须要设置该参数。
binlog_format这个参数十分重要,它影响了binlog的格式,在MySQL5.1版本之前,没有这个参数。所有的二进制文件的格式都是基于SQL语句的statement级别的,因此基于这个格式的binlog文件的复制和oracle的逻辑Standby有点相似。同时对于复制是有一定要求的。如在主服务器运行rand,uuid等函数,又或者使用触发器等操作,这些都可能会导致主从服务器上表中数据的不一致,另一个影响是,会发现InnoDB的默认隔离级别是RR,这其实也是因为binlog文件格式的关系,如果使用读已提交会出现类似丢失更新的现象,从而出现主从数据不一致。
网站声明:如果转载,请联系本站管理员。否则一切后果自行承担。
添加我为好友,拉您入交流群!
请使用微信扫一扫!