On Tue, 18 Oct 2022 11:52:42 +0100
Peter Duffy <peter@???> wrote:

> Sorry, this isn't specific to devuan (although it's involved
> indirectly) - I'm really just looking for thoughts and comments on a
> problem which has been driving me insane for the last few weeks.
>
> I'm trying to replicate a setup of several fairly old linux/mysql
> systems, as part of a project to upgrade them to devuan. I was trying
> to use virtualbox VMs to do the replication (virtualbox 6.1.32). First
> VM was ubuntu 14 and percona mysql 5.6.37; second VM was devuan
> chimaera and percona mysql 5.6.37. Each VM had 32g RAM, 1 CPU core and
> 500g disk. I had a copy of the database from one of the original
> systems (gzipped output from mysqldump) and the first step was to load
> it into the first VM. That was when the problems started.

Hi,
try this ugly and dirty hack, copy to the vm the full mysql
data folder from the original server through a shared folder,
rather than doing the mysqldump dance.
Also be aware that mysqldump has a lot of command
line options that could be incompatible between different
versions. You need to restore the dump with the same
version of mysql/mysqldump that created it to be sure
it will work, later you can upgrade mysql, hoping that
the upgrade scripts will take care of your db.
Also take a look at the hex-blob option of mysqldump.

Hope this helps

Ciao,
Tito


> Loading the dump just consisted of "gunzip -c <file> | mysql
> <credentials and options>" - I've done it successfully on many systems
> before now. This time, the mysql client kept choking, with complaints
> that the input contained binary zeroes. That's not supposed to happen -
> mysqldump is supposed to output a file consisting of valid SQL
> statements and comments, designed to be poured straight back into mysql
> (I've never had a problem with it before now). I tried gunzipping the
> file on the VM, and on a separate physical box with the same version of
> gunzip, then comparing the md5sums of the files: original - md5sum
> matches; unzipped file - md5sums didn't match. I then wrote a little
> prog to scan for binary zeros, and ran it on both files: not there in
> the one done on the physical box; there in the one done on the VM.
>
> After tearing my hair over this for over a week and getting nowhere, I
> decided to ditch the idea of using virtualbox VMs, dug out some old
> retired boxes, set them up to match the VMs, and tried the load on the
> first one again. This time, no problems (apart from the fact that the
> load takes forever).
>
> At the moment, what seems to be inescapable is that gunzipping files in
> linux on virtualbox VMs can in some cases cause file corruption. Given
> that the identical procedure works on a physical box, it seems to
> exclude gzip itself, the shell (bash), the file system, and the kernel.
> The only thing which seems to be left is virtualbox itself.
>
> Has anyone else ever experienced anything else even remotely similar?
> I've not been able to find anything relevant on google. Also - has
> anyone any preferences for virtualisation under linux: what seems to be
> the most reliable from the range of available tools to do it?
>
> Thoughts would be most welcome!
>
>
> _______________________________________________
> Dng mailing list
> Dng@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng