Данная инструкция подходит для установок, использующих СУБД MySQL.

Введение

Приложение RITM.LINK (может использоваться как отдельно, так и в составе GEO.RITM SE) имеет собственную БД. В ней хранятся временные данные, которые поступают от объектовых приборов. Данные нужно сохранять до момента передачи (трансляции) в другое ПО - GEO.RITM или стороннее ПО по протоколам Surgard, EGTS и т.п. Период хранения регулируется параметром ru.ritm.idp.history.depth.days со значением в сутках. Все принятые от приборов данные со датой принятия больше заданного периода - удаляются. Сравнивается именно дата принятия сервером, а не дата формирования события на приборе.

Изменение параметра ru.ritm.idp.history.depth.days применяется после перезапуска RITM.LINK.


Отличия для стационарных и мобильных объектов

Для стационарных объектов (охрана недвижимости - Контакт, Мега) нет смысла долго хранить временные данные в БД idp. Для лучшего быстродействия рекомендуется значение параметра ru.ritm.idp.history.depth.days указывать в диапазоне 1-7. Трансляция происходит почти мгновенно и данные в БД idp могут пригодиться только для просмотра событий в интерфейсе idp.

Рекомендуем ограничивать количество событий по разделу до снятия с охраны. Настраивается на странице "Разделы" программы настройки прибора. Это позволит сэкономить GSM трафик, уменьшить размер БД RITM.LINK и GEO.RITM, уменьшить нагрузку на серверное ПО, уменьшить нагрузку на оперативных дежурных.

Для мобильных объектов (Voyager) можно хранить данные и дольше 7 дней. Дело в том, что данные по мобильным объектом можно удалить из GEO.RITM и запросить в RITM.LINK заново. Данная процедура важна в том случае, если "Автоматическая настройка фильтров" (см. стр. 49) не подходит для вашего объекта и вы перенастраиваете фильтры. Затем выбираете дату, начиная с которой данные в GEO.RITM будут удалены и запрошены повторно из RITM.LINK.

В момент запуска пересчёта важно знать какой период хранятся данные в RITM.LINK. Можно запустить пересчёт и данные из GEO.RITM будут удалены, а из RITM.LINK импортировать будет уже нечего. Рекомендуется значение параметра ru.ritm.idp.history.depth.days указывать в диапазоне 1-30. Но при малом значении нужно следить за треками объекта - если они не удовлетворительные, то пересчитать с новыми фильтрами вы сможете только за малый период времени.

Рекомендуем ограничивать набор данных, записываемые в историю прибора и  передаваемые прибором на сервер. Отключайте не используемые данные. Настраивается на странице "Состав истории" программы настройки прибора. Это позволит сэкономить GSM трафик, уменьшить размер БД RITM.LINK и GEO.RITM, уменьшить нагрузку на серверное ПО.

Процедура пересчёта создаёт сильные нагрузки на сервер БД. Без необходимости не нужно запускать пересчёт.


Очистка БД idp

Если заранее корректно не настроить параметр ru.ritm.idp.history.depth.days, то размер БД idp может превысить оптимальный размер для вашего сервера. В таком случае на диске может закончиться место или скорость работы сервера может замедлиться. Решение - удаление таблиц БД с временной историей, но сохранение таблиц БД с настройками потоков. Для этого:

  • Авторизуйтесь в Linux ВМ GEO.RITM SE (RITM.LINK);

    Имя пользователя и пароль по умолчанию

    admin

    masterkey


  • Для Oracle Linux - создайте файл /root/clear_idp_db.sh с таким содержимым
#!/bin/bash
HOST=localhost
DB_FILE=idp_${HOST}.sql
USER=root
PASSWORD=masterkey
DATABASE=idp
EXCLUDED_TABLES=(
dump_info
last_packets
packet_dumps
sessions
session_cache
deffered_commands
firmware_objects
objects
)

IGNORED_TABLES_STRING=''
for TABLE in "${EXCLUDED_TABLES[@]}"
do :
   IGNORED_TABLES_STRING+=" --ignore-table=${DATABASE}.${TABLE}"
done

rm -f ${DB_FILE}

cd /root/

kill -9 $(pidof java)

# echo "Dump structure"
mysqldump --host=${HOST} --user=${USER} --password=${PASSWORD} --single-transaction --no-data --routines ${DATABASE} > ${DB_FILE}

# echo "Dump content"
mysqldump --host=${HOST} --user=${USER} --password=${PASSWORD} ${DATABASE} --no-create-info --skip-triggers ${IGNORED_TABLES_STRING} >> ${DB_FILE}

mysql -hlocalhost -uroot -pmasterkey -Bse "DROP DATABASE IF EXISTS idp;"
mysql -hlocalhost -uroot -pmasterkey -Bse "CREATE DATABASE idp;"
mysql -hlocalhost -uroot -pmasterkey ${DATABASE} < ${DB_FILE}

/opt/payara41/glassfish/bin/asadmin start-domain
  • Для Astra Linux - создайте файл /root/clear_idp_db.sh с таким содержимым
#!/bin/bash
HOST=localhost
DB_FILE=idp_${HOST}.sql
USER=root
PASSWORD=masterkey
DATABASE=idp
EXCLUDED_TABLES=(
dump_info
last_packets
packet_dumps
sessions
session_cache
deffered_commands
firmware_objects
objects
)

IGNORED_TABLES_STRING=''
for TABLE in "${EXCLUDED_TABLES[@]}"
do :
   IGNORED_TABLES_STRING+=" --ignore-table=${DATABASE}.${TABLE}"
done

rm -f ${DB_FILE}

cd /root/
systemctl stop payara
kill -9 $(pidof java)

# echo "Dump structure"
mysqldump --host=${HOST} --user=${USER} --password=${PASSWORD} --single-transaction --no-data --routines ${DATABASE} > ${DB_FILE}

# echo "Dump content"
mysqldump --host=${HOST} --user=${USER} --password=${PASSWORD} ${DATABASE} --no-create-info --skip-triggers ${IGNORED_TABLES_STRING} >> ${DB_FILE}

mysql -hlocalhost -uroot -pmasterkey -Bse "DROP DATABASE IF EXISTS idp;"
mysql -hlocalhost -uroot -pmasterkey -Bse "CREATE DATABASE idp;"
mysql -hlocalhost -uroot -pmasterkey ${DATABASE} < ${DB_FILE}

systemctl start payara
  • При необходимости измените пароль подключения к БД, адрес БД и название БД;
  • Выполните
cd /root
chmod +x /root/clear_idp_db.sh
./clear_idp_db.sh

Скрипт остановит payara, создаст резервную копию БД idp без "тяжёлых" таблиц, удалит БД idp, создаст БД idp и восстановит её из резервной копии.