Yb voyager issues

General
1

Hi All,

We are in the process of migrating mysql to Yugabyte but we have come up with below 3 limitations:

  • Voyager does not natively support automated migration of MySQL binary data types such as BLOB, TINYBLOB, MEDIUMBLOB, and LONGBLOB.

  • Data type mismatches were observed in UNION queries.

  • AUTO_INCREMENT sequence migration for primary keys is not currently supported

Is there is any workaround as it is blocking our migration. Thanks

2

Hello @bunty.b

Can you tell me your workflow please?

See Data type mapping from MySQL to YugabyteDB | YugabyteDB Docs (data is ignored)

Question: what is the maximum column value for these across all rows?

I think you’re hitting this: MySQL source database | YugabyteDB Docs ? Can you add more details?

This should be supported I believe? Can you add more details? See Steps to perform offline migration of your database using YugabyteDB Voyager | YugabyteDB Docs

In MySQL, auto-increment column is migrated to YugabyteDB as a normal column with a sequence attached to it.

3

For the UNION ALL issues…

This will fail in Postgres and YugabyteDB:

yugabyte=# **SELECT 1 UNION SELECT 'A';**
ERROR:  invalid input syntax for integer: "A"
LINE 1: SELECT 1 UNION SELECT 'A';
^

But unlike YugabyteDB (which inherits PostgreSQL’s strict type system), MySQL is much more permissive with implicit type conversion (type coercion).

When you combine an integer and a string using UNION in MySQL, it automatically resolves the conflict by converting the integer 1 into a string so both values can live happily in the same result column.

If you run that exact query in MySQL, here is what happens:

mysql> SELECT 1 UNION SELECT 'A';
+---+
| 1 |
+---+
| 1 |
| A |
+---+
2 rows in set (0.00 sec)

The Difference in a Nutshell

  • MySQL: Prioritizes flexibility. It looks at 1 and 'A', decides that a string data type (like VARCHAR) can hold both, converts the 1 to '1', and returns the result.

  • YugabyteDB / PostgreSQL: Prioritizes type safety. It uses the data type of the first SELECT statement (integer) to determine the column type. When it hits 'A' in the second statement, it tries to cast 'A' to an integer, fails, and throws the error you saw.

If you want to make this query work in YugabyteDB, you just have to be explicit about the type conversion:

SELECT CAST(1 AS TEXT) UNION SELECT 'A';
-- Or using the PostgreSQL shorthand:
SELECT 1::text UNION SELECT 'A';
4

The ENABLE_BLOB_EXPORT directive in the ora2pg conf file can be enabled (i.e., set to 1) to have Voyager export BLOB data from MySQL.
The ora2pg conf file should be located here: /etc/yb-voyager/base-ora2pg.conf
However, note that there is a there is an RPC message size restriction in YugabyteDB of about ~200 MB. If a row size (including the BLOB columns) exceeds 200 MB, you won’t be able to use the export BLOB feature.