mysql中relay log和binlog有什么用
发布时间：2021-12-23 12:33:39 所属栏目：MySql教程 来源：互联网
导读：这篇文章主要为大家展示了mysql中relay log和binlog有什么用，内容简而易懂，条理清晰，希望能够帮助大家解决疑惑，下面让小编带领大家一起研究并学习一下mysql中relay log和binlog有什么用这篇文章吧。 突然mysql数据库的一个表的数据少了很多，我想着通过
|
这篇文章主要为大家展示了“mysql中relay log和binlog有什么用”，内容简而易懂，条理清晰，希望能够帮助大家解决疑惑，下面让小编带领大家一起研究并学习一下“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来实时备份和恢复数据库。 （编辑：PHP编程网 - 黄冈站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
浙公网安备 33038102330482号