如何管理 MySQL 的 binlog
作者&投稿：掌欧 （若有异议请与网页底部的电邮联系）
有两种方法，一种方法使用mysql的check table和repair table 的sql语句，另一种方法是使用MySQL提供的多个myisamchk, isamchk数据检测恢复工具。前者使用起来比较简便。推荐使用。
1. check table 和 repair table
登陆mysql 终端：
mysql -uxxxxx -p dbname
check table tabTest;
如果出现的结果说Status是OK，则不用修复，如果有Error，可以用：
repair table tabTest;
进行修复，修复之后可以在用check table命令来进行检查。在新版本的phpMyAdmin里面也可以使用check/repair的功能。
2. myisamchk, isamchk
其中myisamchk适用于MYISAM类型的数据表，而isamchk适用于ISAM类型的数据表。这两条命令的主要参数相同，一般新的系统都使用MYISAM作为缺省的数据表类型，这里以myisamchk为例子进行说明。当发现某个数据表出现问题时可以使用：
myisamchk tablename.MYI
进行检测，如果需要修复的话，可以使用：
myisamchk -of tablename.MYI
关于myisamchk的详细参数说明，可以参见它的使用帮助。需要注意的时在进行修改时必须确保MySQL服务器没有访问这个数据表，保险的情况下是最好在进行检测时把MySQL服务器Shutdown掉。
另外可以把下面的命令放在你的rc.local里面启动MySQL服务器前：
[ -x /tmp/mysql.sock ] && /pathtochk/myisamchk -of /DATA_DIR/*/*.MYI
其中的/tmp/mysql.sock是MySQL监听的Sock文件位置，对于使用RPM安装的用户应该是/var/lib/mysql/mysql.sock，对于使用源码安装则是/tmp/mysql.sock可以根据自己的实际情况进行变更，而pathtochk则是myisamchk所在的位置，DATA_DIR是你的MySQL数据库存放的位置。
需要注意的时，如果你打算把这条命令放在你的rc.local里面，必须确认在执行这条指令时MySQL服务器必须没有启动！检测修复所有数据库(表)
怎么执行mysqlbinlog命令
这个你可以看配置文件 启用了才有这样的记录默认是没有的 /etc/my.conf log-bin = mysqlbin 一般放在/var/lib/mysql 比如上面的设置重启数据库会生成mysqlbin.000001文件
- 所有已经提交的事务的数据仍然存在。
- 所有没有提交的事务的数据自动回滚。
- 所有已经提交了的事务的Binlog Event也仍然存在。
- 所有没有提交事务没有记录Binlog Event。
这些要求很好理解，如果重启后数据还在，但是Binlog Event没有了，就没办法复制到其他节点上了。如果重启后，数据没了，但是Binlog Event还在，那么不存在的数据就会被复制到其他节点上，从而导致主从的不一致。
为了保证带Binlog的CrashSafe，MySQL内部使用的两阶段提交(Two Phase Commit)。
2 - MySQL的Two Phase Commit(2PC)
在开启Binlog后，MySQL内部会自动将普通事务当做一个XA事务来处理：
- 自动为每个事务分配一个唯一的ID
- COMMIT会被自动的分成Prepare和Commit两个阶段。
- Binlog会被当做事务协调者(Transaction Coordinator)，Binlog Event会被当做协调者日志。
想了解2PC，可以参考文档：【https://en.wikipedia.org/wiki/Two-phase_commit_protocol。】
- 分布式事务ID(XID)
使用2PC时，MySQL会自动的为每一个事务分配一个ID，叫XID。XID是唯一的，每个事务的XID都不相同。XID会分别被Binlog和InnoDB记入日志中，供恢复时使用。MySQ内部的XID由三部分组成：
- 前缀部分
前缀部分是字符串"MySQLXid"
- Server ID部分
当前MySQL的server_id
- query_id部分
为了保证XID的的唯一性，数字部分使用了query_id。MySQL内部会自动的为每一个语句分配一个query_id，全局唯一。
参考代码：sql/xa。h的struct xid_t结构。
- 事务的协调者Binlog
Binlog在2PC中充当了事务的协调者（Transaction Coordinator）。由Binlog来通知InnoDB引擎来执行prepare，commit或者rollback的步骤。事务提交的整个过程如下：
1. 协调者准备阶段(Prepare Phase)
告诉引擎做Prepare，InnoDB更改事务状态，并将Redo Log刷入磁盘。
2. 协调者提交阶段(Commit Phase)
2.1 记录协调者日志，即Binlog日志。
2.2 告诉引擎做commit。
注意：记录Binlog是在InnoDB引擎Prepare(即Redo Log写入磁盘)之后，这点至关重要。
在MySQ的代码中将协调者叫做tc_log。在MySQL启动时，tc_log将被初始化为mysql_bin_log对象。参考sql/binlog.cc中的init_server_components()：
if (opt_bin_log) tc_log= &mysql_bin_log;
而在事务提交时，会依次执行：
tc_log->prepare()；
tc_log->commit()；
参考代码：sql/binlog.cc中的ha_commit_trans()。当mysql_bin_log是tc_log时，prepare和commit的代码在sql/binlog.cc中：
MYSQL_BIN_LOG::prepare()；
MYSQL_BIN_LOG::commit()；
-协调者日志Xid_log_event
作为协调者，Binlog需要将事务的XID记入日志，供恢复时使用。Xid_log_event有以下几个特点：
- 仅记录query_id
因为前缀部分不变，server_id已经记录在Event Header中，Xid_log_event中只记录query_id部分。
- 标志事务的结束
在Binlog中相当于一个事务的COMMIT语句。
一个事务在Binlog中看起来时这样的：
Query_log_event("BEGIN");DML产生的events; Xid_log_event;
- DDL没有BEGIN，也没有Xid_log_event 。
- 仅InnoDB的DML会产生Xid_log_event
因为MyISAM不支持2PC所以不能用Xid_log_event ，但会有COMMIT Event。
Query_log_event("BEGIN");DML产生的events;Query_log_event("COMMIT");
问题：Query_log_event("COMMIT")和Xid_log_event 有不同的影响吗？
- Xid_log_event 中的Xid可以帮助master实现CrashSafe。
- Slave的CrashSafe不依赖Xid_log_event
事务在Slave上重做时，会重新产生XID。所以Slave服务器的CrashSafe并不依赖于Xid_log_event 。Xid_log_event 和Query_log_event("COMMIT")，只是作为事务的结尾，告诉Slave Applier去提交这个事务。因此二者在Slave上的影响是一样的。
3 - 恢复(Recovery)
这个机制是如何保证MySQL的CrashSafe的呢，我们来分析一下。这里我们假设用户设置了以下参数来保证可靠性：
- 恢复前事务的状态
在恢复开始前事务有以下几种状态：
- InnoDB中已经提交
根据前面2PC的过程，可知Binlog中也一定记录了该事务的的Events。所以这种事务是一致的不需要处理。
- InnoDB中是prepared状态，Binlog中有该事务的Events。
需要通知InnoDB提交这些事务。
- InnoDB中是prepared状态，Binlog中没有该事务的Events。
因为Binlog还没记录，需要通知InnoDB回滚这些事务。
- Before InnoDB Prepare
事务可能还没执行完，因此InnoDB中的状态还没有prepare。根据2PC的过程，Binlog中也没有该事务的events。 需要通知InnoDB回滚这些事务。
- 恢复过程
从上面的事务状态可以看出：恢复时事务要提交还是回滚，是由Binlog来决定的。
- 事务的Xid_log_event 存在，就要提交。
- 事务的Xid_log_event 不存在，就要回滚。
恢复的过程非常简单：
- 从Binlog中读出所有的Xid_log_event
- 告诉InnoDB提交这些XID的事务
- InnoDB回滚其它的事务
* 关于 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);
满闻诺欣： 我以前设计过类似系统,作为省、市、县、业务员多层次的领用、销号,种类繁多、数目庞大.我采用了大家可能都会认为非常笨的程序设计方法:每一张单证一条数据库记录.这样程序就非常...
