[Mailman3-dev] Re: [Mailman-Developers] Debate about Mailman on BytesForAll

[Richard Barrett]

On 27 Aug 2004, at 11:24, Brad Knowles wrote:

> At 11:10 AM +0100 2004-08-27, Richard Barrett wrote:
>
>>  Another post to this list asked why NFS mounting of the database
>>  storage matters. Explanation for me: we have a large, high 
>> reliabilty,
>>  high availabilty,  etc etc file server accessible over Gigabit via an
>>  Extreme switch; we have an effective backup strategy for the file
>>  systems which that file server publishes via NFS.
>
> 	Not particularly unusual for large NFS server installations I've seen.
>

Didn't say it was.

>>                                                     I currently use
>>  NFS storage with MM 2.1.x
>
> 	And this works today?  You don't have file locking problems, etc...?
>
>>                            and given a catastrophic hardware failure
>>  in my mailing list server I can switch to a backup server and have
>>  full service back within minutes without data loss.
>
> 	Fair enough.  I wasn't aware that anyone was doing this sort of stuff 
> today with NFS, and that this worked without all the traditional file 
> locking problems, etc....
>

I said "switch to a backup server". Hot server, warm standby. When 
primary fails, then and only then, does the standby takes over so there 
is no contention in normal operation. Without NFS this approach cannot 
work easily because failure of the primary denies the backup server 
access to everything Mailman'ish. To be entirely accurate the only 
potentially delayed data is that in the current primary's local MTA 
queues (on local storage) which is undelivered to MM or not yet passed 
on to our outbound relay at the time the primary fails. But MM's qfiles 
directory is on NFS so the potential for delayed incoming mail is 
fairly small. I was not suggesting load sharing between the primary and 
secondary server, although I may go there someday.

> 	Certainly, I'd agree that we should support PostgreSQL and 
> MySQL/MaxSQL, BerkeleyDB, etc... as alternative database methods that 
> should be included with the base package.
>
> 	Now, whether one of them should be the primary database method, I'm 
> not quite ready to agree to that, at least not yet.  I tend to place 
> pretty high value on the "Keep It Simple" style of solution, at least 
> as far as the default stuff is concerned.
>

My concern is getting a heavy duty solution which will work with a 
database of my choice, i.e. one I have learned to love, trust and 
manage, which I can nominate at install time.

> 	If SQLite is easy to install, gives us decent performance, doesn't 
> make it too difficult to replace with alternative database solutions, 
> and satisfies our other criteria, then I'm all for that. In that case, 
> I'd rather we spent more time providing hooks that would allow us to 
> swap out the database back-end for something faster/more robust, as 
> well as doing things like fixing the pipermail/archiving tool, archive 
> searching tool(s), etc....
>

I am all for that, so that I can stop extending and maintaining my 
patches to integrate htdig and MHonArc with MM 2.1.x for these latter 
purposes.

> 	Out of curiosity, can someone remind me where the current mm3 "wish 
> list" is?  Are there mm3 specification and/or design documents yet?
>
> -- 
> Brad Knowles, <brad at stop.mail-abuse.org>
>
> "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.