It is possible that the two versions have different query plans, with the new version requiring more temp space. It is also possible that different temporary table engines are in use. Check to make sure you are using aria for temp tables and not innodb.
> On Feb 21, 2019, at 8:31 AM, Benoit Plessis <[email protected]> wrote: > > Hello Andrei, > >> On 21/02/2019 14:19, [email protected] wrote: >> [...] >> To the issue itself >> >>> 2019-02-20 15:24:12 140618945124096 [ERROR] Slave SQL: Could not >>> execute >>> Write_rows_v1 event on table xxx.yyyy; Error writing file >>> '/tmp/MLxClNzW' (Errcode: 28 "No space left on device"), Error_code: >>> 3; >> >> the error was caused by ROW format event and therefore does not do with > > yeah that's what i feared. > > >>> I was looking at using a separate tmp space for the slave needs >>> using slave_load_tmpdir >> the parameter above but indeed check out @@global.tmpdir location and >> size available. > > Yes as i said initially, the binlog corruption issues are related to > saturations in tmpdir location. > > The initial issue is this strange huge increase in tmpdir space with > mariadb 10.1 were previously 4Gb was largely enough and now even 5 times > this (20Gb) isn't anymore ... > > >> Perhaps the >> > someone ate a few words here ;) > > Thanks for your insight anyway! > > > _______________________________________________ > Mailing list: https://launchpad.net/~maria-discuss > Post to : [email protected] > Unsubscribe : https://launchpad.net/~maria-discuss > More help : https://help.launchpad.net/ListHelp _______________________________________________ Mailing list: https://launchpad.net/~maria-discuss Post to : [email protected] Unsubscribe : https://launchpad.net/~maria-discuss More help : https://help.launchpad.net/ListHelp
