This issue is hard to reproduce, it happens 10 times in last 24 hours

duration_hr is a field with type Decimal (13, 4), I found some abnormal conversion during the ClickHouse replication, as below:
```
MySQL     ClickHouse
0.3333 -> -2147483653.2202
0.5000 -> -2147483653.0535
0.1667 -> -2147483653.3868
0.0833 -> -2147483653.4702
0.7500 -> -2147483652.8035
```
As you can see, a weired one among the normal ones:
```
│ HCAC    │ 2020-10-22 07:10:00 │           0.3333 │
│ HCAC    │ 2020-10-22 07:15:00 │           0.3333 │
│ HCAC    │ 2020-10-22 07:20:00 │           0.3333 │
│ HCAC    │ 2020-10-22 07:25:00 │           0.3333 │
│ HCAC    │ 2020-10-22 07:30:00 │           0.3333 │
│ HCAC    │ 2020-10-22 07:35:00 │ -2147483653.2202 │
│ HCAC    │ 2020-10-22 07:40:00 │           0.3333 │
│ HCAC    │ 2020-10-22 07:45:00 │           0.3333 │
│ HCAC    │ 2020-10-22 07:50:00 │           0.3333 │
│ HCAC    │ 2020-10-22 07:55:00 │           0.3333 │
│ HCAC    │ 2020-10-22 08:00:00 │           0.3333 │
│ HCAC    │ 2020-10-22 08:05:00 │           0.3333 │
```


-Lyon
{
        auto pos = 0;
        column_meta.reserve(column_count);
        for (auto i = 0U; i < column_count; i++)
        {
            UInt16 typ = column_type[i];
            switch (typ)
            {
                case MYSQL_TYPE_DECIMAL:
                case MYSQL_TYPE_TINY:
                case MYSQL_TYPE_SHORT:
                case MYSQL_TYPE_LONG:
                case MYSQL_TYPE_NULL:
                case MYSQL_TYPE_TIMESTAMP:
                case MYSQL_TYPE_LONGLONG:
                case MYSQL_TYPE_INT24:
                case MYSQL_TYPE_DATE:
                case MYSQL_TYPE_DATETIME:
                case MYSQL_TYPE_NEWDATE:
                {
                    
                    column_meta.emplace_back(0);
                    break;
                }
                case MYSQL_TYPE_FLOAT:
                case MYSQL_TYPE_DOUBLE:
                case MYSQL_TYPE_TIMESTAMP2:
                case MYSQL_TYPE_DATETIME2:
                case MYSQL_TYPE_BLOB: