W7 Pro 64-bit w MariaDB 5.5.30 64-bit.

You can upload the dump to our ftp: ftp.askmonty.org. If the data is sensitive, choose the 'private' folder, this way only MariaDB developers will have access to it. Please include 'mdev-4287' into the name of the dump so it can be found easily.

I've just discovered that the dump has been uploaded.
Now I'm trying to do
mysql <credentials> test < MDEV-4287-weatherdata_dump.sql
on 5.5.30 release, but I'm not getting any errors, it goes smoothly. Is there anything else to be done to reproduce the problem?

Hi Elena,

No, there is nothing else needed for repro of the problem. I did this dump on a MySQL 5.5.27 my old Weather station Computer (AMI dual core VistaU 32-bit). I then installed MariaDB 5.5.30 release onto my new weather station computer (Intel quad W7Pro-64bit) and I got the problem. I did several attempts to reinstall MariaDB on that computer and did more tests, with same sad result. Then I downloaded MySQL 5.5.30 on to my development computer (quad W7U-64-bit) and imported the dump flawlessly. No problem with MYSQL installed on the new weather station computer where I had had import problems. Same file was still on the new weather station for all tests. (I did renewed tests with the much shrunken file I sent to you.

Haven't had time to test any new releases of MariaDB - have had my hands full with new network here - 20-50 times faster to the internet... Will probably have time to make another test with any new release of your MariaDB 5.5.3x or so you might have available for Win-64bit. (please advise).

As I stated in my original report there was no problem with MariaDB 10.10 beta available at that time.

Regards,

Ingemar Skarpås

I did this imports using the root and its password -so nothing in the neighborhood of rights could have gone wrong.

Hi Ingemar,

It could be useful to see the error log of the failing MariaDB server, if you still have one. Also, the actual mysql.proc table files (not the dump, but the binary files – frm, MYD, MYI) might help.
You mentioned in the description "There seems to be no problems with the two tables", but I'm not sure which tables you meant. A probable reason of the failure is that mysql.proc was actually corrupted, in which case it should be seen in the error log, as well as in CHECK TABLE mysql.proc (I'm not sure if it would necessarily be seen from an INSERT statement, even if you executed one on the table).

Thanks.

I think it is not the dump´, but an existing database where mysql.proc has some kind of problems. When you were reinstalling MariaDB, did you remove all data, and started from scratch?

I deleted everything - including the folders...before installing anything new.

If I recall correct - there were 1 database (weatherdata), and possibly its two tables definitions and table data (for oasen and osterasen), or just one of them, and then a couple of stored procedures and events.

I will not have opportunity to dive into this until tomorrow, Sunday afternoon, then I can retest the scenario.

Cheers,

Ingemar Skarpås

Hi Elena,

I did tests late last night, and I was confused by the results, so I decided to wait till this evening to sum up the results. (below - when I say deinstalled I mean Everything including the MariaDB 5.5 folder...)

1) I deinstalled MariaDB 10.0.1 64-bit (which worked fine compared to the earlier 5.5.30 test)
2) Installed MariaDB 5.5.30 64-bit and tested the "mysql .... < weatherdata_dump.sql" small file and Everything Went OK! (surprise).
3) Deinstalled MariaDB 5.5.30 64-bit and reininstalled it.
4) Tested "mysql .... < weatherdata_dump.sql" on my full size 3.3 GB file.
It reported that it had lost the Connection to MySQL, error 2013 HY0000.
5) Attempted to dump the weatherdata schema, but it reported erratic database and proc errors - told me to fix the database/table before a new attempt to dump.
6) Read on about error 2013 HY0000, and deinstalled 5.5.30, and reinstalled the same.
7) Entered wait_timeout = 28800 and connect_timeout = 28800 into the my.ini and restarted MySQL service.
8) Attempted to import the full 3.3 GB weatherdata_dump.sql and - It Went ok!

So, I Think that your colleague who mentioned a possible mysql.proc problem was probably right on the spot...

So, the only thing is - should a database or tables or proc be able to cause this problem due to a lack of best settings for wait_timeout and/or connect_timeout.

Regards,

Ingemar

Hi Ingemar,

>> So, I Think that your colleague who mentioned a possible mysql.proc problem was probably right on the spot...

He certainly was, there is a little doubt about it, the error that you received says that much (Cannot load from mysql.proc. The table is probably corrupted). The only question is how you got it corrupted. Most usual reason is that the system table comes from a previous installation already corrupted (or the server thinks it's corrupted), which is what Wlad suggested. But you said you removed the old datadir and installed everything from scratch, which eliminates this possibility. I don't think that the timeout problem should cause the table corruption, so if it does, it's most likely a bug.

Hi again,

The original problem was that the first original dump (147 MB) went ok into MySQL 5.5.30, but not to MariaDB 5.5.30 - the file was left on the computer while I deinstalled MySQL in favor of MariaDB... To add to any already existing confusion; A smaller 20 MB dump worked ok on MySQL but NOT in the next reinstallation of MariaDB.

I don't have time tomorrow, but maybe right after that, I could test a reinstallation of MariaDB 5.5.30 and read the whole dump (3.3 GB) without the wait_timeout and connect_timeout set in the .ini. (I don't know what the internal defaults are). If that still brings up a bad attempt to drop the weatherdata schema we'll know!

Cheers,

Ingemar

Please make check a few things when you're on it:

1) you do certainly clean up the datadir after uninstallation of MySQL (normally it shouldn't be needed at all on upgrade from MySQL to MariaDB; but since we now want a clean test, it's better this way);
2) after you have installed MariaDB, check the value of @@datadir variable (select @@datadir) and make sure that's indeed the location you previously cleaned up;
3) check if you have any errors in mysql error log about mysql.proc (or any other table, for that matter) being crashed.

Thanks!

Hi Elena,

Thanks for your suggestions. I did a test after midnight, I couldn't sleep, and This time even the 3.3 GB import went smooth, even without setting the variables to 28800. (Yes one of them was set by default to that value).

So, right now I cannot reproduce any of the errors. I think you can close this case.

I have downloaded 10.0.2 and will test that, and also 5.5.31 when it is release on 12 days...

Cheers,

Ingemar

Hi Ingemar,

Okay, if you think it could happen that there were leftovers from the previous installation in the datadir, I suppose we can indeed close it.
Back to real-life scenarios, there are two generic (system-independent) ways to do what you were trying to do, each of which is supposed to work, and if they don't, it's most likely a bug:

1. you could have installed a really, really new MariaDB server, meaning that you certainly didn't have an old datadir; in this case a brand new empty datadir would have been created upon installation, and restoration of your dump should have worked;

2. you could have upgraded to MariaDB server from an earlier version of MariaDB or MySQL server; but in this case you should have run mysql_upgrade before trying to restore your dump, and better still, restart your server after running mysql_upgrade (in rare cases it might be important).

But since you are working on Windows, please check Windows-specific recommendations on upgrading MariaDB server:
https://kb.askmonty.org/en/upgrading-mariadb-on-windows/

Closing as discussed above. Please comment if you get any new information on this.