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

mysqlbinlog Don't know how to handle column type=0 meta=0 (0000)#

        Details

        • Type: Bug
        • Status: Closed
        • Priority: Major
        • Resolution: Fixed
        • Affects Version/s: 10.0, 5.5
        • Fix Version/s: 5.5.44
        • Component/s: Replication, Scripts & Clients
        • Labels:
          None
        • Environment:
          cento6
        • Sprint:
          5.5.44

          Description

          mysqlbinlog Ver 3.3 for Linux at x86_64 from MariaDB-client.x86_64 5.5.40-1.el6 @mariadb

          Following on from MDEV-7268

          mysqlbinlog --start-position 30748070  mysql-bin.046557 | more

BEGIN
/*!*/;
# at 30748141
# at 30748202
# at 30748274
#141204 10:12:43 server id 1  end_log_pos 30748202      Table_map: `weather`.`lightning` mapped to number 177647
#141204 10:12:43 server id 1  end_log_pos 30748274      Table_map: `weather`.`_lightning_new` mapped to number 177646
#141204 10:12:43 server id 1  end_log_pos 30748356      Delete_rows: table id 177647 flags: STMT_END_F

BINLOG '
65h/VBMBAAAAPQAAACou1QEAAO+1AgAAAAEAB3dlYXRoZXIACWxpZ2h0bmluZwAHAw8MAAAADwQK
AAoAYA==
65h/VBMBAAAASAAAAHIu1QEAAO61AgAAAAEAB3dlYXRoZXIADl9saWdodG5pbmdfbmV3AAcDDwz2
9vYPCgoACgcKBwUBCgBg
65h/VBkBAAAAUgAAAMQu1QEAAO+1AgAAAAEAB/+AG4GOBAVHUEFUU5OG1tNFEgAAIC0zMy42MzA3
NDc5IDE1Mi44MzIwNjk3ICAtNDEuMgJHUw==
'/*!*/;
# at 30748356
#141204 10:12:43 server id 1  end_log_pos 30748383      Xid = 12786901894
COMMIT/*!*/;

          decoded version

          mysqlbinlog --start-position 30748070  --verbose --base64-output=decode-rows mysql-bin.046557 | more

BEGIN
/*!*/;
# at 30748141
# at 30748202
# at 30748274
#141204 10:12:43 server id 1  end_log_pos 30748202      Table_map: `weather`.`lightning` mapped to number 177647
#141204 10:12:43 server id 1  end_log_pos 30748274      Table_map: `weather`.`_lightning_new` mapped to number 177646
#141204 10:12:43 server id 1  end_log_pos 30748356      Delete_rows: table id 177647 flags: STMT_END_F
### DELETE FROM `weather`.`lightning`
### WHERE
###   @1=76448027
###   @2='GPATS'
###   @3=2009-11-16 09:51:23
###   @4=!! Don't know how to handle column type=0 meta=0 (0000)# at 30748356
#141204 10:12:43 server id 1  end_log_pos 30748383      Xid = 12786901894
COMMIT/*!*/;

          from upstream:

          mysqlbinlog did not properly decode DECIMAL ( http://dev.mysql.com/doc/refman/5.6/en/fixed-point-types.html ) values in a row-based binary log. This could cause invalid values to be printed out for DECIMAL columns. (Bug #17544169)

            Gliffy Diagrams

              Attachments

                Issue Links

                blocks

                Task - A task that needs to be done. MDEV-7628 Row-based replication of old DECIMAL to new DECIMAL

                • Major - Major loss of function.
                • Stalled

                  Activity

                  Ascending order - Click to sort in descending order
                  Hide
                  Permalink
                  elenst Elena Stepanova added a comment -

                  While the parent issue MDEV-7268 is still full of mysteries, this one is quite straightforward.

                  If a server has a table with a column of type DECIMAL (as opposed to NEWDECIMAL), the described effect happens while trying to read its row-based event.

                  Please note it's not an operational error; doesn't matter how many mysql_upgrade's and ALTER's a table has undergone, the DECIMAL type remains intact. A table should be re-created from scratch (not via LIKE, but with the actual CREATE TABLE statement) to get rid of it.

                  Show
                  elenst Elena Stepanova added a comment - While the parent issue MDEV-7268 is still full of mysteries, this one is quite straightforward. If a server has a table with a column of type DECIMAL (as opposed to NEWDECIMAL), the described effect happens while trying to read its row-based event. Please note it's not an operational error; doesn't matter how many mysql_upgrade's and ALTER's a table has undergone, the DECIMAL type remains intact. A table should be re-created from scratch (not via LIKE, but with the actual CREATE TABLE statement) to get rid of it.
                  Hide
                  Permalink
                  serg Sergei Golubchik added a comment -

                  for the record, Bug#17544169 is about new decimal type, not related to this bug report.

                  Show
                  serg Sergei Golubchik added a comment - for the record, Bug#17544169 is about new decimal type, not related to this bug report.

                    People

                    • Assignee:
                      bar Alexander Barkov
                      Reporter:
                      danblack Daniel Black
                    • Votes:
                      0 Vote for this issue
                      Watchers:
                      3 Start watching this issue

                      Dates

                      • Created:
                        Updated:
                        Resolved:

                        Agile