Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-14014

Multi-Slave Replication Fail: bogus data in log event

    XMLWordPrintable

Details

    • 10.2.14, 10.1.32

    Description

      After upgrading to 10.1.20, replication now intermittently stops (randomly and not all slaves of a master at the same time) with the following errors:

      2017-10-01 20:38:20 140079966804736 [ERROR] Master 'trades': Error reading packet from server: bogus data in log event; the first event 'mysql-bin.038184' at 156161357, the last event read from 'mysql-bin.038185' at 60018003, the last byte read from 'mysql-bin.038185' at 60018022. (server_errno=1236)
      2017-10-01 20:38:20 140079966804736 [ERROR] Master 'trades': Slave I/O: Got fatal error 1236 from master when reading data from binary log: 'bogus data in log event; the first event 'mysql-bin.038184' at 156161357, the last event read from 'mysql-bin.038185' at 60018003, the last byte read from 'mysql-bin.038185' at 60018022.', Internal MariaDB error code: 1236
      

      We can fix this by issuing a START SLAVE and everything works without issue but the regular replication failures occurs.

      It looks like upstream bug : https://bugs.mysql.com/bug.php?id=84752

      With setting slave_compressed_protocol=1 and change the sync_binlog value to off, it's working fine. This is not easily reproducible. As per the comment in upstream bug, able to reproduce only with high load on master server and multiple slaves (like 5 or 6)

      Attachments

        Issue Links

          Activity

            People

              serg Sergei Golubchik
              niljoshi Nilnandan Joshi
              Votes:
              0 Vote for this issue
              Watchers:
              8 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Git Integration

                  Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.