Re: Live migrating index/control files
> On 26 Apr 2021, at 16:03, azu...@pobox.sk wrote:
>
> Btw, if your control files are OUTSIDE maildir and you are moving them back
> INSIDE maildir, notice (for example in my script) that .INBOX directory
> doesn't exists in maildir and control files for INBOX are placed directly in
> maildir instead. This is probably why you are failing to prevent
> resync/redownload.
Oh, thanks!
I was simply using rsync to synchronize the control/index directory tree into
the maildir, incorrectly assuming the trees were the same in both
configurations:
rsync -uav /mail/{index,control}/${user:0:1}/${user:0:2}/${user}/
/mail/${user:0:1}/${user:0:2}/${user}/Maildir/;
I see now, as you said, that the control and index files for INBOX should be
placed directly in the maildir, and that they have been recreated for the users
in question.
I'll try modifying the sync part to also move the files from the .INBOX folder:
rsync -uav /mail/{index,control}/${user:0:1}/${user:0:2}/${user}/ ~/Maildir/;
mv -v ~/Maildir/.INBOX/* ~/Maildir/;
rmdir -v ~/Maildir/.INBOX;
Thanks again!
Best regards,
Eirik
Re: Live migrating index/control files
Citát Eirik Rye :
On 26 Apr 2021, at 15:14, Eirik Rye wrote:
Both ~/Maildir and /mail/{control,index}/ are separate NFS-mounts,
and we now want to consolidate all files to the user's home
directory instead. The end goal is to stop using NFS altogether.
Some more background information:
- Running 2.3.13 (89f716dc2)
- The rsync is run from the user's current mapped backend (from
`doveadm director status `), in hopes to reduce NFS-related
issues
- Kicking is done through one of the directors, to ensure all of the
user's connections are kicked.
Best regards,
Eirik
Btw, if your control files are OUTSIDE maildir and you are moving them
back INSIDE maildir, notice (for example in my script) that .INBOX
directory doesn't exists in maildir and control files for INBOX are
placed directly in maildir instead. This is probably why you are
failing to prevent resync/redownload.
Re: Live migrating index/control files
> On 26 Apr 2021, at 15:14, Eirik Rye wrote:
>
> Both ~/Maildir and /mail/{control,index}/ are separate NFS-mounts, and we now
> want to consolidate all files to the user's home directory instead. The end
> goal is to stop using NFS altogether.
Some more background information:
- Running 2.3.13 (89f716dc2)
- The rsync is run from the user's current mapped backend (from `doveadm
director status `), in hopes to reduce NFS-related issues
- Kicking is done through one of the directors, to ensure all of the user's
connections are kicked.
Best regards,
Eirik
Re: Live migrating index/control files
Sorry, accidentaly sent the uncomplete message.
Here is the mentioned script (see some configuration directives at the
beginning of the script):
https://pastebin.com/ArG8zspi
Citát azu...@pobox.sk:
Hi,
i think you cannot do this without preventing users to log in. We
were doing similar thing few years ago and i wrote a Python script
for this purpose - you can use it if you find it usefull (script is
copying only control files as indexes are transparently recreated):
Citát Eirik Rye :
Hello,
We are running a director-based dovecot cluster where the user's
maildir and the indexes/control files are, for legacy reasons,
stored on separate NFS-backends, i.e.:
mail_location =
maildir:~/Maildir:CONTROL=/mail/control/%1u/%2u/%u:INDEX=/mail/index/%1u/%2u/%u
Both ~/Maildir and /mail/{control,index}/ are separate NFS-mounts,
and we now want to consolidate all files to the user's home
directory instead. The end goal is to stop using NFS altogether.
I have devised a four step plan for gradually migrating the
index/control files into the user's maildir, on a per-user basis:
1. Kick the user in an attempt to flush the user's index files:
`doveadm director kick `
2. Rsync the index/control files into the user's maildir:
`rsync -uav /mail/{index,control}/${user:0:1}/${user:0:2}/${user}/
/mail/${user:0:1}/${user:0:2}/${user}/Maildir/;`
3. Update the (redis-based) userdb for the specific user to
override mail_location to use the default CONTROL/INDEX locations:
`{"mail": "maildir:~/Maildir"}`
4. Kick the user one last time so that they reconnect using the new
settings.
Unfortunately, after running this for a small batch of users, we
recieved a couple reports that their clients had started to
resynchronize and redownload their mailboxes, which is exactly what
we're trying to avoid. There are no index related error messages
related to the few users that reported these issues.
From my understanding, clients become confused when the control
files are changed or lost (`dovecot-uidlist` and
`dovecot-uidvalidity`), so I suspect the kick + rsync + kick
procedure is not robust enough for this.
Does anyone have any experience with performing such a migration
without taking systems offline for the duration? Any suggestions to
make this process more transparent for our users, so as to not
induce panic when their mailboxes abruptly appear empty?
Best regards,
Eirik
Re: Live migrating index/control files
Hi,
i think you cannot do this without preventing users to log in. We were
doing similar thing few years ago and i wrote a Python script for this
purpose - you can use it if you find it usefull (script is copying
only control files as indexes are transparently recreated):
Citát Eirik Rye :
Hello,
We are running a director-based dovecot cluster where the user's
maildir and the indexes/control files are, for legacy reasons,
stored on separate NFS-backends, i.e.:
mail_location =
maildir:~/Maildir:CONTROL=/mail/control/%1u/%2u/%u:INDEX=/mail/index/%1u/%2u/%u
Both ~/Maildir and /mail/{control,index}/ are separate NFS-mounts,
and we now want to consolidate all files to the user's home
directory instead. The end goal is to stop using NFS altogether.
I have devised a four step plan for gradually migrating the
index/control files into the user's maildir, on a per-user basis:
1. Kick the user in an attempt to flush the user's index files:
`doveadm director kick `
2. Rsync the index/control files into the user's maildir:
`rsync -uav /mail/{index,control}/${user:0:1}/${user:0:2}/${user}/
/mail/${user:0:1}/${user:0:2}/${user}/Maildir/;`
3. Update the (redis-based) userdb for the specific user to override
mail_location to use the default CONTROL/INDEX locations:
`{"mail": "maildir:~/Maildir"}`
4. Kick the user one last time so that they reconnect using the new settings.
Unfortunately, after running this for a small batch of users, we
recieved a couple reports that their clients had started to
resynchronize and redownload their mailboxes, which is exactly what
we're trying to avoid. There are no index related error messages
related to the few users that reported these issues.
From my understanding, clients become confused when the control
files are changed or lost (`dovecot-uidlist` and
`dovecot-uidvalidity`), so I suspect the kick + rsync + kick
procedure is not robust enough for this.
Does anyone have any experience with performing such a migration
without taking systems offline for the duration? Any suggestions to
make this process more transparent for our users, so as to not
induce panic when their mailboxes abruptly appear empty?
Best regards,
Eirik
Live migrating index/control files
Hello,
We are running a director-based dovecot cluster where the user's maildir and
the indexes/control files are, for legacy reasons, stored on separate
NFS-backends, i.e.:
mail_location =
maildir:~/Maildir:CONTROL=/mail/control/%1u/%2u/%u:INDEX=/mail/index/%1u/%2u/%u
Both ~/Maildir and /mail/{control,index}/ are separate NFS-mounts, and we now
want to consolidate all files to the user's home directory instead. The end
goal is to stop using NFS altogether.
I have devised a four step plan for gradually migrating the index/control files
into the user's maildir, on a per-user basis:
1. Kick the user in an attempt to flush the user's index files:
`doveadm director kick `
2. Rsync the index/control files into the user's maildir:
`rsync -uav /mail/{index,control}/${user:0:1}/${user:0:2}/${user}/
/mail/${user:0:1}/${user:0:2}/${user}/Maildir/;`
3. Update the (redis-based) userdb for the specific user to override
mail_location to use the default CONTROL/INDEX locations:
`{"mail": "maildir:~/Maildir"}`
4. Kick the user one last time so that they reconnect using the new settings.
Unfortunately, after running this for a small batch of users, we recieved a
couple reports that their clients had started to resynchronize and redownload
their mailboxes, which is exactly what we're trying to avoid. There are no
index related error messages related to the few users that reported these
issues.
From my understanding, clients become confused when the control files are
changed or lost (`dovecot-uidlist` and `dovecot-uidvalidity`), so I suspect the
kick + rsync + kick procedure is not robust enough for this.
Does anyone have any experience with performing such a migration without taking
systems offline for the duration? Any suggestions to make this process more
transparent for our users, so as to not induce panic when their mailboxes
abruptly appear empty?
Best regards,
Eirik
