Hi Nic,
Sorry for the delay answering... I have been ill and later on holiday,
with very very very few time to answer to nothing when coming from
illness. Sorry then...
My idea really, was to upgrade to 3.0... So I'm planning:
- Upgrade in place from 2.3 to 2.4.
- Continue giving the service...
- Later setup a 3.0 slave.... all of this WITHOUT doing a reconstruct -V
max..... as it seems in 2.4 all works (unexpunge command and so) without
it... should say too, it seems the own sync client performs database
upgrade....
Jan 3 14:46:02 mx8c sync_client[17186]: Index upgrade:
mydomain.com!user.mytestuser.Sarenet-staff.Alberto (10 -> 12)
Jan 3 14:46:06 mx8c sync_client[17186]: Index upgrade:
mydomain.com!user.mytestuser.Sarenet-staff.Comerciales (10 -> 12)
Jan 3 14:46:15 mx8c sync_client[17186]: Index upgrade:
mydomain.com!user.mytestuser.Sarenet-staff.Instalaciones-staff (10 ->
12)
Jan 3 14:46:25 mx8c sync_client[17186]: Index upgrade:
mydomain.com!user.mytestuser.Sarenet-staff.RRHH (10 -> 12)
It seems to anyway be happening....
- When the 3.0 slave is totally replicated from the 2.4 mater... turn
the 3.0 as mater, and take a copy of it becoming it slave.....
This way I should have all the platform upgraded without downtimes....
How do you see Nic?. I think it should work... I'm still doing checks
anyway.....
Cheers!! Thanks a lot for your time!!
---
EGOITZ AURREKOETXEA
Departamento de sistemas
944 209 470
Parque Tecnológico. Edificio 103
48170 Zamudio (Bizkaia)
ego...@sarenet.es
www.sarenet.es [2]
Antes de imprimir este correo electrónico piense si es necesario
hacerlo.
El 15-12-2018 17:05, Nic Bernstein escribió:
> On 12/13/18 9:52 AM, Egoitz Aurrekoetxea wrote:
>
>> I was trying to upgrade part of our Cyrus imap installation, concretely that
>> one consisting in still 2.3. I was planning to set up Cyrus 3.0. I have seen
>> all works properly except for the unexpunge command because as someone
>> stated here, a reconstruct -V max was needed.The problem is that this
>> reconstruct command, takes ages and I'm not able to keep the service offline
>> so many time. So I have been thinking in the following scenario :
>
> Egoitz,
> As long as you've followed all of the various steps needed to account for
> version changes, as outlined in the Release Notes for _all_ intermediary
> releases, then the last step should be the updating of the indexes. Rather
> than running "reconstruct -V max" on all mailboxes at once, simply run it on
> subsets. We've done this on large installations without ill effect. You can
> have the service on line during the reconstruct, and, as you note, have most
> all functionality present.
>
> We build a list of users (mboxlist.txt), and then run a cron job, during
> off-peak hours, using the 'parallel' command like so (from 'crontab -e -u
> cyrus'):
>
>> ###
>> ## Start a batch of recursive reconstruct jobs at 7PM and discontinue
>> ## at 6:53AM.
>> 0 19 * * * parallel -j 5 --resume --joblog /var/lib/imap/reconstruct.log
>> cyrus reconstruct -G -V max -r -u {} < /var/lib/imap/mboxlist.txt
>> 53 06 * * * kill -TERM `ps ax | grep [p]arallel | awk '{print $1}'`
> Cheers,
> -nic
>
> --
> Nic Bernstein n...@onlight.com
> Onlight Inc. www.onlight.com [1]
> 6525 W Bluemound Rd., Ste 24 v. 414.272.4477
> Milwaukee, Wisconsin 53213-4073 f. 414.290.0335
Links:
------
[1] http://www.onlight.com
[2] http://www.sarenet.es
