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.