[technique] serveur mail haute dispo

Mathieu Goessens (breizh-entropy) mathieu at breizh-entropy.org
Mar 31 Jan 06:36:54 CET 2012


On 30/01/2012 10:53, ikujam wrote:
> On 30/01/2012 03:26, Mathieu Goessens (breizh-entropy) wrote:
>> On 29/01/2012 20:38, ikujam wrote:
>>> j ai fini mon setup de test, et ça tourne plutôt pas mal ~
>>>
>>> le howto (un peu sec pour l'instant encore) se trouve dans le wiki :
>>>
>>> https://chiliproject.tetaneutral.net/projects/tetaneutral/wiki/HowTo_Mail_Backup_-_Ikujam
>>>
>>[...]
>>
>> - Est ce que ça vaudrait pas le coût de mettre les rsync à faire dans
>> une queue ? Ça éviterait deux choses pour moi 1) les avalanches de
>> rsync, quand pleins d'users reçoivent des mails * 2) de devoir refaire
>> un rsync global, quand ça remonte.
> 
> 
> Le risque avec les queues c'est la perte de données il me semble, alors
> que le push est plus direct. à étudier et adapter en fonction je penses.
> 
> 

Si tu as 50 rsync qui tournent en cascade sur le même dossier, ils
risquent d'effacer les données les un des autres, une queue permettra
d'éviter ça (rien empêche par contre de lancer plusieurs rsync en
parallèle si ils pointent pas vers les mêmes dossiers).

Cela augmentera effectivement la "latence", mais une fois que ces rsync
auront fini de tourner, tu seras dans un état cohérent. Sans ça, c'est
loin d'être sûr. Si tu as plusieurs rsync en même temps, c'est le
dernier à finir qui "gagnera". Autrement dit tu seras dans un état
"cohérent" ... celui du dernier rsync *à finir*.

Imagines le cas suivant:

- Gros batch de mails
- Lancement d'un rsync1 pour copier ceux ci.

- Pendant ce temps, un mail arrive, un rsync2 est lancé et copie ce
mail. Il a un seul mail à copier donc c'est quasi immédiat.

- rsync1 continue de tourner.
- Il voit un fichier sur le serveur destination qu'il connait pas (celui
copié par rsync2, qui n'était pas encore sur le serveur source quand
rsync1 a été lancé) => --delete

=> Tu as perdu un mail. En tt cas jusqu'au prochain rsync.

>>[...]
>> * Ou sont en train de lire/trier leurs mails. Je sais pas comment se
>> comporte courrier, mais dovecot à une fâcheuse tendance à les renommer
>> dans ce cas. Ou pire, sont en train de les lire/trier et d'en recevoir
>> (Deuxième race condition).
> 
> 
> de ce côté je n'ai jamais eu de souci - mais pas trop cherché la bête
> non plus, à tester ~

Testé et désapprouver avec dovecot: ne pas faire de rsync, quand un
client imap est en train de lire les mails, certains sont renommés, et
finissent en doublons. Ça c'est le cas gentil, avec un seul rsync.

-- 
Mathieu Goessens
Hackerspace Breizh-entropy



Plus d'informations sur la liste de diffusion technique