mysql binlog二进制日志详解
程序员文章站
2023-12-18 09:16:46
基本概念 定义： 二进制日志包含了所有更新了数据或者已经潜在更新了数据（例如，没有匹配任何行的一个delete）的所有语句。 作用： 1。二进制日志的主要目的是在恢复使能够...
基本概念
定义：
二进制日志包含了所有更新了数据或者已经潜在更新了数据（例如，没有匹配任何行的一个delete）的所有语句。
作用：
1。二进制日志的主要目的是在恢复使能够最大可能地更新数据库，因为二进制日志包含备份后进行的所有更新。
2。二进制日志还用于在主复制服务器上记录所有将发送给从服务器的语句。
不良影响：
运行服务器时若启用二进制日志则性能大约慢1%。
如何启动：
通过 –log-bin=file选项可以启用
(更改my.ini文件)
日志位置
>>如果没有指定文件名,则mysql使用hostname-bin文件.
>>如果指定了相对路径,则假定该路径相对于数据目录
>>mysql在文件名后添加了数字索引.所以该文件最后的形式为filename.number
如果你在日志名中提供了扩展名(例如，–log-bin=file_name.extension)，则扩展名被悄悄除掉并忽略。
更换策略：
使用索引来循环文件,在以下条件将循环至下一个索引
1。服务器重启
2。服务器被更新
3。日志到达了最大日志长度 max_binlog_size
4。日志被刷新 mysql> flush logs;
工具介绍：
shell>>mysqlbinlog [option] binlogfile> newfile
如： d:\mysql\log>mysqlbinlog binlog.000001 > 1.txt
一个例子：
log-bin=”d:/mysql/log/binlog” 那么，在该文件夹下就会有文件d:/mysql/log/binlog.000001等
常见问题
1.如何清除binlog
>>>使用下面的两个命令
purge {master | binary} logs to ‘log_name' //log_name不会被清除
purge {master | binary} logs before ‘date' //date不会被清除
实例如下：
mysql> purge master logs to ‘binlog.000004′;
query ok, 0 rows affected (0.01 sec)
mysql> purge master logs before '2009-09-22 00:00:00′;
query ok, 0 rows affected (0.05 sec)
>>>或使用命令
reset master
删除之前所有的binlog，并重新生成新的binlog
后缀从000001开始
注：如果您有一个活性的从属服务器，该服务器当前正在读取您正在试图删除的日志之一，
则本语句不会起作用，而是会失败，并伴随一个错误。
不过，如果从属服务器是休止的，并且您碰巧清理了其想要读取的日志之一，则从属服务器启动后不能复制。
当从属服务器正在复制时，本语句可以安全运行。您不需要停止它们。
2.记录到二进制日志知的内容配置
binlog-do-db=sales 只记录sales库
binlog-ignore-db=sales 除sales库不记录，其他都记录
但是如果在操作数据库之前，不使用use $dbname 那么所有的sql都不会记录
如果使用了use $dbname,那么判断规则取决于这里的$dbname，而不是sql中操作的库
3.二进制日志不准确的处理
默认情况下，并不是每次写入时都将二进制日志与硬盘同步。因此如果操作系统或机器(不仅仅是mysql服务器)崩溃，有可能二进制日志中最后的语句丢失。
要想防止这种情况，你可以使用sync_binlog全局变量(1是最安全的值，但也是最慢的)，使二进制日志在每n次二进制日志写入后与硬盘同步。
即使sync_binlog设置为1,出现崩溃时，也有可能表内容和二进制日志内容之间存在不一致性。
如果崩溃恢复时mysql服务器发现二进制日志变短了(即至少缺少一个成功提交的innodb事务)，
如果sync_binlog =1并且硬盘/文件系统的确能根据需要进行同步(有些不需要)则不会发生，则输出错误消息 (“二进制日志<名>比期望的要小”)。
在这种情况下，二进制日志不准确，复制应从主服务器的数据快照开始。
定义：
二进制日志包含了所有更新了数据或者已经潜在更新了数据（例如，没有匹配任何行的一个delete）的所有语句。
作用：
1。二进制日志的主要目的是在恢复使能够最大可能地更新数据库，因为二进制日志包含备份后进行的所有更新。
2。二进制日志还用于在主复制服务器上记录所有将发送给从服务器的语句。
不良影响：
运行服务器时若启用二进制日志则性能大约慢1%。
如何启动：
通过 –log-bin=file选项可以启用
(更改my.ini文件)
日志位置
>>如果没有指定文件名,则mysql使用hostname-bin文件.
>>如果指定了相对路径,则假定该路径相对于数据目录
>>mysql在文件名后添加了数字索引.所以该文件最后的形式为filename.number
如果你在日志名中提供了扩展名(例如，–log-bin=file_name.extension)，则扩展名被悄悄除掉并忽略。
更换策略：
使用索引来循环文件,在以下条件将循环至下一个索引
1。服务器重启
2。服务器被更新
3。日志到达了最大日志长度 max_binlog_size
4。日志被刷新 mysql> flush logs;
工具介绍：
shell>>mysqlbinlog [option] binlogfile> newfile
如： d:\mysql\log>mysqlbinlog binlog.000001 > 1.txt
一个例子：
log-bin=”d:/mysql/log/binlog” 那么，在该文件夹下就会有文件d:/mysql/log/binlog.000001等
常见问题
1.如何清除binlog
>>>使用下面的两个命令
purge {master | binary} logs to ‘log_name' //log_name不会被清除
purge {master | binary} logs before ‘date' //date不会被清除
实例如下：
mysql> purge master logs to ‘binlog.000004′;
query ok, 0 rows affected (0.01 sec)
mysql> purge master logs before '2009-09-22 00:00:00′;
query ok, 0 rows affected (0.05 sec)
>>>或使用命令
reset master
删除之前所有的binlog，并重新生成新的binlog
后缀从000001开始
注：如果您有一个活性的从属服务器，该服务器当前正在读取您正在试图删除的日志之一，
则本语句不会起作用，而是会失败，并伴随一个错误。
不过，如果从属服务器是休止的，并且您碰巧清理了其想要读取的日志之一，则从属服务器启动后不能复制。
当从属服务器正在复制时，本语句可以安全运行。您不需要停止它们。
2.记录到二进制日志知的内容配置
binlog-do-db=sales 只记录sales库
binlog-ignore-db=sales 除sales库不记录，其他都记录
但是如果在操作数据库之前，不使用use $dbname 那么所有的sql都不会记录
如果使用了use $dbname,那么判断规则取决于这里的$dbname，而不是sql中操作的库
3.二进制日志不准确的处理
默认情况下，并不是每次写入时都将二进制日志与硬盘同步。因此如果操作系统或机器(不仅仅是mysql服务器)崩溃，有可能二进制日志中最后的语句丢失。
要想防止这种情况，你可以使用sync_binlog全局变量(1是最安全的值，但也是最慢的)，使二进制日志在每n次二进制日志写入后与硬盘同步。
即使sync_binlog设置为1,出现崩溃时，也有可能表内容和二进制日志内容之间存在不一致性。
如果崩溃恢复时mysql服务器发现二进制日志变短了(即至少缺少一个成功提交的innodb事务)，
如果sync_binlog =1并且硬盘/文件系统的确能根据需要进行同步(有些不需要)则不会发生，则输出错误消息 (“二进制日志<名>比期望的要小”)。
在这种情况下，二进制日志不准确，复制应从主服务器的数据快照开始。