最新文章专题视频专题问答1问答10问答100问答1000问答2000关键字专题1关键字专题50关键字专题500关键字专题1500TAG最新视频文章推荐1 推荐3 推荐5 推荐7 推荐9 推荐11 推荐13 推荐15 推荐17 推荐19 推荐21 推荐23 推荐25 推荐27 推荐29 推荐31 推荐33 推荐35 推荐37视频文章20视频文章30视频文章40视频文章50视频文章60 视频文章70视频文章80视频文章90视频文章100视频文章120视频文章140 视频2关键字专题关键字专题tag2tag3文章专题文章专题2文章索引1文章索引2文章索引3文章索引4文章索引5123456789101112131415文章专题3
当前位置: 首页 - 科技 - 知识百科 - 正文

Disablingbinlog_checksumforMySQL5.5/5.6master-masterre_MySQL

来源:动视网 责编:小采 时间:2020-11-09 19:11:39
文档

Disablingbinlog_checksumforMySQL5.5/5.6master-masterre_MySQL

Disablingbinlog_checksumforMySQL5.5/5.6master-masterre_MySQL:Replicating from a newer major version to an older major version in MySQL (for example a 5.6 master and a 5.5 replica) is generally not recommended, but when upgrading a master-master replication topology its hard to avoid this scenario en
推荐度:
导读Disablingbinlog_checksumforMySQL5.5/5.6master-masterre_MySQL:Replicating from a newer major version to an older major version in MySQL (for example a 5.6 master and a 5.5 replica) is generally not recommended, but when upgrading a master-master replication topology its hard to avoid this scenario en


Replicating from a newer major version to an older major version in MySQL (for example a 5.6 master and a 5.5 replica) is generally not recommended, but when upgrading a master-master replication topology it’s hard to avoid this scenario entirely. We ended up in this situation last week when upgrading the passive master of an active-passive master-master pair from 5.5 to 5.6. The primary replication flow was going from the active master (5.5) to the passive master (5.6) with no errors, butpt-heartbeatwas running on the passive master, which led to a replication failure with this error on the active master:

Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: ‘Slave can not handle replication events with the checksum that master is configured to log; the first event ‘bin-log.002648’ at 4, the last event read from ‘/var/lib/mysqllogs/bin-log.002648’ at 120, the last byte read from ‘/var/lib/mysqllogs/bin-log.002648’ at 120.’

Why did this happen? Starting in MySQL 5.6.6, the newbinlog_checksumoption defaults toCRC32. Since that option did not exist in MySQL 5.5, the replica can’t handle the checksums coming from the master. Therefore I recommend settingbinlog_checksum=NONEin my.cnf as part of the upgrade process for a master-master setup to avoid this error.

My fix was to run this on the passive master:

set global binlog_checksum='NONE';

Then I added this to my.cnf so it would survive a restart:

binlog_checksum=NONE

After that change was made I examined the binary log to confirm that it did not include anything other than pt-heartbeat activity, and then executedCHANGE MASTERon the active master to skip the checksummed events.

Once the other master is upgraded I can go back and consider changingbinlog_checksumtoCRC32.

文档

Disablingbinlog_checksumforMySQL5.5/5.6master-masterre_MySQL

Disablingbinlog_checksumforMySQL5.5/5.6master-masterre_MySQL:Replicating from a newer major version to an older major version in MySQL (for example a 5.6 master and a 5.5 replica) is generally not recommended, but when upgrading a master-master replication topology its hard to avoid this scenario en
推荐度:
标签: 5.5 for mysql
  • 热门焦点

最新推荐

猜你喜欢

热门推荐

专题
Top