Hi Denis,

Please attach your cnf file(s) or output of SHOW VARIABLES from any of the servers where you are getting the error.

Thanks.

Thank you, it helps.
As a workaround, please try to increase the value of innodb_log_file_size (it's now set to 5M in your cnf file).

Thanks, it works (innodb_log_file_size=64M). But still keep in mind there are dangerous versions, while cannot reload some dump...

I'm not saying it's not a bug, just suggesting a workaround.
It's an upstream issue which got into 10.0 (and further into 10.1) with the merges of InnoDB from MySQL and XtraDB from Percona. I'm looking for the commit that caused it to understand whether it was intentional or not. After that, the normal routine is to report the problem upstream so they can fix, and we'll pull the fix along with the next engine merge.

I found the revision that caused it, and the change appears to be intentional:
http://bazaar.launchpad.net/~mysql/mysql-server/5.6/revision/5958

revno: 5958

revision-id: annamalai.gurusami@oracle.com-20140522155303-y5bvfo4sq0tdls98

parent: marko.makela@oracle.com-20140522115539-2yijjno0m7n65i7o

committer: Annamalai Gurusami <annamalai.gurusami@oracle.com>

branch nick: mysql-5.6

timestamp: Thu 2014-05-22 21:23:03 +0530

message:

  Bug #16963396 INNODB: USE OF LARGE EXTERNALLY-STORED FIELDS MAKES CRASH

  RECOVERY LOSE DATA

  Problem:

  When too-large blob fields are used, InnoDB overwrites its most recent

  checkpoint in its redo logs.

  Solution:

  Ensure that the total blob length does not exceed 10% of the redo log file

  size.

  rb#5399 approved by Marko, Nuno, Manish. 

  Venkat also contributed to patch (in replication related test case).

Your data is some 770 Kb, the log file is 5 Mb, so it all fits.

I don't think ti's wise to change the behavior in MariaDB, it will probably cause more incompatibility than it solves. If you feel strong about it, please try to report it upstream at bugs.mysql.com, and if they decide to fix it we'll merge. If you do so, please comment here so that we re-open this issue and keep it open until the fix arrives.

Yes, also I see - it is fixed unlimited upstream in 5.7. So, just hope to mering 5.7.

In which Version will the fix be available?
How do we get the information?

Whichever major version declares inclusion of InnoDB 5.7 should have it.
When it happens highly depends on the upstream release cycle – until MySQL 5.7 is officially stable (GA), InnoDB won't be merged because it changes too much from release to release.
If 5.7 goes GA before 10.1 does, or preferably before 10.1 is RC, there is a good chance InnoDB 5.7 will be included into it. Otherwise it should be 10.2.

well, that's very bad, because the bug is in actual release. How can we work around it?
What is the impact of this failure?
Does it work to add --force to the import-parameters?
It seems so, because the data where the error is thrown is in the table. And thats what I don't understand. I expected, that the data would be stepped over.

can someone put the reference to the mysql-bug in here.

If you read previous comments, specifically the commit comment for the upstream revision, you'll see that it was an intentionally introduced limitation. My guess is that's what the InnoDB team had to come up with in order to fix the recovery crash without making too intrusive changes in a post-GA version.
The workaround should be to shutdown the server gracefully, increase the value of innodb_log_file_size to make it definitely greater than 10x(total blog length), and to start the server again.

That said, it looks like in InnoDB 5.6.22 the limitation is a bit relaxed (although not completely removed like in 5.7). InnoDB 5.6.22 will most likely be in 10.0.16 – doubt it will make it to 10.0.15 since 5.6.22 has not been released yet..

The upstream bug they were solving is http://bugs.mysql.com/bug.php?id=69477

Is there a chance to get back to 10.0.13 (with debian/ubuntu repository?) or is the bug in there to?

You can find 10.0.13 in the repo, e.g. ftp://ftp.osuosl.org/pub/mariadb/mariadb-10.0.13/repo/ (the repo that you are using is likely to have a similar path).
But really, increasing the value of innodb_log_file_size is much simpler, and it's the right thing to do anyway if you have big blobs, otherwise your server is potentially affected by bug#69477 which might cause real damage.

which log_file_size should we set?
we have blobs which might be over 100MB...

The max allowed value for innodb_log_file_size is 512GB / innodb_log_files_in_group , so you have enough room for the maneuver.
Big redo files might make crash recover slower, but since your crash recovery is affected by the bug anyway, it shouldn't be a critical reason not to increase them.