List Info

Thread: Re: Configurations for performance




Re: Configurations for performance
country flaguser name
United States
2007-03-29 23:05:48
On Fri, 2007-03-30 at 13:44 +1000, Jake Anderson wrote:
> > Perdition would solve the IMAP UID problem, but it
doesn't help with the
> > plain old auto_increment collisions...
> >
> >   
> Yeah thats what i was thinking, to me thats just part
of multi master
> replication.

This is *the* core issue of multimaster. There are decades
of work on
distributed lock management to figure out who gets to make
what changes
to which critical data structures.

> Although... you wouldn't really need multi-master as
each server really
> is the "real deal" with all reads and writes
being done on it. The
> backup will only be used if the master is gone. It
might still be an
> idea to set it with the auto_increment value (in mysql
at least, i don't
> know about postgres), just incase you get a "split
brain" situation.

"The backup will only be used if the master is
gone." is *the* core
issue! Split brain is a very real, very serious problem.

STOMITH stands for "Shoot The Other Man In The
Head" and involves
physically cutting power to the other machine to prevent a
split brain.
In other words, the problem is serious enough that otherwise
sane people
consider it a lesser risk to yank the power than allow a
split brain.

> > If we combined Perdition with per-server
auto_increment id windows, then
> > I think we'd be onto something!
> >
> > Aaron
> Thats what i was thinking.
> postfix can direct mail to a host based on a database
lookup.

Can it? Point me to some docs and/or sample configs. If this
can be made
to work, then we really would have a single namespace
horizontally
scalable setup that we could recommend.

Aaron

_______________________________________________
DBmail mailing list
DBmaildbmail.org
htt
ps://mailman.fastxs.nl/mailman/listinfo/dbmail

Re: Configurations for performance
user name
2007-03-29 23:57:49
Aaron Stone wrote:
localhost" type="cite">
On Fri, 2007-03-30 at 13:44 +1000, Jake Anderson wrote:
  
Perdition would solve the IMAP UID problem, but it doesn't help with the
plain old auto_increment collisions...

  
      
Yeah thats what i was thinking, to me thats just part of multi master
replication.

    

This is *the* core issue of multimaster. There are decades of work on
distributed lock management to figure out who gets to make what changes
to which critical data structures.

  
And all those helpful people have done the work for us, aren't we lucky ;->
The only "danger" i see is doing admin tasks, everything else is no different to a single db server.
localhost" type="cite">

  
Although... you wouldn't really need multi-master as each server really
is the "real deal" with all reads and writes being done on it. The
backup will only be used if the master is gone. It might still be an
idea to set it with the auto_increment value (in mysql at least, i don't
know about postgres), just incase you get a "split brain" situation.
    

"The backup will only be used if the master is gone." is *the* core
issue! Split brain is a very real, very serious problem.

STOMITH stands for "Shoot The Other Man In The Head" and involves
physically cutting power to the other machine to prevent a split brain.
In other words, the problem is serious enough that otherwise sane people
consider it a lesser risk to yank the power than allow a split brain.

  
Again, its a solved problem, yes it has to be implemented but thats a matter of following recipes.
With seperate auto-increments then there should be no collisions of auto ID's, and with all writes to one DB there should be no collisions on guids.

localhost" type="cite">

  
If we combined Perdition with per-server auto_increment id windows, then
I think we'd be onto something!

Aaron
      
Thats what i was thinking.

postfix can direct mail to a host based on a database lookup.
    

Can it? Point me to some docs and/or sample configs. If this can be made
to work, then we really would have a single namespace horizontally
scalable setup that we could recommend.
  
I read it somewhere specifically but from my readings of
http://www.postfix.com/transport.5.html
and
http://www.postfix.com/ldap_table.5.html
(or you could use sql rather than ldap)
then i believe basically that postfix can look up a transport map per user, by writing the query to do so.
dbmail has LMTP listening on the network, postfix looks up a transport map for said user (from its local replicated database?) and delivers it (after scanning?) to the correct server for that user.

ultramonkey sitting in front of it to loadbalance your inbound smtp/content scanning servers.


What would be handy is to have a tool that would let you add a server to the pool and would then move users onto it to spread the load. (presumably making that users account inactive during the changeover period)

Re: Configurations for performance
country flaguser name
United States
2007-03-30 11:35:19
> Can it? Point me to some docs and/or sample configs. If
this can be made
> to work, then we really would have a single namespace
horizontally
> scalable setup that we could recommend.
>   

look at the transport maps in postfix.

In my configuration its

transport_maps = hash:/etc/postfix/transports

Then my transports file looks like:

domain1.com            smtp:192.168.1.5:25
domain2.com            dbmail-lmtp:127.0.0.1:24
domain3.com            smtp:mailhost.somewhere.com:25
lists.domain1.com    mailman:


you get the picture.

then run postmap hash:/etc/postfix/transports

I would imagine that a table in mysql would work as well. 
The 
configuration would look something like:

transport_maps=mysql:transports.cf

/etc/postfix/transports.cf

user=dbuser
passoword=somepassword
hosts=192.168.1.10
dbname=<whatever database you're using>
select_field=destination
where_field=domain

then the table would be:

create table 'transports' (
'domain'   text(120),
'destination' text(120),
UNIQUE KEY 'domain' ('domain')
) ENGINE=MyISAM;

In fact this is the method that dbmail administrator uses
with postfix.

> Aaron
>
> _______________________________________________
> DBmail mailing list
> DBmaildbmail.org
> htt
ps://mailman.fastxs.nl/mailman/listinfo/dbmail
>
>
>
>   

_______________________________________________
DBmail mailing list
DBmaildbmail.org
htt
ps://mailman.fastxs.nl/mailman/listinfo/dbmail

[1-3]

about | contact  Other archives ( Real Estate discussion Medical topics )