I’m wondering in general if Percona is still interested in developing pxc-operator further? We’re running into issues with the tool that have Jira tickets from 2021 or earlier where there seem to be no progress at all. But the issues seem like a Very Big Deal that I’m sure we’re not the only ones running into. Like [K8SPXC-735] ProxySQL uses only one server for reads - Percona JIRA, which basically makes the entire proxysql deployment unusable for what it’s supposed to solve.
I mean, it’s fine if Percona has other priorities, but would be nice if we could get some idea what to expect from the tool moving forward and whether it would make sense to start forking and fixing issues ourselves, as it seems like PRs are not really resolved either.
Hello @timstoop,
we continue our development and support of the PXC Operator. Last release was in July and the next one is coming this quarter (November - December timeframe).
As for K8SPXC-735 - there are a couple of thoughts:
- We tried to solve this issue with our ProxySQL scheduler that we developed internally: GitHub - percona/pxc_scheduler_handler
Unfortunatelly it caused even more problems and we rolled back the change. We will continue looking into it.
- We also usually recommend to use haproxy, but I agree that ProxySQL choice has its reasoning behind it.
What are the other issues that you are running into?
Hi Sergey,
Thanks for your response and great to hear this is still being worked on!
Basically, one of the issues that’s bothering us the most is the lack of configurability options. We keep running into (possibly small) issues that we could solve if the pxc-db resource was a lot more configurable. Being able to apply a patch to the actual StatefulSet definition would be very welcome.
For instance, we run into an issue where a specific customer is doing a lot of queries every so often that result in temporary tables being created in /tmp within the container. This is using the host storage, but due to the large amount of writes here, this is actually impacting other containers running on that same host. If we were just able to mount an additional PV in /tmp instead, we could solve the issue for the specific customer without having to use SSD disks in our nodes.
The issue I linked to would possibly be solved by setting the environment variable WRITERS_ARE_READERS="backup" (discussed in [K8SPXC-553] Change default configuration of ProxySQL to WRITERS_ARE_READERS=yes - Percona JIRA), but again, there’s no option to actual set this from within the PXC resource, making a fairly easy fix pretty hard to perform ourselves without forking the code and adding this either hard coded or optionally.
I understand the need to prevent foot-shooting, but having the flexibility of saying “I know you want to do this, but I want to do this instead” without the operator limiting what should be a fairly easy fix, would be very welcome.
Again, really happy with what you’re doing in this space and it’s by far the best solution out there I think, but it could be better fairly easy if less was set in stone and more was overridable.