[11:13:23] volans, I remembered the reason why I want to take load balancing outside of the application, and not only outside of the deployment [11:14:30] Long-running requests (like queue processing) do not reload their config immediately, which is already causing small issues in some special cases [11:14:56] also, we want non-mediawiki apps to connect directly to the databases, such as the dump process [11:17:37] now, haproxy, or anything else, is something that has not been tested, etc. [11:19:07] what I need is a programmable, network-syncronizable, connection handler with a pool of connections on client side [11:36:48] * Reedy orders jynus a unicorn [15:24:24] jynus: thanks for the context, but the long-running requests will still continue to go to the previous one for the established connections unless you kill the connection forcing the application to reconnect (assuming has this automation) [15:25:29] which may be an option... in some cases [15:26:57] jobrunners and dumps should do that, after a timeout [15:29:38] Reedy, we also need that intermediate agent to have 0 latency :-) [15:31:04] or as a more realistic goal "improve in some way what we have now" [15:33:42] in any case, there needs to be a discussiona first with application server ops owner, performance and mediawiki-core developers. So do not hold your breath. [15:40:10] of course :) [15:59:30] https://github.com/mariadb-corporation/MaxScale is a product to take a potentially consider, if not for production, for labsdb scaling [15:59:56] s/take a potentially// [20:22:53] I leave 3 long running processes during the weekend: db1069 compression, db1024 defragmenting and db1046 purging