Hello, i'm looking at this for our setup as well. How are others handling the Mailman processes (qrunners) starting on a second server once the first server has gone down, and switching back to the first server once it has recovered?
Mailman's locks are usually not cleaned up properly when a server unexpectedly fails - although we could force the locks to be removed and start mailman processes on the second machine, we'll need to be sure that the first machine is really "dead". I assume two machines trying to run qrunners on the same mailman directories at once is not a good thing. This brings me to search for a way to insure that even if other services on a machine are not available, Mailman is certainly not operating on the Mailman directories before I try starting Mailman processes on a second machine. Perhaps looking at access / modification times of particualr files or directories, relative to the current time? Are there any ideas or comments from others doing or looking into this? - Ivan Fetch. >> I'm very interested in the solution you chose, and in how well it works >> for you. > > Sorry, I missed the original message. > >> I'm in the process of designing a fault-tolerant mailman installation, >> and any wisdom from experience would be very useful. > > Generally speaking, I don't think that many people try to do > this. You can off-load the web processing with multiple front-end > web proxies, and you can off-load the mail processing with multiple > inbound and outbound mail servers (usually best kept as separate > groups, since the anti-spam, anti-virus, and certain other > requirements are different for inbound versus outbound use), and the > rest is just Mailman itself. > > But, if you do want to go the whole nine yards, the Mailman > programmers have been pretty careful to keep everything relatively > NFS-safe, so you should just be able to have an NFS filesystem which > is then mounted on all of the Mailman servers (preferably served by a > high availability/redundant NFS server cluster). Doing things over > NFS will slow down individual operations, but the overall aggregate > throughput might be able to be higher, if the NFS server has the > right architecture and you spread the load out across enough Mailman > servers, etc.... > >>> Any thoughts on what is the best way to synchronize mailman databases >>> between to linux boxes? > > Mailman doesn't really use databases. At least, not > out-of-the-box. There are third-party unsupported patches to allow > database member adapters, but that's about it. > > Mailman stores pretty much everything into Python "pickle" files, > which is a particular binary Python-specific file format that can be > quickly saved and re-loaded in the native binary format. > >>> If my alias_maps are defined the same in /etc/postfix/main.cf are the >>> same on both hosts can I just duplicate my /usr/lib/mailman and >>> /var/lib/mailman directories? > > Duplicate? What do you mean by "duplicate"? Just once? If so, > then the directories would get out-of-sync. You'd have to keep all > the directories in sync somehow. > > In a nearline backup method, something as simple as rsync would > suffice, and would potentially only lose any information that was > written since the last rsync. > > In a production OLTP type of environment, you'd have to use > shared filesystems between the sets of machines, and you'd have to > make sure that those shared filesystems implement all the necessary > cluster-wide locking facilities, etc... to keep Mailman working > correctly. > > -- > Brad Knowles, <[EMAIL PROTECTED]> > > "Those who would give up essential Liberty, to purchase a little > temporary Safety, deserve neither Liberty nor Safety." > > -- Benjamin Franklin (1706-1790), reply of the Pennsylvania > Assembly to the Governor, November 11, 1755 > > SAGE member since 1995. See <http://www.sage.org/> for more info. > ------------------------------------------------------ > Mailman-Users mailing list > Mailman-Users@python.org > http://mail.python.org/mailman/listinfo/mailman-users > Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py > Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ > Unsubscribe: > http://mail.python.org/mailman/options/mailman-users/ifetch%40du.edu > > Security Policy: > http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp > > ------------------------------------------------------ Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp