OpenVPMS Backup Issue
Submitted by Ben_Charlton on Tue, 20/12/2016 - 16:09
Encoding problems drive me nuts - so this was fun
I was doing a upgrade today
I ran
mysqldump -uopenvpms -popenvpms openvpms > openvpms.sql
to create a backup - no problems
however I then decided to test the import..
>create schema test DEFAULT CHARACTER SET utf8; >Source openvpms.sql;
Numerous warning were generated:
Records: 9 Duplicates: 0 Warnings: 9
Warning (Code 1300): Invalid utf8 character string: '9CD4BB' Warning (Code 1300): Invalid utf8 character string: '9CCCBC' Warning (Code 1300): Invalid utf8 character string: '9CECBC' Warning (Code 1300): Invalid utf8 character string: '9CB49B' Warning (Code 1300): Invalid utf8 character string: '9CECBB' Warning (Code 1300): Invalid utf8 character string: '9CB4BB' Warning (Code 1300): Invalid utf8 character string: '9CBCBB' Warning (Code 1300): Invalid utf8 character string: '9CBCBB' Warning (Code 1300): Invalid utf8 character string: '9CECBC'
I have tried numerous approaches to get around this issue nothing seems to be working...the server default encoding is actually latin1.
Any ideas?
Re: OpenVPMS Backup Issue
Are the tables UTF8?
E.g.
> show create table acts;
If the tables are correct, what does:
give you?
If not:
try:
Re: OpenVPMS Backup Issue
This is running mysql 5.5.x on Ubuntu
So that looks fine I have tried running mysql with the --defaults set and the same error occurs
I have checked an older backup that was produced with a different mysqlbackup version
I really need a display as to which of the inserts are causing the error...
Re: OpenVPMS Backup Issue
So using --verbose crashes my ssh client
The characters corrupt the terminal ..
Re: OpenVPMS Backup Issue
These are the vars if I run SHOW VARIABLES;
Re: OpenVPMS Backup Issue
These are the vars if I run SHOW VARIABLES;
Re: OpenVPMS Backup Issue
Probably unrelated but should:
have been:
Re: OpenVPMS Backup Issue
I have confirmed it was indeed the method of backup that corrupted the data..
I reviewed a backup from 2 weeks ago and it has non of the problems importing...
It was also backed up by mysqlbackup but on windows based machine..
Ben
Re: OpenVPMS Backup Issue
Question: is the document BLOB data base64 encoded before its stored?
Re: OpenVPMS Backup Issue
No, and it shouldn't need to be. Base64 encoding adds a lot of overhead.
This might be relevant: http://stackoverflow.com/a/14745685
Are you restoring to the same version?
Re: OpenVPMS Backup Issue
In an attempt to determine what is actually happening and if the backup was truly corrupt....
If I run
The output will screw up my console
If I ran
It outputs normally to console indicating to me the encoding is ok
NOW if I Restore the 2week old backup
now I also then ran
mysqldbcompare which fails on the documents table with the error
Basically saying it cant decode the table with a UTF8 codec.
HOWEVER I then ran
The result was that all 4731 rows in test(uncorruptrestore) matched the suspectrestore.
I also ran compares using length() and char_length()
If I skip the data checks the msyqldbcompare runs without error.
Tim my bottom line question is there anyway that the BLOB fields could contain NON UTF8 chars in a normal openvpms database?
Or could that only happen as a result of extract/dump problems.
Re: OpenVPMS Backup Issue
In an attempt to determine what is actually happening and if the backup was truly corrupt....
If I run
The output will screw up my console
If I ran
It outputs normally to console indicating to me the encoding is ok
NOW if I Restore the 2week old backup
now I also then ran
mysqldbcompare which fails on the documents table with the error
Basically saying it cant decode the table with a UTF8 codec.
HOWEVER I then ran
The result was that all 4731 rows in test(uncorruptrestore) matched the suspectrestore.
I also ran compares using length() and char_length()
If I skip the data checks the msyqldbcompare runs without error.
Tim my bottom line question is there anyway that the BLOB fields could contain NON UTF8 chars in a normal openvpms database?
Or could that only happen as a result of extract/dump problems.
Re: OpenVPMS Backup Issue
Blob fields are binary so can contain any data. It sounds like your issue is with the dump not correctly encoding that binary data as UTF8, so that when you go to restore, it generates warnings.
This may be relevant: http://nathan.rambeck.org/blog/1-preventing-encoding-issues-mysqldump
Re: OpenVPMS Backup Issue
Can I make a point however IF the BLOB fields cannot be cast to UTF8 data there is NO possible way a text file encoded with UTF8 can handle that data.
This
Re: OpenVPMS Backup Issue
Can I make a point however IF the BLOB fields cannot be cast to UTF8 data there is NO possible way a text file encoded with UTF8 can handle that data.
This
Re: OpenVPMS Backup Issue
I suspect that just means your terminal can't display UTF-8.
If you look at a backup in vi or emacs, you'll see similar escaping going on.
In general, mysqldump for backup and mysql for restore work for blob data without any issues. I use it all the time.
Re: OpenVPMS Backup Issue
So I worked it out the best way to deal with this is use --hex-blob option during a mysql dump
This will encode a blob in hexadecimal during the bumb to ensure all the chars are readable during reimportation via whatever charset the client is using.
It does not affect data integrity and prevents the warnings...that being said the warnings can be ignored as long as they apply to binary data
Re: OpenVPMS Backup Issue
So just in summary
a good backup option is
then to reimport at a mysql prompt
then I ran seperately from mysqlutilities
to receive a report like this (please note I skipped data checking as this utility cannot handle BINARY data)
Re: OpenVPMS Backup Issue
http://bugs.mysql.com/bug.php?id=80150
This is the underlying error...