On Tue, Jun 05, 2007 at 09:56:29PM +0300, Timo Sirainen wrote:
> On Tue, 2007-05-22 at 09:58 -0500, Troy Benjegerdes wrote:
> > Best case, when all the nodes, and the network is up, locking latency
> > shouldn't be much longer than say twice the RTT. But what really
> > matters, and causes all the
On Tue, 2007-05-22 at 09:58 -0500, Troy Benjegerdes wrote:
> Best case, when all the nodes, and the network is up, locking latency
> shouldn't be much longer than say twice the RTT. But what really
> matters, and causes all the nasty bugs that even single-master
> replication systems have to deal w
Hi list,
> OpenLDAP uses another strategy, which is more robust aka needs less
> fragile interaction between the servers.
We have been thinking very long about replication. The requirement
is to have a backup computing center in distant location, so
replication has to work over a WAN connection
> > This increases communication and locking significantly. The locking alone
> > will likely be a choke point.
>
> My plan would require the locking only when the mailbox is being updated
> and the global lock isn't already owned by the server. If you want to
> avoid different servers from cons
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, 21 May 2007, Francisco Reyes wrote:
I am basically suggesting to log all the changes to a log(s) and have a
separate program handle passing on the information to the slaves.
That's the old OpenLDAP way.
However, it's surprising that you ha
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, 22 May 2007, Timo Sirainen wrote:
a) Accept that replication process can lose changes, and require a full
resync when it gets back up. This of course means that all users'
mailboxes need to be scanned, which can be slow.
If you generate (i
Timo Sirainen writes:
Why not go with a pure log replication scheme?
this way you basically have 3 processes.
1- The normal, currently existing programs. Add logs to the process
2- A Master replication process which listens for clients requesting for
info.
3- The slave processes that request i
On Sun, 2007-05-20 at 20:58 -0400, Francisco Reyes wrote:
> Timo Sirainen writes:
>
> > Master keeps all the changes in memory until slave has replied that it
> > has committed the changes. If the memory buffer gets too large (1MB?)
>
> Does this mean that in case of a crash all that would be los
Timo Sirainen writes:
Master keeps all the changes in memory until slave has replied that it
has committed the changes. If the memory buffer gets too large (1MB?)
Does this mean that in case of a crash all that would be lost?
I think the cache should be smaller.
because the slave is handli
Timo Sirainen writes:
Then there are also people who would want to run Dovecot on their laptop
and have it synchronize with the main server whenever network connection
is available.
YES!
I had not thought of that, but that would be killer.. although that would be
multi-master which I think w
Troy Benjegerdes writes:
But that's currently not *really* replicated. The real question I guess
is why not use a cluster/distributed/san filesystem like AFS, GFS,
Because those distribute filesystems may be more difficult to setup, more
difficult to maintain and may be less portable than a d
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, 17 May 2007, Timo Sirainen wrote:
Hello,
OpenLDAP uses another strategy, which is more robust aka needs less
fragile interaction between the servers.
OpenLDAP stores any transaction into a replication log file, after it has
been processe
On Fri, May 18, 2007 at 12:20:13PM -0400, Bill Boebel wrote:
> On Fri, May 18, 2007 1:42 am, Troy Benjegerdes <[EMAIL PROTECTED]> said:
>
> > I'm going to throw out a warning that it's my feeling that replication
> > has ended many otherwise worthwhile projects. Once you go down that
> > rabbit ho
On 18.5.2007, at 5.41, Christian Balzer wrote:
Yes, all these FS based approaches currently have one or more of
the issues Timo lists. The question of course is, will a replicated
dovecot be less complex, slow, etc.
The good thing is at least that Dovecot won't be any more complex if
you're
On Fri, May 18, 2007 1:10 pm, Timo Sirainen <[EMAIL PROTECTED]> said:
> On Fri, 2007-05-18 at 12:20 -0400, Bill Boebel wrote:
>> So what about tackling this replication problem from a different
>> angle... Make it Dovecot's job to replicate the index and control
>> files between servers, and make
On Fri, 2007-05-18 at 12:20 -0400, Bill Boebel wrote:
> So what about tackling this replication problem from a different
> angle... Make it Dovecot's job to replicate the index and control
> files between servers, and make it the file system's job to replicate
> just the mail data. This would req
On Fri, May 18, 2007 1:42 am, Troy Benjegerdes <[EMAIL PROTECTED]> said:
> I'm going to throw out a warning that it's my feeling that replication
> has ended many otherwise worthwhile projects. Once you go down that
> rabbit hole, you end up finding out the hard way that you just can't
> avoid the
On Fri, May 18, 2007 at 11:41:46AM +0900, Christian Balzer wrote:
> On Thu, 17 May 2007 19:17:25 +0300 Timo Sirainen <[EMAIL PROTECTED]> wrote:
>
> > On Thu, 2007-05-17 at 10:04 -0500, Troy Benjegerdes wrote:
> > > But that's currently not *really* replicated. The real question I guess
> > > is wh
On Thu, 17 May 2007 19:17:25 +0300 Timo Sirainen <[EMAIL PROTECTED]> wrote:
> On Thu, 2007-05-17 at 10:04 -0500, Troy Benjegerdes wrote:
> > But that's currently not *really* replicated. The real question I guess
> > is why not use a cluster/distributed/san filesystem like AFS, GFS,
> > Lustre, GP
On Thu, 2007-05-17 at 10:04 -0500, Troy Benjegerdes wrote:
> But that's currently not *really* replicated. The real question I guess
> is why not use a cluster/distributed/san filesystem like AFS, GFS,
> Lustre, GPFS to handle the actual data, and specify that replication
> only works for maildir o
On Thu, 2007-05-17 at 09:23 -0600, Aredridel wrote:
> Jonathan wrote:
> > Hi Timo,
> >
> > MySQL gets around the problem of multiple masters allocating the
> > same primary key, by giving each server its own address range
> > (e.g. first machine uses 1,5,9,13 next one uses 2,6,10,14,...).
> > Would
Jonathan wrote:
> Hi Timo,
>
> MySQL gets around the problem of multiple masters allocating the
> same primary key, by giving each server its own address range
> (e.g. first machine uses 1,5,9,13 next one uses 2,6,10,14,...).
> Would this work for UIDs?
UIDs have to be sequential. Causes some probl
My first reaction is that I've already got replication by running
dovecot on AFS ;)
But that's currently not *really* replicated. The real question I guess
is why not use a cluster/distributed/san filesystem like AFS, GFS,
Lustre, GPFS to handle the actual data, and specify that replication
only w
Hi Timo,
MySQL gets around the problem of multiple masters allocating the
same primary key, by giving each server its own address range
(e.g. first machine uses 1,5,9,13 next one uses 2,6,10,14,...).
Would this work for UIDs?
Jonathan.
Several companies have been interested in getting replication support
for Dovecot. It looks like I could begin implementing it in a few months
after some other changes. So here's how I'm planning on doing it:
What needs to be replicated:
- Saving new mails (IMAP, deliver)
- Copying existing mai
25 matches
Mail list logo
