rvlane (ralf.gebhardt@mariadb.com): I am sorry, I scrapped my text as it inferred something like sending to the slaves beyond prior binlogging (feasible, but not something we should do). I am thinking over this matter..

I understand that binlog logging after slave ack is something you may not want to do, but that type of solution is exactly what I am looking for in this ticket (not logging on failed master when it will never get to a semi-sync repl slave). I'll wait for further discussion.

rvlane, (ralf.gebhardt@mariadb.com):

The slaves in your setup, as I understand, go ahead to elect a new Master which won't be having
some sequence of transactions that "lost" in network. Those transactions were not committed so I gather it's fine (though not perfect) that their users may find out that the transactions have to be retried against the new master.

The old master then needs a mode of recovery with two things combined:

• --tc-heuristic-recover=rollback and
• wipe out the binlogged-but-not-committed range from its binlog

Upon recovery the restarted old master will be consistent with the new one.

How this looks like for you?

rvlane, (ralf.gebhardt@mariadb.com): there could be another option to store acknowledgment into Engine. Innodb already provides a similar service on the binlog-less slave to maintain file:pos of the last commit trx. I need to speak to marko whether it's realistic to squeeze one more such pair into the Engine's recoverable area.

Yes, that sounds like it would work. We actually always do a --tc-heuristic-recover=rollback first before the mysqld is started to try to force rollback of uncommitted transactions, we have found that without this, there is a very high chance that the master will not come back to re-join as slave. However this does not cover all cases (I believe your #2 point).

Our setup is maxscale with mariadbmon and auto-failover (master/slave/slave). An option to allow us to perform auto-rollback on mysqld start (without us having to run it first before starting the service) and whatever else is necessary to ensure that transactions that never made it to the semi-sync slave are rolled back is needed so the failed master can automatically re-join as a slave (via maxscale).

Elkin, we’d have to discuss this some time next week. Before MariaDB Server 10.3 implemented MDEV-15158, InnoDB stored the latest binlog position in the TRX_SYS page in the system tablespace. Since then, it is being written to the rollback segment header page on transaction commit.

I don’t know if it is feasible to store the acknowledgements inside InnoDB rollback segment or undo pages. At the very least, the semantics should be clarified. And in any case, this should be tested with innodb_undo_log_truncate=ON.

If MXS-2542 were implemented, then this could also be fixed in MaxScale by automatically rebuilding the crashed master.

https://jira.mariadb.org/browse/MDEV-20996?focusedCommentId=138318&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-138318 suggestion is in other words to turn --tc-heuristic-recover=rollback replication safe. Its current behaviour is not as rolled back transaction may remain in binlog.
Find MDEV-21117 for more.

For a real lossless HA solution you need MDEV-19140
The current asnych or semi-synch replication solutions cannot provide this.

This Issue is addressed as part of MDEV-21117