Is this intended to solve cases when replication lag is too large for efficient use of causal_reads? Could max_slave_replication_lag help in these cases?

Here are a few ways how the GTID extraction part could be implemented:

• Using monitors for GTID retrieval could work but it would be highly reliant on the monitoring interval.
• The replication stream could be used to extract GTIDs but the overhead of sending everything through MaxScale would far outweight the benefit of faster GTID event delivery.
• Installing some sort of an agent application on the database node would allow an efficient and fast method of delivering GTIDs but this is the most cumbersome solution to apply as separate binaries would have to be installed and managed on each node.
• Writing a server-side plugin that exports GTID events to MaxScale would be a neater solution but it still faces some of the same problems that an agent application would.

Another way to do this would be to extend the causal_reads behavior with dedicated GTID tracking threads for each server. These threads would execute a MASTER_GTID_WAIT for each GTID on the master, effectively synchronizing the slave to a certain point. The GTID waiting could be done in batches to synchronize multiple transactions at the same time. This logical timestamp could then be used in place of the replication lag in readwritesplit.

Added a preliminary implementation that uses monitors to get the GTID positions.