I have looked over the mysqlbinlog
command as a candidate for rollback method from MySQL 5.5 to MySQL 5.0.
When I ran the command on one of the bin-log files in the MySQL 5.5 server, I've noticed those base64 statements:
/*!40019 SET @@session.max_insert_delayed_threads=0*/;
/*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/;
DELIMITER /*!*/;
# at 4
#111219 19:25:06 server id 395220 end_log_pos 107 Start: binlog v 4, server v 5.5.18-log created 111219 19:25:06
BINLOG '
ko/vTg/UBwYAZwAAAGsAAAAAAAQANS41LjE4LWxvZwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAEzgNAAgAEgAEBAQEEgAAVAAEGggAAAAICAgCAA==
'/*!*/;
# at 107
#111219 19:25:06 server id 370534 end_log_pos 171 Query thread_id=387276 exec_time=73680 error_code=0
When I've checked the MySQL 5.0 bin-log files, I've noticed those statments were missing. My first guess was that this is a new feature in MySQL Replication. I know I should not use binlogs from MySQL 5.5 on MySQL 5.0. Therefore, the only way I can promise the rollback of the data is by running the queries as queries.
When I ran mysqlbinlog --base64-output=NEVER
, I noticed that the base64 statements had disappeared. I would have expected them to be translated to plain text queries, but this was not the case.
Can someone put more light on what those base64 statements means?
Thanks,
Shahar.
Best Answer
From the MySQL Documentation
CAVEAT
Please keep in mind that binary logs are not backward compatible.
In ServerFault. someone thought that a master's binary log was corrupt, not realizing that binary logs have different start points. I addressed by explaining the following:
An empty binary log's filesize is
As you already pointed out, Replication works from a 5.0 Master to a 5.5 Slave, not the other way around.