Replication lag

[dreyks]

Everywhere I read about Makara I see a line regarding master stickiness countering the replication lag. But I can't quite get this thing to work.

Judging from the code, Makara writes current context with needed ttl to cache in case this context stuck to master. That's ok. But then to know what the previous context was, a cookie is used, and this cookie lives only for 5 seconds, and this time is not affected by master_ttl config option. What if my replication lag is bigger? Say I put master_ttl: 20 for a 20 seconds master stickiness, but the cookie still expires in 5 seconds, so Makara generates a new "previous" context, that doesn't match the context stored in cache.

Am I doing something wrong?

[evantahler]

The way it is now, master_ttl is a setting which can be thought of per thread, and is invoked in the Proxy. It's used in the stick_to_master! method indicating that a certain request/worker/etc should remain on master for the duration of the request. We actually use Thread.current.object_id under the hood here. This is used, for example, in a Rails request you create a new object and you need to read it back. This is one blocker for "internal" replication delays.

Separate to this, the makara cookie is used to tell the client to inform the server that in a subsequent request that the web server should stick to master for duration of the request. This can inform the Proxy to stick_to_master. As you point out, this cookie TTL is currently hard-coded to be 5s.

I agree that this should be configurable.

[dreyks]

I see. But the question still stands: How do I counter replication lag of
20 seconds?

[evantahler]

A possible solution is being discussed here: #100

[bleonard]

Before, makara would only use it for the next request. #194 should fix this so it can be 20 seconds or more.