Skip to main content
Database Administrators

Return to Answer

replaced http://dba.stackexchange.com/ with https://dba.stackexchange.com/
Source Link
Community Bot
Community Bot
  • 1

I have another reason why replication can never fully work in this scenario.

The format of binary logs can shift when the format of data changes. One crazy example I have written about is the DATETIME data type. MySQL 5.6 introduced microseconds into DATETIME. This changed the width of the DATETIME value when the binlog_format used was ROW. This will instantly break replication when a slave before MySQL 5.6 tries to interpret a DATETIME value from a master whose version is MySQL 5.6+.

I wrote about this phenomenon twice

While Michael - sqlbot's answerMichael - sqlbot's answer is much closer to the answer you are looking for, my answer is just giving you an additional reason why replication must always break in your particular case.

Perhaps if both Master and Slave used binlog_format=STATEMENT, you might get away with replication for a limited time, provided the internal binlog format does not unpack into another ENUM value that cannot be understand by the 5.5 slave.

I have another reason why replication can never fully work in this scenario.

The format of binary logs can shift when the format of data changes. One crazy example I have written about is the DATETIME data type. MySQL 5.6 introduced microseconds into DATETIME. This changed the width of the DATETIME value when the binlog_format used was ROW. This will instantly break replication when a slave before MySQL 5.6 tries to interpret a DATETIME value from a master whose version is MySQL 5.6+.

I wrote about this phenomenon twice

While Michael - sqlbot's answer is much closer to the answer you are looking for, my answer is just giving you an additional reason why replication must always break in your particular case.

Perhaps if both Master and Slave used binlog_format=STATEMENT, you might get away with replication for a limited time, provided the internal binlog format does not unpack into another ENUM value that cannot be understand by the 5.5 slave.

I have another reason why replication can never fully work in this scenario.

The format of binary logs can shift when the format of data changes. One crazy example I have written about is the DATETIME data type. MySQL 5.6 introduced microseconds into DATETIME. This changed the width of the DATETIME value when the binlog_format used was ROW. This will instantly break replication when a slave before MySQL 5.6 tries to interpret a DATETIME value from a master whose version is MySQL 5.6+.

I wrote about this phenomenon twice

While Michael - sqlbot's answer is much closer to the answer you are looking for, my answer is just giving you an additional reason why replication must always break in your particular case.

Perhaps if both Master and Slave used binlog_format=STATEMENT, you might get away with replication for a limited time, provided the internal binlog format does not unpack into another ENUM value that cannot be understand by the 5.5 slave.

Source Link
RolandoMySQLDBA
RolandoMySQLDBA
  • 185.6k
  • 34
  • 327
  • 543

I have another reason why replication can never fully work in this scenario.

The format of binary logs can shift when the format of data changes. One crazy example I have written about is the DATETIME data type. MySQL 5.6 introduced microseconds into DATETIME. This changed the width of the DATETIME value when the binlog_format used was ROW. This will instantly break replication when a slave before MySQL 5.6 tries to interpret a DATETIME value from a master whose version is MySQL 5.6+.

I wrote about this phenomenon twice

While Michael - sqlbot's answer is much closer to the answer you are looking for, my answer is just giving you an additional reason why replication must always break in your particular case.

Perhaps if both Master and Slave used binlog_format=STATEMENT, you might get away with replication for a limited time, provided the internal binlog format does not unpack into another ENUM value that cannot be understand by the 5.5 slave.