香港vps服务器的MySQL日志管理：
1.1 错误日志
文件名：可用�log-error[=file_name]指定，否则默认使用hostname.err
内容：记录mysqld启动和停止时，以及服务器发生任何严重错误时记录相关信息
1.2 二进制日志
文件名：也是binlog(逻辑日志)，可用�log-bin[=file_name] 指定，默认为主机名
内容：包含了所有更新了或者潜在更新了数据的所有语句，语句以“事件”的形式保存，描述数据更改文件位置和格式
查看日志：
mysqlbinlog log-file
删除日志：
#删除所有的binlog日志，新日志从头开始编号
RESET MASTER
#删除mysql-bin.010之前的所有日志
PURGE MASTER LOGS TO ‘mysql-bin.010’
#删除2022.5.1之前的binlog日志
purge master logs before ‘2022-05-01 08:00:00’;
1.3 查询日志
文件名：使用�log指定，默认hostname.log
内容：记录客户端所有查询语句记录，在二进制日志不存在查询语句记录
1.4 慢查询日志
文件名：使用�log-slow-querie指定，默认*-slow.log，写入data目录
内容：记录执行时间超过long_query_time秒的SQL查询日志文件
其它选项：�log_slow_admin_statements：表示将慢管理语句，如OPTIMIZE TABLE、ANALYZE TABLE和ALTER TABLE写入慢查询语句
1.5 通用查询日志
查看：show variables like ‘%general_log%’;
执行SQL命令 set global general_log=on; 开启
文件：默认存放在data目录下hostname.log文件
内容：记录客户端的所有查询行为
1.6 中继日志
文件：默认文件名hostnamet-relay-bin，存放在data目录下
功能：从服务器I/O线程将主服务器的二进制日志读取过来记录到从服务器本地文件，然后从服务器SQL线程会读取relay-log日志的内容并应用到从服务器，从而使从服务器和主服务器的数据保持一致
参数：show variables like ‘%relay%’;
max_relay_log_size
relay log 允许的最大值，如果该值为0，则默认值为 max_binlog_size (1G)
如果不为0，则 max_relay_log_size 则为最大的relay_log文件大小
relay_log
定义 relay_log 的位置和名称，如果值为空，则默认位置在数据文件的目录
relay_log_index
定义 relay_log 索引的位置和名称，记录有几个 relay_log 文件，默认为2个
relay_log_info_file
定义 relay-log.info 的位置和名称，relay-log.info 记录 master 主库的 binary_log 的恢复位置和 从库 relay_log 的位置
relay_log_purge
是否自动清空中继日志，默认值为1(启用)
relay_log_recovery
当slave从库宕机后，假如relay-log损坏了，导致一部分中继日志没有处理，则自动放弃所有未执行的relay-log，并且重新从master上获取日志，这样就保证了relay-log的完整性。默认情况下该功能是关闭的，将relay_log_recovery的值设置为 1时，可在slave从库上开启该功能，建议开启
sync_relay_log
当设置为1时，slave的I/O线程每次接收到master发送过来的binlog日志都要写入系统缓冲区，然后刷入relay log中继日志里，这样是最安全的，因为在崩溃的时候，你最多会丢失一个事务，但会造成磁盘的大量I/O
当设置为0时，并不是马上就刷入中继日志里，而是由操作系统决定何时来写入，虽然安全性降低了，但减少了大量的磁盘I/O操作。这个值默认是0，可动态修改
sync_relay_log_info
这个参数和 sync_relay_log 参数一样
1.7 审计日志
内容：企业版自带功能，社区版需使用audit审计插件完成数据库审计工作
开启步骤：
下载插件：https://github.com/mcafee/mysql-audit
查看插件功能是否开启： show variables like “%audit%”;
开启插件功能：set global audit_json_file=1;
注意，使用此方法开启对global全局变量的设置仅对于新开启的会话才是有效的，对已经开启的会话不生效，参数最终需持久化到my.cnf配置文件中
开启后，在MySQL数据目录下会多出一个mysql-audit.json审计日志
2 InnoDB日志
2.1 重做日志 (Redo Log)
文件：默认情况下，对应的物理文件位于数据库的data目录下的ib_logfile1&ib_logfile2
内容：物理日志，记录物理数据页面的修改信息，redo log顺序写入redo log file物理文件中
重做日志有一个缓冲区Innodb_log_buffer，InnoDB优先将重做日志写入缓冲区，日志写盘通常有三种方式：
Master Thread 每秒一次执行刷新Innodb_log_buffer到重做日志文件
每个事务提交时会将重做日志刷新到重做日志文件。
当重做日志缓存可用空间 少于一半时，重做日志缓存被刷新到重做日志文件
因此，重做日志的写盘，并不一定是随着事务的提交才写入重做日志文件的，而是随着事务的开始逐步开始的，这可以很好地解释再大的事务的提交（commit）的时间也是很短暂的
事务产生的重做日志，通过innodb_flush_log_at_trx_commit参数控制：
设置为 0 的时候，表示不写入buffer，直接每秒写入到redo file中，但mysql 崩溃会丢失1s数据
设置为 1 的时候，表示每次事务提交时都将 redo log 直接持久化到磁盘
设置为 2 的时候，表示每次事务提交时都只是把 redo log 写到 page cache，由OS处理回写磁盘操作，OS宕机会丢失数据
2.2 回滚日志(Undo Log)
文件：逻辑日志，记录在表空间中
MySQL5.6之前，undo表空间位于共享表空间的回滚段中，共享表空间的默认的名称是ibdata，位于数据文件目录中
MySQL5.6之后，undo表空间可以配置成独立的文件，但是提前需要在配置文件中配置，完成数据库初始化后生效且不可改变undo log文件的个数
内容：记录数据的逻辑变化，一条INSERT会对应一条DELETE的undo log，发生错误时能够恢复到事务之前的数据状态
undo log是MVCC(多版本并发控制)实现的关键