Zimbra прекрасно работает, вот только Вам на почту приходят сообщения о непонятных ошибках в базе данных. Конечно же их можно игнорировать, ведь всё и так работает. А может пора навести порядок, “чтобы не было мучительно больно” потом.
Обычно сообщения об ошибках начинаются так:
Database errors found. /opt/zimbra/mysql/bin/mysqlcheck --defaults-file=/opt/zimbra/conf/my.cnf -S /opt/zimbra/db/mysql.sock -A -C -s -u root --password=XXXXXXXX
В принципе вес понятно: у Вас в БД имеются ошибки и Вам может помочь вот эта длинная команда. Узнать пароль на БД MySQL можно выполнив еще одну команду от пользователя zimbra:
zmlocalconfig -s | grep mysql | grep password
Вот только не все ошибки лечатся такой командой. О них и поговорим…
Рассмотрим примеры самых распространенных сообщений об ошибках в БД zimbra:
1.
Database errors found. /opt/zimbra/mysql/bin/mysqlcheck --defaults-file=/opt/zimbra/conf/my.cnf -S /opt/zimbra/db/mysql.sock -A -C -s -u root --password=XXXXXXXX mboxgroup1.appointment error : Table upgrade required. Please do "REPAIR TABLE `appointment`" or dump/reload to fix it! mboxgroup1.data_source_item error : Table upgrade required. Please do "REPAIR TABLE `data_source_item`" or dump/reload to fix it! mboxgroup1.imap_folder error : Table upgrade required. Please do "REPAIR TABLE `imap_folder`" or dump/reload to fix it! mboxgroup1.mail_item error : Table upgrade required. Please do "REPAIR TABLE `mail_item`" or dump/reload to fix it! mboxgroup1.pop3_message error : Table upgrade required. Please do "REPAIR TABLE `pop3_message`" or dump/reload to fix it! ... и так далее еще очень много строк... ...
Наиболее вероятная причина ошибки – невнимательность при обновлении в прошлом с версии 6.x на 7.x. В release notes есть раздел “After the Upgrade is Complete” (после завершения обновления). После перехода с версии 6 на более старшую надо просто выполнить еще один скрипт (он уже есть на сервере):
1. Переключаемся на пользователя zimbra su - zimbra 2. Останавливаем сервис mailboxd zmmailboxdctl stop 3. Запускаем скрипт perl для обновления таблиц /opt/zimbra/libexec/scripts/migrate20100913-Mysql51.pl 4. Запускаем сервис mailboxd zmmailboxdctl start 5. Проверяем БД на ошибки /opt/zimbra/libexec/zmdbintegrityreport -r
2.
Database errors found. /opt/zimbra/mysql/bin/mysqlcheck --defaults-file=/opt/zimbra/conf/my.cnf -S /opt/zimbra/db/mysql.sock -A -C -s -u root --password=XXXXXXXX mysql.general_log Error : You can't use locks with log tables. mysql.slow_log Error : You can't use locks with log tables.
Данная проблема лечится еще проще:
1. Останавливаем zimbra 2. Переходим в каталог БД и удаляем файлы *log.frm (лучше их перенести куда-нибудь, удалить всегда успеется): cd /opt/zimbra/db/data/mysql mv *log.frm /tmp/ 3. Стартуем zimbra, новые (правильные) версии файлов *log.frm будут созданы автоматически 4. Проверяем БД на ошибки su - zimbra /opt/zimbra/libexec/zmdbintegrityreport -r
3.
Database errors found. /opt/zimbra/mysql/bin/mysqlcheck --defaults-file=/opt/zimbra/conf/my.cnf -S /opt/zimbra/db/mysql.sock -A -C -s -u root --password=XXXXXXXX mboxgroup100.revision_dumpster Error : Incorrect information in file: './mboxgroup100/revision_dumpster.frm' error : Corrupt mboxgroup19.mail_item_dumpster Error : Incorrect information in file: './mboxgroup19/mail_item_dumpster.frm' error : Corrupt
Повреждение базы данных после сбоя, плохо. Нам поможет то, что все эти таблицы, находящиеся в разных mboxgroup – одинаковы.
1. Останавливаем zimbra 2. Переходим в каталог БД cd /opt/zimbra/db/data 3. Копируем файлы frm вместо поврежденных из другого каталога mboxgroup. Например: cp mboxgroup1/revision_dumpster.frm mboxgroup100/ cp mboxgroup1/mail_item_dumpster.frm mboxgroup19/ 3. Стартуем zimbra 4. Проверяем БД на ошибки su - zimbra /opt/zimbra/libexec/zmdbintegrityreport -r
Не коллекционируйте ошибки… избавьтесь от них!
Огромное спасибо, пофиксил сразу две ошибки =)
Примите и от меня благодарность, для меня статья была актуальна…
Спасибо!
По невнимательности словил первые две ошибки.
http://vitich.kiev.ua/migratsiya-zimbra-ocs-6-32bit-centos-58-na-zimbra-ocs-7-64bit-oracle-linux-65
Здравствуйте.
Можете что-нибудь посоветовать как решить такую проблему:
[root@mail log]# /opt/zimbra/libexec/zmdbintegrityreport
Database errors found.
/opt/zimbra/mysql/bin/mysqlcheck –defaults-file=/opt/zimbra/conf/my.cnf -S /opt/zimbra/db/mysql.sock -A -C -s -u root –password=XXXXXXXX
mboxgroup24.mail_item
Warning : InnoDB: The B-tree of index “PRIMARY” is corrupted.
Warning : InnoDB: Index “i_name_folder_id” is marked as corrupted
Warning : InnoDB: Index “i_type” is marked as corrupted
Warning : InnoDB: Index “i_parent_id” is marked as corrupted
Warning : InnoDB: Index “i_folder_id_date” is marked as corrupted
Warning : InnoDB: Index “i_index_id” is marked as corrupted
Warning : InnoDB: Index “i_date” is marked as corrupted
Warning : InnoDB: Index “i_mod_metadata” is marked as corrupted
Warning : InnoDB: Index “i_uuid” is marked as corrupted
error : Corrupt
mboxgroup75.tagged_item
Warning : InnoDB: Index “fk_tagged_item_item” is marked as corrupted
error : Corrupt
mboxgroup89.mail_item
Warning : InnoDB: Index “i_name_folder_id” is marked as corrupted
Warning : InnoDB: Index “i_type” is marked as corrupted
Warning : InnoDB: Index “i_parent_id” is marked as corrupted
Warning : InnoDB: Index “i_folder_id_date” is marked as corrupted
Warning : InnoDB: Index “i_index_id” is marked as corrupted
Warning : InnoDB: Index “i_date” is marked as corrupted
Warning : InnoDB: Index “i_mod_metadata” is marked as corrupted
Warning : InnoDB: Index “i_uuid” is marked as corrupted
error : Corrupt
mboxgroup95.mail_item
Warning : InnoDB: Index “i_name_folder_id” is marked as corrupted
Warning : InnoDB: Index “i_type” is marked as corrupted
Warning : InnoDB: Index “i_parent_id” is marked as corrupted
Warning : InnoDB: Index “i_index_id” is marked as corrupted
Warning : InnoDB: Index “i_date” is marked as corrupted
Warning : InnoDB: Index “i_mod_metadata” is marked as corrupted
error : Corrupt
[root@mail log]# /opt/zimbra/libexec/zmdbintegrityreport -r
Database errors found.
/opt/zimbra/mysql/bin/mysqlcheck –defaults-file=/opt/zimbra/conf/my.cnf -S /opt/zimbra/db/mysql.sock -A -C -s -u root –auto-repair –password=XXXXXXXX
…
(same from previous post)
…
mboxgroup24.mail_item
note : The storage engine for the table doesn’t support repair
mboxgroup75.tagged_item
note : The storage engine for the table doesn’t support repair
mboxgroup89.mail_item
note : The storage engine for the table doesn’t support repair
mboxgroup95.mail_item
note : The storage engine for the table doesn’t support repair
Имеет ли смысл попробовать сделать это: https://wiki.zimbra.com/wiki/Mysql_Crash_Recovery
или не поможет?
[zimbra@mail ~]$ zmcontrol -v
Release 8.6.0_GA_1153.RHEL6_64_20141215151155 RHEL6_64 FOSS edition, Patch 8.6.0_P4.
Сперва – резервное копирование, а то…
Потом попробуйте сделать “OPTIMIZE TABLE …”, может помочь.
Поясните пожалуйста про «OPTIMIZE TABLE …». Я очень поверхностно знаком с СУБД.
Работаем от пользователя zimbra:
su - zimbra
Для битой таблицы выполняем оптимизацию, например так:
mysql -e 'use mboxgroup24; optimize table mail_item;'
Не забываем про главное – резервное копирование!
По результату не забудь отписаться… всем полезно.
[zimbra@mail ~]$ mysql -e ‘use mboxgroup24; optimize table mail_item;’
+———————–+———-+———-+——————————————————————-+
| Table | Op | Msg_type | Msg_text |
+———————–+———-+———-+——————————————————————-+
| mboxgroup24.mail_item | optimize | note | Table does not support optimize, doing recreate + analyze instead |
| mboxgroup24.mail_item | optimize | status | OK |
+———————–+———-+———-+——————————————————————-+
[zimbra@mail ~]$
[zimbra@mail ~]$ mysql -e ‘use mboxgroup89; optimize table mail_item;’
+———————–+———-+———-+——————————————————————-+
| Table | Op | Msg_type | Msg_text |
+———————–+———-+———-+——————————————————————-+
| mboxgroup89.mail_item | optimize | note | Table does not support optimize, doing recreate + analyze instead |
| mboxgroup89.mail_item | optimize | status | OK |
+———————–+———-+———-+——————————————————————-+
[zimbra@mail ~]$ mysql -e ‘use mboxgroup95; optimize table mail_item;’
+———————–+———-+———-+——————————————————————-+
| Table | Op | Msg_type | Msg_text |
+———————–+———-+———-+——————————————————————-+
| mboxgroup95.mail_item | optimize | note | Table does not support optimize, doing recreate + analyze instead |
| mboxgroup95.mail_item | optimize | status | OK |
+———————–+———-+———-+——————————————————————-+
[zimbra@mail ~]$ mysql -e ‘use mboxgroup75; optimize table tagged_item;’
+————————-+———-+———-+——————————————————————-+
| Table | Op | Msg_type | Msg_text |
+————————-+———-+———-+——————————————————————-+
| mboxgroup75.tagged_item | optimize | note | Table does not support optimize, doing recreate + analyze instead |
| mboxgroup75.tagged_item | optimize | status | OK |
+————————-+———-+———-+——————————————————————-+
После этого ошибки исчезли:
[zimbra@mail ~]$ /opt/zimbra/libexec/zmdbintegrityreport
[zimbra@mail ~]$
Однако, например, фантомные письма, которых нет в почтовых ящиках, остались.
Можете подсказать как их почистить в почтовых ящиках?
Попробуйте сделать переиндексацию почтовых ящиков
Здравствуйте.
Спасибо за помощь в устранении ошибок БД.
Из админки вручную поставил на переиндексацию ящик с фантомными письмами.
Можно ли запустить такую процедуру массово на все почтовые ящики?
Поиск по инету выдал: https://wiki.zimbra.com/wiki/Glenno-Notes
% for i in `zmprov -l gaa example.com`; do echo "rim $i start" >> /tmp/rim_start.txt; done
% zmprov -f /tmp/rim_start.txt
Попробовал сделать переиндексацию двух ящиков с фантомными письмами – к сожалению, не помогло.
В случае когда письмо находится в созданной пользователем папке проблема решается простым пересозданием папки (создание временной папки-перемещение всех писем в нее-удаление исходной папки-создание исходной папки-возвращение перемещенных писем-удаление временной папки).
Но у меня есть случаи, где фантомы сидят в системных папках, таких как Входящие и Спам, которые нельзя удалить.
Что еще можно попробовать?
А как они выглядят эти “фантомы”, что под этим подразумеваете?
Папка “Спам” пуста, но в ее статусе отображается, что имеется 1 непрочитанное сообщение:
http://s019.radikal.ru/i629/1511/6e/58c1b1d4194d.png
А, теперь понятно, надо просто письма посчитать:
% zmprov rmc {emailaddress}
% zmprov fc -a {emailaddress}
Первая команда RecalculateMailboxCounts – “Когда количество непрочитанных сообщений и/или использование квоты не синхронизированы с данными в почтовом ящике, используйте эту команду, чтобы немедленно пересчитать квотирование почтовых ящиков и пересчитать непрочитанные сообщения. Замечение: Пересчет квот почтового ящика и количества сообщений должно быть запланировано для запуска в часы минимальной нагрузки и используется для одного почтового ящика одновременно.”
Первая команда flushCache – и так понятно, что чистит кеш.
По аналогии с переиндексацией всех ящиков можно попробовать:
% for i in `zmprov -l gaa example.com`; do echo "rmc $i" >> /tmp/rс_start.txt; echo "fc $i" >> /tmp/rс_start.txt; done
% zmprov -f /tmp/rс_start.txt
Написал, но не запускал…
[zimbra@mail root]$ zmprov rmc test@domain.ru
account: test@domain.ru
quotaUsed: 542774007
[zimbra@mail root]$ zmprov fc -a test@domain.ru
ERROR: service.INVALID_REQUEST (invalid request: unknown cache type: test@domain.ru)
[zimbra@mail root]$
zmprov fc account test@domain.ruВы знаете, попробовал первую приведенную вами команду на 5-6 ящиках – помогло. Фантомные письма после перезахода в ящик исчезли.
Спасибо Вам огромное за помощь!
Незачто, обращайтесь!
Надо ли все равно выполнять команду zmprov fc account …?
Если делать на все учётки через цикл, то разницы нет, я бы сделал (у нас более 1500 ящиков). Если ручками, то можете не делать.
Сделал так:
% for i in `zmprov -l gaa domain.ru`; do echo “rmc $i” >> /tmp/rс_start.txt; echo “fc account $i” >> /tmp/rс_start.txt; done
% zmprov -f /tmp/rс_start.txt
Еще раз большое спасибо за решение проблем!
Кстати, после исправления ошибок базы данных исчезла также ранее имеющаяся следующая проблема:
Периодически на почтовый ящик админа сервера приходят вот такие сообщения:
Oct 21 07:24:40 mail zmconfigd[20269]: Service status change: mail…. mailbox changed from running to stopped
и по истечению 1 минуты вот такие:
Oct 21 07:25:42 mail zmconfigd[20269]: Service status change: mail…. mailbox changed from stopped to running
Вот что показывает системный лог почтовика (zimbra.log):
Oct 21 07:23:38 mail zmconfigd[20269]: Fetching All configs
Oct 21 07:23:38 mail zmconfigd[20269]: All configs fetched in 0.05 seconds
Oct 21 07:23:39 mail zmconfigd[20269]: Watchdog: service antivirus status is OK.
Oct 21 07:23:39 mail zmconfigd[20269]: All rewrite threads completed in 0.00 sec
Oct 21 07:23:39 mail zmconfigd[20269]: All restarts completed in 0.00 sec
Oct 21 07:24:39 mail zmconfigd[20269]: Fetching All configs
Oct 21 07:24:40 mail zmconfigd[20269]: All configs fetched in 0.21 seconds
Oct 21 07:24:40 mail zmconfigd[20269]: Executed: /opt/zimbra/bin/zmstorectl status norewrite returned 1 (29 – 13) (0.06 sec)
Oct 21 07:24:40 mail zmconfigd[20269]: Service status change: mail…. mailbox changed from running to stopped
Oct 21 07:24:42 mail zmconfigd[20269]: Watchdog: service antivirus status is OK.
Oct 21 07:24:42 mail zmconfigd[20269]: All rewrite threads completed in 0.00 sec
Oct 21 07:24:42 mail zmconfigd[20269]: All restarts completed in 0.00 sec
Oct 21 07:25:42 mail zmconfigd[20269]: Fetching All configs
Oct 21 07:25:42 mail zmconfigd[20269]: All configs fetched in 0.05 seconds
Oct 21 07:25:42 mail zmconfigd[20269]: Service status change: mail…. mailbox changed from stopped to running
Oct 21 07:25:43 mail zmconfigd[20269]: Watchdog: service antivirus status is OK.
Oct 21 07:25:43 mail zmconfigd[20269]: All rewrite threads completed in 0.00 sec
Oct 21 07:25:43 mail zmconfigd[20269]: All restarts completed in 0.00 sec
Oct 21 07:26:43 mail zmconfigd[20269]: Fetching All configs
Oct 21 07:26:44 mail zmconfigd[20269]: All configs fetched in 0.05 seconds
Oct 21 07:26:45 mail zmconfigd[20269]: Watchdog: service antivirus status is OK.
Oct 21 07:26:45 mail zmconfigd[20269]: All rewrite threads completed in 0.00 sec
Oct 21 07:26:45 mail zmconfigd[20269]: All restarts completed in 0.00 sec
Подскажите с чем связана в вот такая ошибка. Укажите направление…
smtpd (total: 297)
288 database /opt/zimbra/conf/client_access.lmdb is older than sour…
Пока ничего не скажу. Можете дать информации побольше?
Эта ошибка в отчёте приходит, где смотреть больше инфы в логах?
Выдает ли ошибки проверка БД:
su - zimbra/opt/zimbra/libexec/zmdbintegrityreport -r
Добрый день, было аварийное выключение сервера, после чего появилась куча ошибок. В один из ящиков не заходит, почту из его восстановили и думал его просто удалить, но при попытке удалить ошибка – Сообщение: no such mailbox: 30 Код ошибки: mail.NO_SUCH_MBOX Method: [unknown] Детали:soap:Sender.
При попытке проверить БД на ошибки командой /opt/zimbra/libexec/zmdbintegrityreport -r
ошибка –
/opt/zimbra/mysql/bin/mysqlcheck: Got error: 2013: Lost connection to MySQL server during query when executing ‘CHECK TABLE … CHANGED’
command failed
И самое главное, не стартует служба zmamavisdctl ошибка – Starting amavisd…No listen sockets or ports specified
failed.
С включенной этой службой почта не ходит, а с выключенной куча спама у пользователей. Подскажите с чего начать?
Как общее состояние сервера? Разделы, файловая система, свободное место на дисках?
Ну и на что он ругается в логах, начинать можно с первой ошибки в логах при рестарте сервера.
Да, были ошибки и на файловой, вроде все удалось исправить, и получилось накатить обновление, с 8.0.6 (вроде была) до 8.6.0. Из базы удалил злосчастный 30-ый ящик и обновление прошло, после чего смог его удалить и в админке, служба антивируса и антиспама так же запустилась, и все бы нечего если как всегда не одно но… Сервер очень сильно нагружается java, иногда под 80%, не пойму, что не так(
80% это не показатель, надо знать мощность сервера и нагрузку на него:
Какой у вас CPU и сколько ядер, сколько памяти, сколько ящиков на сервере и сколько писем в сутки (в среднем по ежедневным отчетам)?
Загрузка вроде уже в норме, видимо индексация ящиков грузила, почему-то думал, что не запустилась она. А, вот службы антиспама и антивируса хоть и запущены, но спама куча и в мониторенге количество писем обработанных системой AV/AS = 0 за последние 48 часов. Как проверить работу данных служб?
1. Проверить настройки уровней спам-фильтров;
2. Смотреть спам-рейтинг писем, если рейтинга (баллов) нет, то фильтр точно не работает;
3. Читать логи.
Zimbra: фильтруем спам
Мониторинг обновляется не в реальном времени…
Благодарю, очень полезная статья, я немного не так понял значимость настроек, по проценту удаления и пометок, и завысил получается рейтинг писем для удаления. Рейтинг проставляется, буду наблюдать тогда за работой сервера. Еще раз Спасибо!