Conceptually, the fix for this would depend on what we would determine to be the underlying cause.. What would be the contributing "issue(s)" here (as opposed to allowable input/behavior)?
1. An incomplete binlog recording of the master dying. Additionally, couldn't this issue "silently" break replication, even if the slave didn't die? I.e., if the trigger was executable, wouldn't it continue to persist on the slave when it would be deleted from the master after it died?
2. The slave crashing because it can't execute the trigger.
3. The trigger having invalid references.
4. Anything/something else?
Each problem would then have a different fix:
1. Write more events in the binlog to more accurately the state of the master, e.g. additionally include DROP TRIGGER statements in the binlog for tables with MEMORY based storage engines (before the DELETE).
2. Change the error handling logic on the slave to allow certain "fatal" errors in certain situations.
3. Validate the trigger query (on the master?).
My thought would be just #1. Elkin
bnestere: There's no crashing really, rather the slave stops with an error.
According to the description (the slave error) the slave does not have t2 table.
I'd say simply does not have.
But that's an inconsistency with the master in the very setup that is required.
I have to involve elenst again to help me to understand what is the problem or is there any.
I am puzzle 'cos if t were not of Memory type, and the user DELETE:d from it, it'd be the same error.
elenst: Finally I understood the "magic". Needed to have the 2nd chance 
. DELETE ends up in the binlog bypassing execution , so it misses its chance to hit the slave side error, on master.
That's exactly right.
The essence of this report is that DELETE which, if it had been executed, would have caused an error on the master and thus would have never been written into the binary log, gets written there directly by the special HEAP logic, gets replicated to the slave, expectedly ends up with an error on the slave, and thus causes replication abort due to the error code mismatch (0 vs non-zero). There is no previous discrepancy between master and slave, besides the inevitable loss of contents of the memory table after master restart.
Hypothetically it is not anyhow limited to triggers, it can be any error which satisfies the conditions above. Triggers were just the only example I came up with for DELETE failure on a memory table.
Surely, as bnestere describes, there can be numerous reasons for error code mismatches causing replication abort. They would be different problems though, or non-bugs if, for example, they are caused by previous schema/data discrepancy.
The problem is, I don't see a way out of it. Even if you don't write DELETE on the master, or if you ignore the event failure on the slave – still, we will end up with discrepancy in the table data, which will very likely make replication abort anyway, just later. Somehow the table on the slave has to be emptied to preserve consistency.
elenst, (to The problem is) indeed! So we should only binlog it but with a hint to slave(s) which is not call triggers - bnestere, right? And the best hint to my knowledge would be logging TRUNCATE instead of DELETE !
Elkin Nice. Just did some testing/debugging with truncate, and I agree, I think truncate would work well here.
Hi Andrei,
The fix is ready for review.
The status confirmed. The review should be completed, to make the patch into the upcoming CS release.