What does the error "VALUE_PRINT_NOT_SUPPORTED" mean and how do I fix it?
I'm using DMS to move a MySQL 5.7 database from one AWS account to another. I'm not changing versions or schemas or anything, just migrating it to a new RDS instance. Everything was going pretty well until I ran into the "VALUE_PRINT_NOT_SUPPORTED" error. This error only seems to happen on MySQL "TEXT" fields, and only on some of them.
Looking at my table statistics I can see that there are 10 tables that have a Validation State of "Mismatched records". When I query the "awsdms_validation_failures_v1" table in the TARGET database I can see these errors are listed as "VALUE_PRINT_NOT_SUPPORTED".
{'contact_notes': '<VALUE_PRINT_NOT_SUPPORTED>'}, {'contact_notes': '<VALUE_PRINT_NOT_SUPPORTED>'}
What is this error trying to tell me? Are there characters in those records that can't be migrated? Is the content on the fields too large? Is there some other error?
- Newest
- Most votes
- Most comments
if we are moving db instance across VPC. i would suggest create a read replica from main instance using a precreated dbsubnet group of the required vpc subnets.
once ready to cutover just promote the read replica.
That's a good idea and I didn't realize that RDS supported read replicas for MySQL. Unfortunately, I am moving my DB to a VPN in a different account and according to the docs, read replicas are only supported in the same account.
However, I will probably use MySQL RR for some upcoming data warehousing situations. So, thanx for the tip!
In case of cross account you can use rds snapshot to restore to that account. lastly if downtime windows is smaller you can setup native mysql replication between them post snapshot restore.
also you can refer to this article to create read replica in another account https://aws.amazon.com/premiumsupport/knowledge-center/rds-mysql-cross-region-replica/
I'm also getting this error on a field in one of my tables. I've tried reloading and re-verifying the data but it still doesn't work. I also can't find the row that is having problems because the "key" doesn't seem to match up with any of the indexes on that table.
+--------------------------+----------+--------------------------+--------------+-----------------------------------------------------------------------------------------------------------+
| KEY_TYPE | KEY | FAILURE_TYPE | DETAILS |
+--------------------------+----------+--------------------------+--------------+-----------------------------------------------------------------------------------------------------------+
| Row | {"key": ["11111111"] } | RECORD_DIFF |
[[{'object_changes': '<VALUE_PRINT_NOT_SUPPORTED>'}, {'object_changes': '<VALUE_PRINT_NOT_SUPPORTED>'}],] |
| Row | {"key": ["22222222"] } | RECORD_DIFF |
[[{'object_changes': '<VALUE_PRINT_NOT_SUPPORTED>'}, {'object_changes': '<VALUE_PRINT_NOT_SUPPORTED>'}],] |
Scenario where source DB is Oracle and destination DB is PostgreSQL. Below scenario could be one of the cases.
This happens if column in Oracle table is of CLOB type and while inserting into this column, EMPTY_CLOB() function is used. It will be easy to understand if the value is space/null/blank depending on which IDE your are using. When using AWS DMS, these values are migrated as blanks/NULLs. In Oracle, you may see either nothing or if you use DUMP function in Oracle then you will see NULL as its value.
Use function dbms_lob.compare(<CLOBColumnName>,empty_clob()) to determine the value for that column in a row. If empty_clob() is used, then you will get 0 as an output for this function.
Hello, Within an AWS Region, we strongly recommend that you create all read replicas in the same virtual private cloud (VPC) based on Amazon VPC as the source DB instance. If you create a read replica in a different VPC from the source DB instance, classless inter-domain routing (CIDR) ranges can overlap between the replica and the RDS system. CIDR overlap makes the replica unstable, which can negatively impact applications connecting to it. If you receive an error when creating the read replica, choose a different destination DB subnet group.
That is correct, you cannot create a RR in a different AWS account from the source DB instance.
Relevant content
- asked a year ago
AWS OFFICIALUpdated a year ago- AWS OFFICIALUpdated a year ago
- AWS OFFICIALUpdated a year ago
Scenario where source DB is Oracle and destination DB is PostgreSQL. Below scenario could be one of the cases.
This happens if column in Oracle table is of CLOB type and while inserting into this column, EMPTY_CLOB() function is used. It will be easy to understand if the value is space/null/blank depending on which IDE your are using. When using AWS DMS, these values are migrated as blanks/NULLs. In Oracle, you may see either nothing or if you use DUMP function in Oracle then you will see NULL as its value.
Use function dbms_lob.compare(<CLOBColumnName>,empty_clob()) to determine the value for that column in a row. If empty_clob() is used, then you will get 0 as an output for this function.