Help with few questions

[Sebastian Hagedorn]

Hi,

I will try to answer what I can ... see below.

--On 8. Januar 2019 um 18:40:17 +0100 Egoitz Aurrekoetxea 
<egoitz at sarenet.es> wrote:

> - search_fuzzy_always: 1 , causes all searches to go through Xapian
> engine. Being so good as it seems (and the way it speeds in my testing
> env search operations, it's nice!!), what could be the reason for not
> having it enabled by default?. Can it have some kind of problem?. I
> can't see them... Just for avoiding surprises.

With FUZZY you may get more matches than without. Look here for an 
explanation:

<https://tools.ietf.org/html/rfc6203>

The example in 3. is a good one:

3.  The FUZZY Search Key

   The FUZZY search key takes another search key as its argument.  The
   server is allowed to perform all matching in an implementation-
   defined manner for this search key, including ignoring the active
   comparator as defined by [RFC5255].  Typically, this would be used to
   search for strings.  For example:

      C: A1 SEARCH FUZZY (SUBJECT "IMAP break")
      S: * SEARCH 1 5 10
      S: A1 OK Search completed.

   Besides matching messages with a subject of "IMAP break", the above
   search may also match messages with subjects "broken IMAP", "IMAP is
   broken", or anything else the server decides that might be a good
   match.

Note that the *server* decides what "might be a good match". When all 
searches become FUZZY it might confuse users, but on the other hand I doubt 
there is a single IMAP client that lets the user choose whether a 
particular search should be FUZZY or not ...

> - Bron, in this post
> https://fastmail.blog/2014/12/01/email-search-system/ told that Fastmail
> was not able to handle with just one Xapian default database (even on
> SSD disks) all traffic. So he said Fastmail was using a in-memory
> filesystem for a database (called temp) for new email. Later another for
> cleaning up that in memory filesystem. And later one more, for keeping
> definitively the content. You seemed to use a Squatter command for
> moving elements between databases. Concretely (sudo -u cyrus
> /usr/cyrus/bin/squatter -C /etc/cyrus/imapd-sloti30t01.conf -v -z
> archive -t temp,meta,data,archive -u brong). I assume that compacts all
> elements from all databases to archive?. If I wanted to compact elements
> from temp to data, the command should be "sudo -u cyrus
> /usr/cyrus/bin/squatter -C /etc/cyrus/imapd-sloti30t01.conf -v -z data
> -t temp -u brong" (in this example for user brong) ??. I assume you
> launch something like it with a cron weekly and it's done?.

That depends entirely on your system. Without knowing the number of users 
you have, the number of mails that arrive per hour, what kind of storage 
systems you have, how much free RAM your servers have, it is impossible to 
say how often you need to squatter in compact mode. On a test server I set 
up I run a cron job every 2 minutes to check if tmpfs is getting tight ...

> - If something went wrong when the upgrade proccess from 2.4 to 3.0,
> could I setup 3.0 as master of the 2.4 and later make 2.4 master again?.
> Could that cause info loosing?. I assume yes but just
> for knowing posibilities.

You have to describe in more detail what you mean. The point of no return 
is usually when you start to deliver new mail to the new server. You cannot 
sync from 3.0 to 2.4. That means if you start to deliver new mail to the 
3.0 server, you can't go back to 2.4 without losing the messages that have 
arrived n the meantime. Strictly speaking to could manually copy the 
mailboxes from the 3.0 server to the 2.4 and run reconstruct, but I don't 
consider that a viable option.

> - When a Xapian or conversation index becomes broken, a reconstruct
> could recover?. What could be the repairing procedure?.

ctl_conversationsdb -z "zaps" the conversationsdb – it basically empties 
it. Then you can recreate it with ctl_conversationsdb -b. The "reconstruct" 
command does not touch the conversationsdb. If the actual Xapian index 
should be broken, I guess you'd have to delete the index files and run 
squatter again.

Cheers
Sebastian
-- 
    .:.Sebastian Hagedorn - Weyertal 121 (Gebäude 133), Zimmer 2.02.:.
                 .:.Regionales Rechenzentrum (RRZK).:.
   .:.Universität zu Köln / Cologne University - ✆ +49-221-470-89578.:.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
URL: <http://lists.andrew.cmu.edu/pipermail/info-cyrus/attachments/20190109/af6f2099/attachment.sig>