BackUp тупит система

[Nafanya]

При работе скрипта система практически зависает. Нельзя перейти на другую страницу. Инет начинает тупить. Кто работает по РРРоЕ сессии отваливаются. Если делать снимки базы каждые 8 часов, то у людей происходит перерегистрация.
Что может быть? Подскажите.
команда:

/bin/sh /root/backup_nodeny.sh

Скрипт:

#!/bin/sh
PATH=/etc:/bin:/sbin:/usr/bin:/usr/sbin
passwd='hardpass'
mysql_cmd='/usr/local/bin/mysql'
mysqldump_cmd='/usr/local/bin/mysqldump'

file=`date "+%H-%M-%d-%h-%Y"`
cd /var/backups/nodeny/
echo show tables | $mysql_cmd -u root --password=$passwd nodeny | \
    grep -v '^[ZX]2' | grep -v 'traflost' | grep -v '^Tables' | \
    xargs $mysqldump_cmd -R -Q --add-locks -u root --password=$passwd nodeny $1 > nodeny_${file}.sql
tar -c -z -f ${file}.tar.gz nodeny_${file}.sql
rm -f nodeny_${file}.sql
chmod 400 ${file}.tar.gz

find . -name "*.tar.gz" -mtime +5 -type f -delete

ntfs-3g /dev/da0p2 /backup

cd /backup/

cp /var/backups/nodeny/${file}.tar.gz /backup/
find . -name "*.tar.gz" -mtime +5 -type f -delete

система

FreeBSD 11.3-STABLE на amd64

[elite]

делать репликацию, а с нее бэкап

[Cell]

Нужно посмотреть что там в базе имеет такой размер что надолго лочит таблицу.
Чуйка мне подсказывает что это auth_log.  Эта таблица иногда достигает гигантских размеров измеряемых в гигабайтах.
Если это так - то нужно ее просто удалить

Код:

drop table auth_log;

и создать заново взяв структуру из bill.sql

Код:

CREATE TABLE `auth_log` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `uid` int(10) unsigned NOT NULL DEFAULT '0',
  `ip` int(10) unsigned NOT NULL DEFAULT '0',
  `start` int(10) unsigned NOT NULL DEFAULT '0',
  `end` int(10) unsigned NOT NULL DEFAULT '0',
  `properties` text NOT NULL,
  PRIMARY KEY (`id`),
  KEY `uid` (`uid`),
  KEY `start` (`start`),
  KEY `last` (`end`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8;

После этого проверирть как работает бэкап.
еще большой размер может иметь таблица pays но с ней такой фокус провернуть нельзя т.к. данные в этой таблице важны.

[Redmen]

Нужно посмотреть что там в базе имеет такой размер что надолго лочит таблицу.
Чуйка мне подсказывает что это auth_log.  Эта таблица иногда достигает гигантских размеров измеряемых в гигабайтах.
Если это так - то нужно ее просто удалить

Мы просто ее чистим, удаляя все старше 3 лет, + есть идея очистки от коротких авторизаций, пока не реализовал(

[cojiict]

Нужно посмотреть что там в базе имеет такой размер что надолго лочит таблицу.
Чуйка мне подсказывает что это auth_log.  Эта таблица иногда достигает гигантских размеров измеряемых в гигабайтах.
Если это так - то нужно ее просто удалить

Код:

drop table auth_log;

и создать заново взяв структуру из bill.sql

Код:

CREATE TABLE `auth_log` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `uid` int(10) unsigned NOT NULL DEFAULT '0',
  `ip` int(10) unsigned NOT NULL DEFAULT '0',
  `start` int(10) unsigned NOT NULL DEFAULT '0',
  `end` int(10) unsigned NOT NULL DEFAULT '0',
  `properties` text NOT NULL,
  PRIMARY KEY (`id`),
  KEY `uid` (`uid`),
  KEY `start` (`start`),
  KEY `last` (`end`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8;

После этого проверирть как работает бэкап.
еще большой размер может иметь таблица pays но с ней такой фокус провернуть нельзя т.к. данные в этой таблице важны.

Код:

 nodeny             | changes                                              |      31.58 |
| nodeny             | ip_pool                                              |      33.56 |
| nodeny             | pays                                                 |     165.17 |
| nodeny             | auth_log                                             |     635.97 |
| nodeny             | snmptraps                                            |   43557.00 |
+--------------------+------------------------------------------------------+------------+

А як на рахунок snmptraps. Нічого не знайшов в документації до Nodeny.
Користуємось модулем snmp для отримання інформації по портах обладнання, їх включенні і виключені, а от до чого тут trap і чи можна його дропнути без наслідків?

[Cell]

думаю можно, но сделав предварительно бекап! )

[Nafanya]

Нужно посмотреть что там в базе имеет такой размер что надолго лочит таблицу.
Чуйка мне подсказывает что это auth_log.  Эта таблица иногда достигает гигантских размеров измеряемых в гигабайтах.
Если это так - то нужно ее просто удалить

Код:

drop table auth_log;

и создать заново взяв структуру из bill.sql

Код:

CREATE TABLE `auth_log` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `uid` int(10) unsigned NOT NULL DEFAULT '0',
  `ip` int(10) unsigned NOT NULL DEFAULT '0',
  `start` int(10) unsigned NOT NULL DEFAULT '0',
  `end` int(10) unsigned NOT NULL DEFAULT '0',
  `properties` text NOT NULL,
  PRIMARY KEY (`id`),
  KEY `uid` (`uid`),
  KEY `start` (`start`),
  KEY `last` (`end`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8;

После этого проверирть как работает бэкап.
еще большой размер может иметь таблица pays но с ней такой фокус провернуть нельзя т.к. данные в этой таблице важны.

| auth_log |       484.72 |

MB
Это много?

in MB |
+-------+--------------+
| pays  |        79.13 |
+-------+--------------+

[Cell]

Нет, это не много. Ну auth_log в любом случае хрень, которую удалить приятно ) а вот это

Код:

nodeny             | snmptraps                                            |   43557.00 |

43 гигабайта?   -- за  гранью добра и зла
ты просто попробуй 43 гигабайта скопировать с диска на диск не говоря про архивирование и все поймешь. Хороший выход исключить эту таблицу из бэкапа вовсе добавив в скрипт что-то типа:

Код:

| grep -v 'snmptraps' |

[Nafanya]

Table     | Size in MB |
+-----------+------------+
| snmptraps |       0.08 |

А вот вся база ?

| nodeny             |     6081.2 |

Конкретно посмотреть список не могу - слишком длинный.

[Cell]

Вся база не важна, там куча таблиц не бэкапится из-за ненадобности. Пробуй так как есть)
Думаю результат превысит все ожидания.

[Nafanya]

Table   Size in MB
admin   0.03
auth_log   0.31
auth_now   0.13
c_switch   0.00
cards   5.55
changes   2.72
config   1.43
data0   1.72
data1   0.11
datasetup   0.01
datasetup1   0.03
dictionary   0.01
documents   0.09
dopdata   
dopfields   0.00
dopvalues   0.48
fullusers   
ip_mac   0.03
ip_pool   0.70
links   0.02
mac_uid   0.13
monitor   0.00
nets   0.00
notifications   0.06
notifications_users   0.06
pays   79.13
paysystems_tokens   0.03
places   0.02
places_events   0.09
pon_bind   0.03
pon_fdb   0.02
pon_mon   0.05
pon_olt   0.05
pon_onu   0.03
pon_ports   0.03
ports   0.17
services   0.02
services_log   2.45
ses_traf   0.00
snmptraps   0.08
temp_ip_pool   0.02
traflost   0.00
user_grp   0.00
users   0.31
users_limit   0.02
users_services   0.41
users_trf   0.34
v_auth_now   
v_ips   
v_services   
webses_data   0.06
websessions   0.01
x2020_10_1   23.05

Размер всей базы

DB Name   DB Size in MB
nodeny   6988.3

Ну х-вые.  Они не архивируются. Не пойму - тормозит. Может сам мускул?
Вопрос, процедуры пересоздавать, при переезде на другой сервер? Это как бы заодно спросил.

[Cell]

Процедуры попадают в бэкап, не надо пересоздавать

[Efendy]

Чтобы снмп трапы не писались, не запускайте модуль ядра snmp_trap

[Nafanya]

Чтобы снмп трапы не писались, не запускайте модуль ядра snmp_trap

Да он как-бы и не запускается.

[Nafanya]

Появилось время и немного разобрался. У меня в архив уходят файлы Х и Z Раньше такого не было. Они там нужны? Какую роль они играют. Один - связан с трафиком, а второй?