Re: Questions about user mode sync_client (move mailboxes from one server to another) and mailbox moving from partition (moving from partition in same server, renaming) lock

2019-05-23 Thread Sebastian Hagedorn

Hi,


Our Cyrus machines (Cyrus 3.0.8), usually have 3 mailbox partitions.
Sometimes, one of them becomes highly filled so we usually perform a
mailbox rename to another partition of the same server. For that
purpose, we normally lock at our proxy barrier any access to the mailbox
(we do play with Nginx authentication, Postfix hold and so). Is it
really needed to lock that way the mailbox, at some "external to Cyrus
level," in order to avoid mailbox corruption?. Or does Cyrus handle that
properly?. Does Cyrus exclusively lock and after done, unlock again?.


I can only answer that part of the question. We have been doing it like 
that (without blocking access from the outside) for years, but we're still 
on Cyrus 2.4. We only make sure there are no active processes by the user 
before starting the RENAME, and we do it at night. There haven't been any 
problems with that approach.

--
Sebastian Hagedorn - Weyertal 121, Zimmer 2.02
Regionales Rechenzentrum (RRZK)
Universität zu Köln / Cologne University - Tel. +49-221-470-89578

Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
To Unsubscribe:
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus

Questions about user mode sync_client (move mailboxes from one server to another) and mailbox moving from partition (moving from partition in same server, renaming) lock

2019-05-23 Thread Egoitz Aurrekoetxea via Info-cyrus
Good afternoon, 

Our Cyrus machines (Cyrus 3.0.8), usually have 3 mailbox partitions.
Sometimes, one of them becomes highly filled so we usually perform a
mailbox rename to another partition of the same server. For that
purpose, we normally lock at our proxy barrier any access to the mailbox
(we do play with Nginx authentication, Postfix hold and so). Is it
really needed to lock that way the mailbox, at some "external to Cyrus
level," in order to avoid mailbox corruption?. Or does Cyrus handle that
properly?. Does Cyrus exclusively lock and after done, unlock again?.
Have been taking a look at mboxlist_renamemailbox() and seemed so. Have
noticed too, that it seems that partition rename operation from and to
the same server but different parition at least, is not being inserted
in the rolling mode lock.. is this a new security measure for avoiding
accidents with the rename?. Always I have done a mailbox rename
previously (Cyrus 2.3.X), have stopped the master/slave replication,
done the rename in the master and later if all ended fine... launched in
the slave a dm of the "in the master renamed mailbox" and a sync_client
-u from the master for the mailbox to be copied to the appropiate
partition in the slave. 

My other question is.. with the new replication method (imap based and
so...), can I do a user mode sync_client from a mailbox, to another
server acting as a master?. I mean, in the following scenario :  

Server A (master) => Server B (slave) 

Server C (master) => Server D (slave) 

The a...@bbb.net mailbox is in A server. I want to move the mailbox from
A=>B couple of master/slave server to C=>D couple of mater/slave. I
launch a "sync_client -v -u a...@bbb.net -S C -p partition3" in server A.
Server C, has sync_log_chain enabled. Would that mailbox be replicated
in C=>D couple (to both from A to C and from C to D) and been able to be
accesible in C?. If so, does any kind of drawback exist in having always
sync_log_chain enabled?... else for this kind of movement seems to be
useful.. 

But thinking about it... if C is master... is it really needed that
sync_log_chain config statement in that case or it would just be
necessary (as I think), for replicating in the following scenario only?.


Server 1 (master) -> Server 2 (slave) -> Server 3 (slave) 

So, not needed when (there's a master in the middle) : 

Server 1 (master) -> Server 2 (master) -> Server 3 (slave)   perhaps
as in
https://www.cyrusimap.org/imap/reference/admin/sop/replication.html can
be read?. 

Thank you so much for your time, 

Best regards,
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
To Unsubscribe:
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus