Bug #72495 mysqlbinlog doesn't properly read GIS columns
Submitted: 30 Apr 2014 19:55 Modified: 3 May 2014 9:29
Reporter: Greg Lane Email Updates:
Status: Verified Impact on me:
None 
Category:MySQL Utilities: Binlog Events Severity:S3 (Non-critical)
Version:5.6.16 OS:Linux
Assigned to: CPU Architecture:Any
Tags: bin-log, gis, mysqlbinlog

[30 Apr 2014 19:55] Greg Lane
Description:
While creating a replica I noticed that a table from my master wasn't properly dumped into the replica, and this table had a GIS(point) column.  After some work I discovered the bug #43544, which describes how GIS columns are not dumped correctly while using --hex-blob and a --blob-geom was created as a patch.  
So while in this process I was reading the bin-log on master and the relay-bin on the while I was trying to discover why replication broke and discovered this issue while using:  mysqlbinlog --base64-output=decode-rows -v -v mysql-bin.xxxx --stop-position=xxxxxx

#140428 14:03:31 server id 1  end_log_pos 451540839 CRC32 0xc728da64    Update_rows: table id 203 flags: STMT_END_F
### UPDATE `db`.`table`
### WHERE
###   @1=2
###   @2=1404
###   @3='1996-07-17 12:00:00'
###   @4=!! Don't know how to handle column type=255 meta=4 (0004)# at 4192061
#140428 14:03:31 server id 1  end_log_pos 451540870 CRC32 0xae920342    Xid = 124050909

As you can see the @4 is decoded as not knowing how to hand the column data.
This can be misleading if you are troubleshooting a replication problem.  I originally did not know the table was not dumped correctly due to bug #43544.
So before I discovered that bug I was under the impression that the binlog was being created correctly and the problem was with an interpretation via mysqlbinlog. 

How to repeat:
create database test
use test
create table (location POINT)

insert into point values(GeomFromText('POINT(1 1)')),(GeomFromText('POINT(2 2)')),(GeomFromText('POINT(3 3)'));

exit 

go to binlog directory

mysqlbinlog --base64-output=decode-rows -v -v mysql-bin.xxxxxx

or 

mysqlbinlog -v -v mysql-bin.xxxxx

you will get the same result for the @1 variable

### INSERT INTO `test`.`point`
### SET
###   @1=!! Don't know how to handle column type=255 meta=4 (0004)# at 489

Suggested fix:
After conferring with Oracle support it was discovered that in sql/log_event.cc thet log_event_print_value function there is a switch for all the types except for GIS types.  

GIS types should be included.
[1 May 2014 12:45] Greg Lane
updated to version I am running
[3 May 2014 9:29] Shane Bester
Verified on latest 5.7.5 too.

### INSERT INTO `test`.`point`
### SET
###   @1=!! Don't know how to handle column type=255 meta=4 (0004)# at 493