mysql中relay log和binlog有什么用

54次阅读

共计 6895 个字符，预计需要花费 18 分钟才能阅读完成。

这篇文章主要为大家展示了“mysql 中 relay log 和 binlog 有什么用”，内容简而易懂，条理清晰，希望能够帮助大家解决疑惑，下面让丸趣 TV 小编带领大家一起研究并学习一下“mysql 中 relay log 和 binlog 有什么用”这篇文章吧。

突然 mysql 数据库的一个表的数据少了很多，我想着通过查看日志来判断针对这个表到底做了那些操作，然后再有针对性的去恢复，可是直接看 binlog(二进制的形式) 发现很乱，看不清楚，于是上网查询得知，需要先通过 mysqlbinlog 进行格式化，具体如下：

主库 binlog：mysqlbinlog –base64-output=decode-rows -v -v mysql-bin.000058 binlog

从库 relay log：mysqlbinlog –base64-output=decode-rows -v -v mysql-relay-bin.000031 relaylog

然后查看变成很规整的形式：就是一些具体的 sql 语句。

[root@S243 mybinlog]# more binlog28

/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=1*/;

/*!40019 SET @@session.max_insert_delayed_threads=0*/;

/*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/;

DELIMITER /*!*/;

# at 4

#161125 22:17:23 server id 20 end_log_pos 120 Start: binlog v 4, server v 5.6.18-enterprise-commercial-advanced-log created 161125 22:17:23

# at 120

#161125 22:17:23 server id 20 end_log_pos 204 Query thread_id=3498328 exec_time=0 error_code=0

SET TIMESTAMP=1480083443/*!*/;

SET @@session.pseudo_thread_id=3498328/*!*/;

。

SET TIMESTAMP=1480083443/*!*/;

insert into mailer.khgz_coreseek_result (info_id, khgz_id, last_modify, result, status) values (1 , 1 , 2016-11-25 22:17:24 , 29803096:8d78ac82-e746-423a-9615-971485e8 , 0)

/*!*/;

# at 487

#161125 22:17:23 server id 20 end_log_pos 572 Query thread_id=3498328 exec_time=0 error_code=0

SET TIMESTAMP=1480083443/*!*/;

COMMIT

/*!*/;

# at 572

关于 binlog 和 relay log 的 rotate 机制：

Binary Log rotate 机制：

?Rotate：每一条 binary log 写入完成后，都会判断当前文件是否超过 max_binlog_size(默认 1g)，如果超过则自动生成一个 binlog file

?Delete：expire-logs-days 只在实例启动时和 flush logs 时以及文件文件是否超过 max_binlog_size 时判断是否有过期的 binlog 文件，如果文件访问时间早于设定值，则 purge file
Relay Log rotate 机制：

Rotate：每从 Master fetch 一个 events 后，判断当前文件是否超过 max_relay_log_size（默认 1g) 如果超过则自动生成一个新的 relay-log-file

Delete：purge-relay-log 在 SQL Thread 每执行完一个 events 时判断，如果该 relay-log 已经不再需要则自动删除

Delete：expire-logs-days 只在实例启动时和 flush logs 时判断，如果文件访问时间早于设定值，则 purge file （同 Binlog file） (updated: expire-logs-days 和 relaylog 的 purge 没有关系)

关于 binlog 和 relay log 的参数：

binlog 的相关参数：

mysql show variables like %bin%

+—————————————–+———————————+

| Variable_name | Value |

+—————————————–+———————————+

| bind_address | * |

| binlog_cache_size | 1048576 |

| binlog_checksum | NONE |

| binlog_direct_non_transactional_updates | OFF |

| binlog_format | MIXED |

| binlog_max_flush_queue_time | 0 |

| binlog_order_commits | ON |

| binlog_row_image | FULL |

| binlog_rows_query_log_events | OFF |

| binlog_stmt_cache_size | 32768 |

| innodb_api_enable_binlog | OFF |

| innodb_locks_unsafe_for_binlog | OFF |

| log_bin | ON |

| log_bin_basename | /mysql/mybinlog/mysql-bin |

| log_bin_index | /mysql/mybinlog/mysql-bin.index |

| log_bin_trust_function_creators | OFF |

| log_bin_use_v1_row_events | OFF |

| max_binlog_cache_size | 18446744073709547520 |

| max_binlog_size | 1073741824 |

| max_binlog_stmt_cache_size | 18446744073709547520 |

| sql_log_bin | ON |

| sync_binlog | 0 |

+—————————————–+———————————+

22 rows in set (0.00 sec)

log_bin

设置此参数表示启用 binlog 功能，并指定路径名称

log_bin_index

设置此参数是指定二进制索引文件的路径与名称

binlog_do_db

此参数表示只记录指定数据库的二进制日志

binlog_ignore_db

此参数表示不记录指定的数据库的二进制日志

max_binlog_cache_size

此参数表示 binlog 使用的内存最大的尺寸

binlog_cache_size

此参数表示 binlog 使用的内存大小，可以通过状态变量 binlog_cache_use 和 binlog_cache_disk_use 来帮助测试。

binlog_cache_use：使用二进制日志缓存的事务数量

binlog_cache_disk_use: 使用二进制日志缓存但超过 binlog_cache_size 值并使用临时文件来保存事务中的语句的事务数量

max_binlog_size

Binlog 最大值，最大和默认值是 1GB，该设置并不能严格控制 Binlog 的大小，尤其是 Binlog 比较靠近最大值而又遇到一个比较大事务时，为了保证事务的完整性，不可能做切换日志的动作，只能将该事务的所有 SQL 都记录进当前日志，直到事务结束

sync_binlog

sync_binlog”：这个参数是对于 MySQL 系统来说是至关重要的，他不仅影响到 Binlog 对 MySQL 所带来的性能损耗，而且还影响到 MySQL 中数据的完整性。对于“sync_binlog”参数的各种设置的说明如下：

sync_binlog=0，当事务提交之后，MySQL 不做 fsync 之类的磁盘同步指令刷新 binlog_cache 中的信息到磁盘，而让 Filesystem 自行决定什么时候来做同步，或者 cache 满了之后才同步到磁盘。

sync_binlog=n，当每进行 n 次事务提交之后，MySQL 将进行一次 fsync 之类的磁盘同步指令来将 binlog_cache 中的数据强制写入磁盘。

在 MySQL 中系统默认的设置是 sync_binlog=0，也就是不做任何强制性的磁盘刷新指令，这时候的性能是最好的，但是风险也是最大的。因为一旦系统 Crash，在 binlog_cache 中的所有 binlog 信息都会被丢失。而当设置为“1”的时候，是最安全但是性能损耗最大的设置。因为当设置为 1 的时候，即使系统 Crash，也最多丢失 binlog_cache 中未完成的一个事务，对实际数据没有任何实质性影响。

从以往经验和相关测试来看，对于高并发事务的系统来说，“sync_binlog”设置为 0 和设置为 1 的系统写入性能差距可能高达 5 倍甚至更多。

relay log 的相关参数：

通过语句：show variables like %relay%，查看先骨干的 relay 的所有相关参数

mysql show variables like %relay%

+———————–+—————-+

| Variable_name | Value |

+———————–+—————-+

| max_relay_log_size | 0 |

| relay_log | |

| relay_log_index | |

| relay_log_info_file | relay-log.info |

| relay_log_purge | ON |

| relay_log_recovery | OFF |

| relay_log_space_limit | 0 |

| sync_relay_log | 0 |

| sync_relay_log_info | 0 |

+———————–+—————-+

9 rows in set (0.08 sec)

2.1 max_relay_log_size：标记 relay log 允许的最大值，如果该值为 0，则默认值为 max_binlog_size(1G)；如果不为 0，则 max_relay_log_size 则为最大的 relay_log 文件大小；

2.2 relay_log：定义 relay_log 的位置和名称，如果值为空，则默认位置在数据文件的目录，文件名为 host_name-relay-bin.nnnnnn（By default, relay log file names have the form host_name-relay-bin.nnnnnn in the data directory）；

2.3relay_log_index：同 relay_log，定义 relay_log 的位置和名称；

2.4relay_log_info_file：设置 relay-log.info 的位置和名称（relay-log.info 记录 MASTER 的 binary_log 的恢复位置和 relay_log 的位置）

2.5relay_log_purge：是否自动清空不再需要中继日志时。默认值为 1(启用)。

2.6relay_log_recovery：当 slave 从库宕机后，假如 relay-log 损坏了，导致一部分中继日志没有处理，则自动放弃所有未执行的 relay-log，并且重新从 master 上获取日志，这样就保证了 relay-log 的完整性。默认情况下该功能是关闭的，将 relay_log_recovery 的值设置为 1 时，可在 slave 从库上开启该功能，建议开启。

2.7relay_log_space_limit：防止中继日志写满磁盘，这里设置中继日志最大限额。但此设置存在主库崩溃，从库中继日志不全的情况，不到万不得已，不推荐使用；

2.8sync_relay_log：这个参数和 sync_binlog 是一样的，当设置为 1 时，slave 的 I / O 线程每次接收到 master 发送过来的 binlog 日志都要写入系统缓冲区，然后刷入 relay log 中继日志里，这样是最安全的，因为在崩溃的时候，你最多会丢失一个事务，但会造成磁盘的大量 I /O。当设置为 0 时，并不是马上就刷入中继日志里，而是由操作系统决定何时来写入，虽然安全性降低了，但减少了大量的磁盘 I / O 操作。这个值默认是 0，可动态修改，建议采用默认值。

2.9sync_relay_log_info：这个参数和 sync_relay_log 参数一样，当设置为 1 时，slave 的 I / O 线程每次接收到 master 发送过来的 binlog 日志都要写入系统缓冲区，然后刷入 relay-log.info 里，这样是最安全的，因为在崩溃的时候，你最多会丢失一个事务，但会造成磁盘的大量 I /O。当设置为 0 时，并不是马上就刷入 relay-log.info 里，而是由操作系统决定何时来写入，虽然安全性降低了，但减少了大量的磁盘 I / O 操作。这个值默认是 0，可动态修改，建议采用默认值。

关于 binlog 和 relay log 的删除方法：

binlog 太多的解决方法如下：

PURGE MASTER LOGS 手动删除用法及示例,MASTER 和 BINARY 是同义词

PURGE {MASTER | BINARY} LOGS TO log_name

PURGE {MASTER | BINARY} LOGS BEFORE date

实例：

PURGE MASTER LOGS TO MySQL-bin.010 // 清除 MySQL-bin.010 日志

PURGE MASTER LOGS BEFORE 2008-06-22 13:00:00 // 清除 2008-06-22 13:00:00 前 binlog 日志
PURGE MASTER LOGS BEFORE DATE_SUB(NOW(), INTERVAL 3 DAY); // 清除 3 天前 binlog 日志 BEFORE，变量的 date 自变量可以为 YYYY-MM-DD hh:mm:ss 格式。

或者直接：

进入数据库，查看一下当前使用的 binlog 日志是哪个，除了这个以外的，其它都可以使用 rm -rf 删除！

relay log 可以通过修改一个参数自动删除，前面已经介绍过参数：relay_log_purge=on 即可，自动清空不再需要中继日志。

总结：

mysql 数据库的 binlog 和 relay log 日志有着举足轻重的作用，并且 relay log 仅仅存在于 mysql 的 slave 库，它的作用就是记录 slave 库中的 io 进程接收的从主库传过来的 binlog, 然后等待 slave 库的 sql 进程去读取和应用，保证主从同步，但是 binlog 主库和从库（slave）都可以存在，记录对数据发生或潜在发生更改的 SQL 语句，并以二进制的形式保存在磁盘，所以可以通过 binlog 来实时备份和恢复数据库。

以上是“mysql 中 relay log 和 binlog 有什么用”这篇文章的所有内容，感谢各位的阅读！相信大家都有了一定的了解，希望分享的内容对大家有所帮助，如果还想学习更多知识，欢迎关注丸趣 TV 行业资讯频道！

正文完