如何管理 MySQL 的 binlog

*************************************
*                       关于 binlog              *
*************************************
--binlog 以一种更有效的格式，并且是事务安全的方式包含更新日志中可用的所有信息。
--binlog 包含了所有更新了数据或者已经潜在更新了数据（例如，没有匹配任何行的一个DELETE）的所有语句。语句以“事件”的形式保存，它描述数据更改。
--binlog 还包含关于每个更新数据库的语句的执行时间信息。它不包含没有修改任何数据的语句。如果你想要记录所有语句（例如，为了识别有问题的查询），你应使用一般查询日志。
--binlog 的主要目的是在恢复使能够最大可能地更新数据库，因为 binlog 包含备份后进行的所有更新。
--binlog 还用于在主复制服务器上记录所有将发送给从服务器的语句。
--运行服务器时若启用 binlog 则性能大约慢1%。但是， binlog 的好处，即用于恢复并允许设置复制超过了这个小小的性能损失。
--当--log-bin[=file_name]选项启动时，mysqld写入包含所有更新数据的SQL命令的日志文件。如果未给出file_name值， 默认名为-bin后面所跟的主机名。如果给出了文件名，但没有包含路径，则文件被写入数据目录。建议指定一个文件名。如果你在日志名中提供了扩展名(例如，--log-bin=file_name.extension)，则扩展名被悄悄除掉并忽略。
--mysqld在每个 binlog 名后面添加一个数字扩展名。每次你启动服务器或刷新日志时该数字则增加。如果当前的日志大小达到max_binlog_size，还会自动创建新的 binlog 。如果你正使用大的事务， binlog 还会超过max_binlog_size：事务全写入一个 binlog 中，绝对不要写入不同的 binlog 中。
--为了能够知道还使用了哪个不同的 binlog 文件，mysqld还创建一个 binlog 索引文件，包含所有使用的 binlog 文件的文件名。默认情况下与 binlog 文件的文件名相同，扩展名为'.index'。你可以用--log-bin-index[=file_name]选项更改 binlog 索引文件的文件名。当mysqld在运行时，不应手动编辑该文件；如果这样做将会使mysqld变得混乱。
--binlog 格式有一些已知限制，会影响从备份恢复。
--默认情况下，并不是每次写入时都将 binlog 与硬盘同步。因此如果操作系统或机器(不仅仅是MySQL服务器)崩溃，有可能 binlog 中最后的语句丢失了。要想防止这种情况，你可以使用sync_binlog全局变量(1是最安全的值，但也是最慢的)，使 binlog 在每N次 binlog 写入后与硬盘同步。

************************************************
*                如何管理 MySQL 的 binlog           *
************************************************
1、在 my.ini 中增加下述参数，指定保存更新到 binlog 的数据库：db_name，未在此指定的数据库将不记录 binlog
--binlog-do-db=db_name

2、在 my.ini 中增加下述参数，指定不保存更新到 binlog 的数据库：db_name
--binlog-ignore-db=db_name

3、如果 binlog 已经产生，可以通过 SQL 命令行清除：

/*
* 要清理日志，需按照以下步骤：
* 1 在每个从属服务器上，使用SHOW SLAVE STATUS来检查它正在读取哪个日志。
* 2 使用SHOW MASTER LOGS获得主服务器上的一系列日志。
* 3 在所有的从属服务器中判定最早的日志。这个是目标日志。如果所有的从属服务器是更新的，这是清单上的最后一个日志。
* 4 制作您将要删除的所有日志的备份。（这个步骤是自选的，但是建议采用。）
* 5 清理所有的日志，但是不包括目标日志。
*
*/

/*
* 清除 binlog
*
* 为了执行RESET，您必须拥有RELOAD权限。
* 以下命令将删除列于索引文件中的所有 binlog，把 binlog 索引文件重新设置为空，并创建一个新的 binlog。
* （在以前版本的MySQL中，被称为FLUSH MASTER。）
*/
RESET MASTER;

/*
* 清除指定的 binlog
*
*/
PURGE MASTER LOGS TO 'mysql-bin.010';
/*
* 清除日期为 2006-06-06 06:06:06 以前的 binlog
*
* BEFORE变量的date自变量可以为'YYYY-MM-DD hh:mm:ss'格式。MASTER和BINARY是同义词。
*/
PURGE MASTER LOGS BEFORE '2006-06-06 06:06:06';
/*
* 清除3天前的 binlog
*
*/
PURGE MASTER LOGS BEFORE DATE_SUB( NOW( ), INTERVAL 3 DAY);

评论

1 楼 rq2_79 2007-12-12  

MySQL的binlog, InnoDB的日志和Oracle的日志

MySQL中有一个binlog的概念, 用于保存对数据库所作的修改, 这点上和Oracle的归档日志很接近, 但在原理上是很不一样的. 以InnoDB为例, InnoDB本身就有log文件, 和Oracle的联机日志一样, 用完了就重用, 但binlog并不是InnoDB的日志在重用前的拷贝, 而是另外写了一个文件. 因为binlog并不是专门为InnoDB设计的, 其他的存贮引挚如MyISAM也支持binlog, 它是MySQL备份及复制支持的重要基础, 因此不同于InnoDB的日志文件.

    如果MySQL用于很重要的系统, 需要事务支持, 并且要支持联机备份, 要保证没有数据丢失, 目前来说, 一般会用InnoDB存贮引挚, 并启用binlog, 为了保证事务的数据不丢失, 就得:

1, 在每次Commit时, 将修改写入InnoDB的日志文件
2, 在每次Commit时, 将修改写入binlog文件
    而在Oracle中只是保证写入到Oracle的联机日志就够了, 因此在性能测试中, 如果启用了binlog, 性能基本上下降了一半, 因为这中间要做两次写操作. 另外现在的版本中, 一个事务不能跨越binlog, 因此启用binlog的情况下, 就要少用大事务了. 查一下资料, 原来InnoDB也可以有Archived Log模式, 但在MySQL的手册中找到这样一段话, 好象功能已经过时了?

innodb_log_archive

Whether to log InnoDB archive files. This variable is present for historical reasons, but is unused. Recovery from a backup is done by MySQL using its own log files, so there is no need to archive InnoDB log files. The default for this variable is 0.
    过多的功能支持, 必然会造成衔接的松散, 从儿得不到最大化的性能. 理论上来说不够安全的成组提交是MySQL的亮点, Oracle10g好象也有这个功能的, 只不过默认情况下是关闭的.

    从这个结构来看, MySQL不太适合用于很重要的数据, 如财务数据等.