Hi, Eugenio,
I wrote this earlier but am in the middle of moving my office so my mail has been intermittent. I have been following your discussion with Abhilash, and he's definitely the expert, especially if you are using the containers he creates and distributes. But there's some information here he hasn't mentioned yet.
Please consider the following discussion to be background that allows you to understand some of the considerations. I've only run the Mailman 3 suite with all three running constantly on the same host, so I have no experience with this kind of issue.
eugenio.jordan@esa.int writes:
Our customer is currently using PostGRESQL as backend, and we would like to perform some maintenance tasks, namely running vacuum full, or at least trying to rebuild hyperkitty_email primary key related index. We have been asked on the real impact of putting in place such initiative. Though the latter is related to archiving, I haven't found a way to stop just Hyperkitty or Django related processes other than stopping Mailman's core, hence preventing mails addressed to distribution lists from being delivered, could you please confirm if I am correct?
Mailman core can certainly run without either Postorius or HyperKitty. Controlling Mailman core (moderation, helping users) without Postorius is annoying, but it can be done. If you stop the HyperKitty process, what should happen, I believe, is that posts for archiving will accumulate in the 'archive' queue until HyperKitty is available again.
It's been a while since I studied this so I could be completely wrong, but as I understand it HyperKitty and Postorius are not daemon processes. Rather, they are WSGI applications, which means they are subprocesses spawned by your webserver, and controlled by it. In order to keep them from running, you would reconfigure the webserver to not call those WSGI applications. How that is done is specific to the webserver and the WSGI module. If you are running from Docker containers, most likely, you can just stop their containers.
The larger problem is that Mailman core uses a RDBMS. Normally both Django and Mailman are referring to the same RDBMS, PostgreSQL in your case. I'm not familiar with the vaccuum operation; if it requires taking the whole RDBMS down, and Mailman is running on that RDBMS, you're out of luck. Mailman can accept posts and queue them, but it can't deliver them to subscribers without access to the RDBMS tables.
If it's just a matter of locking some tables while other are available, then it should work because the tables used by core and HyperKitty are disjoint as far as I know. (I think Postorius and HyperKitty both use Django's user tables for authorization, so at least for those tables both Postorius and HyperKitty will have to be down, but core can continue running because its database is completely separate.)
Regarding the former, as far as I have read, the "mappings" lists -> addresses are stored just in the database, so if we run some kind of procedure or task like vacuum which will lock exclusively tables, or want anyway to have the database stopped for a cold backup or whatever, Mailman willl not work, that is, again the mails addressed to the distribution lists will not be delivered. Will you please confirm this point, too?
That depends on how "vacuum" works. If you can tell the RDBMS not to lock Mailman core's tables, it can continue to run. Definitely if the database is not running, Mailman will continue to receive and store the posts, but it won't be able to distribute mail to subscribers until its tables are available again. At that point the queued posts will be processed normally, except that if there's a large backlog, they won't go out in a quick burst, it may take a while.
One possible worry, depending on how you are connected to the Internet, is that your provider may interpret the sudden burst of outgoing mail when Mailman comes back on line as spam or some other sort of mischief. Mailman has no way to throttle this: it feeds messages to the MTA until the MTA says "stop". Then it waits until the MTA is ready again.
Regards, Steve