幂等性
数据库日志文件中的操作记录应该具有幂等性，同一个操作执行多次，结果是一样的。因为日志在故障恢复过程中，可能会被回放多次。
查询日志
- 数据库的查询日志记录了每一条sql语句；
- 访问量较大时建议不开启，因为设想一下如果同时又几百万个用户同时访问数据库，查询日志的记录就会占用大量的系统开销，直接影响服务器性能；
vim /etc/my.cnf.d/server.cnf
general_log = ON| OFF #查询日志开关
general_log_file localhost.log #查询日志的文件名字（/var/lib/mysql）
log_output TABLE | FILE | NONE #查询日志的存储形式慢查询日志
- 它用来记录在mariadb中响应时间超过阀值的语句。具体指运行时间超过long_query_time值的SQL语句，则会被记录到慢查询日志中。
- 慢查询日志是做数据优化可查的分析项
slow_query_log = OFF|ON #开启慢查询日志
slow_query_log_file = LOCALHOST-SLOW.log #慢查询日志的文件路径
long_query_time #慢查询时长；默认是10s
log_slow_rate_limit #如果要记录的慢查询日志非常多的话，会按照速率来记录，默认1秒记录一个
log_slow_verbosity=full | query_plan #记录的详细级别错误日志
- 错误日志包含了mariadb 启动和关闭的次数.
- 包含了错误,警告,和注释的相关诊断信息.
- mariadb 在运行时,如果你的mariadb 中的表需要自动检查或者修复.这些信息都会写入到error log 里面.
- 在主从复制架构中的从服务器上启动从服务器线程时产生的信息
- event scheduler 运行一个event时产生的日志信息
log_error = /var/log/mysql_error.log#指定错误日志的输出位置
log_warnings 为0， 表示不记录告警信息。
log_warnings 为1， 表示告警信息写入错误日志。
log_warnings 大于1， 表示各类告警信息，例如有关网络故障的信息和重新连接信息写入错误日志。(默认为2)二进制日志
- 二进制日志：记录着所有更改（增删改）数据的语句，可以用于数据的恢复，并且是针对时间点还原，对数据库查询的语句如show，select开头的语句，不会被binlog日志记录。
- 二进制日志：是在数据库中起着至关重要的作用（主从架构，数据备份，数据恢复等）
log_bin = OFF | ON
log_bin_basename = /var/lib/mysql/mysql-bin
sql_log_bin=1|0 #是否启用二进制日志
log_bin_index=PATH #二进制日志索引位置
sync_binlog=1|0 #设定是否启动二进制日志同步功能
max_binlog_size=SIZE #单个二进制文件最大体积，默认为1G
expire_logs_days=0 #超过多少天就清除二进制日志，默认为0,代表不启用此功能
binlog_format=STATEMENT|ROW|MIXED
#二进制记录格式(STATEMENT：基于“语句”记录; ROW：基于“行”记录 ;MIXED：让系统自行判定该基于哪种方式进行)row level
日志中会记录成每一行数据被修改的形式，然后在slave端再对相同的数据进行修改。
优点：在row level模式下，bin-log中可以不记录执行的sql语句的上下文相关的信息，仅仅只需要记录哪一条记录被修改了，修改成什么样了。
缺点：row level下，所有的执行语句当记录到日志中的时候，都将以每行记录的修改来记录，这样可能会产生大量的日志内容。尤其是当执行alter table之类的语句的时候，产生的日志量是惊人的，因为MySQL对于alter table之类的表结构变更语句的处理方式是整个表的每一条记录都需要变动，实际上就是重建了整个表，那么该表的每一条记录都会被记录到日志中。
statement level
每一条会修改数据的sql都会记录到master的bin-log中。slave在复制的时候sql进程会解析成和原来master端执行过程相同的sql来再次执行。
优点：statement level下的优点首先就是解决了row level下的缺点，不要需要记录每一行数据的变化，减少bin-log日志量，节约IO，提高性能。因为它只需要记录在master上所执行的语句细节，以及执行语句时候的上下文信息。
缺点：由于他是记录的执行语句，所以，为了让这些语句在slave端也能正确执行，那么它还必须记录每条语句在执行时候的一些相关信息，也就是上下文信息，以保证所有语句在slave端被执行的时候能够得到和在master端执行时候相同的结果。
mixed level
实际上就是前两种模式的结合。在Mixed模式下，MySQL会根据执行的每一条具体的sql语句来区分对待记录的日志形式，也就是在statement和Row之间选择一种。新版本中的statement level还是和以前一样，仅仅记录执行的语句。而新版本的MySQL中对row level模式也做了优化，并不是所有的修改都会以row level来记录，像遇到表结构变更的时候就会以statement模式来记录，如果sql语句确实就是update或者delete等修改数据的语句，那么还是会记录所有行的变更。
如何选择
1、互联网公司，使用MySQL的功能相对少（存储过程、触发器、函数），选择默认的语句模式,statement Level模式
2、如果用到MySQL的特殊功能（存储过程、触发器、函数）则选择Mixed模式。
3、公司如果用到使用MySQL的特殊功能（存储过程、触发器、函数），数据最大化一致，此时最好row level模式。
中继日志
中继日志：复制架构中，备服务器用于保存主服务器的二进制日志中读取到的事件。
事务日志
InnoDB的事务日志主要分为redo log(重做日志，提供前滚操作)和undo log(回滚日志，提供回滚操作)，为了最大程度上减少数据写入时io问题，在存储引擎修改表的数据时，会将数据从磁盘拷贝到内存中，然后修改内存中的数据拷贝，再将修改行为持久化到磁盘中（先写redo log buffer(日志缓冲区)，再定期批量写入），而不用每次将修改的数据本身持久化到硬盘中。
innodb_buffer_pool_size 一般设置成为物理内存的3/4,或者4/5
innodb_log_files_in_group = 2 事务日志文件的个数，默认为2个事务日志文件
innodb_log_file_size = 50331648（48m） 事务日志文件的单个大小48m
innodb_log_group_home_dir = ./ 事务日志文件的所在路径，默认mariadb的数据目录/var/lib/mysql重做日志（Redo log）
redo log是InnoDB存储引擎层的日志，又称重做日志文件，用于记录事务操作的变化，记录的是数据修改之后的值，不管事务是否提交都会记录下来。在实例和介质失败（media failure）时，redo log文件就能派上用场，如数据库掉电，InnoDB存储引擎会使用redo log恢复到掉电前的时刻，以此来保证数据的完整性。
在一条更新语句进行执行的时候，InnoDB引擎会把更新记录写到redo log日志中，然后更新内存，此时算是语句执行完了，然后在空闲的时候或者是按照设定的更新策略将redo log中的内容更新到磁盘中，这里涉及到WAL即Write Ahead logging技术，他的关键点是先写日志，再写磁盘。
回滚日志（Undo log）
undo log就是把所有没有COMMIT的事务回滚到事务开始之前的状态(撤销事务在系统崩溃前可能还没有完成的影响来恢复数据库状态)，对于已经commit的事务不做任何处理。
Redo log和Undo log的区别
Undo日志：
在恢复时取消未完成事务，忽略已提交事务
先将修改后的数据写到磁盘。
遵循Undo日志的U1和U2规则，恢复时需要的是数据库的旧值。
Redo日志：
忽略未完成事务，重做已经提价事务的改变。
先写到磁盘，然后数据进入缓冲区，选择合适时间在写入磁盘。
恢复时需要的是新值。
Redo log和binlog区别
- redo log是属于innoDB层面，binlog属于MySQL Server层面的，这样在数据库用别的存储引擎时可以达到一致性的要求。
- redo log是物理日志，记录该数据页更新的内容；binlog是逻辑日志，记录的是这个更新语句的原始逻辑
- redo log是循环写，日志空间大小固定；binlog是追加写，是指一份写到一定大小的时候会更换下一个文件，不会覆盖。
- binlog可以作为恢复数据使用，主从复制搭建，redo log作为异常宕机或者介质故障后的数据恢复使用。
