OpenVPMS Backup Issue

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?

 

 

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Re: OpenVPMS Backup Issue

Are the tables UTF8?

E.g.

> show create table acts;

CREATE TABLE `acts` (
  `act_id` bigint(20) NOT NULL AUTO_INCREMENT,
  `version` bigint(20) NOT NULL,
  `arch_short_name` varchar(100) NOT NULL,
  `arch_version` varchar(100) NOT NULL,
  `linkId` varchar(36) NOT NULL,
  `name` varchar(255) DEFAULT NULL,
  `description` varchar(255) DEFAULT NULL,
  `active` bit(1) DEFAULT NULL,
  `title` varchar(255) DEFAULT NULL,
  `activity_start_time` datetime DEFAULT NULL,
  `activity_end_time` datetime DEFAULT NULL,
  `reason` varchar(255) DEFAULT NULL,
  `status` varchar(255) DEFAULT NULL,
  `status2` varchar(50) DEFAULT NULL,
  PRIMARY KEY (`act_id`),
  KEY `act_short_name_status_idx` (`arch_short_name`,`status`),
  KEY `act_start_time_idx` (`activity_start_time`),
  KEY `act_short_name_status2_idx` (`arch_short_name`,`status2`),
  KEY `act_end_time_idx` (`activity_end_time`)
) ENGINE=InnoDB AUTO_INCREMENT=770 DEFAULT CHARSET=utf8

If the tables are correct, what does:

> mysql --help |grep default-character-set

give you?

If not:

default-character-set             utf8

try:

> mysql -u openvpms -p openvpms --default-character-set=utf8 ....

 

Re: OpenVPMS Backup Issue

default-character-set             auto

This is running mysql 5.5.x on Ubuntu

CREATE TABLE `acts` (
  `act_id` bigint(20) NOT NULL AUTO_INCREMENT,
  `version` bigint(20) NOT NULL,
  `arch_short_name` varchar(100) NOT NULL,
  `arch_version` varchar(100) NOT NULL,
  `linkId` varchar(36) NOT NULL,
  `name` varchar(255) DEFAULT NULL,
  `description` varchar(255) DEFAULT NULL,
  `active` bit(1) DEFAULT NULL,
  `title` varchar(255) DEFAULT NULL,
  `activity_start_time` datetime DEFAULT NULL,
  `activity_end_time` datetime DEFAULT NULL,
  `reason` varchar(255) DEFAULT NULL,
  `status` varchar(255) DEFAULT NULL,
  PRIMARY KEY (`act_id`),
  KEY `act_end_time_idx` (`activity_end_time`),
  KEY `act_short_name_status_idx` (`arch_short_name`,`status`),
  KEY `act_start_time_idx` (`activity_start_time`)
) ENGINE=InnoDB AUTO_INCREMENT=159291 DEFAULT CHARSET=utf8 

 

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...

 

Regards
 
Ben 
OpenVPMS Installer and Helper 
Ph: +61423044823 
Email: info[at]charltonit.com[dot]au

Re: OpenVPMS Backup Issue

So using --verbose crashes my ssh client

The characters corrupt the terminal ..

 

Regards
 
Ben 
OpenVPMS Installer and Helper 
Ph: +61423044823 
Email: info[at]charltonit.com[dot]au

Re: OpenVPMS Backup Issue

| character_set_client                              | utf8
| character_set_connection                          | utf8  
| character_set_database                            | latin1
| character_set_filesystem                          | binary
| character_set_results                             | utf8  
| character_set_server                              | latin1
| character_set_system                              | utf8  
| character_sets_dir                                | /usr/share/mysql/charsets/
| collation_connection                              | utf8_general_ci
| collation_database                                | latin1_swedish_ci     
| collation_server                                  | latin1_swedish_ci

These are the vars if I run SHOW VARIABLES;

 

Regards
 
Ben 
OpenVPMS Installer and Helper 
Ph: +61423044823 
Email: info[at]charltonit.com[dot]au

Re: OpenVPMS Backup Issue

| character_set_client                              | utf8
| character_set_connection                          | utf8  
| character_set_database                            | latin1
| character_set_filesystem                          | binary
| character_set_results                             | utf8  
| character_set_server                              | latin1
| character_set_system                              | utf8  
| character_sets_dir                                | /usr/share/mysql/charsets/
| collation_connection                              | utf8_general_ci
| collation_database                                | latin1_swedish_ci     
| collation_server                                  | latin1_swedish_ci

These are the vars if I run SHOW VARIABLES;

 

Regards
 
Ben 
OpenVPMS Installer and Helper 
Ph: +61423044823 
Email: info[at]charltonit.com[dot]au

Re: OpenVPMS Backup Issue

Probably unrelated but should:

>create schema test DEFAULT CHARACTER SET utf8;

>source openvpms.sql;

have been:

>create schema test DEFAULT CHARACTER SET utf8;
>use test;
>source openvpms.sql;

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

Regards
 
Ben 
OpenVPMS Installer and Helper 
Ph: +61423044823 
Email: info[at]charltonit.com[dot]au

Re: OpenVPMS Backup Issue

Question: is the document BLOB data base64 encoded before its stored? 

Regards
 
Ben 
OpenVPMS Installer and Helper 
Ph: +61423044823 
Email: info[at]charltonit.com[dot]au

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

cat corruptback.sql  

The output will screw up my console

If I ran 

cat dbbackfrom2weeksago.sql

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

Traceback (most recent call last):
  File "G:\ade\build\sb_0-19921351-1470074463.97\Python-2.7.6-windows-x86-64bit\lib\site-packages\cx_Freeze\initscripts\Console.py", line 27, in <module>
  File "scripts\mysqldbcompare.py", line 413, in <module>
  File ".\mysql\utilities\command\dbcompare.py", line 479, in database_compare
  File ".\mysql\utilities\command\dbcompare.py", line 315, in _check_data_consistency
  File ".\mysql\utilities\common\dbcompare.py", line 1526, in check_consistency
  File ".\mysql\utilities\common\dbcompare.py", line 1290, in _generate_data_diff_output
  File ".\mysql\utilities\common\dbcompare.py", line 1211, in _get_formatted_rows
  File ".\mysql\utilities\common\format.py", line 302, in print_list
  File ".\mysql\utilities\common\format.py", line 197, in format_tabular_list
  File "G:\ade\build\sb_0-16184688-1439901496.7\Python-2.7.6-windows-x86-64bit\lib\encodings\utf_8.py", line 16, in decode
UnicodeDecodeError: 'utf8' codec can't decode byte 0x9c in position 1: invalid start byte

Basically saying it cant decode the table with a UTF8 codec.

HOWEVER I then ran 

SELECT odoc.document_id,
FROM openvpms.documents as odoc 
JOIN test.documents as tdoc 
ON odoc.document_id = tdoc.document_id 
WHERE md5(odoc.contents)=md5(tdoc.contents);

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.

 

Regards
 
Ben 
OpenVPMS Installer and Helper 
Ph: +61423044823 
Email: info[at]charltonit.com[dot]au

Re: OpenVPMS Backup Issue

In an attempt to determine what is actually happening and if the backup was truly corrupt....

If I run

cat corruptback.sql  

The output will screw up my console

If I ran 

cat dbbackfrom2weeksago.sql

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

Traceback (most recent call last):
  File "G:\ade\build\sb_0-19921351-1470074463.97\Python-2.7.6-windows-x86-64bit\lib\site-packages\cx_Freeze\initscripts\Console.py", line 27, in <module>
  File "scripts\mysqldbcompare.py", line 413, in <module>
  File ".\mysql\utilities\command\dbcompare.py", line 479, in database_compare
  File ".\mysql\utilities\command\dbcompare.py", line 315, in _check_data_consistency
  File ".\mysql\utilities\common\dbcompare.py", line 1526, in check_consistency
  File ".\mysql\utilities\common\dbcompare.py", line 1290, in _generate_data_diff_output
  File ".\mysql\utilities\common\dbcompare.py", line 1211, in _get_formatted_rows
  File ".\mysql\utilities\common\format.py", line 302, in print_list
  File ".\mysql\utilities\common\format.py", line 197, in format_tabular_list
  File "G:\ade\build\sb_0-16184688-1439901496.7\Python-2.7.6-windows-x86-64bit\lib\encodings\utf_8.py", line 16, in decode
UnicodeDecodeError: 'utf8' codec can't decode byte 0x9c in position 1: invalid start byte

Basically saying it cant decode the table with a UTF8 codec.

HOWEVER I then ran 

SELECT odoc.document_id,
FROM openvpms.documents as odoc 
JOIN test.documents as tdoc 
ON odoc.document_id = tdoc.document_id 
WHERE md5(odoc.contents)=md5(tdoc.contents);

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.

 

Regards
 
Ben 
OpenVPMS Installer and Helper 
Ph: +61423044823 
Email: info[at]charltonit.com[dot]au

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

Yep that sounds about right....
 
This is an extract out of both databases when I use 
SELECT CAST(BLOB as CHAR CHARACTER SET utf8) 
basically you can clearly see that the data contains non UTF8 chars
 
 
v'x���s�8�?����c(��N�{N�>f��i� �a[I �展�9���V���y
�~hmI+���v��j��s�r����nK-iEU��I-��Է��������    ���G}�����!c�A� �|�h�&�S�5�t�*E�;��ڸ��@A/K��s��o�C��A*��xAMĄ�����K�.�R%4HP9��z�6v�5vlׂ1S
�{�bÖZmV��+l���6*�����7*R�"�Y�:Q���y��F��U��e�:S)�Ov ϧ!���١����#�
�k�CU�Ed%�ja�\4�qq9�B�vĤ�0DZ���c�]�
k���n�6b6����> 1Iy���C�y^GL�1A� S�A��[�    ��c�^�u�M�6�    %�

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 

Regards
 
Ben 
OpenVPMS Installer and Helper 
Ph: +61423044823 
Email: info[at]charltonit.com[dot]au

Re: OpenVPMS Backup Issue

Yep that sounds about right....
 
This is an extract out of both databases when I use 
SELECT CAST(BLOB as CHAR CHARACTER SET utf8) 
basically you can clearly see that the data contains non UTF8 chars
 
 
v'x���s�8�?����c(��N�{N�>f��i� �a[I �展�9���V���y
�~hmI+���v��j��s�r����nK-iEU��I-��Է��������    ���G}�����!c�A� �|�h�&�S�5�t�*E�;��ڸ��@A/K��s��o�C��A*��xAMĄ�����K�.�R%4HP9��z�6v�5vlׂ1S
�{�bÖZmV��+l���6*�����7*R�"�Y�:Q���y��F��U��e�:S)�Ov ϧ!���١����#�
�k�CU�Ed%�ja�\4�qq9�B�vĤ�0DZ���c�]�
k���n�6b6����> 1Iy���C�y^GL�1A� S�A��[�    ��c�^�u�M�6�    %�

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 

Regards
 
Ben 
OpenVPMS Installer and Helper 
Ph: +61423044823 
Email: info[at]charltonit.com[dot]au

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

 

Regards
 
Ben 
OpenVPMS Installer and Helper 
Ph: +61423044823 
Email: info[at]charltonit.com[dot]au

Re: OpenVPMS Backup Issue

So just in summary

a good backup option is

mysqldump -uopenvpms -popenvpms --opt --hex-blob --result-file=openvpms.backup.sql openvpms

then to reimport at a mysql prompt

CREATE Database newSchema DEFAULT CHARACTER SET UTF8;

use newSchema;

source opnevpms.backup.sql;

then I ran seperately from mysqlutilities

mysqldbcompare --server1=root:password@10.1.3.100:3306 --server2=root:password@10.1.3.100:3306 openvpms:newschema --changes-for=server1 --run-all-tests --skip-data-check > output.log

to receive a report like this (please note I skipped data checking as this utility cannot handle BINARY data)

Checking databases openvpms on server1 and test on server2
#
#                                                   Defn    Row     Data   
# Type      Object Name                             Diff    Count   Check  
# ------------------------------------------------------------------------- 
# TABLE     act_details                             pass    pass    SKIP    
# TABLE     act_relationship_details                pass    pass    SKIP    
# TABLE     act_relationships                       pass    pass    SKIP    
# TABLE     action_type_descriptors                 pass    pass    SKIP    
# TABLE     acts                                    pass    pass    SKIP    
# TABLE     archetype_descriptors                   pass    pass    SKIP    
# TABLE     assertion_descriptors                   pass    pass    SKIP    
# TABLE     assertion_type_descriptors              pass    pass    SKIP    
# TABLE     audit_records                           pass    pass    SKIP    
# TABLE     contact_classifications                 pass    pass    SKIP    
# TABLE     contact_details                         pass    pass    SKIP    
# TABLE     contacts                                pass    pass    SKIP    
# TABLE     document_acts                           pass    pass    SKIP    
# TABLE     document_details                        pass    pass    SKIP    
# TABLE     documents                               pass    pass    SKIP    
# TABLE     entities                                pass    pass    SKIP    
# TABLE     entity_classifications                  pass    pass    SKIP    
# TABLE     entity_details                          pass    pass    SKIP    
# TABLE     entity_identities                       pass    pass    SKIP    
# TABLE     entity_identity_details                 pass    pass    SKIP    
# TABLE     entity_link_details                     pass    pass    SKIP    
# TABLE     entity_links                            pass    pass    SKIP    
# TABLE     entity_relationship_details             pass    pass    SKIP    
# TABLE     entity_relationships                    pass    pass    SKIP    
# TABLE     etl_log                                 pass    pass    SKIP    
# TABLE     financial_acts                          pass    pass    SKIP    
# TABLE     granted_authorities                     pass    pass    SKIP    
# TABLE     lookup_details                          pass    pass    SKIP    
# TABLE     lookup_relationship_details             pass    pass    SKIP    
# TABLE     lookup_relationships                    pass    pass    SKIP    
# TABLE     lookups                                 pass    pass    SKIP    
# TABLE     node_descriptors                        pass    pass    SKIP    
# TABLE     participation_details                   pass    pass    SKIP    
# TABLE     participations                          pass    pass    SKIP    
# TABLE     parties                                 pass    pass    SKIP    
# TABLE     product_price_classifications           pass    pass    SKIP    
# TABLE     product_price_details                   pass    pass    SKIP    
# TABLE     product_prices                          pass    pass    SKIP    
# TABLE     products                                pass    pass    SKIP    
# TABLE     roles_authorities                       pass    pass    SKIP    
# TABLE     security_roles                          pass    pass    SKIP    
# TABLE     user_roles                              pass    pass    SKIP    
# TABLE     users                                   pass    pass    SKIP   

# Databases are consistent given skip options specified.
#
# ...done
Regards
 
Ben 
OpenVPMS Installer and Helper 
Ph: +61423044823 
Email: info[at]charltonit.com[dot]au

Re: OpenVPMS Backup Issue

http://bugs.mysql.com/bug.php?id=80150

This is the underlying error...

Regards
 
Ben 
OpenVPMS Installer and Helper 
Ph: +61423044823 
Email: info[at]charltonit.com[dot]au
Syndicate content