в верхней части страницы, чтобы произвести архивирование.28
Для предотвращения потери данных необходимо регулярно производить резервное копирование БД с помощью штатных средств сервера БД (см. документацию к используемой БД). Рекомендуется создавать резервные копии БД перед всеми нетривиальными операциями с базой (архивация таблиц списаний, прямое обращение к базе вручную, отладка скриптов urfaclient и т. п.), а также на регулярной основе, как минимум раз в месяц.
Существуют два вида резервных копий: краткая и полная. В полную входят все таблицы БД, в краткую – все, кроме таблиц со списаниями. В связи с большим объемом таблиц со списаниями создание полной копии может занимать длительное время. При проведении этой процедуры рекомендуется останавливать ядро UTM5. В противном случае длительная блокировка таблиц может привести к аварийному завершению работы ядра.
Для крупных проектов, когда таблицы особенно велики и в то же время длительный простой биллинговой системы крайне нежелателен, рекомендуется использовать slave-сервер БД, с помощью которого можно создать резервную копию, не останавливая биллинг.
При загрузке ядра UTM5 одновременно с заполнением системного кэша происходит верификация базы данных. Найденные несоответствия в отношении кэшируемых данных устраняются автоматически. Эти же данные, но содержащиеся в базе, должны быть исправлены вручную с использованием информации из log-файла верификатора.
Директория хранения log-файла верификатора определяется значением системного параметра log_file_verificator (по умолчанию /netup/log/verificator.log). Для каждого несоответствия приводятся:
–описание ошибки с указанием её уровня (ERROR или WARNING);
–предполагаемые действия по устранению ошибки;
–команда SQL (если требуется), эквивалентная автоматическому исправлению, которое было применено к данным в кэше:
|
-- WARNING slink 4876 exists only in dtagg_periodic |
|
-- SQL DESC check slink exists and delete dtagg_periodic entry for deleted slink |
|
UPDATE dtagg_periodic SET is_closed=1 WHERE slink_id=4876; |
|
|
Объекты, перечисленные в verificator.log , не загружаются системой, не учитываются при тарификации и не отображаются в интерфейсе администратора. |
Перед исправлением ошибок рекомендуется остановить ядро UTM5 и создать резервную копию базы данных (по крайней мере, таблиц, задействованных в исправлении).
В простейшем случае исправление сводится к подаче log-файла верификатора на вход MySQL:
|
mysql UTM5 < /netup/utm5/log/verificator.log |
Следует учесть, что некоторые SQL-запросы в log-файле по умолчанию закомментированы, так как их непосредственное применение может привести к потере данных. При наличии таких запросов следует проверять каждый случай по отдельности.
Архивирование применяется к некоторым наиболее быстро растущим таблицам с целью снизить накладные расходы на операции вставки. В ходе архивирования таблица переносится (переименовывается) в архивную, и одновременно создаётся пустая (текущая) таблица с тем же названием и той же структурой для вновь поступающих данных. Операция может применяться периодически по мере роста таблиц. Ограничения описаны ниже.
В настоящий момент механизм архивирования распространяет свое действие на следующие таблицы:
|
Таблица |
Тип |
Название поля даты |
|
1 |
||
|
2 |
||
|
3 |
||
|
4 |
|
|
|
5 |
||
|
6 |
|
|
|
7 |
||
|
8 |
||
|
9 |
||
|
10 |
||
|
11 |
|
|
|
12 |
|
Чтобы произвести архивирование таблиц:
1.Подключитесь к UTM5 через интерфейс администратора.
2.Перейдите на страницу Архивирование БД в группе страниц Настройки.
3.Нажмите в верхней части страницы, чтобы произвести архивирование.
Архивирование можно производить не чаще одного раза в 28 дней. Если кнопка 
не активна, значит с момента предыдущего архивирования прошло менее 28 дней.
Если необходимо производить архивирование чаще, чем это позволяет делать интерфейс администратора, воспользуйтесь утилитой db_archiver (см. Утилита db_archiver).