gh-ost: Gh-ost breaks when using unsigned MEDIUMINT

When using unsigned integer data types, binary log behavior changes if the inserted number is higher than the max signed integer value.

The original table

CREATE TABLE `test_table` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `column1` int(11) NOT NULL,
  `column2` int(11) NOT NULL,
  `column3` mediumint(8) unsigned NOT NULL,
  `column4` tinyint(3) unsigned NOT NULL,
  `column5` int(11) NOT NULL,
  `column6` int(11) NOT NULL,
  PRIMARY KEY (`id`),
  KEY `user_id_level_id` (`column1`,`column2`)
) ENGINE=InnoDB AUTO_INCREMENT=4647930180 DEFAULT CHARSET=utf8

The new schema;

CREATE TABLE `test_table` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `column1` int(11) NOT NULL,
  `column2` smallint(5) unsigned NOT NULL,
  `column3` mediumint(8) unsigned NOT NULL,
  `column4` tinyint(3) unsigned NOT NULL,
  `column6` int(11) NOT NULL,
  PRIMARY KEY (`column1`,`column2`),
  UNIQUE KEY `id` (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=4632662231 DEFAULT CHARSET=utf8

We were experiencing the same issue explained on the issue #348 . Alter was never starting, even for hours. The table has more than 4 billion records and receiving 200 million records per week. So we tested the version that has included in this comment: https://github.com/github/gh-ost/issues/348#issuecomment-270592112 and it was quite fast. It was estimating 35 hours to complete which is perfectly acceptable for us.

We then executed the following statement

./gh-ost --max-load=Threads_running=800 --critical-load=Threads_running=1200 --chunk-size=50000 --dml-batch-size=100 --user="root" --password="" --host=localhost --database="test" --table="test_table" --verbose --alter="ADD UNIQUE INDEX (id), DROP COLUMN column5, DROP INDEX column1_column2, DROP PRIMARY KEY,ADD PRIMARY KEY(column1,column2),MODIFY column2 SMALLINT UNSIGNED NOT NULL, MODIFY column3 INT NOT NULL" --cut-over=default --exact-rowcount --concurrent-rowcount --default-retries=120 --panic-flag-file=ghost.panic.flag --postpone-cut-over-flag-file=ghost.postpone.flag

These are from binary logs;

### INSERT INTO `test`.`test_table`
### SET
###   @1=4632662255 /* LONGINT meta=0 nullable=0 is_null=0 */
###   @2=13382498 /* INT meta=0 nullable=0 is_null=0 */
###   @3=536 /* SHORTINT meta=0 nullable=0 is_null=0 */
###   @4=8388607 /* MEDIUMINT meta=0 nullable=0 is_null=0 */
###   @5=3 /* TINYINT meta=0 nullable=0 is_null=0 */
###   @6=1483892218 /* INT meta=0 nullable=0 is_null=0 */

### INSERT INTO `test`.`test_table`
### SET
###   @1=4632662255 /* LONGINT meta=0 nullable=0 is_null=0 */
###   @2=13382498 /* INT meta=0 nullable=0 is_null=0 */
###   @3=536 /* SHORTINT meta=0 nullable=0 is_null=0 */
###   @4=-6777216 (10000000) /* MEDIUMINT meta=0 nullable=0 is_null=0 */
###   @5=3 /* TINYINT meta=0 nullable=0 is_null=0 */
###   @6=1483892218 /* INT meta=0 nullable=0 is_null=0 */

Since the format is different, I guess we hit some kind of bug. This issue looks like similar to this: https://github.com/github/gh-ost/issues/157 However my version is 1.0.32. MySQL version: Server version: 5.7.10-3-log Percona Server (GPL), Release 3, Revision 63dafaf

The error is;

2017-01-08 17:16:03 ERROR Error 1264: Out of range value for column 'column3' at row 1; query=
                        replace /* gh-ost `test`.`test_table` */ into
                                `test`.`test_table`
                                        (`id`, `column1`, `column2`, `column3`, `column4`, `column6`)
                                values
                                        (?, ?, ?, ?, ?, ?)
                ; args=[4632662255, 13382498, 536, 10000000, 3, 1483892218]