Inconsistencies migrating a database from MySQL Community Edition 5.7.22 (32 Bit) to MySQL Community Edition 5.7.32 (64 Bit)
Posted by: Christian Schnell
Date: October 22, 2020 04:46AM

Hi,

for almost three weeks now I have been trying to migrate a MediaWiki (+SemanticMediaWiki) Database from an old Debian 7 (Wheezy) Sytstem to a current Debian 10 (Buster) System and I get inconsistencies within the restored database.

Originally, the Wheezy System had MySQL 5.5.60 (32 Bit) installed (part of the Debian Wheezy standard distribution), and I did two in-place upgrades, first from MySQL 5.5.60 to Community Server 5.6.40, and then to Community Server 5.7.22. I used the DEB-Bundle "mysql-apt-config_0.7.3-1_all.deb" on that old 32 Bit System as it seems to be the last one for Wheezy. These upgrades worked perfectly fine and the database system continued to deliver consistent database query results.

Maybe it is important, the old 32 Bit System had default character set "latin1", I am not sure how much that affects text encoding in the databases.

On the new Debian Buster System, I deinstalled MariaDB 10.3 and downgraded to MySQL 5.7.32 using DEB bundle "mysql-apt-config_0.8.15-1_all.deb". I actually purged MariaDB to make sure the MySQL installation is clean.

I did all the up- and downgrading after noticing that a mysqldump from 5.5 (32 Bit) to MariaDB 10.3 (64 Bit) caused inconsistencies in the restored database. Yet, this problem persisted throughout all my efforts, however I do think migrating from 5.7.x (32) to 5.7.y (64) should have the best preconditions in order to succeed.

I have tried the usual mysldump <OLD_DB> | mysql <NEW_DB>, several variations using "--default-character-set=latin1" for the mysqldump command, for the mysql command and also for both. I have also tried a filesystem-based copy of the entire directory "/var/lib/mysql". Again and again, nothing crashes or reports and error, but the restored database has inconsistencies.

Thinking that the inconsistency might stem from the current version of MediaWiki (1.35), I also tried the same with MediaWiki 1.31 (current long-term stable release), but there it is even worse.

The inconsistencies themselves are a bit vague to describe for me, as I am not too deply involved with the relatively complex MediaWiki Software (plus SemanticMediaWiki on top), but in general the restored system delivers wrong content for valid page paths, it is as if pointers (indices, I guess) are pointing into the wrong table.

My question is: How is it even conceivable that "mysqlump | mysql" fails under the circumstances that I have described above? I simply don't understand it. The 32/64 Bit difference should not matter since I am transforming the database in a textual representation (by unsing mysqldump), that would be a bug too worse to imagine. So all that is left is maybe a Latin1/Unicode conflict that messes things up?

Thanks for any help, I'm basically out of ideas. I've tried to search for bug reports similar to what I am experiencing, no luck.

Christian

Options: ReplyQuote




Sorry, you can't reply to this topic. It has been closed.

Content reproduced on this site is the property of the respective copyright holders. It is not reviewed in advance by Oracle and does not necessarily represent the opinion of Oracle or any other party.