There are two common ways to implement the read replica pattern: 1. Embed the routing logic in the application code (explained in the last post). 2. Use database middleware. We focus on option 2 here. The middleware provides transparent routing between the application and database servers. We can customize the routing logic based on difficult rules such as user, schema, statement, etc.
1. When we say that "Data is replicated to two replicas. " are we saying sync or async way. If its async how can we guarantee that during we are not providing the stale data
After all the biggest problem is read repair latency.
Are there any middleware for postgresql? It will be nice if the middleware can do the heavy lifting of routing "read your own write" by understanding the client's DAO call i.e
1. If the client say inserts and reads what it inserted in a transaction, the middleware should know this complete transaction request and call only the primary
2. If it is just read it should call replicas (even better will be if it calls replicas that has caught up with the primary at least for that log in Primary)
Not sure if I missed something here :
1. When we say that "Data is replicated to two replicas. " are we saying sync or async way. If its async how can we guarantee that during we are not providing the stale data
After all the biggest problem is read repair latency.
Are there any middleware for postgresql? It will be nice if the middleware can do the heavy lifting of routing "read your own write" by understanding the client's DAO call i.e
1. If the client say inserts and reads what it inserted in a transaction, the middleware should know this complete transaction request and call only the primary
2. If it is just read it should call replicas (even better will be if it calls replicas that has caught up with the primary at least for that log in Primary)