Re: Cyrus Murder Environment Upgrade

2020-06-11 Thread Wolfgang Breyha
On 10/06/2020 20:47, Miguel Mucio Santos Moreira wrote:
> Wolfgang,
>
> If you don't mind, I'd like to know if when you upgraded backend servers
> from 2.4 version to 2.5 version you have an increase, in metadata size.Here
> we had 30% around of increase

Yes, cyrus.* are larger. Not sure about .cache, but .index for sure. And
the databases will grow as well if you change to twoskip.

We had to go back to skiplist on some hosts after the database reached
~200MB due to long locking times. The frontends started to have troubles
with long locks leading to timeouts on connect.

Greetings, Wolfgang
--
Wolfgang Breyha  | https://www.blafasel.at/
Vienna University Computer Center | Austria

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


Re: Cyrus Murder Environment Upgrade

2020-06-10 Thread Nic Bernstein

Miguel,
That's perfectly normal, and I think it's even covered in the release 
notes... Nope, I'm wrong, the release notes mention the larger Memory 
footprint, due to more data and metadata being cached in memory.  But 
the on-disk size increases, too, as there is more information being held 
in indexes, etc.


The same is true, again, when going from 2.5 to 3.X

Cheers,
    -nic

On 6/10/20 1:47 PM, Miguel Mucio Santos Moreira wrote:

Wolfgang,

If you don't mind, I'd like to know if when you upgraded backend 
servers from 2.4 version to 2.5 version you have an increase, in 
metadata size.Here we had 30% around of increase


Thanks one more time

Greetings
--

*Miguel Moreira*
DTE/SRE/GRE - Gerência de Redes
+55(31)3339-1401
PRODEMGE - Companhia de Tecnologia da Informação do Estado de Minas Gerais


Aviso: Esta mensagem é destinada exclusivamente para a(s) pessoa(s) a 
quem é dirigida, podendo conter informação sigilosa e legalmente 
protegida. O uso impróprio será tratado conforme as normas da empresa 
e a legislação em vigor. Caso não seja o destinatário, favor notificar 
o remetente, ficando proibidas a utilização, divulgação, cópia e 
distribuição. Em Terça, Junho 09, 2020 10:39 -03, Wolfgang Breyha 
 escreveu:

Hi!

On 09/06/2020 14:56, Miguel Mucio Santos Moreira wrote:
> Dear Wolfgang,
>
> Firstly thanks for your answer, secondly I have one more doubt, 
during this
> time where the new Mupdate Master is receiving mailboxes 
information from

> backend servers, is necessary stopping comunications between frontend
> servers and mupdate master or none action is necessary besides that one
> you've mentioned before?
> We're concerned if frontend servers will connect to Mupdate Master and
> receive from it an information which there's no mailboxes anymore 
until the
> backend push entirely mailboxes information and this situation to 
cause any

> trouble.

I recommend the follow steps:
*) check that your currently running setup has no conflicts in 
mailboxes.db

by running "ctl_mboxlist -mw". It is possible that you see output if
somebody changes his mailboxes while you run the command, but it should
not appear again if you run the command a second time. If everything is
fine...

*) shut down all running cyrus
frontends first, then backends and mupdate last
*) backup your mailboxes.db on mupdate server
*) replace/update mupdate and start it with empty/removed mailboxes.db.
*) backup your mailboxes.db on the backends
*) do the ctl_mboxlist -m by hand on the backends (only one at the same
time) you can check if everything went ok with "-mw" at any time
afterwards.
*) start cyrus on backends

In our setup the frontends have mupdate running as well. I can't 
currently

remember if this is mandatory. If this is true in your setup then:
*) remove or rename the mailboxes.db database on the frontends and start
them. They will fetch the database immediately from the mupdate server.
This is visible in syslog as well and takes about 30 seconds in our
setup (~250MB mailboxes.db).
otherwise
*) start the frontends

At this point everything should be up and running again.

Watching syslog output all the time usually helps.

IIRC we updated the mupdate server to 2.5 first. Then we had a mix of 2.4
and 2.5 backends for some time. The 2.5 backends had some capabilities
suppressed. Frontends had 2.4 until all backends had 2.5. Last but not
least we upgraded to 2.5 on the frontends.

If you need more info/details feel free to ask.

Greetings, Wolfgang
--
Wolfgang Breyha  | https://www.blafasel.at/
Vienna University Computer Center | Austria



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


--
Nic Bernstein   n...@nicbernstein.com
https://www.nicbernstein.com
https://www.linkedin.com/in/nic-b-26577a178/


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

Re: Cyrus Murder Environment Upgrade

2020-06-10 Thread Miguel Mucio Santos Moreira

Wolfgang,

If you don't mind, I'd like to know if when you upgraded backend servers from 
2.4 version to 2.5 version you have an increase, in metadata size.Here we had 
30% around of increase

Thanks one more time

Greetings
--

Miguel Moreira
DTE/SRE/GRE - Gerência de Redes
+55(31)3339-1401
PRODEMGE - Companhia de Tecnologia da Informação do Estado de Minas Gerais


Aviso: Esta mensagem é destinada exclusivamente para a(s) pessoa(s) a quem é 
dirigida, podendo conter informação sigilosa e legalmente protegida. O uso 
impróprio será tratado conforme as normas da empresa e a legislação em vigor. 
Caso não seja o destinatário, favor notificar o remetente, ficando proibidas a 
utilização, divulgação, cópia e distribuição. Em Terça, Junho 09, 2020 10:39 
-03, Wolfgang Breyha  escreveu:Hi!

On 09/06/2020 14:56, Miguel Mucio Santos Moreira wrote:
> Dear Wolfgang,
>
> Firstly thanks for your answer, secondly I have one more doubt, during this
> time where the new Mupdate Master is receiving mailboxes information from
> backend servers, is necessary stopping comunications between frontend
> servers and mupdate master or none action is necessary besides that one
> you've mentioned before?
> We're concerned if frontend servers will connect to Mupdate Master and
> receive from it an information which there's no mailboxes anymore until the
> backend push entirely mailboxes information and this situation to cause any
> trouble.

I recommend the follow steps:
*) check that your currently running setup has no conflicts in mailboxes.db
by running "ctl_mboxlist -mw". It is possible that you see output if
somebody changes his mailboxes while you run the command, but it should
not appear again if you run the command a second time. If everything is
fine...

*) shut down all running cyrus
frontends first, then backends and mupdate last
*) backup your mailboxes.db on mupdate server
*) replace/update mupdate and start it with empty/removed mailboxes.db.
*) backup your mailboxes.db on the backends
*) do the ctl_mboxlist -m by hand on the backends (only one at the same
time) you can check if everything went ok with "-mw" at any time
afterwards.
*) start cyrus on backends

In our setup the frontends have mupdate running as well. I can't currently
remember if this is mandatory. If this is true in your setup then:
*) remove or rename the mailboxes.db database on the frontends and start
them. They will fetch the database immediately from the mupdate server.
This is visible in syslog as well and takes about 30 seconds in our
setup (~250MB mailboxes.db).
otherwise
*) start the frontends

At this point everything should be up and running again.

Watching syslog output all the time usually helps.

IIRC we updated the mupdate server to 2.5 first. Then we had a mix of 2.4
and 2.5 backends for some time. The 2.5 backends had some capabilities
suppressed. Frontends had 2.4 until all backends had 2.5. Last but not
least we upgraded to 2.5 on the frontends.

If you need more info/details feel free to ask.

Greetings, Wolfgang
--
Wolfgang Breyha  | https://www.blafasel.at/
Vienna University Computer Center | Austria

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

Re: Cyrus Murder Environment Upgrade

2020-06-09 Thread Miguel Mucio Santos Moreira

Wolfgang,

I'm sure your help and experience with Cyrus Murder upgrading will save a lot 
of time and reduce the possibility of an eventual problem during the upgrade.

Thankful

--

Miguel Moreira
DTE/SRE/GRE - Gerência de Redes
+55(31)3339-1401
PRODEMGE - Companhia de Tecnologia da Informação do Estado de Minas Gerais


Aviso: Esta mensagem é destinada exclusivamente para a(s) pessoa(s) a quem é 
dirigida, podendo conter informação sigilosa e legalmente protegida. O uso 
impróprio será tratado conforme as normas da empresa e a legislação em vigor. 
Caso não seja o destinatário, favor notificar o remetente, ficando proibidas a 
utilização, divulgação, cópia e distribuição. Em Terça, Junho 09, 2020 10:39 
-03, Wolfgang Breyha  escreveu:Hi!

On 09/06/2020 14:56, Miguel Mucio Santos Moreira wrote:
> Dear Wolfgang,
>
> Firstly thanks for your answer, secondly I have one more doubt, during this
> time where the new Mupdate Master is receiving mailboxes information from
> backend servers, is necessary stopping comunications between frontend
> servers and mupdate master or none action is necessary besides that one
> you've mentioned before?
> We're concerned if frontend servers will connect to Mupdate Master and
> receive from it an information which there's no mailboxes anymore until the
> backend push entirely mailboxes information and this situation to cause any
> trouble.

I recommend the follow steps:
*) check that your currently running setup has no conflicts in mailboxes.db
by running "ctl_mboxlist -mw". It is possible that you see output if
somebody changes his mailboxes while you run the command, but it should
not appear again if you run the command a second time. If everything is
fine...

*) shut down all running cyrus
frontends first, then backends and mupdate last
*) backup your mailboxes.db on mupdate server
*) replace/update mupdate and start it with empty/removed mailboxes.db.
*) backup your mailboxes.db on the backends
*) do the ctl_mboxlist -m by hand on the backends (only one at the same
time) you can check if everything went ok with "-mw" at any time
afterwards.
*) start cyrus on backends

In our setup the frontends have mupdate running as well. I can't currently
remember if this is mandatory. If this is true in your setup then:
*) remove or rename the mailboxes.db database on the frontends and start
them. They will fetch the database immediately from the mupdate server.
This is visible in syslog as well and takes about 30 seconds in our
setup (~250MB mailboxes.db).
otherwise
*) start the frontends

At this point everything should be up and running again.

Watching syslog output all the time usually helps.

IIRC we updated the mupdate server to 2.5 first. Then we had a mix of 2.4
and 2.5 backends for some time. The 2.5 backends had some capabilities
suppressed. Frontends had 2.4 until all backends had 2.5. Last but not
least we upgraded to 2.5 on the frontends.

If you need more info/details feel free to ask.

Greetings, Wolfgang
--
Wolfgang Breyha  | https://www.blafasel.at/
Vienna University Computer Center | Austria

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

Re: Cyrus Murder Environment Upgrade

2020-06-09 Thread Wolfgang Breyha
Hi!

On 09/06/2020 14:56, Miguel Mucio Santos Moreira wrote:
> Dear Wolfgang,
>
> Firstly thanks for your answer, secondly I have one more doubt, during this
> time where the new Mupdate Master is receiving mailboxes information from
> backend servers, is necessary stopping comunications between frontend
> servers and mupdate master or none action is necessary besides that one
> you've mentioned before?
> We're concerned if frontend servers will connect to Mupdate Master and
> receive from it an information which there's no mailboxes anymore until the
> backend push entirely mailboxes information and this situation to cause any
> trouble.

I recommend the follow steps:
*) check that your currently running setup has no conflicts in mailboxes.db
   by running "ctl_mboxlist -mw". It is possible that you see output if
   somebody changes his mailboxes while you run the command, but it should
   not appear again if you run the command a second time. If everything is
   fine...

*) shut down all running cyrus
   frontends first, then backends and mupdate last
*) backup your mailboxes.db on mupdate server
*) replace/update mupdate and start it with empty/removed mailboxes.db.
*) backup your mailboxes.db on the backends
*) do the ctl_mboxlist -m by hand on the backends (only one at the same
   time) you can check if everything went ok with "-mw" at any time
   afterwards.
*) start cyrus on backends

In our setup the frontends have mupdate running as well. I can't currently
remember if this is mandatory. If this is true in your setup then:
*) remove or rename the mailboxes.db database on the frontends and start
   them. They will fetch the database immediately from the mupdate server.
   This is visible in syslog as well and takes about 30 seconds in our
   setup (~250MB mailboxes.db).
otherwise
*) start the frontends

At this point everything should be up and running again.

Watching syslog output all the time usually helps.

IIRC we updated the mupdate server to 2.5 first. Then we had a mix of 2.4
and 2.5 backends for some time. The 2.5 backends had some capabilities
suppressed. Frontends had 2.4 until all backends had 2.5. Last but not
least we upgraded to 2.5 on the frontends.

If you need more info/details feel free to ask.

Greetings, Wolfgang
--
Wolfgang Breyha  | https://www.blafasel.at/
Vienna University Computer Center | Austria

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


Re: Cyrus Murder Environment Upgrade

2020-06-09 Thread Miguel Mucio Santos Moreira

Dear Wolfgang,

Firstly thanks for your answer, secondly I have one more doubt, during this 
time where the new Mupdate Master is receiving mailboxes information from 
backend servers, is necessary stopping comunications between frontend servers 
and mupdate master or none action is necessary besides that one you've 
mentioned before?
We're concerned if frontend servers will connect to Mupdate Master and receive 
from it an information which there's no mailboxes anymore until the backend 
push entirely mailboxes information and this situation to cause any trouble.

One more time, thanks

Cheers!

--

Miguel Moreira
DTE/SRE/GRE - Gerência de Redes
+55(31)3339-1401
PRODEMGE - Companhia de Tecnologia da Informação do Estado de Minas Gerais


Aviso: Esta mensagem é destinada exclusivamente para a(s) pessoa(s) a quem é 
dirigida, podendo conter informação sigilosa e legalmente protegida. O uso 
impróprio será tratado conforme as normas da empresa e a legislação em vigor. 
Caso não seja o destinatário, favor notificar o remetente, ficando proibidas a 
utilização, divulgação, cópia e distribuição. Em Terça, Junho 09, 2020 05:31 
-03, Wolfgang Breyha  escreveu:On 08/06/2020 17:37, Miguel 
Mucio Santos Moreira wrote:
> Now we're in doubt about how is the best solution to replace the mupdate
> master server for a new one.
> Nowadays we have around 16K mailboxes.

IIRC we simply replaced the mupdate server and did a "ctl_mboxlist -m" on
all backends to fill it. Shouldn't take that long since we did it with 130k
on 8 backends in under 20 minutes (or even shorter).

Greetings, Wolfgang
--
Wolfgang Breyha  | https://www.blafasel.at/
Vienna University Computer Center | Austria

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

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

Re: Cyrus Murder Environment Upgrade

2020-06-09 Thread Wolfgang Breyha
On 08/06/2020 17:37, Miguel Mucio Santos Moreira wrote:
> Now we're in doubt about how is the best solution to replace the mupdate
> master server for a new one.
> Nowadays we have around 16K mailboxes.

IIRC we simply replaced the mupdate server and did a "ctl_mboxlist -m" on
all backends to fill it. Shouldn't take that long since we did it with 130k
on 8 backends in under 20 minutes (or even shorter).

Greetings, Wolfgang
--
Wolfgang Breyha  | https://www.blafasel.at/
Vienna University Computer Center | Austria

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


Cyrus Murder Environment Upgrade

2020-06-08 Thread Miguel Mucio Santos Moreira

Hello guys!

We have a cyrus murder environment with cyrus 2.4 version, according to cyrus 
documentation we should upgrade backend servers, mupdate master and for last 
frontend servers.
Following this recommendantions we've installed new backend servers, with 2.5 
version, joined them to the cluster and migrated mailboxes from old servers to 
new servers throught xfer.
Now we're in doubt about how is the best solution to replace the mupdate master 
server for a new one.
Nowadays we have around 16K mailboxes.

Any hint?

Thanks in advance

Cheers!

--

Miguel Moreira
DTE/SRE/GRE - Gerência de Redes
+55(31)3339-1401
PRODEMGE - Companhia de Tecnologia da Informação do Estado de Minas Gerais


Aviso: Esta mensagem é destinada exclusivamente para a(s) pessoa(s) a quem é 
dirigida, podendo conter informação sigilosa e legalmente protegida. O uso 
impróprio será tratado conforme as normas da empresa e a legislação em vigor. 
Caso não seja o destinatário, favor notificar o remetente, ficando proibidas a 
utilização, divulgação, cópia e distribuição.

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