Another enhancement idea. More robustness with postgres impl. for traditional mode.

[jeremyjpj0916]

Right now Kong will not be able to read from the db if the primary r/w goes down. The secondary PG node in config can only be used as a spare pressure relief for read queries but plays no role in Kong's high availability from what I understand.

I view this as a decent miss, and while yes there is a field I think that specifies a backup yaml for the runtime if the DB were to go down. I think there is a better solution like this:

Say I run a postgres cluster. 1 primary r/w node and 2 other secondary read-only nodes, I specify 1 of each of those read only nodes in other kong deployments too in traditional mode in certain datacenters.

What I would like to see if the primary node were to go offline briefly(vm server patching restarts etc.) I would like Kong to be smart enough to at least go into a protective "read-only" mode for all runtime activities and serve anything stored in the read-only secondary postgres nodes to be treated as the "primary node" for the main nodes downtime, at least serving proxy traffic correctly while the primary node is down and helping Kong cache and use any resources stored in the db at that time.

And when the primary node is detected to be back up and active for reads and writes then Kong switches back into normal behavior.

Going to be posting all my enhancement ideas as they come to me, been using Kong a long time so I see most the shortcomings or whats lacking. List isn't too long though :) .

[chobits]

@bungle Hi aapo, if you have found some interesting information, you could left one message. I think we have discussed a lot about this one internally.