mysql5.6增量备份

最新推荐文章于 2024-09-24 14:19:22 发布

sylalak123

最新推荐文章于 2024-09-24 14:19:22 发布

阅读量889

点赞数 1

分类专栏： mysql

本文链接：https://blog.csdn.net/yejinxiong001/article/details/77094763

版权

mysql 专栏收录该内容

27 篇文章 0 订阅

订阅专栏

本文介绍了MySQL Binlog的使用方法，包括如何通过指定日期范围或位置坐标来导出和恢复Binlog，同时还提供了关于sql_log_bin、skip-name-resolve及sync_binlog等重要配置项的解释。

摘要由CSDN通过智能技术生成

命令：

mysqlbinlog --start-datetime="2017-08-11 11:13:29" --stop-datetime="2017-08-11 11:14:29" mysqld-bin.000002 >2.sql

这是导出为sql文件然后导入sql文件即可！

或者

mysqlbinlog --start-datetime="2017-08-11 11:13:29" --stop-datetime="2017-08-11 11:14:29" mysqld-bin.000002 |msyql -uroot -p

直接恢复即可！！

恢复的起始时间和结束时间，不包含结束时间点的执行语句。

mysqlbinlog --start-position="8944" --stop-position="10620" mysqld-bin.000003 >3.sql

恢复的起始坐标和结束坐标，不包含结束坐标点的执行语句。

几个重要的设置说明：

mysql>set  sql_log_bin=0;

表示在当前会话不保存log_bin日志，一般在恢复数据的时候使用，恢复数据结束后，设置1即可。

skip-name-resolve
#禁止MySQL对外部连接进行DNS解析，使用这一选项可以消除MySQL进行DNS解析的时间。但需要注意，如果开启该选项，
#则所有远程主机连接授权都要使用IP地址方式，否则MySQL将无法正常处理连接请求。

“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倍甚至更多。

lower_case_table_names = 1 #实现mysql不区分大小（开发需求，建议开启）

bin_log备份中使用到的操作：
1.产看最后一个bin日志文件是那个,现在位置

2.启用新的日志文件,一般备份完数据库后执行

3.清空现有的所用bin-log