mysqlbinlog Ver 3.3和3.1版本之间的输出差异

mysqlbinlog Ver 3.3中多了一个--base64-output参数，默认值为auto:

--base64-output[=name]
Determine when the output statements should be
base64-encoded BINLOG statements: 'never' disables it and
works only for binlogs without row-based events; 'auto'
is the default and prints base64 only when necessary
(i.e., for row-based events and format description
events); 'always' prints base64 whenever possible.
'always' is for debugging only and should not be used in
a production system. The default is 'auto'.
--base64-output is a short form for
--base64-output=always.

在原来的Ver3.1版本中没有此参数，对比mysql5.0生成的日志文件的输出结果：
Ver3.1版本中使用mysqlbinlog输出结果：

shell> mysqlbinlog mysql-bin.000182|less
/*!40019 SET @@session.max_insert_delayed_threads=0*/;
/*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/;
DELIMITER /*!*/;
# at 4
#100515 1:38:58 server id 25 end_log_pos 98 Start: binlog v 4, server v 5.0.37-log created 100515 1:38:58
# at 98

Ver3.3版本中使用mysqlbinlog输出结果：

shell> mysqlbinlog --base64-output=never mysql-bin.000182|less
/*!40019 SET @@session.max_insert_delayed_threads=0*/;
/*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/;
DELIMITER /*!*/;
# at 4
#100515 1:38:58 server id 25 end_log_pos 98 Start: binlog v 4, server v 5.0.37-log created 100515 1:38:58
# at 98

shell> mysqlbinlog --base64-output=auto mysql-bin.000182|less
/*!40019 SET @@session.max_insert_delayed_threads=0*/;
/*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/;
DELIMITER /*!*/;
# at 4
#100515 1:38:58 server id 25 end_log_pos 98 Start: binlog v 4, server v 5.0.37-log created 100515 1:38:58
BINLOG '
sortSw8ZAAAAXgAAAGIAAAAAAAQANS4wLjM3LWxvZwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAEzgNAAgAEgAEBAQEEgAASwAEGg==
'/*!*/;
# at 98

从上面结果比较而言，相当于3.1版本的mysqlbinlog的base64-output参数默认为never。
在mysql 5.0中带的mysqlbinlog一般为3.1版本的，而mysql5.1版本中带的mysqlbinlog则为3.3版本，如果需要将mysql5.0生成的日志文件导入mysql5.1时，需要将mysqlbinlog的base64-output值设置为never。如果不设置此参数，导入日志时，会在

BINLOG 'sortSw8ZAAAAXgAAAGIAAAAAAAQANS4wLjM3LWxvZwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAEzgNAAgAEgAEBAQEEgAASwAEGg=='

处报SQL语法错误。

MySQL5 slave同步报错(server_errno=1236)

100519 19:35:33 [Note] Slave I/O thread: connected to master 'repl@master:3306', replication started in log 'mysql-bin.000176' at position 615525147

100519 19:35:33 [ERROR] Error reading packet from server: Could not find first log file name in binary log index file ( server_errno=1236)

从日志信息上可知，slave已经连接到master，并且准备从指定的binlog文件指定位置开始同步，但后面错误提示日志文件找不到，而master服务器上日志文件是存在的。
这种情况有二种处理方法：
一、重启主数据库(master)之后，然后slave上stop slave;start slave，再检查同步的状态。
二、不重启主服务器，则用mysqlbinlog根据start-position或者start-datetime，将日志分析出来后，将分析结果在slave上用mysql命令导入，导入完成后，再用CHANGE MASTER TO语句，从下一个日志文件MASTER_LOG_POSITION=98开始同步。

另外在使用mysqlbinlog工具进行日志导入时，需要注意以下问题，下面内容转自MySQL官方手册：
如果MySQL服务器上有多个要执行的二进制日志，安全的方法是在一个连接中处理它们。下面是一个说明什么是不安全的例子：

shell> mysqlbinlog hostname-bin.000001 | mysql # DANGER!!
shell> mysqlbinlog hostname-bin.000002 | mysql # DANGER!!

使用与服务器的不同连接来处理二进制日志时，如果第1个日志文件包含一个CREATE TEMPORARY TABLE语句，第2个日志包含一个使用该临时表的语句，则会造成问题。当第1个mysql进程结束时，服务器撤销临时表。当第2个mysql进程想使用该表时，服务器报告 “不知道该表”。

要想避免此类问题，使用一个连接来执行想要处理的所有二进制日志中的内容。下面提供了一种方法：

shell> mysqlbinlog hostname-bin.000001 hostname-bin.000002 | mysql -u root -ppassword

Reference: http://yuweijun.blogspot.com/2009/12/mysql50.html