Hi, I will try to answer what I can ... see below.--On 8. Januar 2019 um 18:40:17 +0100 Egoitz Aurrekoetxea <egoitz@xxxxxxxxxx> 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.:.Attachment:
pgpYFzXTUdsdc.pgp
Description: PGP signature
---- 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
