Hi Sébastien,
Hi Ralph.
I had a bunch of records specifying non ascii “tags” (this is a
"french" instance) in contact_geo.
GEO is meant for geographic coordinates of the address, these are numbers.
I first wanted to switch from mysql to mariadb on the target instance.
I took my 1.8 sqldump which have been generated by a
"/usr/bin/mysqldump --login-path=local -c -e
–default-character-set=utf8 --single-transaction --skip-set-charset
–add-drop-database --databases egw"
And imported it back to target mariadb instance.
After doing the database upgrade to get the 14.3 / 16.1 up :
First shot, mariadb 10.x :
This has led to some very strange behavior on basic sql statements
(almost all selects / updates on egw_contacts failing).
We use MariaDB 10.0 for all our hosting and most our customers.
You did not wrote how you installed MariaDB, we usually use either
packages from a Linux distribution or from downloads.mariadb.org.
Second shot, mariadb 11.x :
This leads to mariadb instance simply crashing upon basic select
statement (i really mean crash, “mysql server has gone away” from
client side and process killed on server side !!).
There is no such thing as MariaDB 11.x currently, there is 10.0, 10.1
and a 10.2 alpha version.
So i decided to switch back to mysql 5.6 :
All records imported (~29000)
Non ascii chars converted to “?”.
No more server crashes, no more sql statements crashes, import/export
egw features doing their job.
Strange, isnt’it ?
You definitely have a problem in your environment!
Ralf
–
S.PERES-LABOURDETTE
De : Ralf Becker mailto:rb@stylite.de
Envoyé : lun. 13 juin 2016 20:04:59 CEST (CEST +0200)
À : Egroupware Ml mailto:egroupware-users@lists.sourceforge.net
Objet : Re: [eGroupWare-users] Sql migration issue
Hi Sébastien,
Hi there.
I just noticed some of the table definitions seemed to have changed
from 1.8 to 14.x / 16.x.
_
_For example :
contact_geo was utf8_general_ci in my existing 1.8 instance.
the upgrade process makes it ascii_general_ci in 16.1
That change was intentional, to improve performance under MySQL.
utf8 columns need 3 times the storage then ascii columns, which is
specially significant for indexes or tables with many rows were full
tablescans are forced to disc.
Which has lead lots of db entries just unusable or even simply not
migrated in the target platform.
Can you elaborate on that a bit?
We only changed columns to ascii_general_ci, which are supposed to store
only ascii values.
Are you using these columns for other values?
Ralf
This is a major issue for me.
Does anybody here met that kind of issue ?
–
S.PERES-LABOURDETTE
–
Ralf Becker
Director Software Development
Stylite AG
Isaac-Fulda-Allee 9 | Tel. +49 6131 32702-0
D-55124 Mainz | Fax. +49 6131 32702-70
Email: rb@stylite.de
www.stylite.de | www.egroupware.org
Managing Directors: Andre Keller | Ralf Becker | Gudrun Mueller
Chairman of the supervisory board: Prof. Dr. Birger Leon Kropshofer
VAT DE214280951 | Registered HRB 46224 Mainz Germany
