是否可以要求ProxySQL在读取时使用特定的GTID？

Question

We have an application that issues a write to ProxySQL, followed by an immediate read that might be affected by the write. Behind ProxySQL are four MySQL servers - one writer and three readers that replicate from the writer.

Now, ProxySQL is able to ensure that it selects an 'up to date' reader by recording the GTID sent back in the OK packet from the original write and the binlog feed from the readers to ensure it picks one that has executed the write already.

Our problem is that, because of our topology, the read may actually reach ProxySQL on a different connection than the write. It's therefore possible that the 'read' connection is holding an older GTID and hence a 'not up to date' reader might be selected upon which the write hasn't yet occurred.

We can see a possible solution if ProxySQL could be told to ensure the reader is up to date with a 'specified' GTID (one that we parse out of the OK packet ourselves) rather than the one on the connection, but we don't know if we can do that - I can't see anything in the documentation.

Any thoughts towards a workable solution would be very much welcomed!

We are using mySQL 5.7.25 with ProxySQL version 2.0.3-29-g00f26d5.

Our result currently is that we often execute the write then a read, but the read returns the state that existed before the write.

Answer 1

My understanding is, that proxysql supports GTID consistent out of the box - when some circumstances are fulfilled.

1. binlog_format is ROW
2. on the backend session_track_gtids is set to OWN_GTID
3. the monitor user of proxysql exists on the backend servers
4. mysql_replication_hostgroups is also setup

Answer 2

It seems there isn't 'an answer' to this with ProxySQL as it stands today (2.0.3-29-g00f26d50), although the ProxySQL guys were willing to build the facility in for fee.

Meanwhile, we've taken the step of using the writer (by assigning it to a group and selecting that) for reads that must be up-to-date with a previous call as it'll always hold the latest consistent view. This will be a performance hit, but should be acceptable if such requests are not too common.