Re: Running PostgreSQL in Kubernetes?
| От | Vijaykumar Jain |
|---|---|
| Тема | Re: Running PostgreSQL in Kubernetes? |
| Дата | |
| Msg-id | CAM+6J97yqWEnBO=GR6QA+-N6JiNFm+XW4H2ZtsnTsD95JfNHBg@mail.gmail.com обсуждение исходный текст |
| Ответ на | Running PostgreSQL in Kubernetes? (Victor Sudakov <vas@sibptus.ru>) |
| Ответы |
Re: Running PostgreSQL in Kubernetes?
(Victor Sudakov <vas@sibptus.ru>)
Re: Running PostgreSQL in Kubernetes? (Scott Ribe <scott_ribe@elevated-dev.com>) |
| Список | pgsql-admin |
I am just asking in a different thread so as to not derail the original conversation.
What was the real need to have postgresql cluster running in kubernetes?
I have experience in apache mesos, and did some beginner tutorial in kubernetes, but in my case those were good for stateless services.
For dbs, we used to have dedicated vms for postgresql clusters on lvm and vmware. It was very rare that we lost a physical server beyond recovery, else most of the time, a reboot of the physical server would resolve the issue. If we were able to figure out the problem with the physical server, we would just vmotion(live migrate) the vm from one server to another and survive fine.
so a large tb sized db, did not really require a resync on server problems.
Now with k8s, every time the server sneezes, the pods would get spawned onto different servers that would result in a full resync unless volumes could be moved.
Since containers are now in a shared environment, and if it is mostly over committed, then tuning of various params of a instance would be totally different compared to what was it on a dedicated vm.
Noisy neighbour's, a typical heavy activity like a bot attack on some services, which do not touch the db that is on the same server will have a serious impact due to shortage of resources.
in our case dns was under huge stress due to constant bouncing of services and discovery compared to original monoliths but were not tuned to handle that amount of changes and suffered stale cache lookups. For apps it would be OK, as they implement circuit breakers , but intra pg setup for barman or logical replication or pgbackrest would suffer a longer outage ?
Lastly, shared resources resulting in a poor query plan, like slow vacuuming may degrade the db.
Now, I have 0 exp in kubernetes, but I tried to understand the basics and found most of then similar to apache mesos. My use case was dbs grow and they grow really fast so they cannot be the same as immutable containers , but idk. Like when in need of a increased memory, it was OK to have do that for a vm and reboot, but for a pod, there is a risk of deployment and moving the instance on another server ? Or else all the pods that server would get bounced?
The point of these queries is just to have a conversation and understanding the need to put dbs on k8s, not about making it about right or wrong.
Maybe just like ssd, hdd, postgresql community would come up with a cost param to generate plans if run on k8s vs dedicated servers :).
Feel free to ignore, it's perfectly fine.
В списке pgsql-admin по дате отправления:
Следующее
От: Mukesh RajpurohitДата:
Сообщение: Re: Multiple refcursor as INOUT parameter in procedure