GET 24/7 LIVE HELP NOW

Announcement

Announcement Module
Collapse
No announcement yet.

5.0.92 binlog issue

Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • 5.0.92 binlog issue

    Hi there,

    I'm trying to set up master-slave replication in between 5.0.92 percona and regular 5.0.77 mysql. 5.0.77 - the slave reports about log corruption once it is established. When I do check binary logs with mysqlbinlog utulity on 5.0.92 - the master I'm getting like :

    #121003 5:22:26 server id 1 end_log_pos 398528
    # Unknown event
    # at 398528
    #960218 6:48:44 server id 1813111337 end_log_pos 1835008
    # Unknown event
    ERROR: Error in Log_event::read_log_event(): 'Event too big', data_len: 1953066613, event_type: 8
    DELIMITER ;
    # End of log file

    However, I'm able to see quieries when I look at raw files and the same if I run mysqlbin -H. The output looks readable besides unknown event messages.
    Most everything looks like this - https://answers.launchpad.net/percona-server/+question/12523 0.

    OS - CentOS 6.3. percona was installed from percona's repo.

    Any help would be appreciated.

    Thank you,

    Pavel

  • #2
    An update. Checking hex dumps I've found out that logs looks similar on both servers besides the following:

    Percona:

    00000062 be f5 6b 50 02 01 00 00 00 82 00 00 00 e4 00 00 00 00 00
    # 00000075 01 00 00 00 00 00 00 00 0c 00 00 17 00 00 00 40 |................|
    # 00000085 00 00 01 00 00 00 00 00 00 00 00 06 03 04 08 00 |................|
    # 00000095 08 00 08 00 61 6d 6d 75 6e 69 74 69 5f 6f 73 63 |....ammuniti.osc|

    Regular mysql:

    00000062 3c 50 6c 50 02 02 00 00 00 85 00 00 00 e7 00 00 00 00 00
    # 00000075 08 00 00 00 00 00 00 00 0c 00 00 1a 00 00 00 40 |................|
    # 00000085 00 00 01 00 00 00 00 00 00 00 00 06 03 73 74 64 |.............std|
    # 00000095 04 08 00 08 00 08 00 61 6d 6d 75 6e 69 74 69 5f |.......ammuniti.|

    I.e. there is no "std" in percona's log.

    Comment


    • #3
      We are facing the same issue! Did you ever find a fix for this? Thanks

      Comment


      • #4
        Seems there is an issue with percona packages deps for 5.0 at least. I don't rememeber all details but close to mysql-client and shared libs. I had no time to investigate it further. Fortunately 5.0.x wasn't not a must in my case and upgrade to 5.1.x sorted it out. Even though I had to try with different versions of the shared libs packages.

        Comment


        • #5
          Hi,


          ERROR: Error in Log_event::read_log_event(): 'Event too big', data_len: 1953066613, event_type: 8


          Can you check and compare the max_allowed_packet value on Master and Slave server? it can cause this issue. You should also try to run mysqlbinlog for the binlog on master and slave.

          Comment


          • #6
            yes, it can but it works with the same max_allowed_packet value with 5.1 though. Please, refer also to the hex above. It is in different format.

            Comment


            • #7
              960218 6:48:44 server id 1813111337 end_log_pos 1835008
              # Unknown event
              ERROR: Error in Log_event::read_log_event(): 'Event too big', data_len: 1953066613, event_type: 8

              The data is corrupted, as the server id is an arbitrary value. We also did a hex dump and saw bits shifted, and if only it could decode correctly we could have read the correct timestamp, server id and the event.

              It has nothing to do with max_allowed_packet on this case, since it is reading corrupted data so event size is huge.

              vpaul , do you know if you installed Percona5.1 and it simply fixed it? Can you tell me any specifics that you had to run on my.cnf? I am thinking yum remove Percona* , and yum install Percona-51 packages? Did you have to run mysql_upgrade?

              Comment


              • #8
                my.cnf had no any specific. From what I remember I had to sort out mysql client packages. Be also aware of 5.1 to 5.0 replication compatibilities. If you are going to keep your data on the upgrading server you should run mysql_upgrade.

                Comment

                Working...
                X