On 03/23/2016 07:44 PM, Michael Wilson wrote:
We’ve been having an interesting problem in a Galera configuration:

1. We get a session.

2. We add a row with session.add()

3. We commit with session.commit()

4. Using the SAME session, we then try and get the same row.

5. We get row not found.

We believe that what’s happening is the get is using a different pool 
connection than the add, so Galera perceives it as a
different session, and directs it to a different instance, which may not have 
the commit() yet.

We would think that we could avoid this by using the same session, but maybe 
not. Is there a way to force the add() and get to
use the same connection across commit()?

you are in luck, because I not only maintain SQLAlchemy, I work for Red Hat as the Galera maintainer! Otherwise I'd have no clue what this is about. What you're probably seeing is the fact that Galera, despite being "synchronous", actually has a little bit of replication lag which is described best here: https://www.percona.com/blog/2013/03/03/investigating-replication-latency-in-percona-xtradb-cluster/ (Percona is obviously 95% the same as plain Galera).

Anyway, the best way to deal with this is when using HAProxy, one of your VIPs is configured as the "single-master" vip that just stays on one node for all connections, failing over to another node only if the first goes down (I can share the optimal configuration for this). Then the app has to use this "writer" connection for all operations that are sensitive to commit-then-read (there's a lot of ways to achieve that too).

A totally different way to go would be to bind your Session to a single Connection when you first build it up, rather than binding it to an engine/connection pool. That would allow that Session to keep using the same connection across commits. If you can organize your application so that you have control over the scope of a Session vs. the scope of the transactions within it, that could work also.







Thanks!



--
You received this message because you are subscribed to the Google Groups 
"sqlalchemy" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sqlalchemy+unsubscr...@googlegroups.com.
To post to this group, send email to sqlalchemy@googlegroups.com.
Visit this group at https://groups.google.com/group/sqlalchemy.
For more options, visit https://groups.google.com/d/optout.

Reply via email to